Manager-Agent Architecture: Routing, Review, State, and Failure Containment

§ 01What Is a Manager-Agent Architecture?

A manager-agent architecture is a centralized multi-agent control pattern. One manager retains responsibility for the parent task while calling specialists for bounded contributions.

OpenAI’s current agent orchestration documentation describes “agents as tools” as the manager pattern: the central agent keeps control of the conversation, calls specialists, combines their outputs, and owns the final answer. Anthropic’s orchestrator-workers pattern uses a central model to break down a task dynamically, delegate subtasks, and synthesize results when the required subtasks cannot be predicted in advance.

The comparison of agent handoffs versus agents as tools defines when that manager should retain control and when a specialist genuinely needs to become the active owner.

The pattern has four operating layers.

The table draws the most important boundary. The manager can decide that a research specialist is useful; it should not be able to invent that specialist’s permissions, override a spend cap, or declare an unapproved external action valid.

A manager is more than a router

A router usually classifies one input and selects one destination. A manager may create several child tasks, manage dependencies, revisit assignments, compare results, request repairs, and integrate contributions over multiple turns.

A manager is not the specialist

The manager-agent versus specialist-agent model separates coordination outputs from domain outputs. The manager produces a valid task graph, assignments, review decisions, escalation, and parent closure. A specialist produces a verified research memo, reconciled ledger, tested patch, approved message candidate, or another domain artifact.

A manager is not the policy engine

Natural-language instructions are not an authorization boundary. A policy service should determine whether a manager may delegate a task, whether a worker may accept it, which resources are available, and whether a proposed action needs approval.

§ 02Which Components Does the Controller Need?

A manager architecture needs more than a manager prompt and a list of subagents. It needs durable components that make every coordination decision attributable and recoverable.

The manager depends on these services; it should not replace them. A strong controller remains useful after a model swap because its task, state, authority, and evaluation contracts are external to the model.

§ 03How Should the Manager Process a Parent Task?

Use a staged control loop. The model may handle ambiguous decisions inside a stage, while code validates every boundary.

The stages prevent one model response from silently becoming an assignment, permission grant, approval, and completed outcome at once. Each transition leaves a structured record that another service can validate.

Intake creates the authoritative parent record

The parent task should capture:

• parent ID and version;
• initiating principal, tenant, and session;
• requested outcome and scope;
• acceptance criteria;
• inputs and source versions;
• data classification;
• permitted and prohibited actions;
• deadline and priority;
• time, spend, child, depth, and concurrency caps;
• required reviews and approvals;
• and the parent closure owner.

Ambiguous goals should enter input_required, not proceed with guessed scope.

Risk classification comes before delegation

Classify whether the task is read-only, reversible, externally visible, financial, administrative, privacy-sensitive, or destructive. The class determines eligible workers, tool scopes, review independence, approval, and stop behavior.

Closure checks the parent outcome

A parent can close only after required child contributions are accepted, required approvals remain valid, external effects reconcile, and the parent acceptance criteria pass. “Every worker returned” is an activity condition, not an outcome condition.

§ 04How Should the Manager Build a Task Graph?

The task graph represents contributions and dependencies. A node is a bounded task or deterministic check. An edge means one node needs an artifact, state, or authorization from another.

Decompose by outputs, not job titles

Weak decomposition creates roles such as “researcher,” “writer,” and “reviewer” without defining what each returns. Strong decomposition names artifacts:

• verified source ledger;
• market comparison matrix;
• risk register;
• recommendation memo;
• citation check;
• approved release package.

An output-based node can be tested, versioned, retried, reassigned, or rejected.

Keep graph constraints outside the manager

The task-graph service should reject:

• a missing parent ID;
• duplicate child IDs;
• cycles where no loop was approved;
• dependencies on nonexistent artifacts;
• depth above the parent cap;
• child count above the parent cap;
• a child whose deadline exceeds the parent deadline;
• and a required node without an acceptance rule.

Version every material graph change

If new evidence creates another task, increment the graph version and record:

• the changed nodes and edges;
• the triggering event;
• the manager decision category;
• affected budgets and deadlines;
• canceled or superseded work;
• and the resulting parent state.

Structured fields and evidence references let another service reconstruct the change and validate it against policy.

§ 05What Belongs in a Worker Capability Registry?

A worker registry turns a roster into a testable routing surface. Names and self-descriptions are discovery hints, not proof of eligibility.

The registry should be versioned and refreshed. A worker that passed last month may be unhealthy, outdated, over capacity, or no longer authorized for the current tenant.

