What is a sub-agent?

A sub-agent is an AI agent that receives a specific task from another agent, usually an orchestrator, carries it out and returns the result. It has its own role, tools and limits, narrower than the work as a whole. Sub-agents let a large job be split into parts that can each be built, tested and certified separately.

Why use sub-agents?

Because narrow agents are easier to trust. A sub-agent that only extracts figures from bank statements can be tested on hundreds of statements and certified for that one job. A general agent that extracts, assesses and decides needs to be proven on all three at once, and a weakness in one undermines the others.

Sub-agents also keep tools apart. The sub-agent that reads a customer's uploaded documents does not need, and should not have, access to the payment system.

Why does a sub-agent matter once agents act?

The risk is inherited authority. If an orchestrator cleared to coordinate payments asks a sub-agent to "release this batch", the natural assumption is that the request carries the orchestrator's authority. It should not. A sub-agent acts under its own certificate and bounds, and a request from another agent is just one input to its own check.

Without that rule, the weakest link sets the limit: anything that can reach the orchestrator can reach every sub-agent's tools through it. The full argument is in can an orchestrator agent give a sub-agent more authority than it has?

How do sub-agents work in practice?

The orchestrator sends a task with three things: what to do, the facts needed with their provenance, and its own identity. The sub-agent works on the task within its bounds. Any action it proposes is checked against its own role, certificate, sources and limits. It returns a result, which the orchestrator receives as a fact from that sub-agent.

Between systems, or between agents built by different teams, the task may travel over an agent-to-agent protocol. The authority rule is the same either way.

What does that look like in an example?

A mortgage lender's application orchestrator delegates to three sub-agents: income verification, property valuation intake, and affordability calculation. The income sub-agent reads payslips and bank data and returns verified income with the class of each figure. The affordability sub-agent runs the calculation. Neither sub-agent can approve the mortgage, and neither can the orchestrator. The approval is held for an underwriter, with each sub-agent's result attached.

How is a sub-agent different from a tool?

A tool does exactly what it is asked: run this query, return these rows. It has no judgement. A sub-agent uses a model, so it can interpret the task, choose its steps, ask for clarification, or refuse. That makes sub-agents more capable and harder to predict, which is why they need their own certification where a tool needs only a correct connection.

The word also appears in finance with a different meaning: a sub-ledger is a detailed ledger that feeds totals into the general ledger. The two are unrelated.

Where Pryme fits

In Pryme each sub-agent has its own brief and certificate, and every action it proposes is checked against its own minimum chain, not its orchestrator's. The orchestrator's request is an input to that check, never a grant of authority, and the filed verdict names the sub-agent that acted. See the governed agentic operating system, explained.