LuaN1aoAgent v2: A Planner-Executor-Observer Pentest Agent Built on Graph Memory

The Problem: Pentest Conclusions That Cannot Be Audited

An autonomous agent that scans a target and then reports a finding is easy to build and hard to trust. The usual failure is not a wrong answer, it is an unaccountable one. The model's reasoning sits in a chat history that gets truncated, summarized, or discarded, and the operator is left holding a conclusion with no path back to the packet, response, or tool output that produced it. LuaN1aoAgent v2 is aimed at that gap. The README states the design principle directly: every important conclusion must remain traceable to persisted events, artifacts, and graph evidence. The intended user is not a hobbyist running a scanner against a random host. It is a security team doing authorized research who needs the agent's intermediate state to survive a session, be inspected after the fact, and be defended in a report. The project also carries a competition badge referencing a Tencent hackathon, which suggests the target audience includes research and demonstration settings as much as production red-team work. That framing matters, because the README is explicit that v2 is a new implementation rather than an in-place refactor of the Python v1 runtime, with different configuration, persistence, Agent lifecycle, and observability contracts.

Three Roles, Four Terminating Tools

The architecture splits responsibility across Planner, Executor, and Observer, and each role has a defined submission channel. The Planner reads compact task, reasoning, and operation graph views, then creates or patches goal-level tasks rather than prescribing low-level actions. It controls dependencies, priority, independent-task concurrency, scope, and task budgets, and it submits decisions through a structured terminating tool named planner_submit. The README notes that the Planner reconciles ready tasks against available capacity after graph changes and task handoffs, without waiting for an entire parallel wave to finish. The Executor receives a bounded TaskEnvelope, chooses its own tool strategy, and records public intent, tool input, tool output, usage, errors, and final results. Large outputs become immutable artifacts rather than context. It submits through task_result_submit. The Observer runs in two modes: a hot-path Supervisor that inspects recent Executor actions and decides whether to continue, checkpoint, stop, or return control to the Planner, and an asynchronous Projector that converts normalized observations into graph deltas. Each Observer invocation uses a fresh Pi session without sharing hidden model history, and the two modes submit through control_submit and graph_delta_submit. Four terminating tools, four write paths. If any one of them fails to persist, the traceability claim weakens at exactly that step. That is the first thing worth checking in a real deployment.

The Causal Graph: Evidence Before Vulnerability

The reasoning model is a directed chain from Evidence through Hypothesis to Vulnerability to Exploit, with a separate dashed relation from Evidence to WebEndpoint or Service entities in the Operation Graph. The README describes three properties. Reasoning nodes and edges preserve references to the events that support them. Hypotheses stay distinct from confirmed vulnerabilities and successful exploits. And confirmed Vulnerability nodes and successful Exploit nodes cannot be written without evidence references. That last constraint is the one with teeth: it is an enforced schema rule rather than a prompting convention, which means the graph can reject a conclusion the model would otherwise state. The trade-off is that the agent may stall or downgrade a real finding when the supporting evidence was not captured as an artifact, which is a plausible failure mode for noisy or non-deterministic tooling. The README does not describe a manual override path for that case. Cross-graph context is handled by linking reasoning conclusions to concrete entities in the Operation Graph, so a confirmed vulnerability points at the endpoint or service it was observed on.

Plan-on-Graph Instead of a Linear Checklist

The Planner maintains an evolving Task Graph rather than regenerating a linear plan. The README's diagram shows a Goal branching into a Recon Task and an Auth Task, with Recon producing a Service Profile milestone that feeds a Validation Task, and Auth also feeding that Validation Task, while a Blocker node marks a dependency that blocks it. The documented graph operations are create_tasks, patch_task, replace_dependencies, and set_task_status. This is a different bet from the plan-execute-reflect loop that the repository topics still reference. A regenerated checklist is simpler to implement and easier to reason about, but it loses the record of why a step existed once the plan is rewritten. A patched graph keeps that record, at the cost of a Planner that must reason about a mutating structure with dependencies, priorities, and budgets. Note the naming: the README lists these as structured graph operations, and the cleaned excerpt ends mid-list, so the full operation set is not confirmed here. Treat the four named operations as the documented minimum, not the complete surface.

Running It: Node.js 25+, Pi SDK, and What the README Does Not Give You

