# How AI Employees Work Together: Delegation, Handoffs, and Shared Context

> How AI employees coordinate through explicit task states, typed delegation, shared artifacts, bounded authority, review, escalation, and accountable closure.

- Author: Nitish Garg, Founder & CEO, CellCog
- Published: 2026-07-31
- Canonical (HTML): https://cellcog.ai/blog/how-ai-employees-work-together/
- 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

- Start collaboration only when a second role resolves a specific capability, capacity, permission, independence, or context boundary.
- Give every collaboration a parent task, one closure owner, a typed request, explicit acceptance, a deadline, a budget, and a stop condition.
- Exchange versioned artifacts and source references. Messages carry coordination; they should not be the only durable result or state record.
- Separate delegation from handoff: a delegator normally retains the parent outcome, while a true handoff transfers defined ownership after acceptance.
- Treat returned agent work as untrusted input until schema, source, policy, permission, and acceptance checks pass.
- Keep shared authoritative sources distinct from role working memory. Do not let one agent's unverified note become organization-wide truth.
- Measure accepted system outcomes, handoff integrity, misroutes, rework, duplicate actions, human intervention, latency, and cost.

AI employees work together when they coordinate around durable tasks, explicit ownership, bounded authority, versioned artifacts, shared approved sources, review criteria, escalation, and closure.

They do not collaborate merely because agents can send messages to one another.

A useful collaboration has a beginning and end: one role requests a defined result, another explicitly accepts it, work and state remain visible, the result arrives as an identifiable artifact, acceptance is recorded, and one owner closes or escalates the complete outcome.

