The work should be easy to verify and continue after the conversation ends.
An agent changes the code, runs a few commands and says the work is complete. You close the conversation. The next morning, somebody opens the repository. Can they tell what changed, what was checked and what still needs attention?
When I think about coding agents, this is the handoff I care about. A useful session should leave the project in a state that another person, or another agent, can understand without having to reconstruct the conversation.
Consider a simple request: fix a settings page so that a user's changes survive a refresh. The agent needs to find the page, understand where settings are stored and see how the application identifies the user. It needs to know which existing behaviour must remain intact. Missing one of those details can produce a change that looks reasonable in isolation and fails in the application.
This is what makes context engineering a practical problem. The information needed to finish the task may be scattered across code, documentation, a failing test and a decision somebody made months ago. Giving the agent room to read more does not establish that it has found the right information.
A repository can make that search easier. Keep instructions close to the work they describe. Show how to start the application and run its checks. Record decisions that would otherwise surprise a new contributor. When documentation and code disagree, the agent needs a way to recognise and resolve the disagreement.
The agent also needs a working environment. If a test cannot run because a dependency is missing, the change remains unverified. A clear record should distinguish a failed test, a check that never ran and a successful check. Otherwise, even an accurate summary can leave the reader with the wrong impression.
Then consider what happens when the session stops halfway through.
In its account of experiments with long-running agents, Anthropic described sessions that left features unfinished and later sessions that saw partial progress and declared the project complete. Its approach used explicit feature requirements, progress records and incremental commits to help the next session understand the state of the work.
Those practices make sense to me because the handoff is familiar. If a colleague takes over a task, I would want them to know the goal, the changes already made, the checks that ran and the unresolved questions. A summary helps them get started. The actual changes and test output let them check whether that summary is right.
Completion needs a check of its own. For the settings page, saving a value and refreshing the page tests whether the change survives. Checking the same flow with a second account helps test that users' settings stay separate. The acceptance criteria should follow the behaviour we asked for, including the boundaries around it.
Apply the submitted change to a clean checkout and repeat the relevant checks. That can expose a dependency on something left behind in the agent's session. It still cannot tell us whether the requirements were complete or whether the tests missed an important case. Review remains part of the work.
If the agent changes a test, inspect why. The expected behaviour may legitimately have changed. Or the test may have been weakened until the new implementation passed. A green result is useful only when we understand what it establishes.
I would start with this fairly ordinary discipline before adding more agents and more orchestration. Make the necessary information findable, preserve enough state to recover, and give completion a meaning that somebody else can check.
The next morning, the conversation may be gone. The repository should still be able to explain the work.
Top comments (1)
“Done” should be a claim backed by evidence, not a status emitted by the agent. A useful completion receipt would name the changed files, tests or checks actually run, their results, and any assumptions left unverified. That gives a reviewer a small, inspectable surface instead of asking them to rediscover the work from scratch.