Every sprint they pick up whatever the roadmap has in build, write the code, and open the pull requests. Nobody re-checks the roadmap before they start. That is what it is for.
Before the sprint began, you gave them everything they needed to know what to build. This is the whole of what they can read.
You are a build agent. Each sprint, take whatever the current Roadmap has marked in build for the committed segment. Write the code and open the pull requests. Do not improvise scope. The Roadmap is the source of truth for what is in build. Route each pull request to the owning team for review.
There is no field for a strategy killed in a board review.
Every recent sprint built mid-market. The recent past argues for the wrong answer.
Four sources, every one current, correct, and consistent. The decision to pull out of the mid-market is in none of them, because a decision made in a room has no field, no document, and no file to land in. So it doesn’t.
In the board review, the company decides to pull out of the mid-market, enterprise only for the rest of the year. A real decision, made by the people with the authority to make it. It is written back to none of the sources above: not the prompt, not the roadmap, not the board, not a single file the agents can open. In build is still the only state anywhere they can look.
The decision didn’t sit still. It just never went anywhere the agents could read.
The board review ends.
Enterprise only, agreed. Everyone who needs to know is in the room.
Product asks what happens to the self-serve tier.
It was built for the segment being dropped. The question sits open.
Finance reworks the plan around the new segment.
A revised model circulates to the exec team.
Legal and sales work through the mid-market contracts.
Existing customers have to land somewhere. It takes a week.
Enterprise-only is confirmed for the year.
Signed off, and circulated as a revised plan.
The roadmap is updated.
Mid-market finally changes out of in build.
Twenty-five days the strategy had changed everywhere except the one place the agents build from. Not a system failure. Just how long it takes a decision to reach a document when nobody’s job is to carry it there.
Resolved context has no place to live in real time. So it doesn’t.
The result
Across those twenty-five days, the agents ran three sprints against the only roadmap they could read. Twenty-eight pull requests, every one shipping the mid-market product, the product you had already decided to stop building.
Twenty-eight pull requests, merged into a product you killed.
~$62,000
of engineering, spent building what you decided to stop building.
Twenty-eight pull requests of build and review time, plus the roadmap it pushed aside, which is the part you never get back.
Not fraud. Not a bug. Not one thing anyone did wrong. Just a decision that took twenty-five days to reach a document, while the agents kept building from the old plan, into a codebase you now have to unwind.
Every source the agents read was correct the day it was written. Any one of them can go on being read as current long after it stopped being true, and nothing you own can tell those two states apart.
Rithmo would have caught this.
It reads across all of those places at once and keeps one answer: what was decided, who owns it, and whether it still holds.
That is what a guardrail is up against. It inspects what the agents produced, and this was real, committed work, from the current version of a real roadmap, built correctly. The error was never in the output. It was in what the agents were told to work from.
A live record of decisions can be asked the one thing a guardrail cannot: was this still what the company had decided when the agents acted. If there’s no current, owned, sourced answer, the agent stops and routes it to a person instead of running on the last thing anyone wrote down. That is the difference between agents you supervise and ones you can leave running.