A cloud agent has a wider tool set than a local one, because it has its own screen and its own desktop. It produces screenshots, recordings and logs as artifacts of its work, can interact with the interface and the browser, and lets you temporarily hand control to a human and then give it back to the agent. Diagnostics are available separately through a built-in external server: the transcript, events, environment details and setup logs.
The naive attitude to artifacts is to treat them as proof. A screenshot looks convincing, and the investigation often ends there. But every piece of evidence proves exactly its own part of the work and stays silent about the rest, and confusing one with the other is the cheapest way to take unfinished work for finished. Persuasiveness and proof diverge here the more the prettier the artifact is.
It helps to lay the kinds of evidence out in a table with a what-it-does-not-prove column once. Below is that map. A screenshot shows a specific visual state but says nothing about interactivity and accessibility. A recording shows a sequence of actions but does not check server-side invariants. A log shows observed output but does not guarantee the absence of a silent error outside the observation window. Test output proves that the stated set passed, not that coverage is complete. And a diff shows the actual code changes but not that the environment works.
| Evidence | What it proves | What it does not prove |
|---|---|---|
| A screenshot | A specific visual state | Interactivity and accessibility |
| A recording | A sequence of actions | Server-side invariants |
| A log | Observed output during the run | The absence of a silent error outside the window |
| Test output | The stated set passed | Completeness of coverage |
| The pull request diff | The actual code changes | That the environment works |
That table is the chapter's main idea. When judging the result of autonomous work you choose each time which level of evidence is enough for the stakes. For a text edit a diff is enough. For an interface change a screenshot and interaction are needed. For a change to calculations - tests and a check of invariants. Demanding everything always is expensive, taking one thing for everything is dangerous.
A separate mechanism is handing control to a human. It is more useful than it seems: not every task can be entrusted to an agent entirely, but many can be brought to a point where one meaningful click is needed. Returning control turns that into a normal collaborative process rather than an interrupted task.
There is a subtlety about repository event handlers: they start to apply once the agent receives an environment with write access. Early read-only exploration proceeds without them. That is worth remembering when designing policy: a check meant for all of the agent's actions may not fire at the very first stage, while it is only looking around.
One case deserves following to the end, because it shows exactly how evidence deceives. An agent edits a form: adds a field, labels it, fixes the spacing. A screenshot is attached in which the form looks right, and the change is accepted. A week later it turns out the new field cannot be filled from the keyboard and the label is not associated with the field and is not read by assistive technology. The screenshot did not lie: it honestly showed a visual state, that is, exactly what it is able to show. The gap is closed not by looking at the picture more carefully but by evidence of a different nature - a recording of a pass through the form without a mouse and a test that checks the label is bound to the field.
Collecting evidence has a price and a shelf life. Every screenshot and every recording costs run time and storage, and a demand to attach everything to everything quickly turns into noise nobody searches through. Something else matters more: artifacts are tied to the agent and live with it, while the discussion of a change lives in the pull request and in the repository. Anything that must remain an argument half a year later - a test that pinned the behavior, or a note in the change description - is moved into the repository right away. The sign that tells you in real work this was not done is an argument about an old decision in which the only link to the evidence leads to a place where nothing is left.
A cloud run has a settings layer that lives not in the request but in the dashboard: a default model, a default repository and a base branch the agent forks from when creating a pull request. A run that specified none of these silently inherits the shared values, so a wrong base branch shows up not as an error but as a change that went to the wrong place. The permission for long-running agents sits there too - a team switch that decides whether work may stretch for hours, and with it the accumulation of artifacts. And the same place holds the line between what disappears together with the agent and what reaches GitHub: a pull request off the base branch is the only part of a run that outlives it without your involvement.
The engineering conclusion is simple: cloud tools leave a rich trail, and that trail must be used deliberately. Demand evidence matched to the cost of a mistake, read it as the answer to a specific question and do not let one attractive screenshot close a whole task. And use diagnostic access to the transcript and events before you start guessing why an autonomous run behaved strangely.
The typical failures are predictable. Taking a screenshot for proof of workability. Treating green test output as proof of coverage completeness. Forgetting that event handlers do not apply during the exploration phase. Leaving the only proof in an artifact that will not outlive the agent. And investigating a strange run by its final message instead of the transcript and events.