An Agent Team with Unequal Powers

PentAGI's adaptive plan identifies the next piece of work, but it does not decide how every piece should be carried out. That responsibility belongs to the Primary Agent and the specialists behind its tool interface. This chapter explains why PentAGI gives those roles unequal powers, how the Primary Agent turns model output into a protocol-driven execution loop, and how a result travels from a tool call into logs, memory, and the parent Subtask.

The Primary Agent is a protocol-driven orchestrator

The Primary Agent receives a description for one Subtask, not an invitation to redesign the entire Flow. Its execution context includes the surrounding Flow and Task state, the current Subtask, the container image and working directory, available ports, attached files, and the tools it may call. The prompt asks it to stay within the current Subtask and to use structured tool calls. That last requirement is not a stylistic preference. The provider loop expects an AI response that contains tool calls, executes those calls, appends their responses, and calls the model again.

The Primary Agent's executor exposes a deliberately narrow set of high-level decisions: ask for advice, delegate coding, request maintenance, retrieve memory, invoke the Pentester, search for information, or finish the Subtask. The agent is not given a raw catalog of every implementation detail behind those actions. Instead, each delegation handler constructs the appropriate specialist context, executor, message chain, and result path. The Primary Agent remains responsible for deciding what kind of help is needed and for integrating the response into the current objective.

This separation addresses a common failure mode in agentic systems: a model with too many tools can confuse available action with necessary action. PentAGI's primary loop does not expose “do anything” as a single capability. It exposes typed functions with schemas and named outcomes. The model can still misuse a function or choose a poor strategy, but the handler can validate arguments, associate the call with the current Task and Subtask, and return a result in a form the loop understands.

The loop is persistent. When the LLM returns an AI message with one or more tool calls, PentAGI appends that message to the Subtask's message chain. It executes each recognized call, appends a tool response, updates the chain in storage, and continues. The chain therefore records not just the final prose but the sequence of decisions and responses that led there. When the model returns plain prose without a tool call during a Primary-Agent run, the system treats that as a protocol failure and invokes the Reflector rather than assuming that the Subtask is complete.

The done and ask functions are different from ordinary tools because they cross the boundary into controller state. done reports a result and completion status. The handler stores the Subtask result and changes the execution outcome to finished or failed.