Separate declared, verified, and currently eligible

Use three sets:

• Declared capability: what the worker says it can do.
• Verified capability: what representative evaluations show it can do.
• Current eligibility: what identity, policy, data, risk, health, capacity, and budget permit for this exact assignment.

Only the final set may receive the task.

Use hard filters before ranking

A practical eligibility expression is:

eligible = declared AND verified AND schema-compatible AND tenant-allowed AND policy-allowed AND risk-compatible AND healthy AND available

This is a control model, not a claim that one framework implements the exact expression. The manager ranks only workers that survive every hard constraint.

§ 06How Should Routing Work?

Manager routing should have four explicit stages: filter, rank, offer, and evaluate.

Stage 1: filter

The registry and policy services remove workers that fail schema, tenant, data, action, health, capacity, deadline, or budget requirements. The manager cannot restore a denied candidate.

Stage 2: rank

Rank the eligible set using task-relevant evidence. An illustrative score is:

route score = w1(capability fit) + w2(eval fit) + w3(latency fit) + w4(cost fit) + w5(context fit) + w6(current capacity)

Weights are local policy choices and should sum to 1. They are not universal benchmarks. High-risk work may weight verified quality and authority more heavily than speed.

Stage 3: offer and acceptance

The chosen worker receives a proposed child contract. It may accept, reject, or request clarification. Capacity can change between ranking and acceptance, so a routing decision is incomplete until the worker accepts.

Stage 4: evaluate the route

Measure the routing system independently of specialist quality.

The table keeps routing quality separate from downstream execution. A good specialist can rescue a poor route; a correct route can still produce a weak artifact. Both need their own tests.

§ 07What Should a Child Assignment Contain?

A child assignment is a contract, not a conversational request. The complete AI agent task delegation model covers the child boundary in depth.

At minimum, include:

The contract lets the worker decide whether it can accept and lets the manager later decide whether the returned contribution is usable.

Send a context manifest

Pass only the context required for the child outcome:

• authoritative parent objective;
• the child’s exact contribution;
• relevant source and artifact references;
• constraints and exclusions;
• decisions already fixed;
• unresolved questions;
• data classification;
• and output schema.

Do not copy an unrestricted conversation history, every sibling artifact, or the manager’s full credential set.

Prefer durable artifacts to long messages

Anthropic’s multi-agent research-system account describes subagents storing persistent outputs and returning lightweight references to the coordinator to reduce information loss. That pattern keeps large domain work independently retrievable and lets the manager synthesize from versioned artifacts rather than a chain of summaries.

§ 08How Should Parent and Child State Be Modeled?

State should be explicit, durable, and transition-controlled. Framework session memory alone is not enough for a business task that must survive restarts, cancellation, or manager failure.

Google’s ADK state documentation distinguishes temporary invocation state from session state whose persistence depends on the backing service. That distinction reinforces a general rule: store durable task state in a persistent service, not only in an in-memory context object.

Use separate parent and child state machines

An illustrative state model is:

These names are an operating example, not a protocol standard. The important properties are valid transitions, one current state, version control, timestamps, and a terminal result.

Prevent invalid transitions

Examples of invalid transitions include:

• proposed to running without worker acceptance;
• running to accepted without a delivered artifact;
• delivered to completed when the child still needs review;
• canceled to running without a new task version;
• and active parent to completed while a required child is unresolved.

Use optimistic concurrency, compare-and-set, or another atomic update method so two actors cannot write contradictory states.

Store events separately from current state

Current state answers “what is true now?” Event history answers “what happened?”

Each event should include:

• event ID and timestamp;
• parent and child IDs;
• actor identity and version;
• previous and new state;
• action category;
• policy and approval references;
• artifact version;
• budget delta;
• error code;
• and correlation or run ID.

The resulting event trail makes every state change attributable and reconstructable.

§ 09How Should Budgets, Concurrency, and Scheduling Work?

Every child consumes part of the parent envelope. A manager must not create capacity by creating descendants.

Preserve the parent budget invariant

Use:

sum(child reserved spend + child consumed spend) + parent consumed spend <= parent spend cap

Apply the same principle to elapsed time, tool calls, external actions, and retries. Release unused reservations when a child closes or is canceled.

Bound fan-out and depth

Enforce:

• maximum children per parent;
• maximum active children;
• maximum delegation depth;
• maximum retries per child;
• maximum total assignment attempts;
• maximum loop iterations;
• and a parent deadline that every child deadline precedes.

If nested delegation is disabled, a specialist asks the manager for another contribution instead of creating an untracked descendant.

