On July 25, QwenLM/qwen-code changed its workspace-trust runtime so a trust-policy change rebuilds runtime generations and closes affected daemon routes rather than letting an in-flight task quietly continue. That is a concrete reminder that an agent’s next answer starts before its model call: the harness has already decided what authority, context, and recovery state reach the request.
That does not mean models do not matter, or that every weak answer is a runtime bug. It is a reporting rule: a model result has a chain of custody. Before Qwen Code—or any coding agent—sends its next request, its surrounding software has assembled a system prompt, chosen which tool output to retain, summarized or compressed a history, remembered a permission decision, and handled whatever went wrong in the previous turn. The missing object in most model comparisons is the request after those choices, not just the model name printed above it.
Policy arrives inside the next prompt
Parth Sareen’s public account of building an open-model harness is unusually direct about the awkward mechanics. A model may receive a huge command result, a summary of earlier work, a cache-friendly prefix, or a truncated history. Each choice is defensible in some circumstances; none is neutral. A model that seems to lose the plot might be responding to a prompt where the decisive output was compressed away. A model that appears cheaper might be benefiting from a different prefix or tool budget. The answer cannot establish which explanation is right until the run is inspectable.
A fresh public change in Qwen Code’s workspace-trust runtime makes the point tangible. The commit rebuilds runtime generations when workspace trust changes, fails affected daemon routes closed, and tests the policy monitor, reconciliation, and generation boundary. It does not claim a better model. It says something narrower and more useful: a trust decision changes the environment in which a task runs, so an in-flight runtime should not casually keep acting as if nothing changed.
An approval needs an owner too
Context is only one half of the boundary. Cline’s public SDK architecture separates a stateless agent loop from stateful orchestration for sessions, approvals, schedules, and host capabilities. A recent desktop change moves chat through that shared Hub rather than a private in-process runtime. The design answers a very human question—when one task can be reached through several clients, which surface owns the person’s approval?
That is why an answer’s provenance is more than a debugging convenience. A permission, a workspace boundary, and a recovery policy all decide what an agent may do next. Treating them as invisible plumbing invites a bad kind of comparison: two models look like they were asked the same question when they were actually given different tools, different memories, and different authority.
Ask for the run before you rank the model
Teams evaluating a model switch, a local-to-cloud handoff, or a new agent client can ask for five receipts before accepting a conclusion: the next prompt’s relevant inputs; the tool output that was omitted or summarized; whether that loss was declared; the permission and workspace state that persisted; and the path after a failed turn. The record makes a test reproducible enough for someone else to challenge.
The cited code and architecture documents do not prove released behavior, production reliability, or a common portability contract among agent projects. Nor do they apportion blame for a particular failure. The next signal worth watching is a task-matched comparison that publishes the bounded output, compaction, permission state, and recovery path. Until then, “the model did it” is often less a finding than a gap in the trace.