Context Engineering for AI Coding Handoffs

Context engineering for AI coding means choosing and refreshing the information a coding agent uses for the task in front of it. For a handoff, give the next agent a compact packet: objective, relevant constraints, current facts with sources, evidence, unknowns, and a next action. The packet is an entry point, not a substitute for reading current code or the work record. This guide shows an original example of a task passing between coding agents and a way to recover when its context has aged.

This is for engineers who already delegate coding work across sessions or tools. As of October 2026, the general approach follows Anthropic’s context engineering guidance: curate the context available at a decision point and retrieve detail when needed. The packet and CSV-export example below are illustrative templates, not an observed customer workflow or a measured performance claim.

Why a long transcript is a poor handoff

A transcript records how someone reached a point; it rarely identifies which statements are still true. The next coding agent may see an old owner assignment, a passing test from before the latest edit, and a proposed design that was never approved. More pasted history can bury the one constraint that decides whether work should continue. Anthropic describes context as a finite resource and recommends maintaining a focused set of information across long tasks. That advice does not imply a universal token saving or accuracy gain from any particular packet.

Separate standing rules from task state. Repository instructions can say which component library to use and what checks to run. A work item can hold who owns the task, its current scope, and decisions. The branch shows what code exists now. The packet should point to these sources and explain why they matter to this task. See the memory and shared project state guide for the related distinction between remembered context and current work facts.

Build the smallest useful context packet

Start with the decision the next agent must make. If it must finish a CSV export flow, it needs the intended behavior, the files it may change, the current column and response contract, and proof of the downloaded file. It does not need every earlier search result. Keep each mutable fact next to a source and revision or observation time, so the next agent can refresh it. Anthropic’s just-in-time retrieval discussion recommends retaining useful references such as file paths and links, then loading the detail when the work calls for it.

• Objective: Name the user-visible result and a check that would show it works.
• Constraints: State the permitted files, required components, prohibited actions, and approval boundary relevant to this task.
• Current facts: Record owner, scope, dependency status, and code revision with their actual sources.
• References: Give paths or links to the work item, decision, contract, and tests the next agent should open.
• Evidence: Name the command or observation, result, revision, and environment; distinguish a past pass from a current pass.
• Unknowns: Mark unverified assumptions and conflicts explicitly, with the person or source that can resolve them.
• Next action: Give one safe step that can proceed under the stated scope, or a stop condition if it cannot.

These fields form a checklist, not a demand to fill every field with boilerplate. For a one-file documentation edit, a short objective, scope, link, and check may be enough. For work spanning a backend contract and a UI, the dependency and approval facts deserve space. If a field is unknown, write “unknown” and say what to inspect. Omitting it because it is inconvenient makes the packet sound more certain than the evidence supports.

Before and after: a CSV-export handoff

Consider an invented team adding a CSV download to a reports table. Agent A begins on Monday, but another agent will resume on Wednesday. During the gap, a maintainer may change the column-order contract or assign the export UI to a different worker. A bare handoff says, “Finish the CSV download. The columns should be final; tests passed.” It leaves the reader guessing which column contract, which tests, when they ran, who owns the page, and what “finish” means. The confident wording can invite a change beyond the current authorization.

Here is a better illustrative packet. The names, paths, revision, and result below are invented to show the structure; they do not describe AppHandoff customer data or a test we ran. A real worker must replace every placeholder with a verified source and fresh result. The packet deliberately points to a contract and a card instead of pasting their full bodies into the next agent’s context.

Task: Reports CSV export, work item EXPORT-42 (illustrative)
Objective: Download only the selected report rows, using the
  documented column names and order.
Scope: UI files under src/features/reports/ only. Use the
  repository's shared export button. Do not change API code.
Current facts: UI ownership and scope last read from
  EXPORT-42 revision 4 on Wednesday; re-read before editing.
  Current column order is UNKNOWN, despite Monday's note.
References: EXPORT-42; docs/report-export.md on current branch;
  src/features/reports/ExportButton.tsx; its component test.
Evidence: Monday's component test passed on commit abc123
  in local dev. That result predates the current branch.
