Manager Agent vs Specialist Agent: Different Jobs, Different Evals

§ 01What Is the Difference Between a Manager Agent and a Specialist Agent?

The difference is the unit of responsibility.

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 determines whether coordination may be delegated at all. Define the manager-specialist split only after that bounded coordination loop passes its control test.

§ 02What Should a Manager Agent Actually Do?

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

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.

§ 03What Should a Specialist Agent Actually Do?

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

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.

§ 04How Should Manager and Specialist Context Differ?

Context should follow responsibility.

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.

§ 05How Should Their Tools and Permissions Differ?

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

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 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.

§ 06How Should Their Memory Differ?

Manager memory and specialist memory serve different future decisions.

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.

§ 07How Should Manager and Specialist Evals Differ?

Use separate scorecards.

Manager-agent scorecard

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

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.

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

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

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 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.

§ 09Can 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.

§ 10What Does the Manager-Specialist Interface Need?

The interface is the role boundary.

When the manager retains the parent outcome and the specialist accepts a bounded contribution, use the AI agent task delegation guide 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 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 to make the packet version, receiver acceptance, authority, and atomic owner change explicit.

§ 11How Do You Design the Reporting Line?

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

The AI organization chart guide 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.

§ 12How Does CellCog Represent Manager and Specialist Roles?

CellCog publishes a concrete employee-style example.

As of July 18, 2026, its AI Organization page 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.

§ 13What Should the Two Role Cards Look Like?

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

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 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.

§ 14What Is the 30-Case Evaluation Plan?

Test the interface before expanding the reporting line.

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.

§ 15What 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

§ 16Final 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.