The badges set the floor: Node.js 25 or later, TypeScript 5.x, and the Pi SDK as the runtime. That is a high Node version to standardize on, and it is worth confirming your CI images and developer machines carry it before anything else. Beyond that, the supplied README is thin on setup. It has a Quick Start anchor in the navigation, but the cleaned excerpt does not include the Quick Start body, so no install command, no config file path, and no environment variable names can be quoted here with confidence. The configuration keys that are confirmed by the text are the terminating tool names: planner_submit, task_result_submit, control_submit, and graph_delta_submit. The confirmed runtime concepts are the TaskEnvelope passed to the Executor and the isolated workspace it runs in. The README also states that the Executor reuses the same persisted Pi session lineage and workspace across epochs of one Task, while different Tasks remain isolated. That is a real design commitment about state reuse, and it implies workspace directories that persist between epochs. Because the excerpt is truncated, treat the Quick Start section of the live README as required reading before you plan a deployment, and do not assume v1 configuration carries over. The README states plainly that v2 has different configuration, persistence, Agent lifecycle, and observability contracts.

The v1 Break and the Benchmark Gap

Two limitations are stated by the project itself, which is unusual and worth crediting. First, v2 is not an in-place refactor of the Python v1 runtime. Anyone running v1 has a migration, not an upgrade, and the README says the configuration, persistence, Agent lifecycle, and observability contracts all differ. That is a real cost measured in operator time, not just a version bump. Second, the README carries a note that benchmark results reported by v1 are not automatically attributed to v2, and that v2 benchmark results will be published only after reproducible reruns on a frozen release. This is the correct position to take, and it also means that as of this writing there is no v2 performance claim to evaluate. The release history supports the caution: v1.0.0 is labelled Legacy and v2.0.0 arrived the same day, 2026-07-20, with the last push to the repository on 2026-08-24. A rewrite of this scope landing in a single release cycle, followed by a month of active pushes, is a sign of ongoing change rather than a settled interface.

How This Differs From a Plain Plan-Execute-Reflect Loop

The repository topics still list plan-execute-reflect, and the README frames v2 as replacing the shared-history P-E-R loop with explicit runtime boundaries. The concrete difference is where state lives. In a shared-history loop, the Planner, the actor, and the critic read and write one conversation, so a conclusion and its justification are the same object and both are subject to truncation. Here, the Planner reads compact graph views, the Executor writes artifacts, and the Observer writes graph deltas from a fresh session that does not share hidden model history. The comparison to make is not against another named pentest agent, because the supplied material does not name one and inventing a rival would be guesswork. The comparison is against the loop pattern the project itself is moving away from. If your current setup is a scripted P-E-R agent where the transcript is the audit trail, the difference you would feel is that the transcript stops being the source of truth. The cost you would pay is a second persistence layer to operate and a graph schema that can refuse writes.

Licence and Maintenance: AGPL-3.0 on an Actively Rewritten Codebase

The licence is AGPL-3.0. That is a strong copyleft licence with a network-use clause, and it is the single constraint most likely to end an evaluation early. If you plan to run this as part of a hosted service, or to embed it in a product you distribute, the obligations attach in ways that permissive licences do not. This is not legal advice, and the specific question of whether your deployment triggers the network clause depends on facts about your service that only your counsel can assess. On maintenance, the material supports a limited but useful read. The last push is 2026-08-24, roughly a month after the v2.0.0 release on 2026-07-20, so the project is being touched. The v1.0.0 release is explicitly labelled Legacy the same day v2.0.0 shipped, which suggests the maintainers are not committing to long-term parallel support for the Python runtime. Anyone still on v1 should plan a migration rather than expect backports. What the material does not tell you is the size of the maintainer team, the cadence of releases after v2.0.0, or whether the graph schema is considered stable. Those are open questions, and the README's own note about publishing benchmarks only on a frozen release implies the authors do not yet consider the current state frozen.

Editorial conclusion

Adopt LuaN1aoAgent v2 if you already run authorized engagements and want the reasoning trail persisted as graph evidence rather than buried in model history, and if your team can absorb a TypeScript and Node.js 25+ runtime plus a full migration from the Python v1 configuration. Do not adopt it if you need a stable, in-place upgrade from v1, or if AGPL-3.0 obligations conflict with how you ship tooling. Before running anything, verify three things on a frozen release: that your model provider is reachable through the Pi SDK configuration you intend to use, that the workspace and artifact directories are writable outside your repository, and that the terminating tools (planner_submit, task_result_submit, control_submit, graph_delta_submit) are wired to the persistence layer you expect, because every traceability claim in the README depends on those four submission paths actually writing.

Official sources

1. Issues
2. License: AGPL-3.0
3. README
4. Releases
5. SanMuzZzZz/LuaN1aoAgent on GitHub