Orchestration & Delegation

How Mandrel orchestrator agents govern their decision scope and delegate tasks.

Mandrel governs both sides of the orchestrator’s boundary: what tasks it accepts (ingress) and which agents it may route to (egress). This dual-Collet model treats the orchestrator’s own decisions — which agents to invoke, which context to use, how deeply to plan — as first-class governance concerns.

Orchestrator Mode

An agent becomes an orchestrator by declaring spec.orchestrator in its MandrelSpec. The stanza’s presence is the mode signal; its sub-fields define the decision scope. Specialist agents omit the stanza entirely.

spec.orchestrator absent  →  specialist mode (existing Collet layers apply)
spec.orchestrator present →  orchestrator mode (ingress + egress enforcement layers activate)

The orchestrator stanza coexists with all specialist-oriented fields (governance, identity, network, runtime). Those fields continue to govern the orchestrator’s own resource and identity boundaries.

Dual-Collet Enforcement

Orchestrator governance operates at both ends of the agent:

Collet position	What it governs	Fields evaluated
Ingress Collet (extended)	Inbound task scope	`permitted-intents`, `scope-rejection-policy`
Egress enforcement	Outbound delegation decisions	`permitted-delegates`, `context-trust`, `planning-depth`, `autonomy`

The existing ingress enforcement layers (identity, governance matrices, SPIFFE, runtime limits) continue to apply — the orchestrator stanza is additive.

Ingress: Intent Classification (Layer 0)

The ingress Collet gains a new Layer 0 that runs before all existing layers. It applies only when spec.orchestrator is present in the Realized Spec.

1. Read permitted-intents. If absent: no restriction — pass through to Layer 1.
2. If permitted-intents is []: reject all requests (PermissionDenied).
3. Classify inbound request against permitted-intents using an isolated intent classifier.
4. On match: pass through to Layer 1 (loop prevention / hops).
5. On no match: apply scope-rejection-policy.

scope-rejection-policy controls the Collet’s response to out-of-scope requests:

Value	Behaviour
`deny`	PermissionDenied immediately (default)
`escalate`	FailedPrecondition — caller must supply HumanApprovalToken and resubmit
`transfer`	Redirect to a sibling orchestrator via Metrology Lab discovery (requires Lab infrastructure)

Egress: Delegate Validation

After the orchestrator LLM produces a routing decision, the egress enforcement layer validates it before executing the gRPC delegation call. Four independent checks run:

1. permitted-delegates check — validates the selected agent against the declared allowlist. Supports three binding modes:

Mode	`agents` field	Binding
Capability	Absent	Any promoted agent matching capability + optional namespace/risk-profile
Name	`["agent-name"]`	Only the named agent(s)
Hybrid	`["a", "b"]`	Named subset with capability constraint

An empty permitted-delegates: [] blocks all outbound routing. Absent means no restriction.

2. context-trust check — asserts the selection prompt was built only from permitted information sources. Runs at prompt construction time, before the LLM is invoked.

3. planning-depth counter — tracks sub-task decomposition steps within the orchestrator’s reasoning loop. Requires framework instrumentation (LangGraph governance node, AutoGen middleware) for full enforcement.

4. autonomy checks — event-driven checks for three orchestrator actions:

Action	Trigger
`re-planning`	Orchestrator changes its delegation plan mid-task
`scope-expansion`	LLM selects an agent not in `permitted-delegates`
`cross-namespace-delegation`	Selected agent’s namespace differs from the orchestrator’s own namespace

Each action is independently configured as autonomous (proceed), challenge (require HumanApprovalToken), or deny (never permitted).

Relationship to Runtime Controls

The runtime controls govern volume; the orchestrator controls govern content:

Control	Layer	What it bounds
`runtime.max-hops-allowed`	Wire protocol	Delegation chain depth
`runtime.max-fan-out`	Wire protocol	Concurrent delegations in flight
`runtime.max-delegations`	Wire protocol	Total delegation volume per turn / session
`orchestrator.permitted-intents`	Orchestrator ingress	Which task types this orchestrator accepts
`orchestrator.permitted-delegates`	Orchestrator egress	Which agents this orchestrator may route to
`orchestrator.context-trust`	Orchestrator egress	What information may inform routing decisions
`orchestrator.planning-depth`	Orchestrator reasoning	Sub-task decomposition depth
`orchestrator.autonomy`	Orchestrator decisions	Which actions require human approval

Both sets of controls are necessary. An orchestrator may have a wide permitted-delegates set but tight max-fan-out and max-delegations limits — or a narrow delegate list but no fan-out restriction.

A2A Delegation Protocol

Communication between orchestrators and specialists occurs over gRPC, proxied through the Collet. Each delegation carries a DelegationRequest with:

task_payload: The instruction routed to the specialist.
CompoundIdentity: user_delegated_token (RFC 8693) + machine_svid (SPIFFE) + optional human_approval_token (RFC 9470 — required for challenge autonomy actions).
RoutingMetadata: max_hops (decremented by Collet on each hop) and hop_history (audit trail).

Max-Hop Enforcement

Ingress: Collet checks max_hops claim. If ≤ 0, the request is aborted with RESOURCE_EXHAUSTED.
Decrement: Before the specialist calls another agent, its Collet decrements max_hops by 1.
Audit: The Collet appends the agent’s identity to hop_history for full traceability.

Semantic Discovery

Orchestrators interact with the Metrology Lab to discover appropriate specialists at runtime. The Metrology Lab indexes promoted agents by their declared spec.capabilities.intents, enabling capability-based late-binding. An orchestrator’s permitted-delegates entries with no agents field use this discovery path — the delegate list is resolved at routing time, not baked into the spec.

This late-binding model is the default for open, evolving meshes. Name-binding (agents: ["finance-specialist"]) is available for regulated environments where compliance teams must explicitly approve every delegation target.

MCP Integration

When a specialist agent is invoked, it interfaces with backend systems through MCP using three primitives:

Resources (Nouns): Read-only data points (e.g., database records).
Prompts (Workflows): Standard Operating Procedures.
Tools (Verbs): Explicit, state-changing actions guarded by enforcement matrices and HITL.

Source: gitlab.com/the-mandrel-project/mandrel-spec