Schedule by dependency and risk

Ready tasks have accepted dependencies, valid authority, an available worker, and sufficient reserved budget. High-risk tasks may require approval before entering the queue. Low-priority work should not starve behind repeated urgent retries.

The scheduler narrows what can run. The manager may choose among allowed ready tasks, but it cannot schedule blocked dependencies or overdraw the parent envelope.

§ 10How Should the Manager Review Worker Results?

Review has three layers: deterministic validation, domain evaluation, and parent integration.

Layer 1: validate the return envelope

Check:

• child identity and accepted contract version;
• artifact type, schema, and checksum;
• source and evidence fields;
• completed and attempted scope;
• uncertainty and known gaps;
• tool actions and side effects;
• spend and elapsed time;
• and worker terminal state.

Malformed returns do not enter synthesis.

Layer 2: evaluate the domain contribution

The manager may apply the child rubric for low-risk work, but domain-sensitive or consequential work needs an independent evaluator or authorized human.

Possible outcomes are:

• accept;
• repair_required with named defects;
• reroute because the worker is unsuitable;
• escalate because evidence conflicts or authority is insufficient;
• or reject because the contribution cannot safely advance.

Layer 3: test parent integration

A collection of valid child artifacts can still contradict itself. Integration checks:

• coverage of every parent criterion;
• incompatible assumptions or timeframes;
• duplicated evidence;
• unresolved contradictions;
• source freshness and authority;
• dependency versions;
• and whether the recommendation follows from accepted evidence.

Keep evaluation independent enough for the risk

Do not let the manager create an artifact, approve the same artifact, and execute its consequential action under one identity. OWASP’s AI Agent Security Cheat Sheet recommends explicit approval for high-impact actions, validation of agent outputs, trust boundaries between agents, and circuit breakers for cascading failures.

§ 11When Should the Manager Retry, Repair, Reroute, or Escalate?

Different failures need different recovery actions.

The table makes recovery type-specific. Retry is appropriate for a transient execution fault; it is not a substitute for better input, another worker, more authority, or human judgment.

Preserve partial work

When a child fails, return completed artifacts, source references, side-effect records, consumed budget, and blockers. The manager should resume from the last accepted checkpoint rather than discard useful work.

Make retries idempotent

Every externally visible action needs a stable action ID, normalized parameters, status lookup, and duplicate handling. Before replay, determine whether the first attempt failed before or after commit.

Escalate with a decision packet

An escalation should include:

• parent and child state;
• requested decision;
• evidence and conflicting findings;
• prior attempts and outcomes;
• action and risk class;
• remaining budget and deadline;
• safe options;
• and consequence of no decision.

A human should not have to reconstruct the entire run before acting.

§ 12How Narrow Should Manager Authority Be?

The manager needs broad visibility into task state but narrow execution authority.

Use distinct identities

Assign separate identities to:

• initiating user or service;
• manager;
• each specialist;
• evaluator;
• approver;
• and execution service.

NIST’s current Software and AI Agent Identity and Authorization project focuses on standards-based ways to identify agents, authorize their access and actions, and preserve accountability as autonomous action scales.

Recalculate authority at every child edge

A useful model is:

child authority = worker role AND manager delegation scope AND parent task grant AND current policy AND valid approval

The intersection can only narrow authority. The worker uses its own identity; the manager’s credentials do not travel.

Separate proposal from execution

For financial, destructive, administrative, externally visible, or other high-impact actions:

1. the specialist may propose an action;
2. the manager may review its fit with the parent outcome;
3. a policy service verifies actor, target, parameters, and scope;
4. an authorized approver accepts the exact action when required;
5. a constrained execution service performs it;
6. the result reconciles to the task record.

OWASP recommends binding approval to the exact actor, tool, target, normalized parameters, time, and expiry, then failing closed if policy or audit checks fail.

§ 13What Must Be Observable?

Observe the complete parent lineage, not only model calls.

Capture structured events

Record:

• parent creation and version;
• graph changes;
• candidate set and hard-filter outcomes;
• selected worker and contract version;
• acceptance, rejection, and clarification;
• state transitions;
• tool and external-action summaries;
• artifacts and evidence references;
• budget reservations and consumption;
• review decisions and defect codes;
• retries, reroutes, escalations, and circuit breaks;
• approvals and execution results;
• and parent closure.

Keep sensitive content redacted and access-controlled. Typed events, artifact references, and action outcomes provide the operating visibility needed for review and recovery.

Measure each layer separately

