Prepare the handover for a specific task
Begin by explaining why you are changing agents and what work you expect next. The handover should guide a bounded task rather than grant general permission to redesign the project. Identify the intended result and the parts the receiving agent needs to understand before proposing or implementing any changes to the work.
Imagine one agent building a portal's first screen and another checking the approval process. The second needs to understand expected behaviour and locate the implementation, but has not automatically received permission to redesign the interface. Separating review from editing helps establish the role of the person or agent receiving the work.
In this hypothetical example, the request might be to identify differences between the agreed process and the implementation, supplying evidence. If you later decide to correct those differences, define the scope of the change. Explain the reason for switching agents so that the handover does not become a restart of every decision.
The practice of giving AI context with clear criteria helps select handover material. Provide what enables understanding of the task and point to further detail. Copying the whole conversation can transfer many words without clarifying which version of the objective and the work was actually approved.
To prepare your next step, explore Developing applications with AI.
Transfer decisions with their status and reasons
Record what was decided, who confirmed it and why the choice matters to the project. Distinguish current decisions, open suggestions and superseded choices. Reasons help the receiving agent respect the intention without interpreting an earlier solution as an immutable technical requirement or treating an exploratory idea as something already approved for implementation.
For the portal, final approval might be restricted to one manager because the company wants responsibility concentrated in that role. The button's appearance may still be under review. If both appear in an undifferentiated comment list, the next agent might treat authorisation as optional detail and the provisional design as final.
Preparing an application plan helps keep requirements separate from implementation decisions. The receiving agent may find another way to satisfy the same requirement, but needs to demonstrate how it preserves expected behaviour. Preferring another technology is insufficient justification for reopening work that has already been validated against the agreed criteria.
Rejected alternatives and their reasons matter when those reasons remain relevant. A short record prevents repeating a proposal already rejected because it did not fit the business. Do not turn every earlier experiment into a permanent prohibition: preserve the reason and conditions so that new evidence can justify reconsidering a choice.
Show status through files and verification results
The handover should point to existing results and explain which checks apply to them. Identify the version or moment the record describes, alongside local work not yet integrated. The receiving agent needs to distinguish what exists in the project from what somebody intended to do or said they had completed during an earlier session.
For the portal, a change might be saved in a local file but still absent from the version shared with the team. If the summary only says the feature is complete, the recipient may search in the wrong place or rebuild existing work. Location and integration status remove that ambiguity from the handover.
Connect each check to what it actually demonstrates. Looking at a screen does not prove permissions work, and a local test does not confirm an online change. Save references to relevant results and explain known limits so that the next review begins with the real uncertainty rather than repeating successes or assuming nonexistent validation.
The principle of explaining why automation changed a campaign applies to this transfer too. An action should connect to the request, information and decision that supported it. The agent receiving the project needs that connection to assess the work, beyond the visible result presented in the handover.
Confirm instructions, access and scope in the new environment
Before execution, check that the receiving agent obtained relevant instructions and has only the access needed for the task. Changing environments can alter how documents and tools are found. Transferred content explains the project, but does not guarantee equivalent configurations or create permission for actions that nobody requested as part of the handover.
If the project uses instruction files, confirm which are actually read and which is the main reference. Do not assume filenames or structures are recognised identically by different tools. Identify documents to consult and verify that the relevant boundaries appear in the agent's understanding of the task before the first change.
Credentials should not circulate in the handover document. Record where authorised access is obtained and what still needs configuration while keeping secrets in the appropriate location. If the task only involves reviewing files, there is no reason to also supply publication access or customer information irrelevant to that review.
Define who is responsible for changes while the handover occurs. Two agents editing the same work without coordination can quickly make the recorded status outdated. Where parallel work exists, delimit each participant's responsibility and ensure the recipient knows which parts are still changing before relying on them to draw conclusions.
Validate understanding before treating the handover as complete
Ask the receiving agent to identify the objective, decisions constraining the task and evidence consulted. Compare that reading with the handover record and resolve relevant discrepancies. The transfer becomes useful when it enables the right work to begin from verified references, rather than simply when a document has been sent or saved.
A limited first step can reveal gaps without changing the project: locating files, identifying approval states and describing a missing test. If the agent proposes an excluded feature or assumes publication already occurred, a difference in understanding needs correcting before any further execution can reasonably be authorised.
When it finds inconsistencies between the summary and files, ask for evidence of those differences. The solution may be updating documentation, recovering a local change or acknowledging that earlier work remained incomplete. Choose according to confirmed status instead of requiring the new agent to preserve a description that no longer matches reality.
Once the new task begins, keep decisions and current status with the project. Future handovers become easier when context is maintained during the work. Switching agents becomes a practical operational choice when you can preserve intent, locate results and verify what actually happened without relying on the memory of a single conversation.