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

§ 01What Does AI Employee Collaboration Mean?

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

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.

§ 02Why 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 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.

§ 03When 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 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 gives the full architecture test.

§ 04What Is the Collaboration Lifecycle?

Use a 10-stage lifecycle.

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.

§ 05What Should the Collaboration Packet Contain?

Use the minimum fields that make the edge testable.

Request fields

This is the compact collaboration envelope. When ownership actually transfers, use the complete AI agent handoff protocol 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.

§ 06How 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 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

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 defines source provenance, scope, correction, retention, and deletion in more depth.

§ 07How 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: 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 provides the action-level authority model.

§ 08How Should AI Employees Review Each Other’s Work?

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

Choose the review type

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.

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

§ 10How 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 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.

§ 11Which Metrics Show That Collaboration Works?

Measure final outcomes and edge quality.

Use the AI employee KPI framework 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 to test whether one defective plan, artifact, memory entry, retry, or review can cross a prohibited boundary.

§ 12What 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.

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.

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.

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.

§ 13How 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.

§ 14What Does CellCog Say About AI Employee Collaboration?

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

Public mechanics

CellCog’s AI Organization page 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: 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.

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

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

§ 17Define 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 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.