The Plan Changes When the Evidence Changes
In PentAGI, planning is not a one-time preface to execution. The Task receives an objective, the Generator turns it into an ordered set of Subtasks, and the Refiner revisits what remains after each completed Subtask. This chapter explains that feedback mechanism and the boundary it creates: adaptive planning can respond to evidence that a fixed checklist would miss, but it also makes the path model-dependent and prevents anyone from treating the initial plan as a complete testing methodology.
The first plan is a bounded hypothesis about the work
A Task begins with a user objective, not with a ready-made implementation sequence. The Generator examines that objective and the surrounding Flow/Task context, then submits a structured list of Subtasks. Each Subtask has a title and description, and the Task worker stores those rows before execution begins. The descriptions are the bridge between a broad objective and a bounded action: they tell the Primary Agent what this particular unit is meant to accomplish without asking it to solve the entire engagement at once.
The Generator can also use supporting context rather than treating the input as an isolated sentence. Its executor has access to search and memory-oriented handlers, so the initial decomposition can be informed by earlier context and relevant knowledge when those sources are available. That does not make retrieved knowledge authoritative. It means the plan is produced from a wider working set: the current objective, existing Task/Subtask state, and selected context. An operator should still distinguish a useful prior pattern from evidence about the present target.
This decomposition does two things at the same time. It reduces cognitive scope for the agent that will execute the work, and it gives the controller a queue that can be observed and changed. A plan such as “assess the authorized web application” is too broad to tell a worker whether it should be mapping routes, checking authentication, validating an input hypothesis, or preparing a report. A set of narrower objectives makes progress visible. The point is not to produce a long checklist. The Generator is instructed to create a minimal sequence of non-overlapping steps, so the plan should be large enough to cover the objective but small enough to revise without creating an administrative burden.
The implementation caps a Task at TasksNumberLimit = 15. That limit is best understood as a resource and convergence boundary, not as a claim that fifteen steps are enough for every penetration test. It constrains how much work the Task can hold in its adaptive queue and helps prevent a model from responding to uncertainty by generating an endless taxonomy of possible checks. It does not prove that the target was covered. A short plan can be efficient because the objective is narrow, or incomplete because the Generator missed an important path. The number protects the execution loop; it cannot substitute for engagement scope or a human methodology.
The Task worker executes the queue sequentially at the outer level. It asks for the next planned Subtask, runs it, then decides whether the Task is waiting, whether the Subtask failed, or whether refinement should happen before the next step. Internal work inside a Subtask may involve several model calls, specialist delegations, searches, and terminal actions. “Sequential” therefore describes the plan-control loop, not every operation that occurs inside one step. This distinction prevents a common misunderstanding: adaptive planning does not mean all agent actions are globally serialized, nor does it mean the system has a parallel campaign scheduler.
The diagram's key relationship is the return arrow from execution to refinement. The result of a Subtask is not merely an output for a final report; it is information about whether the remaining plan still makes sense.
Refinement turns results into planning information
Suppose a reconnaissance-oriented Subtask reveals that a presumed web surface is not reachable, while a different service exposes an authenticated endpoint. A static plan can record the surprise and continue with steps designed for the original assumption. PentAGI's Refiner has another option: review the completed result and the remaining planned work, remove steps that no longer apply, add steps aimed at the newly relevant surface, or modify a step whose assumptions have changed.
That feedback is not automatic intelligence floating above the database. The Refiner is another agent chain with a defined executor and a typed patch operation. It receives the Task context, the planned and completed Subtasks, and—when useful—the summarized execution state and logs. Its patch is validated before the controller applies it. The controller then identifies the Subtasks that are still merely planned, deletes those rows, invalidates corresponding in-memory workers, and creates replacement rows from the revised plan. Completed work is not silently rewritten as though it never happened.
The distinction between planned and completed rows is the semantic center of refinement. A planned item is a proposal about future work; a completed item is part of the engagement record. The Refiner can replace the former because it is revising a hypothesis. It should not erase the latter merely because the result was inconvenient or a new route became more interesting. New rows may receive new database identities, but that identity change is a consequence of rebuilding the remaining queue, not a rewriting of history.
That last property matters for accountability. A plan is allowed to change because new evidence changes what is relevant; the record of completed work remains part of the engagement. The system can therefore distinguish “this step was completed and later became irrelevant” from “this step was never performed.” The distinction is operationally important when a reviewer asks why a proposed check disappeared or why the final report does not discuss an item that appeared in the initial plan.
The patch boundary also prevents a conversational Assistant from changing a live execution path indiscriminately. Flow-management handlers refuse to patch planned Subtasks while a Task is running. The Refiner's own path occurs at the point the Task worker expects it: after a Subtask returns and before the next planned step is popped. This is a modest but important form of synchronization. An LLM can propose a different plan, but the controller decides when that proposal is legally applied to the running state.
The same design explains why stale-worker invalidation is necessary. A controller can hold an in-memory worker for a planned Subtask that has just been deleted and replaced in the database. If that old object remained usable, a later shutdown or status update could address a row that no longer exists. Invalidating it is not a model-quality feature; it is a consistency repair between the LLM-facing plan and the database-backed worker cache. Adaptive planning is only safe enough to use when both layers change together.
Refinement is still bounded. The available number of new planned steps is calculated from the Task's completed work, so the Refiner cannot grow the Task without limit. If no more Subtasks are needed, the refinement result can be empty and the Task moves toward its Reporter stage. If refinement fails, the Task is not magically considered complete; the controller can return it to a waiting state and preserve the error for the operator. A bounded feedback loop has two terminal possibilities: the objective is sufficiently achieved, or the system stops with an explicit gap.
The boundary also limits what a Refiner is allowed to claim. It can change the future queue, but it does not retroactively validate a completed result, recover evidence that was never captured, or prove that an omitted check was unnecessary. A revised plan can be more relevant than the first one and still leave a coverage gap. That is why the final report needs to retain the distinction between work performed, work superseded by new evidence, and work that remains unverified.
Adaptive does not mean complete
The benefit of refinement is responsiveness to evidence. Its cost is that the path is no longer fully predictable before execution. The model can decide that a result is decisive when a human would want a second check. It can preserve a weak lead because the remaining context makes it look promising. It can remove a planned step because the new evidence appears to make it irrelevant, even though the original assumption deserved independent validation. These are not arguments for disabling refinement; they are reasons to treat the plan as a working hypothesis and the report as something to review.
A static, human-authored sequence is preferable when coverage requirements are contractual, repeatability is more important than discovery, or the operator already knows the exact procedure and wants every run compared against the same baseline. A fixed sequence makes omissions easier to detect against a known checklist and can simplify approval. It is less responsive when the target invalidates the assumptions behind that checklist. PentAGI's adaptive plan is more useful when the objective is exploratory or when evidence can change the next safe step, but it should be constrained by an engagement-defined scope and reviewed against any required baseline.
A practical choice can be made with three questions. Are the required checks known in advance? If yes, retain a human baseline even if PentAGI adapts around it. Can observations materially change the next safe action? If yes, leave room for refinement rather than forcing the agent to follow stale assumptions. Finally, can a reviewer explain why a step was removed or added? If not, the adaptive plan is moving faster than the evidence trail can justify. These questions do not turn planning into a formal coverage proof; they keep flexibility connected to review.
This is also where the Flow hierarchy from the previous chapter matters. The Generator does not replace the Flow's durable state; it populates the Task's planned Subtasks. The Refiner does not replace the operator; it changes the remaining queue through a controller-validated operation. The Primary Agent does not own the whole plan; it executes one Subtask and returns a result. Each layer limits the authority of the next one.
Recovery mechanisms add another boundary. If an agent call produces malformed tool arguments or repeats a tool, PentAGI can retry, repair the arguments, or ask a Reflector to guide the chain. Those responses may keep the Task moving, but they do not alter the basic planning contract: a recovered Subtask still returns a result that the Refiner may need to interpret. Reliability mechanisms can prevent a loop; they cannot prove that the revised plan covers every relevant attack surface.
The practical way to read a PentAGI plan is therefore as a traceable set of hypotheses. The initial list says what the system currently believes must be done. Each completed Subtask supplies evidence about that belief. The Refiner decides how the remaining hypotheses should change. The controller records which changes were applied. That is a more useful model than calling the plan either “autonomous” or “fixed”: it is a bounded feedback process whose quality depends on the objective, the evidence, the model, and the review around it.
Once the plan identifies the next piece of work, another boundary becomes decisive. The Primary Agent must decide whether to search, test, code, install, ask for advice, retrieve memory, or finish—and PentAGI does not give every one of those powers to every agent. The next chapter opens that delegation boundary.