The measures expose where value or failure originates. A low parent acceptance rate may come from poor decomposition, stale registry data, weak specialists, bad synthesis, or overly strict review; one blended score cannot diagnose it.

§ 14How Should Failure Containment Work?

A central manager simplifies ownership but creates a high-impact failure point. The multi-agent system failure-mode model explains how one defect can spread through assignments, shared context, review, memory, and action.

Contain manager failure

The manager should not be able to:

• grant itself or workers new permission;
• bypass worker eligibility;
• create children beyond the parent cap;
• erase task or action history;
• approve its own high-impact action;
• write unvalidated worker output into shared memory;
• or mark a parent complete without acceptance checks.

Contain worker failure

A compromised or defective worker should affect only its task-scoped data, tools, budget, and output. Receiver-side validation prevents its return from becoming trusted merely because the worker was eligible.

Use lineage-wide circuit breakers

Stop the affected parent and descendants when tested conditions indicate:

• abnormal child count or depth;
• repeated assignments without progress;
• budget or call spike;
• repeated authorization failure;
• corrupted task state;
• memory-integrity failure;
• duplicate external effects;
• cross-tenant access;
• or a human stop.

Stopping only the manager while children continue acting leaves the failure active.

Remove the single point of state loss

Workers, artifacts, budgets, and approvals should persist outside the manager context. A replacement manager can load the authoritative parent state, inspect accepted artifacts, reconcile active children, and resume under the same limits.

§ 15What Does a Worked Manager Run Look Like?

Consider a manager responsible for a market-entry decision packet.

Step 1: create the parent

The parent requires a demand assessment, competitor map, regulatory summary, channel recommendation, risk register, and final decision. It is read-only until an authorized human accepts the recommendation.

Step 2: create the graph

The manager creates four independent evidence nodes, one reconciliation node, and one final integration node. The graph service validates dependencies and reserves budget.

Step 3: select workers

The registry returns workers whose schemas, tenant, data scope, evaluations, health, and capacity match each node. The manager ranks that eligible set. One worker rejects because its queue is full, so the manager offers the task to the next eligible candidate.

Step 4: supervise returns

Three workers deliver accepted artifacts. The regulatory worker returns input_required because the target selling entity is missing. That branch of the parent task pauses for clarification, while evidence from the completed branches remains available.

Step 5: review and repair

After clarification, the regulatory artifact passes schema checks but uses an outdated rule version. The evaluator returns repair_required with the exact source and freshness defect. The same worker repairs within its remaining attempt cap.

Step 6: integrate and close

The manager detects a conflict between demand assumptions and channel costs, commissions one bounded reconciliation task, and updates the graph version. The final packet closes only after every required artifact is accepted, contradictions are resolved, the risk register is complete, and the human records the decision.

The example shows why the manager is only one part of the architecture. Durable state, policy, evaluation, and recovery services make flexible coordination inspectable and recoverable.

§ 16How Should a Manager Architecture Be Evaluated?

Test manager decisions and complete outcomes on representative cases.

An illustrative 32-case starter pack could include:

• 10 routine tasks with known decompositions;
• 5 tasks whose required children vary by input;
• 4 cases with an ineligible, unavailable, or rejecting worker;
• 3 cases with missing or conflicting input;
• 3 cases with malformed or unsupported artifacts;
• 2 cases with stale evidence;
• 2 cases with retry uncertainty after a possible side effect;
• 2 cases that require approval or human escalation;
• and 1 lineage-wide stop case.

The counts are illustrative, not universal thresholds. Replace the mix with observed task frequency and consequence.

Score checkpoints and the end state

Anthropic reports that dynamic multi-agent systems may take different valid paths from the same input, making one prescribed step sequence an incomplete evaluation. Its research-system account recommends outcome evaluation plus checkpoints for required state changes.

Use both:

• Checkpoint tests: eligibility passed, authority remained bounded, required artifacts existed, approval matched the action, and budgets held.
• End-state tests: the parent outcome was correct, complete, supported, reconciled, and safely closed.

Compare against a simpler baseline

Run the same cases through:

1. one agent with tools;
2. a fixed workflow or router;
3. and the manager architecture.

The manager should advance only if variable decomposition or coordination improves accepted outcomes enough to justify additional latency, cost, state, and recovery burden.

Use failure-weighted metrics

Do not average a policy violation into routine quality. Report severe failures separately:

• unauthorized assignment;
• approval bypass;
• cross-tenant access;
• unreconciled duplicate action;
• false parent closure;
• and inability to stop the lineage.

