Shared Agent Workspaces Need Evidence, Not Ceremony

The first version of an assessment agent is usually impressive for the wrong reason. It feels like a second workspace appears beside the candidate: a private agent lane, a private set of files, a special promote button, and a transcript that only partly explains what changed. That is dramatic, but it is not the shape hiring teams need. In an assessment, the important question is not whether an agent can make code appear. It is whether the final artifact can explain who did what, when the work changed, and how the result was checked.

That pushed us toward a simpler rule: agents are chats, and chats work on the same workspace. The candidate, editor chat, and assessment agents all operate against one set of files. When an agent suggests a change, it lands through the same review path as any other AI edit. When the candidate keeps or rejects it, that decision belongs to the evidence trail. The product becomes less theatrical, but the review gets stronger.

Why separate workspaces fail

A separate agent workspace creates ceremony. You have to promote work, reconcile files, and explain why the agent's copy differs from the editor's copy. It also creates a subtle trust problem. If the reviewer sees a polished final file but cannot tell whether the candidate wrote it, accepted it, or merely inherited it from an agent run, the assessment is measuring the wrong thing.

Shared workspaces remove that ambiguity. They do not make AI assistance disappear. They make it inspectable. The transcript, diff, attribution, and validation proof can all refer to the same artifact because there is only one artifact.

Attribution is product infrastructure

Once agents share the workspace, attribution becomes more than a nice label. It is part of the scoring substrate. A line can be human-written, editor-chat-written, or agent-written. A candidate can read a diff before keeping it, keep it blindly, reject it after inspection, or ask a follow-up. Those actions should not be flattened into a vague "used AI" flag.

This is the distinction AI-native assessment needs. Two candidates can both use an agent and show very different skill. One directs the agent, inspects the diff, tests the behavior, and explains the tradeoff. Another accepts every generated change without reading. The final code may look similar. The work trail does not.

Two sessions, one diff

Make that concrete. Picture the same take-home task handed to two candidates: a small feature with a known edge case around empty input. Both reach for an agent. Both submit code that passes the visible tests. Read only the final files and you would rank them the same.

The trail separates them. The first candidate, call her the director, asks the agent for a plan before any edit, reads the proposed diff, and rejects the first version because it mishandles the empty case. She reruns the check, watches it fail, tightens the prompt, and keeps the second version only after the behavior matches what she described. Her session has friction in it, and the friction is the signal: questions with intent, a rejected diff, a validation step that reacted to a real failure.

The second candidate accepts every suggestion on the first pass. The agent happens to produce working code, so the tests go green. There is no rejected diff, no follow-up, no moment where the candidate caught something the agent missed. The empty-case handling is correct by luck, not by inspection. When a reviewer opens the trail, the absence is loud: keeps with no reads in front of them, a straight line from prompt to submit.

Neither candidate is disqualified for using an agent. That was never the question. What the shared workspace buys is the ability to tell a directed session from a delegated one without interrogating anyone afterward, and without pretending the tool was not in the room. The director might still lose to the delegator on raw output on a different day. The point is that the trail makes the difference in judgment legible, so a hiring team can weigh it deliberately instead of inferring it from a hunch about the final file.

Validation has to be visible

We also tightened how validation shows up. Browser validation, replay evidence, plan cards, and walkthrough artifacts only help if a reviewer can see what was checked. A green result without context is another magic badge. A useful proof says what the goal was, what steps ran, where the rendered artifact was inspected, and whether the candidate or agent reacted to failures.

That is why validation is better as an evidence surface than as a hidden gate. The candidate should be able to run or trigger checks. The agent can request validation when the work calls for it. The reviewer should see enough of the path to distinguish a tight verify loop from a last-second batch check.

The failure mode: a trail nobody reads

Visibility has a failure mode of its own, and it is not the one people expect. The risk is rarely too little evidence. It is too much. A reviewer works against a budget, often only minutes per candidate, and a trail that records every keystroke, every agent turn, and every intermediate diff can bury the two moments that mattered. Evidence that cannot be read on a reviewer's clock is closer to noise than proof. So the work is not only capturing the trail. It is ranking it, surfacing the rejected diff and the reacted-to failure ahead of the many edits that changed nothing.

Volume is a tempting proxy and a bad one. A candidate who typed a lot did not necessarily think a lot, and a short trail can hold the sharpest moment in the session. Counting activity rewards the wrong thing. The trail earns its keep when it points a reviewer at the decisions, the places where a person read something and changed course, and lets the routine edits recede into the background where they belong.

The shared workspace carries a second cost we had to design against. One set of files means one blast radius. An agent that rewrites a module the candidate was mid-thought on can erase the very context a reviewer needs, and attribution alone will not reconstruct intent after the fact. Knowing which line an agent wrote does not tell you whether it clobbered a better idea underneath. The answer is not to hand the agent its own sandbox again, which drops us right back into the ceremony we left. It is to make agent edits land as proposals the candidate resolves, so a change to shared state always arrives with a human decision beside it.

Evidence has to outlast the session

Most assessment review happens after the candidate has closed the tab. Nobody is there to explain a choice, walk back a mistake, or narrate why a diff got rejected. That changes what the trail has to do. It cannot assume a narrator. A validation proof that only makes sense while the session is live is not evidence, it is a memory that fades.

So the trail has to stand on its own. A reviewer picking it up cold should be able to reconstruct the shape of the work: what the goal was, where the candidate pushed back on the agent, which check caught which failure, and what the final decision rested on. This is also what lets a result travel. A recruiter, a hiring manager, and a skeptical engineer reading three weeks later should reach the same read of the same session, because the artifact carries its own explanation instead of leaning on the room it was made in.

The product lesson

The lesson from agent-native editors is not "add more agents." It is "make the agent's work feel native to the workspace." For AlgoArena, that means fewer parallel universes and more durable artifacts. If a candidate uses AI well, the product should preserve the shape of that skill. If a candidate over-delegates, the product should make that visible without turning the review into guesswork.

The assessment surface is still evolving, but the direction is clear. Shared files, attributed edits, readable diffs, validation proofs, and replayable context belong together. That is how an AI-assisted session becomes something a hiring team can evaluate instead of a demo they have to trust on vibes.