Checkpoint: One Engagement, Three Control Loops

PentAGI's value becomes easier to judge when the Flow hierarchy, adaptive plan, and unequal agent roles are followed through one engagement instead of discussed separately. Consider an authorized request to assess a web application within a defined target and produce a report of confirmed findings. The point is not to prescribe a universal pentest procedure; it is to see where state changes, where a plan changes, where an agent chooses an action, and where evidence is recorded. Those are three different loops that must cooperate without becoming one opaque model call.

One objective crosses three loops

The first loop is the state loop. The controller creates a Flow, prepares its provider and execution environment, accepts an input, creates a Task, and owns the Task's Subtasks. The Flow is the outer engagement record. The Task is the durable objective. Each Subtask is a bounded unit with a message chain and status. If the work runs, the status says so. If a question reaches the operator, the Subtask, Task, and Flow can become waiting. If the work finishes or fails, those outcomes move back through the hierarchy and remain available for reporting and review.

The second loop is the plan loop. The Generator turns the Task objective into an ordered set of Subtasks. Imagine the first planned unit is to establish the application's reachable surface and identify the next sensible validation target. After it runs, its result is not only a completed item. It is evidence about the assumptions behind the remaining queue. The Refiner may keep the queue, remove a planned item that no longer applies, or replace it with a more relevant one. The controller applies that change only at the boundary where the current Subtask has returned and the next planned item has not yet started.

The third loop is the execution loop. The Primary Agent receives the current Subtask and chooses among its typed functions. It might ask a Searcher to clarify a technology, send a focused question to the Pentester, ask the Coder for a small script, retrieve relevant memory, or call a barrier. The specialist executes within its own tool surface and returns a result. The executor records the call and its outcome, and the Primary Agent decides whether the result satisfies the current Subtask or changes its next action.

These loops overlap, but they are not interchangeable. The state loop answers where the engagement is. The plan loop answers what remains worth doing. The execution loop answers what action to take now. A model response can influence all three, but it does not own all three. The controller owns durable transitions; the Refiner proposes changes to future work; the Primary Agent selects actions inside the current unit.