Shared Agent Workspaces Need Evidence, Not Ceremony
Assessment agents got more useful when they stopped living in a separate file universe. A field note on shared workspaces, attribution, validation, and reviewer trust.
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.
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 product lesson
The Cursor-style lesson 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.