Organizational context handoffs for human and AI teams

What is an organizational context handoff?

An organizational context handoff moves both responsibility and verifiable working state across a durable boundary: one department to another, one product team to another, a person to an agent, or an agent to a reviewer. It is not a forwarded chat, a shared folder, or an announcement. The receiving actor must be able to identify the current revision, inspect the evidence, understand the operating constraints, and take the next action without asking the sender to reconstruct the work.

What belongs in the transfer package?

Use one stable handoff record as the index and attach the source material needed to verify it. Keep the brief small enough to scan, but do not flatten SQL, HTML, research, screenshots, datasets, or implementation files into prose when the receiver needs the originals.

• Objective and acceptance criteria: the outcome and the evidence that will prove it.
• Current state: complete, in progress, blocked, and explicitly unverified work.
• Decisions: material choices, rationale, and rejected alternatives that must not be reopened casually.
• Evidence: canonical files, queries, outputs, links, hashes, and observations.
• Constraints: access, safety, legal, privacy, budget, deadline, and public-sharing boundaries.
• Next action and ownership: one bounded step, its expected result, and the accountable person or agent.
• Transfer state: proposed, accepted, blocked, continued, or rolled back.

How should company boundaries map to the handoff?

Treat the company as the hard tenant boundary, a workspace as the durable product or operating area, a folder as navigation, and the handoff as the stable work record. A transfer between teams usually changes workspace membership, record grants, or ownership; it should not copy the material into a loosely governed folder or rely on a matching email domain to widen access.

Company      Hard tenant boundary
Workspace    Product, department, client, or durable operating area
Folder       Navigation inside an already authorized scope
Handoff      Stable record with explicit visibility and ownership
Revision     Immutable state accepted or continued by an actor
Artifact     Source evidence governed by the parent handoff

What is the seven-stage organizational handoff process?

Run the handoff as an acceptance workflow rather than a one-way publication. Each stage leaves evidence that an administrator, reviewer, or successor agent can inspect later.

• 1. Scope: name the business outcome, sending owner, receiving owner, deadline, and rollback condition.
• 2. Classify: declare the company, workspace, visibility, data sensitivity, retention, and prohibited sharing.
• 3. Inventory: identify canonical files, dependencies, credentials by reference, open review, and unresolved risks.
• 4. Publish: create one attributable revision and read every required artifact back from the destination.
• 5. Verify: the receiver authenticates independently, confirms access, and reproduces one material claim or result.
• 6. Accept or block: record missing evidence, denied access, stale state, or the accepted next action.
• 7. Continue and close: create the first successor revision, preserve rollback until the acceptance gate passes, then retire the old path.

How do humans and AI agents divide responsibility?

Use agents for inventory, summarization, deterministic validation, file comparison, retrieval, and bounded continuation. Keep people accountable for access classification, consequential approvals, exception handling, and final cutover. Every actor still needs a distinct authenticated identity: SSO for interactive people and a named, scoped service or workload identity for unattended agents.

• An agent may propose a transfer but must not infer that a mention or copied link grants access.
• A receiver may block the handoff without changing the sender's canonical evidence.
• A human reviewer should approve public release, cross-company sharing, destructive cutover, and unresolved high-risk exceptions.
• The server should derive authorship and scope from the credential rather than caller-provided names or organizations.

What access checks must pass before acceptance?

Test authorization at search, direct record access, artifact retrieval, annotation, and write time. The receiver should see every required item and no denied metadata. MCP clients and servers also need resource-bound tokens, exact redirect handling, secure token storage, and no token passthrough; transport authentication does not replace record-level authorization.

• Positive path: the intended receiver can search, read, annotate, and continue only the granted record.
• Negative path: an ungranted workspace member and a different-company identity receive no title, snippet, count, or artifact.
• Revocation path: a disabled person or agent loses read and write access without erasing historical authorship.
• Stale path: a receiver writing against an old revision is rejected and must reread.

How do you decide whether a migration or cutover can proceed?

Count a record as transferred only after the target exists, required files are retrievable, integrity checks pass where available, access is correct, and a fresh receiver accepts or continues it. Keep ambiguous records in a review state and retain the old workflow until the exception queue and rollback criteria are resolved.

• The 44pixels Reporter migration inventoried 1,497 reports and verified 1,370 Handover records.
• It held 127 reports for review instead of guessing their mappings.
• All 400 comparable product-file hashes matched with zero mismatches.
• Cutover remained blocked while report, backlog, and restricted-folder exceptions were unresolved.

What is the minimum pilot?

Pilot one real workflow with two people and two separately authenticated agents. Require a sender publication, independent receiver read-back, one human review finding, a correcting revision, a fresh-agent continuation, a denied-access check, revocation, and a documented rollback. Expand only when the receiver can continue without the sender's chat and every event preserves the correct company, workspace, author, and revision.

PASS
- Receiver reads the exact accepted revision and required artifacts
- One material claim or result is reproduced
- Review links to the revision that resolves it
- A fresh actor creates the first continuation
- Denied and revoked identities remain denied
- Rollback remains possible until acceptance

BLOCK
- Missing evidence, ambiguous ownership, wrong visibility, stale state,
  unverified artifacts, unresolved high-risk review, or failed revocation