Design context that survives an assistant change.

Give each kind of context a home

Context design decides what an agent needs at the moment of a decision. Start with a short purpose and audience in Project instructions. Put dated source material in Project files. Keep the accepted deliverable and its unresolved questions close to the evidence. A reusable Agent can hold the stable method that applies across Projects.

Avoid repeating every fact in every layer. If a client date changes, four inconsistent copies create a new reasoning problem. Instead, point instructions to the current source and state which material takes precedence. This makes a future assistant change manageable: the next task can reconstruct the rules from visible material rather than an assumed shared memory.

Write a context contract for the next task

The contract is an ordinary working document, not a special access-control feature. Keep it short enough that a reviewer can compare it with the actual Project.

Make disagreement an explicit input

Instructions such as “use the latest information” leave an agent to guess whether latest means upload time, document date, or approval date. Define the rule your reviewer uses. An approved dated requirement can remain authoritative even when a newer working spreadsheet proposes a different plan. Require the agent to preserve that conflict in the output.

Keep a source’s scope with its date. A policy about one business unit does not establish a company-wide rule. A copied external document is a snapshot, not a live connection. When a decision depends on fresh data, name who will refresh it and what should happen if that refresh is missing.

Describe operations without embedding credentials

The context packet can name the supported source location and required operation. It should not contain passwords, access tokens, or an instruction to bypass a missing connection. Ask the agent to verify the tool exists on its actual path before promising a result. Native Workspace, external MCP, BYOA, and HTTP do not expose identical capabilities.

Task instructions also do not shrink an OAuth grant. If an external assistant is connected, review the actual permissions in Workspace. Say which Project and files the task should use, then check its behavior. The written contract explains intended work; the account, connection, and tool settings determine available access.

Define when context becomes stale

Record refresh triggers that relate to the job: a new reporting period, changed requirements, a revised proposal, or an accepted correction. Ask a new task to verify that trigger before drafting. If the inputs have not been refreshed, it can prepare a clearly labeled partial result and list what is missing.

Update the current output and handoff together after a correction. A revised summary can still leave an obsolete date in a table or a stale “unknown owner” statement in the handoff. Inspect the saved artifacts, not only the agent’s final message. A context packet remains useful only while its pointers lead to consistent work.

Test the contract with a different task

Start a fresh Session or compatible authorized client. Ask it to identify the task boundary, name the current sources, resolve one known source conflict, and explain what it may do next. Use a familiar example whose correct interpretation a reviewer can establish independently.

If it cannot answer, repair the relevant layer: missing evidence, ambiguous precedence, unclear output, or unavailable operation. Do not solve every failure by adding a longer instruction. Once the packet works, pair it with a reusable Agent specification and an acceptance test. The Project supplies the current job; the reusable role supplies the method.

Try it with a small example.

Before you use the result.

• Each source has a meaning, scope, and freshness rule.
• A known conflict is resolved or preserved according to the written rule.
• The packet contains no credentials or assumed tool access.
• A fresh task can name the correct output and next permitted step.