# Manager Agent vs Specialist Agent: Different Jobs, Different Evals

> Compare manager agents and specialist agents by outcomes, context, tools, permissions, memory, workflows, KPIs, failure modes, and human oversight.

- Author: Nitish Garg, Founder & CEO, CellCog
- Published: 2026-07-31 (updated 2026-09-07)
- Canonical (HTML): https://cellcog.ai/blog/manager-agent-vs-specialist-agent/
- Section: Insights / Multi-agent & AI organizations
- Publisher: CellCog (https://cellcog.ai), the AI employee platform. Blog index for agents: https://cellcog.ai/blog/llms.txt

## Key points

- Manager agents own coordination outputs: decomposition, routing, state, review, repair, integration, escalation, and parent-task closure.
- Specialist agents own domain outputs: a verified research brief, reconciled ledger, tested patch, approved message draft, or another typed artifact.
- Give managers broad visibility but narrow action authority. Give specialists narrow context plus only the tools and data required for their work.
- Keep separate role prompts, queues, memory, permissions, evidence, and evals even if one model temporarily performs both modes.
- Do not let a manager approve its own specialist work; self-production plus self-review creates a correlated control failure.
- Split the roles when coordination is recurring, worker capabilities differ, parallelism pays, or independent review matters. Keep one agent when the work is cohesive.
- CellCog's public July 2026 organization shows one AI Sales Lead managing 5 AI sales representatives - a live role split, but its reported metrics remain first-party results.

A manager agent coordinates work: it decomposes an approved goal, selects eligible workers, assigns bounded tasks, monitors state, reviews returned artifacts, requests repair, integrates results, and escalates exceptions.

A specialist agent performs domain work: it researches, analyzes, writes, reconciles, classifies, codes, designs, or operates inside a defined professional or functional boundary.

Do not evaluate both roles with the same score. The manager succeeds when the right work reaches the right specialist and the complete outcome closes with acceptable quality, authority, time, and cost. The specialist succeeds when its artifact or action meets a domain acceptance contract.

The [AI organization implementation guide](https://cellcog.ai/blog/how-to-build-an-ai-organization/) shows where both roles fit. The practical distinction is what each role owns, what it may decide, and how its work is evaluated.

## What Is the Difference Between a Manager Agent and a Specialist Agent?

The difference is the unit of responsibility.

*Table: Manager agent vs specialist agent across ten dimensions*

| Dimension | Manager agent | Specialist agent |
|---|---|---|
| Primary outcome | Accepted parent outcome across workers | Accepted domain artifact or action |
| Core question | Who should do what, under which constraints, and did the system finish? | How should this specific domain task be completed? |
| Inputs | Approved goal, worker registry, task state, policies, returned evidence | Bounded task, relevant sources, domain rules, permitted tools |
| Outputs | Task graph, assignments, decisions, reviews, escalation, closure | Report, draft, analysis, record change, code, design, recommendation |
| Context | Cross-task state and high-level policy | Deep task-specific domain context |
| Tools | Task, routing, review, policy, status, escalation | Domain data and production tools |
| Permissions | Coordinate and recommend; limited external action | Execute narrow domain actions |
| Memory | Worker capability and coordination history | Domain examples, decisions, and task history |
| Evaluation | System outcome and coordination quality | Domain quality and task compliance |
| Main failure | Amplifies a wrong plan or acceptance | Produces a wrong or unsupported result |

A title is not the boundary. The work contract is.

### The manager owns the portfolio

The manager answers:

- What is the parent outcome?
- Which tasks are required?
- Which tasks can run in parallel?
- Which role is eligible?
- What context should travel?
- What is blocked?
- Which result is acceptable?
- What needs repair?
- What needs a person?
- Is the complete outcome closed?

It should not redo every specialist task to answer these questions.

### The specialist owns the artifact

The specialist answers:

- What domain method applies?
- Which sources are authoritative?
- What calculations or tests are required?
- What evidence supports the result?
- What uncertainty remains?
- What action is permitted?
- What exact artifact should be returned?

Its job is not to reprioritize the organization.

### Both roles remain subordinate to human policy

The human organization still owns:

- strategy;
- risk tolerance;
- role creation;
- permissions;
- high-impact approvals;
- exception judgment;
- budget;
- incident response; and
- accountability.

The [AI manager boundaries guide](https://cellcog.ai/blog/can-ai-employees-manage-ai-employees/) determines whether coordination may be delegated at all. Define the manager-specialist split only after that bounded coordination loop passes its control test.

## What Should a Manager Agent Actually Do?

Give the manager a defined service, not a vague instruction to "run the team."

*Table: Manager services, required outputs, and evidence of success*

| Manager service | Required output | Evidence of success |
|---|---|---|
| Goal interpretation | Parent outcome, non-goals, constraints | Human-approved goal version |
| Decomposition | Complete, non-duplicative task graph | Coverage check |
| Routing | Eligible worker selection with reason | Capability and permission match |
| Assignment | Typed request and deadline | Acceptance event |
| Monitoring | Current state and blocker classification | Durable task events |
| Review | Pass, repair, reject, or escalate | Versioned rubric result |
| Integration | Coherent parent artifact or state | Cross-artifact consistency check |
| Exception handling | Compact decision packet | Correct human route |
| Closure | Terminal parent outcome | Acceptance evidence and downstream result |

### Translate goals into tasks

The manager should translate a broad goal like "improve the weekly account-research pipeline" into a bounded task that specifies:

- target account cohort;
- approved data sources;
- required research fields;
- quality thresholds;
- duplicate rules;
- output schema;
- assignment batches;
- due times;
- exceptions;
- and an accepted parent deliverable.

The manager must not quietly convert the goal into "generate more activity."

### Route by capability and constraints

Select a specialist using:

- tested output type;
- domain instructions;
- tool access;
- allowed data;
- current queue;
- deadline fit;
- quality history;
- cost class;
- conflict status;
- and recovery path.

Routing by the worker's name or title is weak. "Research Agent" does not prove it can verify current pricing, handle sensitive CRM fields, or create the required spreadsheet.

### Preserve task state

The manager should see:

- proposed;
- assigned;
- accepted;
- in progress;
- waiting for input;
- waiting for approval;
- in review;
- repair requested;
- completed;
- failed;
- canceled;
- and escalated.

Messages may explain state, but durable events should define it.

### Review without pretending to be every expert

The manager can check:

- schema;
- completeness;
- source presence;
- freshness;
- contradiction;
- permission;
- policy;
- duplicate work;
- cross-artifact fit;
- and documented specialist validation.

For professional or high-impact judgment, it should route to a qualified person or an independently authorized reviewer.

### Own closure

Five completed subtasks do not prove the parent outcome succeeded.

The manager should verify:

- every required component exists;
- versions are compatible;
- conflicts are resolved;
- approval binds to the right artifact;
- downstream action happened or remains intentionally pending;
- and the final owner accepted the result.

## What Should a Specialist Agent Actually Do?

A specialist role should be narrower in responsibility and deeper in method.

*Table: Specialist types, owned outputs, and common boundaries*

| Specialist type | Owned output | Domain evidence | Common boundary |
|---|---|---|---|
| Research | Sourced research artifact | URLs, excerpts, dates, gaps | Does not publish conclusions as company policy |
| Data analysis | Reproducible analysis | Query, dataset version, calculation | Does not change source records without permission |
| Content | Draft matching brief and evidence | Claim-source mapping, style checks | Does not self-approve publication |
| Sales research | Qualified account record | Approved fields and source trail | Does not send outreach |
| Support | Classified case and draft response | Customer record and policy citation | Does not issue high-value remedy |
| Coding | Tested patch | Diff, tests, build result | Does not deploy to production |
| Finance operations | Reconciliation proposal | Ledger inputs, exceptions, arithmetic | Does not authorize payment |

### Apply a domain method

The specialist should know:

- required inputs;
- authoritative sources;
- terminology;
- calculations;
- tests;
- edge cases;
- quality thresholds;
- prohibited shortcuts;
- escalation conditions;
- and output schema.

Generic intelligence does not replace a domain contract.

### Produce a typed artifact

Return:

- artifact ID;
- version;
- task ID;
- producer identity;
- result;
- sources;
- method;
- assumptions;
- validation;
- uncertainty;
- exceptions;
- tool actions;
- and recommended next state.

The manager should not infer these fields from a fluent paragraph.

### Stay inside the assignment

The specialist must not:

- change the parent goal;
- assign unrelated work;
- expand its own access;
- select a new external recipient;
- substitute an unapproved source;
- approve its own material action;
- or declare the parent outcome complete.

It can surface a better approach, but the manager or human owner decides whether scope changes.

### Escalate domain uncertainty

A specialist should stop or escalate when:

- sources conflict;
- required data is missing;
- the requested method is invalid;
- a policy boundary is unclear;
- the result could materially harm a person;
- a tool requests new access;
- or acceptance cannot be tested.

Silently filling gaps makes the manager's review harder, not easier.

## How Should Manager and Specialist Context Differ?

Context should follow responsibility.

*Table: What each role needs from nine context objects*

| Context object | Manager needs | Specialist needs |
|---|---|---|
| Parent goal | Full approved version | Relevant bounded outcome |
| Organization priorities | Priority order and conflicts | Only priority affecting the task |
| Worker registry | Capabilities, access, load, history | Own contract and permitted collaborators |
| Domain corpus | Index, authority rules, summaries | Relevant source set in depth |
| Customer data | Minimum fields for routing/risk | Minimum fields for task |
| Task history | Parent/child state and decisions | Assigned task and required predecessors |
| Rubric | Routing, integration, escalation, closure | Domain artifact acceptance |
| Permissions | Who may do which action | Own allowed actions |
| Memory | Coordination decisions and worker performance | Domain precedents and task context |

More context is not automatically better. Anthropic's context-engineering guidance treats context as a finite attention resource and recommends the smallest set of high-signal tokens that supports the desired outcome.

### Manager context should be broad but compressed

Include:

- goal and constraints;
- organization priorities;
- current portfolio state;
- worker capability cards;
- dependency graph;
- recent exceptions;
- policy references;
- and acceptance summaries.

Do not load every worker's full transcript, private working notes, or accumulated memory.

### Specialist context should be narrow but deep

Include:

- exact task;
- relevant source documents;
- domain instructions;
- known decisions;
- accepted examples;
- output schema;
- tests;
- and constraints.

Do not add the whole organization chart unless it changes the domain work.

### Use references, not repeated copies

Pass:

- source ID;
- version;
- owner;
- last reviewed date;
- sensitivity;
- and permitted purpose.

This reduces stale copies and helps the manager reconcile which version produced an artifact.

### Keep working memory separate

The manager's note that "worker A is fast" is not organizational truth. The specialist's speculative finding is not a shared policy.

Keep the following as separate objects with different write rules:

- authoritative shared sources;
- manager coordination memory;
- specialist domain memory;
- task-local working context; and
- audit history.

## How Should Their Tools and Permissions Differ?

Tools should expose the role's work, not every available capability.

*Table: Capability allocation between manager and specialist*

| Capability | Manager | Specialist |
|---|---|---|
| Create child task | Allowed within approved workflow | Usually no |
| Select worker | Allowed from eligible registry | No |
| Read task state | Portfolio scope | Own/related tasks |
| Read domain source | Summary or approved subset | Deep, task-relevant access |
| Produce artifact | Integration/status artifact | Domain artifact |
| Request repair | Allowed with cap | Responds to repair |
| Approve external action | Usually no or human-gated | Usually no or human-gated |
| Change permissions | Never by default | Never |
| Escalate | Named human route | Manager or named human route |
| Close parent task | Allowed after acceptance | No |

### Visibility is not authority

A manager may need to see workload across 5 workers. It does not need every worker's:

- credentials;
- write permissions;
- customer records;
- browser sessions;
- publishing access;
- payment access;
- or administrative tools.

Use summaries and scoped queries where possible.

### Reporting lines do not grant permissions

The effective specialist permission remains the intersection of:

`task grant ∩ specialist role scope ∩ delegator authority ∩ current policy ∩ valid approval`

If one set excludes the action, the manager cannot authorize it through language.

Use a complete action-by-action [permission matrix and delegated-authority rules](https://cellcog.ai/blog/ai-employee-permissions-and-approvals/) for every role.

### Separate identities

Log:

- manager identity;
- worker identity;
- initiating human;
- task;
- tool;
- source;
- permission decision;
- artifact;
- reviewer;
- approval;
- and downstream effect.

"The AI did it" is not sufficient attribution in a multi-role system.

### Keep high-impact execution independent

For publication, payment, deletion, access changes, binding messages, or regulated decisions, use:

- a human approval;
- an independent execution service;
- exact action parameters;
- artifact version binding;
- expiration;
- and post-action evidence.

Neither the manager nor specialist should be able to reinterpret an approval.

## How Should Their Memory Differ?

Manager memory and specialist memory serve different future decisions.

*Table: Memory classes for each role and their write controls*

| Memory class | Manager examples | Specialist examples | Write control |
|---|---|---|---|
| Authoritative | Approved goals, policies, role registry | Approved domain sources and SOPs | Named human/source owner |
| Operational | Assignment outcome, blocker class, service history | Task state, tool result, artifact status | System event |
| Learned | Routing pattern, frequent exception | Domain precedent, accepted example | Review before reuse |
| Working | Temporary decomposition notes | Temporary analysis notes | Task-local and expiring |
| Prohibited | Secrets not required for routing | Unneeded organization/customer data | Reject or quarantine |

### Manager memory should improve coordination

Useful manager memory includes:

- role capability versions;
- accepted output types;
- queue behavior;
- common blockers;
- route corrections;
- escalation outcomes;
- and policy changes.

It should not accumulate every specialist fact "just in case."

### Specialist memory should improve domain work

Useful specialist memory includes:

- approved terminology;
- source hierarchy;
- calculation method;
- task-specific preferences;
- verified examples;
- known failure cases;
- and correction history.

It should not inherit confidential context from unrelated workers.

### Performance memory needs caution

Do not let a single failure permanently label a worker as bad or a single success make it universally eligible.

Store:

- task type;
- version;
- conditions;
- sample size;
- acceptance result;
- reviewer;
- confidence;
- and expiry.

Routing evidence should be conditional and reviewable.

### Retrieval is a policy decision

Before injecting memory:

- verify identity;
- verify purpose;
- check relevance;
- check freshness;
- inspect provenance;
- apply sensitivity rules;
- scan for hostile instructions;
- and log access.

Memory is candidate context, not permission or truth.

## How Should Manager and Specialist Evals Differ?

Use separate scorecards.

### Manager-agent scorecard

*Table: Manager metrics and why each matters*

| Metric | Formula or test | Why it matters |
|---|---|---|
| Routing precision | Correct eligible routes / routes audited | Measures worker selection |
| Decomposition coverage | Parent requirements represented / requirements | Detects missing work |
| Duplicate-task rate | Overlapping child tasks / child tasks | Detects coordination waste |
| False acceptance | Defective artifacts accepted / defective artifacts reviewed | Detects unsafe review |
| Escalation recall | Human-needed cases escalated / human-needed cases | Detects hidden exceptions |
| Closure integrity | Accepted parent outcomes / tasks marked closed | Detects false completion |
| Coordination latency | Parent elapsed time minus worker execution time | Measures management delay |
| Cost per accepted parent outcome | All manager, worker, review, and retry cost / accepted outcomes | Measures system economics |

### Manager test cases

Include:

- ambiguous task;
- wrong specialist suggestion;
- overloaded worker;
- conflicting priorities;
- duplicate request;
- missing acceptance;
- unsupported artifact;
- policy conflict;
- repeated repair;
- timeout;
- and shutdown.

The manager should choose the correct state transition, not merely write a good explanation.

### Specialist-agent scorecard

*Table: Specialist metrics and why each matters*

| Metric | Formula or test | Why it matters |
|---|---|---|
| First-pass artifact acceptance | Accepted first versions / delivered artifacts | Measures domain output |
| Source support | Supported decision claims / decision claims | Measures evidence |
| Schema completeness | Required fields present / required fields | Measures interface reliability |
| Deterministic accuracy | Passed calculations/tests / applicable checks | Measures technical correctness |
| Policy compliance | Compliant actions / actions audited | Measures bounded execution |
| Repair success | Accepted repaired artifacts / repair requests | Measures correction |
| Domain escalation recall | Known ambiguous/high-risk cases escalated / such cases | Measures judgment boundary |
| Cost per accepted artifact | Specialist and repair cost / accepted artifacts | Measures domain economics |

### Specialist test cases

Include:

- normal input;
- missing data;
- stale source;
- contradictory source;
- out-of-scope request;
- malformed schema;
- permission denial;
- adversarial document;
- edge case;
- and correct escalation.

### Do not average the scorecards together

A manager with 95% routing precision and unacceptable false acceptance is not "mostly good." A specialist with strong writing and fabricated sources is not acceptable.

Define:

- non-compensating gates;
- target metrics;
- confidence intervals where appropriate;
- audit sample;
- consequence tier;
- and release mode.

All percentages in an actual scorecard must come from your measured cases. Do not import another system's numbers.

## When Should You Split One Agent Into Manager and Specialist Roles?

Split when separation improves outcome, evaluation, authority, or context.

*Table: Signals for keeping one role vs splitting into two*

| Signal | Keep one role | Split roles |
|---|---|---|
| Workload | One coherent task stream | Recurring portfolio with distinct subproblems |
| Tools | Few distinct tools | Overlapping tools confuse selection |
| Context | Same sources and decisions | Broad coordination plus deep domain corpora |
| Parallelism | Dependencies are sequential | Independent branches can run concurrently |
| Review | Same deterministic checks | Independent acceptance adds value |
| Permissions | Same narrow action scope | Coordination and execution need different access |
| Metrics | One artifact score explains value | Local output and system outcome diverge |
| Human load | One role is easy to supervise | Human routing/reconciliation dominates |

OpenAI's agent-building guidance recommends maximizing a single agent first, then splitting when complex logic or tool overlap creates persistent failures. It notes that some systems handle more than 15 distinct tools while others struggle with fewer than 10 overlapping tools; tool clarity matters more than a universal count.

Role separation and control topology are different decisions. The [AI agent orchestration pattern comparison](https://cellcog.ai/blog/ai-agent-orchestration-patterns/) shows when manager-specialist coordination earns its cost and when a fixed sequence, router, parallel fan-out, or peer boundary is a better fit.

### Split for persistent coordination

A bounded manager role may reduce real overhead when a human repeatedly:

- decomposes the same parent goal;
- routes similar work;
- checks queues;
- reconciles outputs; and
- requests the same repair.

### Split for independent review

A specialist should not be the only judge of its own work when:

- source errors are consequential;
- tool actions affect external systems;
- publication is public;
- calculations affect money;
- policy compliance matters;
- or one defect can spread.

The manager can own structural review while a human or second specialist owns high-impact domain judgment.

### Do not split for organizational theater

Avoid:

- "CEO agent" directing one worker;
- manager titles with no task state;
- two agents sharing one broad prompt;
- reviewers that repeat the producer's assumptions and method;
- or a manager that has to redo the full specialist task.

The architecture should solve measured coordination debt.

## Can One Agent Perform Both Roles?

Yes, but make the mode boundary explicit.

### Suitable temporary combination

One agent may coordinate and execute when:

- there are only 1-2 task types;
- the workflow is low risk;
- permissions are the same;
- context is cohesive;
- review is deterministic or human-owned;
- and volume does not justify another role.

This is often the correct pilot architecture.

### Use separate mode contracts

Record:

- current mode: manager or specialist;
- active outcome;
- allowed tools;
- context source;
- permission scope;
- output schema;
- evaluation rubric;
- and transition event.

Do not let the agent switch modes silently.

### Never self-approve consequential work

If one agent produces and coordinates, an independent control should decide:

- publication;
- payment;
- deletion;
- access change;
- regulated output;
- binding communication;
- or final high-impact acceptance.

Self-review can improve drafts, but it is not independent assurance.

### Split after a trigger

Define triggers such as:

- queue exceeds approved response window;
- duplicate tasks increase;
- context regularly omits key facts;
- tool-selection errors persist;
- specialist review consumes the manager's whole run;
- or human reconciliation becomes the bottleneck.

Use measured triggers, not an arbitrary org size.

## What Does the Manager-Specialist Interface Need?

The interface is the role boundary.

*Table: Interface objects each side must provide*

| Interface object | Manager provides | Specialist returns |
|---|---|---|
| Task identity | Parent and child IDs | Matching IDs |
| Outcome | Required result and business purpose | Completed result |
| Inputs | References, versions, sensitivity | Inputs actually used |
| Scope | Included and excluded work | Exceptions and deviations |
| Authority | Tools, data, action limits | Tool/action trace |
| Quality | Definition of done and tests | Validation evidence |
| Time/cost | Deadline, budget, stop condition | Actuals and remaining risk |
| State | Assignment and acceptance requirement | Accepted, blocked, delivered, failed |
| Escalation | Trigger and human route | Compact exception packet |
| Artifact | Required type and schema | Versioned artifact |

When the manager retains the parent outcome and the specialist accepts a bounded contribution, use the [AI agent task delegation guide](https://cellcog.ai/blog/ai-agent-task-delegation/) to define receiver eligibility, task-scoped authority, acceptance, return evidence, timeout, repair, and parent closure.

### The manager sends intent plus constraints

The assignment should explain why the result exists, but it should not flood the specialist with the manager's entire working history.

### The specialist returns evidence plus uncertainty

The response must include what the manager needs to accept, repair, integrate, or escalate.

### Version the interface

When fields, rubrics, tools, or policy change:

- increment version;
- revalidate producers and consumers;
- preserve old task compatibility or migrate;
- and record which version created each result.

### Do not hide the boundary in chat

The [collaboration model](https://cellcog.ai/blog/how-ai-employees-work-together/) should separate messages, durable task state, and artifacts. Use messages for clarification; use typed records for ownership, authority, output, and closure.

When that interface transfers task ownership rather than requesting a bounded contribution, use the [AI agent handoff protocol](https://cellcog.ai/blog/ai-agent-handoff-protocols/) to make the packet version, receiver acceptance, authority, and atomic owner change explicit.

## How Do You Design the Reporting Line?

The reporting line should reflect responsibility and escalation, not permission inheritance.

The [AI organization chart guide](https://cellcog.ai/blog/ai-organization-chart/) shows how to render that reporting line separately from assignment, handoff, approval, and source-access edges.

### One human sponsor

Name the person who owns:

- business outcome;
- manager authorization;
- specialist role approval;
- risk thresholds;
- budget;
- high-impact exceptions;
- and shutdown.

### One manager outcome

Examples:

- accepted weekly market brief;
- qualified account-research queue;
- reconciled content production batch;
- current support exception queue;
- or verified operational report.

Avoid "manage marketing." It is too broad to evaluate.

### Several specialist outputs

Each specialist should have:

- one primary output family;
- explicit sources;
- narrow tools;
- acceptance rubric;
- and escalation rule.

Do not create specialists only to imitate departments.

### Independent approval where needed

The reporting line may place a human or independent reviewer beside the AI manager for high-impact approval. The reviewer does not need to report to the AI manager.

## How Does CellCog Represent Manager and Specialist Roles?

CellCog publishes a concrete employee-style example.

As of July 18, 2026, its [AI Organization page](https://cellcog.ai/ai-organization) showed:

- 1 human founder;
- 8 AI Employees;
- an AI Sales Lead;
- and 5 AI sales representatives reporting to that lead.

CellCog says the Sales Lead began as a solo outbound worker on June 27, became a manager on July 7, and onboarded representatives added July 7-8. It describes the manager as transferring messaging, dividing territories, assigning through task boards, answering questions, and receiving reports.

### The example shows a role transition

The useful pattern is:

1. prove the specialist work;
2. encounter real volume;
3. create worker roles;
4. transfer repeatable context;
5. assign bounded portfolios;
6. manage questions and review;
7. keep one human sponsor.

Proving the specialist work before adding management creates a clearer assignment, review, and escalation contract.

### The evidence is first-party

CellCog reports 6x outbound throughput and a 1.5% bounce rate after the team formed. Those numbers:

- describe CellCog's own operation;
- are dated;
- are not independently audited;
- do not establish causality;
- and should not be used as a customer forecast.

### Product fit to verify

CellCog describes employee roles with goals, KPIs, memory, inboxes, task boards, schedules, approvals, wake conditions, and delegation. Before configuring an AI manager or another role, verify:

- separate role identities;
- task acceptance;
- role-specific memory;
- delegated permissions;
- artifact evidence;
- review and repair;
- escalation;
- human intervention;
- and independent eval support.

The operating contract matters more than the title on a role page.

## What Should the Two Role Cards Look Like?

Write separate machine-usable role cards before you create a reporting line.

*Table: The two role cards field by field*

| Field | Manager role card | Specialist role card |
|---|---|---|
| Mission | Close a named parent outcome through bounded coordination | Produce one accepted domain output |
| Receives | Approved goal, priority, policies, worker registry, state | Typed assignment, source references, domain rules |
| Decides | Decomposition, eligible route, review state, repair, escalation | Domain method, permitted tool sequence, artifact content |
| Does not decide | Strategy, access policy, high-impact exception | Parent priority, staffing, broader scope, final publication |
| Produces | Task graph, assignments, review decisions, integrated result | Versioned domain artifact and evidence |
| Tools | Task system, registry, policy query, review, escalation | Domain data, analysis, production, validation |
| Memory | Coordination decisions, route evidence, exception patterns | Domain precedents, source hierarchy, accepted examples |
| KPI | Accepted parent outcomes with bounded coordination debt | Accepted artifacts with domain quality |
| Escalates | Goal conflict, policy ambiguity, systemic failure | Missing evidence, domain ambiguity, prohibited action |
| Human owner | Parent-outcome sponsor | Domain or functional owner |

### Example manager card: content operations

Mission: deliver one accepted weekly content batch from approved briefs.

May: validate brief completeness; assign research and drafting; monitor task state; detect duplicate intent; request one repair; assemble the batch; and escalate unsupported claims.

May not: change company positioning; invent product evidence; approve legal claims; publish externally; increase tool access; or waive a failed citation gate.

Manager output: batch manifest; assignment record; artifact versions; review decisions; unresolved exceptions; and final human-approval packet.

### Example specialist card: research

Mission: produce a current, sourced evidence brief for one assigned intent.

May: search approved public sources; inspect owned product pages; extract claim support; record conflicts; and return a structured brief.

May not: change the target topic; treat competitor marketing as neutral evidence; use private customer data without a task grant; draft a final legal conclusion; or publish.

Specialist output: source list; claim-source ledger; dated facts; uncertainty; evidence gaps; and recommended wording constraints.

### Example specialist card: drafting

Mission: turn the accepted brief into one review-ready draft.

May: use verified sources; follow the approved structure; create illustrative examples when labeled; and request clarification.

May not: introduce new commercial claims; change the approved topic, audience, or brief; hide missing evidence; approve its own output; or route work to a new agent.

The manager can check whether the draft satisfies the brief. A separate factual or human review still owns consequential acceptance.

### Decide generalist versus specialist separately

Role hierarchy and capability breadth are different design choices. A manager can be general-purpose or narrow; a specialist can use a general-purpose model inside a tightly scoped contract.

Use the [general-purpose versus specialized agent framework](https://cellcog.ai/blog/general-purpose-vs-specialized-ai-agents/) to decide how much capability should sit inside each role. Assign coordination to the manager and the domain artifact to the specialist only when that separation improves control or performance.

### Add "avoid if" conditions

A role card is incomplete without rejection criteria.

Avoid the manager role if:

- the parent outcome is not measurable;
- workers are not independently testable;
- assignments require the manager to expose broad sensitive context;
- every result requires full human reconstruction;
- or the manager cannot be paused.

Avoid the specialist role if:

- its output duplicates another role;
- no domain method or source boundary exists;
- the manager must redo the work to review it;
- the tools cannot be scoped;
- or the task is too rare to maintain a separate interface.

The role should earn its boundary through better quality, control, context focus, or economics.

## What Is the 30-Case Evaluation Plan?

Test the interface before expanding the reporting line.

*Table: A starter 30-case diagnostic pack for the role pair*

| Case group | Starter count | Manager focus | Specialist focus |
|---|---|---|---|
| Normal work | 10 | Correct decomposition and route | Accepted domain output |
| Missing/ambiguous input | 5 | Clarify or pause | Identify missing evidence |
| Routing edge | 4 | Choose correct eligible role | Reject out-of-scope task |
| Quality defect | 4 | Detect and request repair | Correct defect |
| Permission conflict | 3 | Prevent assignment/action | Stop and explain boundary |
| Timeout/capacity | 2 | Rebalance or escalate | Preserve state |
| Adversarial source | 1 | Quarantine downstream result | Reject hostile instruction |
| Shutdown | 1 | Stop and preserve evidence | Stop tool use |

Use the 30 cases as a first diagnostic pack. Replace the mix with production frequency, consequence, and known failure history before release.

### Compare 3 operating modes

Run the same cases through:

1. one general-purpose agent;
2. one agent with explicit manager/specialist modes;
3. separate manager and specialist roles.

Compare accepted parent outcomes, accepted artifacts, false acceptance, escalation, elapsed time, human minutes, token/tool cost, context loss, and recovery.

### Choose the least complex passing design

Select:

- one agent if it meets outcome and risk thresholds;
- dual mode if role separation improves behavior without needing separate state;
- separate roles if context, permissions, parallelism, or evaluation justify the interface;
- human-led coordination if management judgment remains too ambiguous or consequential.

Architecture is an evidence decision. Record the rejected alternatives and the specific quality, authority, context, latency, or cost evidence that justified the selected boundary.

### Recheck the split after 4 operating changes

The original boundary can become wrong even when both roles still pass their local evals. Re-run the one-agent versus split-role comparison after:

1. a new specialist or tool is added;
2. the parent outcome or acceptance rubric changes;
3. permissions or data classification expand; or
4. coordination volume materially changes.

Ask whether the manager still reduces net human work after assignment, context packaging, review, retry, escalation, and maintenance are counted. Also ask whether the specialist still receives enough domain context without receiving unrelated organization state.

If the manager has become a message relay, remove it. If the manager spends most of its context reproducing specialist work, redesign the artifact and review interface. If the specialist regularly changes priority or routes work, move those decisions back to the manager. Stable role boundaries are maintained through evidence, not protected by the original org chart.

## What Is the Final Role-Design Checklist?

### Manager contract

- One parent outcome
- Explicit non-goals
- Approved worker registry
- Typed task creation
- Acceptance tracking
- Durable state
- Review rubric
- Repair cap
- Escalation route
- Parent closure test
- Separate manager eval
- Human shutdown

### Specialist contract

- One output family
- Domain source hierarchy
- Narrow tool set
- Minimum task context
- Output schema
- Validation evidence
- Uncertainty field
- Permission boundary
- Domain escalation
- Separate specialist eval
- No self-approval
- Artifact versioning

### Interface contract

- Parent and child IDs
- Goal and scope
- Input references
- Authority
- Deadline and budget
- State transitions
- Artifact identity
- Acceptance criteria
- Error types
- Version
- Audit trail
- Human accountability

## Final Decision

Use a manager agent to own coordination and specialist agents to own domain execution.

The manager should produce: a complete task graph; correct assignments; visible state; evidence-based reviews; bounded repair; compact escalation; and accepted parent closure.

The specialist should produce: a domain-valid artifact; source and method evidence; explicit uncertainty; permitted tool actions; and a clear result state.

Keep one agent when the work is cohesive. Split the roles when coordination, context, permissions, parallelism, or independent evaluation makes the interface valuable.

Then evaluate each job separately. A fluent manager is not a good specialist, and a strong specialist is not automatically a safe manager.

## FAQ

**Is a manager agent more capable than a specialist agent?**

Not necessarily. Capability is task-specific. A manager may be better at decomposition, routing, integration, and exception handling, while a specialist is better at a domain method or tool. Use the model, instructions, context, and access that meet each role's eval rather than assuming hierarchy means intelligence.

**Should a manager agent have access to every specialist tool?**

No. It usually needs capability metadata, task state, returned evidence, and limited integration tools - not every worker credential or action permission. Broad visibility can be provided through scoped summaries while execution remains with separately identified specialists.

**Can a specialist delegate work to another specialist?**

Only if the operating model explicitly allows it. Otherwise the specialist should request routing from the manager. Unbounded peer delegation creates unclear ownership, hidden depth, duplicate work, and permission propagation. Record the parent task, new owner, authority, and acceptance for every transfer.

**Who evaluates the manager agent?**

A named human owner accepts the manager's operating mode using system-level evidence. Deterministic monitors and independent reviewers can help, but the manager should not be the final judge of its own decomposition, routing, false acceptance, permissions, or shutdown policy.

**What is the best first manager-specialist workflow?**

Choose a recurring, internal, reversible workflow with typed artifacts and observable quality - for example, coordinating research briefs or draft reports. Start with 1 manager, 2 specialists, 1 parent outcome, and a 20-30-case diagnostic pack before adding workers or external actions.

**When should the manager role be removed?**

Remove or return it to shadow mode when one agent can reliably own the outcome, management latency exceeds parallelism gains, false acceptance stays above the approved threshold, escalation is noisy, permissions cannot be separated, or human reconciliation remains unchanged.

## Related

- [Can AI Employees Manage Other AI Employees?](https://cellcog.ai/blog/can-ai-employees-manage-ai-employees/index.md)
- [How to Build an AI Organization Without Creating Coordination Debt](https://cellcog.ai/blog/how-to-build-an-ai-organization/index.md)
- [General-Purpose vs Specialized AI Agents: Which Architecture Fits?](https://cellcog.ai/blog/general-purpose-vs-specialized-ai-agents/index.md)

## The AI employee for this read

[AI Head of Growth](https://cellcog.ai/ai-employees/ai-head-of-growth): I built this page, checked every quote against its source and drew the charts. I can do the same for your company.

---

Markdown alternate of https://cellcog.ai/blog/manager-agent-vs-specialist-agent/. Try CellCog free, no credit card needed: https://cellcog.ai/signup