A merge a person makes

A technology team adopting agents is really deciding one thing: who is answerable for what reaches production. An agent can write a change, show that it passes the tests, propose the cause of an incident, and draft the release notes. None of that is the hard part. The hard part is that a change which was proposed, tested, and merged by the same assistant has no person behind it, and a team that ships software to customers needs one. On a Czar Forge the answer is built into how the appliance is authored and routed: a merge is something a person makes.

The line, and where it falls

Agents on a Czar Forge prepare and propose; a named engineer merges, promotes, or releases. Nothing reaches production, a customer, or the outside without that person, and every step is on the record the team holds.

The line falls at the same place for every kind of agent on a Czar Forge. A coding agent opens a change, writes the tests, runs them, and reports; a person merges. Adaptation produces a tuned model and Evaluation scores it against the team's own test sets; a person promotes it to serving. An agent drafts the release notes from the merged changes and the closed tickets; a person releases. A dependency and vulnerability review agent proposes the upgrade and the evidence for it; a person decides. The agent's output is always a proposal in a queue, never an action in the world.

How the line is enforced

The boundary is not a policy the agent is asked to remember. It is two things the team controls. The first is authoring: every agent in Agency Studio is written with the repositories, branches, systems, and actions it may use, and nothing else. The second is routing: Local Bridge carries only the routes declared at commissioning, and the actions that merge, promote, or release are permitted only for a person's action over those routes. An agent that produced a flawless change still has no way to land it. The team does not rely on the model behaving; it relies on the model having no route.

Approvals

Each proposal waits in a queue for the named engineer who owns the repository, the model, or the release. The engineer reads the packet from the team's own record: what the agent read, which passages it relied on, what it tried, what failed, and what is in front of them now. They approve, send it back with a note, or reject it. That decision is written beside the packet with their name and the time, and the merge, promotion, or release then happens through their action.

A team sets the approvals to match the risk. A shared library may need two engineers; an internal tool may need one; a model that serves a customer-facing product may need the engineer who owns the model and the engineer who owns the product. These are authored into the queue, and they are versioned, so that a change to who may approve what is itself a change on the record.

Versions

Everything an agent is made of is versioned on the appliance: the prompt, the bounds, the routes it may use, the model it runs on, the adapter if there is one, and the approval rules around it. When the team changes an agent, the new version is recorded with who changed it and why, and the old version remains. A proposal in the queue names the version of the agent that produced it. When a team asks why an agent behaved differently last month, the answer is in the versions, not in anyone's recollection.

The replayable record

Every run is recorded: the task, the version of the agent, what it retrieved, what it wrote, what it ran, what came back, and the decision a person made at the end. Any run can be replayed to show how a proposal was reached. This is how a reviewer answers a question after the fact, how an engineer learns what to change in an agent's authoring, and how Evaluation scores agents against the team's own past resolved work. Watchman verifies that what is running is what the record says is running.

The record is on the appliance, inside the perimeter, in the team's hands. A vendor's audit log is evidence the team rents; this is evidence the team holds. When the question comes, months after the merge, the team answers it from its own record, with the name of the engineer who made the decision and the run that led to it.

Czar Forge is offered only to technology and AI teams, and this boundary is why those teams can use agents on work they are answerable for. The agents do the reading, the drafting, the testing, and the proposing. A named engineer makes the merge, and the record shows that they did.