Inherited agent notes can send the next agent down the same dead end

·3 mins

A new agent can go through a failed investigation again if its first job is to absorb the conclusions of the previous agent. In the course of an authorised security exercise the user was repeatedly asking for a clean start as the prior progress files could be somewhat misleading. The useful reset was to establish a small verified baseline before using the inherited notes to select the next experiment.

A hint survived longer than its evidence

The conversation history had instructions to go it alone after a number of failed attempts at the task. Another handoff stated the prior agent had got lost and that its notes could be misleading to the replacement.

One concrete example concerned an environment hint favoring IPv6. A later SUMMARY.md excerpt said:

IPv4 and IPv6 behave identically everywhere tested

It was very explicit that the IPv6 hint in AGENTS.md didn’t apply in that case. That’s a useful clarification, with a caveat: this is a recorded summary of the checks, not an independent re-run of every network probe. It does support the removal of that hint for that particular surface. It doesn’t in any way establish equivalence for all services or a successful resolution of the problem. The outcome is still unknown.

Rebuild only enough context to choose a test

On a restart read the current task and the mandatory operating instructions. Observe the authorization boundaries and safety rules. Be very clear in your mind about the difference between the instructions and the factual observations about the environment. A line in AGENTS.md could be a binding rule, it could be a fact about the setup or it could be a hypothesis that you need to go out and check.

Then establish the facts required to inform the next decision. In a network investigation that might involve confirming the target endpoint, checking that it’s reachable and then making a baseline request to it. In a code issue scenario you’d want to reproduce the failure that was reported and then have a look at the current code before accepting any diagnosis from a previous developer.

Only then do you compare the inherited notes against that baseline. That way you don’t re-run the whole investigation and the new agent has its own baseline to work from.

A handoff instruction can be as short as:

Establish a minimal baseline from the current tool output.
Treat inherited diagnoses as hypotheses.
For each claim you make, you need to be able to locate the evidence or at the very least be able to run a very cheap check.
Keep the required operating and safety instructions in force.

Preserve the test behind a negative result

A note such as “IPv6 works better” is completely devoid of the endpoint, the request and the comparison that would actually make it useful. “No difference on these tested endpoints” is much more specific and much easier to verify.

For future handoffs, record:

  • The claim and its scope (including when it was checked).
  • The command or test and a pointer to its output.
  • What remains is an interpretation or an unproven lead.

Keep the failed attempts too and state what each one ruled out. A failed request with one set of credentials doesn’t rule out the whole protocol. The next agent needs to be able to make the judgement as to whether repeating that test would in fact add any evidence.

Copying an assertion into successive summaries doesn’t constitute independent corroboration. If the raw output is missing then unverified is the correct designation rather than promoting it to a fact.

Prior to your next agent handoff, pick the assumption that will drive the next action and attach the relevant tool output in support of that assumption. If you can’t find it then that will be the restart task.