The reasoning was right, but the world shifted

While working on the GitHub adapter, a gateway that lets AI agents create pull requests on GitHub, the source_state field first looked like a small technical detail. It was not the operation itself, or the target. It was only a reference to the state the agent had seen before proposing a change. But after working through the write path, this field started to look less like metadata and more like part of the safety model. A proposed change is not only defined by what it wants to do. It is also defined by the state in which that proposal made sense. This is easy to miss. An agent can read a repository, produce a reasonable change, and submit a clean intent. Nothing about that has to be wrong. But while the agent is planning, the repository can move. A human can push a fix. Another workflow can update the same file. A branch can advance. In that case, the agent may still be reasoning correctly over the state it saw. The problem is that this state no longer exists. The reasoning was right, but the world shifted. That is the stale state problem in agent workflows. And it is why I think agent workflows need state-bound intent. The illusion of a static world From the outside, even from the boundary's point of view, a stale request can look just like any other: the operation has the same name, the target path is still allowed, the input is still well formed. But it is not. The proposal belonged to an older state of the repository, formed before the branch moved, before the file changed, before another workflow created a related result. This is why stale state is not only a data freshness problem. For agent workflows, it becomes an admission problem: a decision about whether a proposed change is allowed to become a real effect. We call that decision point an MCP Boundary: the same pattern behind the GitHub adapter and the wider work we do on MCP gateways. The boundary should not only ask whether the operation is allowed on the target. It should also know whether the target i