One severe control failure can outweigh many fluent outputs.

§ 17How Can Teams Introduce the Architecture Safely?

Start with one manager, one known specialist, and one reversible task type.

Phase 1: shadow coordination

The manager proposes decomposition and routes while a human performs the actual assignment. Compare candidate selection and missing tasks without giving the manager action authority.

Phase 2: read-only child work

Allow one specialist to accept a bounded research or analysis task. Require a typed artifact, evidence, explicit state, and human acceptance.

Phase 3: supervised repair

Enable one repair attempt and one reroute path. Verify that partial work, budgets, and task versions remain intact.

Phase 4: constrained concurrency

Add a small number of independent child tasks under an explicit concurrency and spend cap. Fault-test timeouts, rejection, and one slow branch.

Phase 5: bounded action proposals

Let workers prepare externally visible or state-changing actions, but keep exact approval and execution outside the manager.

Phase 6: measured expansion

Add workers, task types, or nested graphs only when existing metrics reveal a real bottleneck and the next boundary passes representative tests.

The architecture advances by task type, not by a broad claim that the manager model is ready for everything.

§ 18Where Can CellCog Fit?

CellCog publicly shows both an internal manager-worker organization and an external artifact-execution surface.

CellCog’s AI Organization page shows one human founder and nine active AI employees as of July 24, 2026. Its AI Sales Lead manages five sales representatives. CellCog says the manager delegates tasks to worker boards with context attached, workers return results, shared documents hold strategy, and handover notes maintain continuity.

The same page reports 267 shifts, $8,309 in spend, 360 closed tasks, 2,765 emails, and 271 dashboard updates from June 27 through July 24. These are dated first-party operating records, not universal manager-agent benchmarks or proof of every control described above.

On the CellCog Agent-to-Agent platform, CellCog says external agents can request research, media, documents, applications, dashboards, and code through one API and receive finished artifacts. That surface could serve as a bounded specialist node when the parent manager retains task state, acceptance, authority, and closure.

What should a buyer verify?

Ask CellCog to demonstrate the exact task type with:

• distinct manager, worker, user, and tenant identities;
• worker capability and version;
• parent and child state;
• bounded context transfer;
• task-scoped authority;
• time, spend, retry, depth, and concurrency controls;
• artifact evidence and acceptance;
• cancellation and partial recovery;
• approval for consequential actions;
• lineage-wide stop behavior;
• and complete event history.

Public pages establish product positioning and a visible operating example. Deployment still depends on proof that the exact workflow satisfies the buyer’s data, authority, evaluation, recovery, and audit requirements.

§ 19What Should Be on the Architecture Checklist?

Before enabling a manager architecture, confirm:

• The manager pattern beats a single-agent or fixed-workflow baseline.
• The parent outcome and closure owner are explicit.
• The manager owns coordination, not unrestricted domain execution.
• Identity, policy, budget, state, approval, and action services are external.
• Every child maps to a typed contribution and acceptance rule.
• Graph cycles, depth, child count, and deadlines are validated.
• The worker registry separates declared, verified, and current eligibility.
• Hard eligibility filters run before ranking.
• Workers explicitly accept assignments.
• Context is task-scoped and source-versioned.
• Worker credentials and manager credentials never cross the child edge.
• Parent and child state machines are separate and persistent.
• Budget reservations cannot exceed the parent envelope.
• Returned artifacts pass schema and domain review before synthesis.
• Repair, retry, reroute, and escalation have distinct conditions.
• Externally visible actions use idempotency and exact approval.
• Event history reconstructs every state, artifact, budget, and action change.
• Circuit breakers halt the complete affected lineage.
• Manager, routing, worker, review, recovery, and parent outcomes have separate measures.
• Expansion requires measured improvement on representative cases.

If authority, state, recovery, or closure exists only inside the manager’s conversation, the architecture is not ready for live use.

§ 20What Is the Final Decision?

A reliable manager-agent architecture gives one controller responsibility for coordination without giving it unrestricted power.

Let the manager decompose, rank eligible workers, supervise assignments, review returns, request repair, integrate accepted evidence, and close the parent outcome. Keep identity, policy, authority, budgets, state transitions, approvals, and consequential execution deterministic and independently enforceable.

Then test the controller by layer. Routing success does not prove worker quality, worker quality does not prove synthesis, and fluent synthesis does not prove safe closure.

Start with one parent, one known worker, one reversible contribution, and one persistent state path. Expand only when the complete accepted outcome improves and every additional edge remains bounded, observable, and recoverable.