How the Orchestrator, the Trainer and the VP Marketing Agent Fit Together

Who this is for: CTOs, architects, CISOs and internal auditors. After reading, you should be able to fill the duties matrix for your own agents, know what a small team can skip, and spot when a design has collapsed. This page is part of the AI agent rails method, which is vendor-neutral.

What do vendors mean by "agent control plane"?

Vendors usually mean a registry, a policy store and a gateway when they say "agent control plane". The phrase comes from networking, where a control plane decides and a data plane carries out. Those products are useful, and they sit underneath the model on this page. We read the pages below on 1 November 2026.

A registry can tell you an agent exists and hold its policy. It cannot tell you whether the agent that routes work should also see customers. That is a design decision, and it is the subject here.

What are the four planes?

The four planes are execution, control, learning and oversight, and each one lacks a power the others hold. No plane can both decide and carry out alone.

Who may do what? The separation-of-duties matrix

Separation of duties for AI agents means no agent or person holds a pair of powers that lets them bypass a check. The matrix below is the page's core asset. Copy it into your own design documents, and a link back is welcome.

Three terms need a definition. Work counts means queue depth, run counts and the declared size of a run: a number with no member behind it. Raise alert means the agent writes a flag into its output, and a separate service delivers it, so neither agent can stop anything itself. Pause: itself covers automatic stops written on a rail, such as a pause after repeated rejections.

A cell is only true if a system refuses the alternative. To fill the matrix for your own agents, list every agent and role across the top, then name what enforces each row. Any cell that depends on a prompt counts as "yes" until you fix it.

Two rules deserve a note. A rail owner who approves requests must be named on the card, and even then cannot approve their own request. A Trainer that can run tests stays at L2 because its tests touch non-production only, so nothing in production changes.

One ledger under all four planes

One audit ledger sits under all four planes, because a plane that cannot be seen in the ledger does not exist for an auditor. It is written outside the agents, it is append-only, and the correlation ID joins the entries for one request.

The gates add approver, decision and bound hash. Services write all of it: the gateway, the approval service and the execution service. No agent writes or edits its own record. PrivyCDP's audit ledger records each AI-assisted action with the human or system actor that authorised it, and the security documentation covers how it is protected.

One request through all four planes

One request shows how the planes work together, and what crosses between them is references and hashes, never records. The story below is illustrative.

1. A marketer asks for an audience. The request enters as free text, and personal data is redacted.
2. The Orchestrator routes it. A classifier picks a label from a fixed list, and the routing table names the segment rail.
3. The Segment Drafter proposes. It returns a definition reference, a hash and an estimated count. It has no way to activate anything.
4. Rule checks run. Consent, size and sensitive-attribute rules run outside the model, and a failure blocks the draft.
5. A person approves. A named approver, who is not the requester, sees the diff and count. The approval binds to the hash.
6. The execution service syncs. It re-checks consent, then acts with its own credentials. The Audience Sync Steward rail holds no profiles.
7. The ledger records. Every step above sits under one correlation ID.
8. The reviewer's edit becomes a test. The reviewer corrected the draft along the way. The Trainer clusters that edit with similar ones and proposes a test, which the rail owner accepts.
9. The VP readout flags an overlap. Next Monday, the VP Marketing agent notes that this audience overlaps another campaign in the same week. A person decides what to do.

View or embed this diagram as SVG

Why does this resist prompt injection better?

Separation resists prompt injection better because a hijacked agent only has the powers of its plane. The Agents Rule of Two says a session should hold at most two of three properties: [A] untrustworthy input, [B] sensitive data, [C] changing state or communicating externally 1. Mapping each plane against it shows where the damage stops.

This limits damage and does not stop injection. Meta says the same of its rule: it reduces the severity of consequences, and it is not a sufficient defence alone 1. A hijacked agent still wastes time, and a persuasive false claim can still mislead a tired approver, which OWASP lists as ASI09 Human-Agent Trust Exploitation 28. A compromised plane is contained, not cured. ASI03 Identity & Privilege Abuse and ASI10 Rogue Agents remain the risks to test for 28.

What can a small team skip?

A small team can skip the separate agents and keep the separate powers. The Orchestrator, the Trainer and the VP Marketing agent are jobs, and a job can be a script, a meeting or a person. What matters is that no one thing does all of them.

Anthropic's advice is to use the simplest solution and add complexity only when it helps, noting that agents carry more cost and can compound errors 9. That applies here. Four planes describe a separation of powers, and they do not require four more models.

How do designs collapse back together?

Designs collapse when a convenient exception gives one agent a second power. Each pattern below sounds reasonable in the meeting where it is proposed.

The last pattern deserves a fair hearing. For read-only, exploratory work, a single capable agent may be the right design. The test is whether it can change state. Once it can, split it. The boundary architecture patterns and the AI governance policy template give the supporting controls, and a rail card records the result for each agent.

Checklist for an AI agent control plane

• ☐ The duties matrix is filled for every agent and role you run.
• ☐ Each cell names the system that enforces it.
• ☐ No agent reads customer data and also routes work.
• ☐ No agent can approve, and no approver can approve their own request.
• ☐ Rail and routing changes go through change control with a person.
• ☐ Every agent has its own identity, so the ledger can tell them apart.
• ☐ One append-only ledger, written outside the agents, covers all planes.
• ☐ You review the matrix after each new agent or tool, looking for collapse.