The [AI organization design guide](https://cellcog.ai/blog/how-to-build-an-ai-organization/) defines which roles and edges should exist. A collaboration contract then governs how each edge operates.

## What Does AI Employee Collaboration Mean?

AI employee collaboration is a governed exchange of responsibility, context, work, evidence, and decisions between persistent roles.

*Table: Seven coordination types and what happens to ownership in each*

| Coordination type | What happens | Ownership after exchange | Example |
|---|---|---|---|
| Consult | One role asks for advice | Requester retains all work | Writer asks legal assistant for issue spotting |
| Delegate sub-task | One role assigns a bounded contribution | Delegator retains parent outcome | Growth manager requests market research |
| Handoff | Defined task ownership transfers | Receiver owns accepted scope | Triage role routes accepted support case |
| Review | One role evaluates another's artifact | Producer owns revision; closure owner decides | Verifier checks cited claims |
| Approval | Authorized role/person permits exact action | Executor remains responsible for execution evidence | Human approves specified email |
| Notify | One role shares state without requesting work | No ownership transfer | Operations role announces source update |
| Escalate | Work moves to higher authority for a decision | Current owner retains or explicitly transfers | Agent requests exception judgment |

The relationship name should determine required fields, permissions, state changes, and evidence.

### Conversation is not coordination

Messages can clarify a question, report progress, or carry a request. They do not prove:

- task creation;
- acceptance;
- ownership;
- permitted authority;
- artifact delivery;
- source provenance;
- review;
- completion;
- external action; or
- closure.

Store those events in a durable task and evidence system.

### Coordination is an interface

Each role can remain internally flexible while exposing a stable boundary:

- capability;
- input;
- output;
- state;
- error;
- authority;
- evidence; and
- service expectation.

That makes the organization easier to change without rewriting every role.

### Collaboration must improve the system

Add an edge only when it improves:

- outcome quality;
- independent verification;
- elapsed time;
- capacity;
- permission separation;
- context focus;
- domain depth; or
- recovery.

If the edge adds more clarification, review, retry, and context loss than value, keep the work with one role.

## Why Is Agent-to-Agent Chat Not Enough?

Free-form chat hides state and responsibility.

### Messages are transient coordination

The official Agent2Agent (A2A) Protocol specification separates messages from artifacts. Messages can initiate tasks, request clarification, and communicate status; results should be returned as artifacts associated with a task.

That distinction is useful even when a platform does not implement A2A. It prevents "the answer was somewhere in the conversation" from becoming the operating model. The broader [agent-to-agent communication contract](https://cellcog.ai/blog/what-is-agent-to-agent-communication/) shows how discovery, identity, relationship, authority, state, and result delivery fit around those messages and artifacts.

### Task status must be authoritative

A role can say "working on it" after a tool has failed or "done" before the parent outcome is accepted.

State should come from explicit events:

- assigned;
- accepted;
- in progress;
- waiting for input;
- waiting for approval;
- review;
- rework;
- completed;
- failed;
- canceled; or
- escalated.

Do not infer state from tone.

### Artifacts need identity and version

A final report, spreadsheet, message draft, record change, or code patch needs:

- artifact ID;
- type;
- version;
- producer;
- task;
- creation time;
- source references;
- validation status;
- sensitivity;
- acceptance status; and
- replacement relationship.

Without versioning, the reviewer may approve an old draft while the executor uses a new one.

### Critical information must survive reconnects

The A2A specification warns that messages should not be treated as reliable delivery for critical information because transient status updates may not persist or may be missed after disconnection.

Persist critical decision, approval, artifact, and state data in the task record or another durable system.

## When Should One AI Employee Delegate to Another?

Delegation should solve a named constraint.

### Capability match

Delegate when another role has:

- required domain instructions;
- approved sources;
- better tool access;
- stable evaluation;
- necessary artifact capability;
- lower-cost model fit; or
- a tested workflow for the sub-task.

A title is not proof of capability. Use current role metadata and performance. The complete [AI agent task delegation protocol](https://cellcog.ai/blog/ai-agent-task-delegation/) shows how to turn that capability match into a bounded child task with scoped authority, explicit acceptance, a return package, and accountable parent closure.

### Capacity and parallelism

Delegate when independent work can run concurrently and elapsed time matters.

Anthropic's multi-agent research system uses a lead agent and parallel research subagents for open-ended breadth. Anthropic also reports that multi-agent systems introduce coordination, reliability, and token costs and are poor fits when tasks have many dependencies or require all agents to share the same context.

Parallelism helps when branches are independent. It hurts when each branch waits on another.

### Permission separation

One role may prepare customer outreach while another approved identity sends it. A research role may access public data while a CRM role accesses selected internal fields.

Separation creates a real control only when credentials, data, operations, and logs are distinct. Two role prompts using the same broad account do not create a security boundary.

### Independent review

A second role can check:

- source support;
- calculation;
- policy;
- format;
- permission;
- risk;
- completeness; or
- acceptance.

Improve independence through a separate rubric, sources, context, method, tool, or model. A reviewer that receives the producer's complete method and assumptions may repeat the same error.

### Do not delegate when context is inseparable

Keep work together when:

- the outcome is cohesive;
- most context is shared;
- steps change tightly with intermediate results;
- one owner can complete inside the deadline;
- authority separation is unnecessary; and
- the handoff packet would nearly reproduce the full context.

The [general-purpose versus specialized AI agent guide](https://cellcog.ai/blog/general-purpose-vs-specialized-ai-agents/) gives the full architecture test.

## What Is the Collaboration Lifecycle?

Use a 10-stage lifecycle.

*Table: The 10-stage collaboration lifecycle with required evidence*

| Stage | Required event | Key evidence | Failure to prevent |
|---|---|---|---|
| 1. Discover | Requester identifies a suitable capability | Role/capability version | Wrong-role assignment |
| 2. Propose | Parent owner creates bounded request | Task packet | Vague work |
| 3. Authorize | System verifies data and action scope | Policy decision | Privilege propagation |
| 4. Accept | Receiver confirms scope and capacity | Acceptance event | Ownerless work |
| 5. Execute | Receiver works inside limits | Tool/source trace | Unbounded action |
| 6. Update | Durable status records material progress | State events | Invisible stall |
| 7. Deliver | Receiver returns versioned artifact | Artifact + evidence | Result lost in chat |
| 8. Review | Reviewer applies acceptance contract | Pass/fail + reasons | False completion |
| 9. Repair/escalate | Failure is corrected or elevated | Rework/escalation packet | Silent defect |
| 10. Close | Parent owner records final outcome | Closure + downstream result | Open logical work |

Every stage does not need a model call. Deterministic systems should enforce identity, schemas, status, limits, approvals, and terminal transitions where possible.

### Discover by capability, not name

A capability record should state:

- role ID and version;
- scope;
- supported input and output;
- approved tools and data classes;
- prohibited actions;
- expected latency;
- cost class;
- quality history;
- current capacity; and
- escalation owner.

The current A2A standard uses an Agent Card for identity, endpoint, capabilities, skills, and supported interaction features. The business may use an internal registry instead.

### Propose a bounded task

The requester should include only the context and authority required. A request such as "handle this account" is too broad.

Use:

> Research account A for 5 specified buying signals using public sources and the approved CRM snapshot. Return one cited brief by 3 p.m. Do not contact the account or change the CRM. Escalate conflicting company identity.

### Require explicit acceptance

The receiver should accept, reject, or request input.

Acceptance confirms:

- understood output;
- required inputs exist;
- scope is inside role;
- authority is sufficient;
- deadline is feasible;
- budget is acceptable; and
- parent/closure owner is known.

Silence is not acceptance.

### Close only after acceptance

The specialist can mark its sub-task delivered. The parent owner marks the complete outcome closed after required review, integration, or external result.

This prevents role-level completion from being counted as business completion.

## What Should the Collaboration Packet Contain?

Use the minimum fields that make the edge testable.

### Request fields

*Table: Request fields for a collaboration packet*

| Field | Purpose |
|---|---|
| Task ID and parent ID | Correlate the work |
| Relationship | Consult, delegate, handoff, review, approve, notify, escalate |
| Requester and closure owner | Preserve accountability |
| Goal | Define the result |
| Output schema | Make delivery checkable |
| Context/artifacts | Supply relevant evidence by reference |
| Constraints | State scope and prohibited behavior |
| Authority | Define tools, data, actions, and approval |
| Acceptance | State required quality/evidence |
| Time/budget | Bound latency, retries, usage, and cost |
| Failure behavior | Define input-required, reject, fail, cancel, escalate |
| Reply destination | Return artifact and status correctly |

This is the compact collaboration envelope. When ownership actually transfers, use the complete [AI agent handoff protocol](https://cellcog.ai/blog/ai-agent-handoff-protocols/) for packet identity, state, sources, artifacts, decisions, authority, uncertainty, deadlines, failure policy, and explicit acceptance.

### Response fields

Return:

- task and artifact IDs;
- status;
- result summary;
- artifact reference and version;
- sources;
- actions taken;
- policy/approval evidence;
- assumptions;
- uncertainty;
- unresolved issues;
- usage and time; and
- recommended next state.

Do not bury uncertainty in a long narrative.

### Error fields

An error should include:

- error class;
- stage;
- retriable or terminal;
- partial actions;
- partial artifacts;
- state consistency;
- data or security effect;
- retry count;
- required owner;
- next safe action; and
- evidence.

"Something went wrong" cannot support recovery.

### Minimize context

Send source references and relevant excerpts rather than the requester's complete memory. Remove secrets, unrelated customer data, and hidden instructions.

If the receiver needs full context, reconsider whether the role boundary is useful.

## How Should AI Employees Share Context and Memory?

Share sources deliberately; isolate accumulated role memory by default.

Use the [shared versus role-specific AI memory architecture](https://cellcog.ai/blog/shared-vs-role-specific-ai-memory/) to decide what several roles may read, what each role alone may retain, who can propose or approve writes, and how correction propagates.

### Use three context planes

*Table: Three context planes and their write policies*

| Plane | Contents | Write policy |
|---|---|---|
| Organization sources | Approved policy, product facts, templates, strategy | Named owner or controlled proposal |
| Role context | Recurring responsibility, customers, tools, rubrics, lessons | Role-scoped and reviewed |
| Task context | Current goal, sources, decisions, state, artifacts | Task owner and event system |

This hierarchy keeps a task observation from becoming permanent organization truth.

### Pass artifacts, not memories

An artifact is bounded, versioned, reviewable, and attributable. Memory may be a retrieval layer with changing content and uncertain relevance.

Use artifacts for:

- research findings;
- source ledgers;
- analysis;
- decision records;
- action previews;
- approved messages;
- reconciliations;
- code changes; and
- handover state.

### Validate inter-role content

Treat another agent's message or artifact as untrusted input:

- validate schema;
- check source permissions;
- scan for malicious instructions where relevant;
- enforce size and type limits;
- verify artifact identity;
- separate content from commands;
- apply data-loss controls;
- reject unauthorized fields; and
- record validation.

OWASP's AI Agent Security guidance recommends signing and verifying inter-agent communication, validating external input, isolating memory, bounding tool chains, and preventing one compromised agent from causing another to exceed its trust boundary.

### Correct shared knowledge

When a source changes:

1. update the authoritative record;
2. identify roles and tasks that consumed it;
3. invalidate affected artifacts;
4. notify closure owners;
5. repair external records if necessary;
6. rerun relevant regressions; and
7. preserve change evidence.

The [AI employee memory lifecycle](https://cellcog.ai/blog/ai-memory-privacy-and-retention/) defines source provenance, scope, correction, retention, and deletion in more depth.

## How Should Authority Move Between AI Employees?

Authority should not automatically travel with the task.

### Separate five authorities

1. authority to request work;
2. authority to disclose data;
3. authority to use a tool;
4. authority to approve an action; and
5. authority to execute the action.

One role may hold the first and none of the others.

### Do not forward credentials

The receiving role should use its own identity and scoped access. Do not place tokens, passwords, session cookies, or broad delegated credentials inside the task packet.

If a role lacks the required access, return an authorization error or request an approved access path.

### Bind approval to parameters

Approval should include:

- action;
- system;
- target object or recipient;
- exact content or change;
- value/volume limit;
- approver;
- timestamp;
- expiration;
- single-use or repeat policy; and
- approval ID.

Changing the artifact or recipient after approval should invalidate it.

### Prevent privilege bridges

A manager with permission to assign work should not be able to bypass a specialist's denied action by asking another privileged role to perform it without reauthorization.

Keep those responsibilities distinct with the [manager-agent versus specialist-agent contract](https://cellcog.ai/blog/manager-agent-vs-specialist-agent/): coordination authority does not confer domain execution rights, and specialist depth does not confer parent-task control.

Enforce policy on the complete chain, not only at the first request.

The [AI employee permissions guide](https://cellcog.ai/blog/ai-employee-permissions-and-approvals/) provides the action-level authority model.

## How Should AI Employees Review Each Other's Work?

Review needs independence, a rubric, and power to reject.

### Choose the review type

*Table: Review types matched to methods*

| Review | Best method | Example |
|---|---|---|
| Schema | Deterministic validation | Required fields and types |
| Calculation | Independent recomputation | Totals reconcile |
| Source | Citation/source check | Claim supported by source |
| Policy | Rules plus domain review | Refund within policy |
| Permission | Policy engine/log check | Action authorized |
| Quality | Calibrated human or model rubric | Completeness and clarity |
| Security | Static/adversarial checks | No secrets or injection |
| Final acceptance | Accountable owner | Business outcome usable |

Use deterministic checks where the answer is known. Use model or human judgment where interpretation is necessary.

### Keep producer and reviewer roles distinct

A producer should not mark its own work accepted. The role can run self-checks, but final acceptance belongs to the defined reviewer or closure owner.

For high-consequence work, use an independently configured reviewer or qualified human.

### Record reason codes

Examples:

- missing source;
- unsupported claim;
- calculation mismatch;
- incomplete scope;
- wrong artifact version;
- policy conflict;
- unauthorized action;
- insufficient uncertainty;
- format failure; or
- no business value.

Reason codes create targeted regressions and reveal recurring edge failures.

### Control review loops

Set:

- maximum rework cycles;
- budget;
- deadline;
- change scope;
- escalation after repeated failure; and
- rule against producer/reviewer debate without new evidence.

Unbounded critique loops create cost without closure.

## How Do AI Employees Handle Failure, Timeout, and Retry?

Failure behavior belongs in the interface.

### Use explicit terminal and interrupt states

The A2A task lifecycle includes terminal outcomes such as completed, canceled, rejected, and failed, as well as interrupted states such as input-required or auth-required.

Your internal system may use different names, but it needs the same distinction: is the task finished, waiting for a defined input, or unsafe to continue?

### Retry only safe operations

A retry policy should know whether an operation is:

- read-only;
- idempotent;
- deduplicated;
- reversible;
- externally visible;
- financial;
- destructive; or
- approval-bound.

Do not retry a send, purchase, delete, or publish blindly.

### Preserve partial state

After failure, record:

- actions that succeeded;
- actions that failed;
- artifacts created;
- records changed;
- approval consumed;
- retry safe/unsafe;
- cleanup required;
- remaining owner; and
- next state.

The parent should not restart the whole chain and duplicate completed work.

### Cap delegation and cost

Set maximum:

- delegation depth;
- child tasks;
- retries;
- turns;
- tokens/credits;
- tool calls;
- elapsed time; and
- external actions.

The cap should produce an escalation, not silent abandonment.

## How Do You Observe and Audit Collaboration?

Correlate the complete chain.

### Minimum event ledger

Record:

- organization, role, and policy version;
- parent and child task;
- requester and receiver;
- relationship type;
- timestamp;
- state transition;
- input artifact;
- source reference;
- tool/action;
- permission decision;
- approval;
- output artifact;
- review result;
- retry/error;
- cost/usage; and
- closure.

The business needs enough observable evidence to reconstruct responsibility and external effect. The [audit-log reconstruction standard](https://cellcog.ai/blog/ai-employee-audit-logs/) defines what buyers should be able to replay.

### Use one correlation ID

Propagate a parent correlation ID across tasks, tool calls, artifacts, approvals, and incidents.

Without it, a downstream CRM write may be visible but disconnected from the research, review, and approval that caused it.

### Segment by edge

Measure each recurring relationship:

- manager to researcher;
- researcher to writer;
- writer to verifier;
- verifier to manager;
- manager to executor; or
- executor to external system.

An aggregate team score can hide one weak edge.

### Protect sensitive logs

Logs can contain customer data, confidential sources, prompts, artifacts, credentials, and security information.

Apply access control, minimization, redaction, retention, export, deletion, and incident policy to the evidence system itself.

## Which Metrics Show That Collaboration Works?

Measure final outcomes and edge quality.

*Table: Collaboration metrics and the decisions they support*

| Metric | Formula | Decision use |
|---|---|---|
| Accepted system outcomes | Final accepted outcomes in period | Core value |
| Handoff integrity | Complete accepted packets / handoffs | Context quality |
| Acceptance latency | Accepted time minus assigned time | Ownership delay |
| Clarification rate | Input-required tasks / accepted tasks | Request quality |
| Misroute rate | Incorrect assignees / assignments | Discovery quality |
| First-pass artifact acceptance | Accepted without rework / delivered | Role/interface quality |
| Reopen rate | Reopened / completed | False closure |
| Duplicate-action rate | Duplicate external actions / actions | State/retry safety |
| Human intervention | Human coordination minutes / accepted system outcomes | Coordination debt |
| Cost per accepted outcome | Full system cost / accepted final outcomes | Economics |
| Cascade severity | Maximum downstream effect | Containment |

Use the [AI employee KPI framework](https://cellcog.ai/blog/ai-employee-kpis/) for role-level outcome, quality, escalation, reliability, cost, and risk. These metrics add the collaboration edge.

### Calculate chain yield

For a 3-edge chain:

System yield = edge 1 pass x edge 2 pass x edge 3 pass x final acceptance.

Illustrative example: `0.95 x 0.92 x 0.90 x 0.90 = 70.8%`

Each step looks strong, but the complete chain accepts only about 71 of 100 started outcomes.

### Compare with one-agent baseline

Measure:

- final acceptance;
- elapsed time;
- human review;
- correction;
- cost;
- severe errors;
- context loss; and
- recovery.

Collaboration earns its complexity only if the system outcome improves enough.

### Keep worst failure beside the average

A 98% handoff pass rate can still hide one unauthorized action or severe data disclosure.

Keep non-compensating risk gates separate from weighted performance. Use the [multi-agent failure-propagation model](https://cellcog.ai/blog/multi-agent-system-failure-modes/) to test whether one defective plan, artifact, memory entry, retry, or review can cross a prohibited boundary.

## What Does AI Employee Collaboration Look Like in Four Workflows?

Worked examples expose whether the roles exchange a useful artifact or merely add conversation.

### Workflow 1: research to content

The content owner needs an approved article; the research specialist supplies evidence.

*Table: Collaboration contract for a research-to-content edge*

| Collaboration field | Contract |
|---|---|
| Parent owner | Content employee |
| Relationship | Delegated research sub-task |
| Request | Answer 8 specified questions using approved primary sources |
| Specialist authority | Public web and approved document repository; no publishing |
| Artifact | Source ledger plus findings, conflicts, dates, and uncertainty |
| Acceptance | Every material claim traceable; contradictions surfaced |
| Failure | Return input-required if market, date, or audience is undefined |
| Closure | Content owner accepts article after claim and editorial review |

The specialist does not send a loose summary. It returns a versioned evidence artifact that the content owner can cite, challenge, and update.

Possible tests:

- source link opens;
- publication date is captured;
- exact claim scope is preserved;
- prohibited secondary source is rejected;
- conflicting official sources trigger escalation;
- unsupported market number is excluded;
- the content role cannot publish from the research identity; and
- a changed source invalidates affected claims.

The collaboration earns its edge when research coverage or provenance improves more than request, review, and update work increases.

### Workflow 2: sales manager to research and outreach

The sales manager owns pipeline outcome, delegates account research, and asks an outreach role to prepare a message.

*Table: Stage-by-stage ownership and authority in a sales collaboration*

| Stage | Owner | Artifact/state | Authority |
|---|---|---|---|
| Select account | Sales manager | Approved account task | Read CRM eligibility fields |
| Research | Research role | Cited account brief | Public sources + minimized CRM snapshot |
| Review fit | Sales manager | Qualified/rejected decision | No external action |
| Draft | Outreach role | Message tied to approved account/brief | Draft only |
| Approve | Human or authorized manager | Exact content and recipient approval | Parameter-bound |
| Send | Sending identity | Delivery event | One approved recipient |
| Reconcile | Sales operations role/workflow | CRM update and response state | Approved fields only |
| Close | Sales manager | Accepted pipeline outcome | Parent closure |

The manager should not provide full CRM exports to research or let the research role send. The outreach role should not select a different recipient after approval.

Test duplicate triggers, expired approval, bounced email, changed company identity, conflicting research, and an account that should be excluded. The most important result may be a correct non-send.

### Workflow 3: support triage to specialist to human

An intake role classifies the issue, a specialist handles bounded categories, and a human receives exceptions.

Required artifacts:

- case ID;
- customer identity state;
- category and confidence;
- policy/source version;
- actions already attempted;
- customer-visible messages;
- account changes;
- unresolved question;
- urgency;
- escalation reason; and
- next response deadline.

The triage role transfers ownership only after the specialist accepts. A low-confidence or out-of-scope case should remain with triage until a human or specialist accepts it.

Use deterministic validation for identity status, policy limits, account fields, and transactional changes. Use the agent for interpreting the issue and selecting among allowed paths. A human owns exceptions involving rights, security, significant money, or policy ambiguity.

Measure:

- correct routing;
- acceptance delay;
- first-contact resolution;
- unnecessary transfer;
- missing context;
- repeated customer explanation;
- policy adherence;
- action accuracy;
- human escalation;
- customer response time; and
- reopen rate.

### Workflow 4: analyst to executive briefing

A data role reconciles metrics; a research role supplies external context; an executive-briefing role synthesizes the decision.

*Table: Risks and controls in a multi-role briefing workflow*

| Risk | Control |
|---|---|
| Internal and external periods differ | Require dates and comparison window |
| Metric definition changes | Include formula and source version |
| Research claim conflicts with data | Surface conflict; do not silently choose |
| Synthesis hides uncertainty | Require uncertainty and decision impact |
| Old artifact reused | Bind to version and expiration |
| Executive action exceeds evidence | Mark recommendation confidence and approval need |
| Reviewer accepts polished but wrong output | Independently reconcile key figures |

The synthesis role owns narrative coherence, not the truth of every input. Each producer remains attributable, and the closure owner accepts the complete briefing.

This workflow often benefits from specialists because numerical reconciliation and external research use different sources and tests. It can still fail if synthesis discards provenance.

### What the four workflows share

Every useful edge contains 9 invariants:

1. one parent outcome;
2. relationship type;
3. explicit receiver acceptance;
4. minimized context;
5. bounded authority;
6. versioned artifact;
7. acceptance rule;
8. exception path; and
9. one closure owner.

The content, sales, support, and executive examples vary in consequence and tools. The collaboration skeleton remains stable.

## How Should You Change a Collaboration Interface Safely?

An interface change can break roles that still appear healthy in isolation.

### Treat material changes as versions

Version changes to:

- request schema;
- output schema;
- state vocabulary;
- source list;
- artifact format;
- authority;
- approval;
- deadline or budget;
- error behavior;
- role/model/tool; and
- validation.

Record old and new versions plus effective time.

### Maintain compatibility deliberately

For each change, choose:

- backward-compatible extension;
- migration period supporting both versions;
- coordinated cutover;
- adapter; or
- breaking change with queue drain.

Do not let a receiver guess which fields an older requester omitted.

### Run interface regressions

Test:

- ordinary accepted request;
- missing required field;
- unknown added field;
- old artifact version;
- wrong relationship type;
- denied authority;
- timeout;
- retry;
- partial prior action;
- canceled parent; and
- receiver unavailable.

Then run one complete parent outcome, not only the interface validator.

### Drain or migrate open work

At cutover, identify:

- proposed but unaccepted tasks;
- accepted tasks in progress;
- waiting approvals;
- delivered artifacts in review;
- rework;
- retries;
- escalations; and
- completed work with downstream action pending.

Assign each to old completion, migration, cancellation, or human takeover. A schema deployment should not strand logical work.

### Observe after release

Compare pre/post:

- acceptance latency;
- clarification;
- schema rejection;
- misroute;
- delivery;
- first-pass artifact acceptance;
- rework;
- duplicate action;
- human intervention;
- cost; and
- severe failure.

Rollback when a knockout gate fails or deterioration exceeds the precommitted threshold.

## What Does CellCog Say About AI Employee Collaboration?

CellCog describes role-based task coordination in its current product.

### Public mechanics

CellCog's [AI Organization page](https://cellcog.ai/ai-organization) says its AI Employees:

- have their own email addresses and task boards;
- delegate tasks to another employee's board with context;
- work delegated tasks on a later shift;
- report back;
- use shared memory for strategy documents; and
- use handover notes to preserve current state.

The page also says manager employees onboard and unblock teams.

Evaluate that operating claim through the [AI manager boundaries and controls](https://cellcog.ai/blog/can-ai-employees-manage-ai-employees/): assignment, review, repair, escalation, and intervention should each be observable and independently testable.

### Dated operating example

As of July 24, 2026, CellCog's public AI Organization page showed 1 human founder and 9 active AI Employees, including a Sales Lead managing 5 sales representatives. CellCog reports the Sales Lead began as an individual contributor on June 27 and became a manager on July 7, then onboarded the representatives.

CellCog self-reports 6x outbound throughput and a 1.5% bounce rate after the team formed. These are first-party metrics, not independently audited customer results or universal collaboration benchmarks.

### Agent-to-agent traffic

CellCog also exposes its capabilities to external agents through API keys, an SDK, plugins, integrations, and skills, and has said about 30% of CellCog chats are initiated by agents rather than people. Treat this as a dated, self-reported usage metric. It demonstrates agent-initiated traffic, not by itself task acceptance, handoff quality, or business outcome.

### Buyer tests

Before adopting the collaboration claim, test:

- assignment and explicit acceptance;
- parent/child state;
- context and source preservation;
- role-specific permissions;
- artifact return and version;
- review and rejection;
- timeout and retry;
- delegation depth and cost caps;
- human escalation;
- evidence export; and
- stop/recovery.

Public product mechanics become buyer evidence only after the actual role passes.

## What 20-Task Collaboration Pilot Should You Run?

Test one edge before a full team.

### Choose one bounded collaboration

Example:

> Marketing Manager delegates a competitor evidence brief to Research Specialist; manager retains campaign ownership.

Do not begin with 5 workers and an open-ended goal.

### Build the case pack

Use an illustrative 20-task pack:

- 10 ordinary requests;
- 3 incomplete requests;
- 2 wrong-role requests;
- 2 source conflicts;
- 1 tool failure;
- 1 prohibited-data request; and
- 1 timeout/retry case.

The distribution is an example. Match production and deliberately test high-consequence boundaries.

### Precommit thresholds

Define:

- request completeness;
- acceptance latency;
- artifact acceptance;
- source preservation;
- correct escalation;
- prohibited action;
- duplicate action;
- cost;
- elapsed time;
- human minutes; and
- worst severity.

Use knockout rules for authority, data, and unreconstructable external action.

### Compare architectures

Run the same final outcome with:

1. one general-purpose employee; and
2. the two-role collaboration.

The collaboration should improve a named constraint without worsening total acceptance, risk, or supervision beyond the approved ceiling.

### Decide

Choose:

- keep one role;
- repair the edge and retest;
- keep the collaboration;
- narrow the specialist;
- change ownership; or
- stop the use case.

Then preserve the case pack as the interface regression suite.

## Which Collaboration Red Flags Should Stop Deployment?

Stop when the edge cannot preserve ownership or control.

### Task red flags

- work exists only in messages;
- assignee never accepts;
- parent and child IDs are missing;
- role-level delivery is counted as final completion;
- waiting tasks have no next owner;
- canceled work still executes; or
- "done" has no acceptance evidence.

### Context red flags

- whole memory is copied by default;
- source provenance disappears;
- untrusted content becomes instruction;
- sensitive data crosses role boundaries;
- artifact version is unclear;
- shared memory accepts automatic writes; or
- corrections do not reach downstream work.

### Authority red flags

- credentials travel in messages;
- one role can grant another access;
- manager delegation bypasses policy;
- approval survives changed parameters;
- roles share broad accounts;
- retries repeat external action; or
- no full-chain stop exists.

### Economic red flags

- specialist outputs are counted as final outcomes;
- token/credit cost excludes manager and retries;
- human coordination time is not tracked;
- parallel agents work on dependent branches;
- review loops have no cap;
- more roles are added to repair unclear jobs; or
- no one compares collaboration with one-agent performance.

## Define Task State and Acceptance Before Collaboration

Start with one parent outcome and one additional role. Define relationship, request, authority, acceptance, artifacts, review, failure, escalation, and closure before enabling the edge.

Use CellCog's [AI Organization](https://cellcog.ai/ai-organization) to inspect the current first-party team example, then run the same 20-task collaboration pack through the real product. Collaboration is successful when accepted system outcomes improve and the complete chain remains explainable, bounded, recoverable, and owned.

Before adding a third role, review every failure from the two-role pilot. If problems came from an incomplete request, unclear acceptance, shared credentials, stale sources, or missing task state, repair the interface first. Another agent will not resolve an undefined boundary; it will give the boundary another place to fail.

The strongest collaboration systems make boring questions easy to answer: Who owns this task now? Which source and artifact version did they use? What may they do? What are they waiting for? Who must decide? What happened externally? Why was the result accepted? If the operator needs a full transcript and a model-generated explanation to answer those questions, the work is not yet operationally visible.

Make those answers available from durable state before increasing task volume, permissions, or delegation depth.

## FAQ

**Can AI agents communicate directly with each other?**

Yes. They can exchange messages, tasks, status, and artifacts through a shared platform or agent protocol. Direct communication becomes useful collaboration only when identity, ownership, authority, state, evidence, acceptance, failure, and closure are governed.

**What is the difference between delegation and handoff?**

Delegation normally asks another role for a contribution while the delegator retains the parent outcome. A handoff transfers a defined responsibility after the receiver accepts it. Record the relationship so both roles know who owns closure.

**Should AI employees share the same memory?**

Not by default. Share approved organization sources and versioned artifacts. Keep role working memory scoped, control shared writes, preserve provenance, and propagate corrections. Broad shared memory can spread error, malicious content, and sensitive data.

**Who is responsible when collaborating AI employees make an error?**

The organization needs a named human accountable for the role and risk, plus a closure owner for the specific outcome. Logs should identify which role, tool, policy, artifact, review, and approval contributed. Agent-to-agent delegation does not remove organizational accountability.

**How many AI employees should collaborate on one task?**

Use the fewest roles that resolve a measured constraint. Start with one, test one additional edge, and compare accepted final outcomes, latency, supervision, cost, and risk. Agent count is not a quality metric.

**Does CellCog support AI employee collaboration?**

CellCog publicly describes employees delegating tasks to one another's boards, reporting back, sharing approved strategy context, maintaining handovers, and operating under manager employees. Buyers should verify the current product, plan, permissions, state, evidence, cost, and failure behavior for their own role.

## Related

- [How to Build an AI Organization Without Creating Coordination Debt](https://cellcog.ai/blog/how-to-build-an-ai-organization/index.md)
- [Can AI Employees Manage Other AI Employees?](https://cellcog.ai/blog/can-ai-employees-manage-ai-employees/index.md)
- [AI Employee Handovers: Context Without Coordination Debt](https://cellcog.ai/blog/ai-employee-handovers/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/how-ai-employees-work-together/. Try CellCog free, no credit card needed: https://cellcog.ai/signup