When AI Agents Delegate

An employee asks an AI assistant to prepare a supplier assessment. The assistant delegates document research to one agent, contract analysis to another, and a review of the findings to a third.

That can be a useful division of work. It also creates several separate decisions about access and information sharing. Each agent receives a task, some context, a set of tools, and a destination for its results. Some may run locally, others through an external model provider. A specialist may need information that the coordinating agent should never see directly.

The organisation needs to decide which of those interactions are permitted - and enforce those decisions throughout the process.

This is the next step in the Dissemination Control blueprint. Version 0.7 extends the architecture to subagents and makes another principle explicit: the blueprint is an extensible framework that operators can adapt to their own requirements, including complex combinations of tools, policies, and checks.

In my earlier article on the governance gap in AI agents, I described the distinction between accessing information and being allowed to share it in a particular context. Delegation adds another dimension: an agent can ask another agent to perform work on its behalf.

Access, Delegation, and Return Need Separate Permissions

Consider the contract-analysis specialist. It may need access to confidential contract documents to answer a narrowly defined question. Giving every agent in the workflow the same access would unnecessarily broaden exposure. Requiring every specialist to have less access than its parent would also be too restrictive.

The revised blueprint therefore distinguishes three permissions:

Access: Which information may an agent retrieve through its tools?
Delegation: Which specialists may it commission, and for which tasks?
Return: Which information may the specialist send back, and to whom?

A specialist can have access that its parent does not possess. The operator must explicitly approve that arrangement and define the permitted return scope.

The standard path continues to use the requesting user’s permissions. An employee should receive information they are entitled to access. Exceptional capabilities are provided through dedicated tools whose extended permissions are approved by the operator. Users cannot activate those privileges themselves.

This makes the exception visible. The operator decides which additional information flows are acceptable, and Dissemination Control enforces the configured conditions.

The same principle applies to the context passed into a subagent. Data admitted for a task may be used within its approved processing scope. That scope must include the intended subagents and execution environments, together with any attachments or retained conversation history they receive.

This approach does not require another language model to classify every delegation prompt as confidential or harmless. It depends on the preventive controls admitting the appropriate data and authorising the environments that may process it.

The Delegation Itself Becomes a Verifiable Execution Instruction

The main agent can formulate a subtask through an enabled tool such as launchSubAgent. The trusted tool implementation resolves the user and task context, obtains the authorisation decision, and constructs the execution message.

That message binds the prompt and context to the permitted models, tools, recipients, and operating limits. The tool signs the complete payload. Before execution, the receiving infrastructure checks its origin, integrity, intended recipient, validity, and authorisation.

The model can request work. The authoritative permission configuration remains outside its control.

A valid signature alone does not make an instruction permissible. It establishes who issued the message and whether the protected content changed. Dissemination Control still evaluates whether the execution is allowed.

The blueprint includes an illustrative JSON message to make these responsibilities concrete. It is a starting point for implementation; operators can extend the schema and choose their own messaging infrastructure.

Message identity also matters. If the transport delivers the same instruction twice, it should not launch two agents. Retransmissions retain the same identifier, and the receiving side checks a shared processing record before starting another execution. A deliberate correction attempt receives a new message identifier while remaining linked to the original task.

Result Submission Is Another Point Where Governance Has to Remain Effective

A subagent completing its work does not automatically make the result available to every participant.

The revised design places results in a protected working area. A submission tool identifies the version to be reviewed. The execution attempt can then end while validation proceeds.

Two decisions follow: whether the work meets the task’s requirements, and whether the result may be released to the intended recipients. A parent agent may help assess research quality. Its approval cannot grant additional access rights.

Storage permissions must support that distinction. A release check has little value if the user can already open the unapproved file directly.

If the result needs correction, the subagent can restart with its previous context and an explanation of the deficiencies. The same execution conditions and checks apply again. Task-level question and rejection counters persist, so restarting does not erase the history that determines when human intervention is required.

The operator sets the thresholds, budgets, and escalation paths. Those values belong to the deployment.

The audit trail connects these events: the original request, each delegation, the tools used, authorisation decisions, submitted versions, corrections, and eventual release. It also needs to identify the credentials used for an operation. Token references or fingerprints provide that correlation while keeping reusable credential secrets out of ordinary audit records.

For model access, a gateway such as LiteLLM can provide virtual keys and central cost tracking. Agent runtimes use those virtual credentials, while provider keys remain at the gateway. Linking model requests to tasks and execution attempts makes the cost of delegation and correction visible.

LiteLLM is one possible implementation. NATS/JetStream is one possible messaging system. S3-compatible storage is one possible result repository. The architecture assigns responsibilities; the operator chooses the products.

Extensibility Is Now an Explicit Design Principle

That distinction is central to the second change in version 0.7: extensibility is now an explicit design principle.

An organisation may need additional data sources, specialist tools, approval steps, or checks before a result can leave a particular environment. Another may need different policies for customers, departments, or project roles. Those requirements can become part of the framework.

Extensions can be introduced as requirements evolve. They follow the same principles as the initial controls: authoritative rules remain outside the LLM, execution passes through the relevant enforcement points, and decisions remain traceable.

Version 0.7 documents this architecture and its execution contract. Deployment-specific implementation and validation remain engineering work.

The practical objective is straightforward: when a task passes through several agents, the organisation should still be able to explain who authorised each step, which information was available, which exceptions applied, and why the final result reached its recipients.

The Dissemination Control blueprint is available on GitHub. It provides a reference for building that chain of responsibility into your own agent workflows.