Unknowns: Which columns does the current contract require?
  Did ownership or approval change after card revision 4?
  Was an actual download checked for selected rows and headers?
Next action: Read the current card and contract, inspect diff,
  rerun affected checks, then inspect a sample downloaded file.

The improved handoff is longer than the weak sentence, but each line answers an operational question. It prevents a past test result from becoming a current claim and makes column order and actual download verification questions rather than premises. If the agent cannot access the card or contract, it can still inspect local code, but it should stop before an action that depends on the missing fact. The engineering handoffs guide explains why missing decisions and ownership make a plausible summary unreliable.

Refresh context at the point of action

A packet becomes stale at different rates. A repository rule is tied to the branch; read the applicable instruction file after switching branches. A work-item owner can change while another agent is active; read the live record immediately before taking overlapping work. A test result applies to the revision and environment it exercised; rerun the affected check after code or contract changes. An approval covers the named action and scope, not every later variation. These are practical refresh rules, not fixed expiry times.

When sources disagree, stop the action that depends on the disputed fact. Suppose the packet says Agent A owns the export button, but the current card names Agent B. Treat the card as the latest recorded assignment, check its revision and history, and ask the authorized owner to resolve any remaining conflict before editing the same files. If the contract specifies a new column order, remove the old “columns final” sentence from the next handoff. Record what changed and which proposed step is now blocked; do not silently carry the old story forward.

1. Identify the exact decision the old context was meant to support.
2. Open the current source for every mutable fact that decision depends on.
3. Compare source revisions, branch changes, and test dates with the packet.
4. Replace outdated facts, preserve unresolved questions, and rerun the narrow affected check.
5. Resume only the step still covered by the current scope and approval.

A failed refresh is useful information. If the work item cannot be reached, write down that access gap; do not invent a stage or owner from a previous chat. If a test cannot run, report the command attempted, failure, and what remains unverified. A readable uncertainty lets the next agent or person choose a safe follow-up. It also keeps a summary from claiming more than the underlying sources can support.

Use retrieval without confusing access with authority

A tool can help an agent retrieve a current record, but tool access does not itself grant permission to change that record. The official July 2026 MCP tools specification defines tool discovery and invocation, including tool metadata. It does not assign project ownership or decide whether a particular product action needs human approval. Those decisions belong to the application’s rules and the account’s scope. Check the tool catalog and the work item in the client that is actually doing the task.

AppHandoff documents its MCP endpoint at https://api.apphandoff.com/mcp. Its current eight-tool service includes bootstrap, get, find, ticket, plan, message, project, and decide_lifecycle_proposal. A connected, authorized agent can resolve the project with bootstrap and read a known card with get or a list with find. Writes depend on the action rules, project access, revision, and any human gate. The last tool is for a signed-in human’s approval-card click, not a model's self-approval action. The MCP overview describes the product surface.

For a CSV-export handoff, keep the work-item reference in the packet and refresh it before work. Read the current card, then inspect the repository sources it points to. Do not assume that every editor exposes the same tools or that a successful read permits a write. If one client cannot reach the shared record, the packet should say so and name the decision it cannot safely make. The connection guide explains the supported setup paths and their access requirements.

Turn the packet into a repeatable habit

At the end of a session, write the packet from actual sources: read the current work item, inspect the changed files, and capture the checks just run. At the next session, treat it as an index for retrieval, then replace facts that changed. Keep long logs and documents at their source; pull in the portion needed for the decision. This is context engineering as a working habit, not a prompt that can make stale data trustworthy by wording alone.

For standing repository guidance, the AGENTS.md generator can format the project rules you enter into a draft. It is deterministic: it does not inspect the repository, read the current card, verify test results, or approve a handoff. Review its output against the actual repo before using it. Task-specific facts such as owner, dependency state, and proof still belong in the live work record and the handoff packet.

A useful final check is simple: can the next agent tell what to do, what it may touch, what has actually been proved, and which fact needs a fresh read? If yes, the handoff provides a focused starting context. If the packet only sounds complete, add source and revision details before passing it on. No packet guarantees a correct implementation; its value is making decisions and uncertainty inspectable when work crosses a context boundary.