Coding agents on Czar Forge

A software team with many services and a long backlog knows what a coding agent could do for it: pick up a ticket, read the service, propose the change, write the tests, run them, and explain what it found. What the team cannot do is let an assistant in a vendor's cloud read its repositories to get there. On a Czar Forge, the agents come to the code. They run on the appliance inside the team's perimeter, against repositories that never leave the building, and they stop at a line the team draws.

What an agent reads

An agent on a Czar Forge is authored for a set of repositories and branches, and it sees nothing outside them. Within that set, Retrieval gives it the service's code, its history, the tickets that touch it, the design notes that explain it, and the runbooks that describe how it is operated. Memory keeps what the agent has learned about the codebase between tasks: which modules are fragile, which conventions the team enforces, which tests are slow. Inference runs an open-weight model on the appliance, and where the team has used Adaptation, the model has been tuned on the team's own repositories so that its proposals read like the team's code.

The agent reads a great deal of the team's own material, which is what agents are good at and what a team has never been able to let an outside service do. All of that reading stays on the appliance.

What an agent writes and tests

Given a task, the agent opens a change on a branch it is permitted to use. It writes the code, writes or extends the tests, and runs them through the build and test system over the route declared at commissioning. If the tests fail, it reads the failure and tries again, within the bounds the author set for it. When it is done, or when it has run out of what it is allowed to try, it reports.

The report is a change packet: the change itself, the tests it added, the results of running them, the services and interfaces affected, the reasoning for the approach, and the open questions it could not resolve. The packet is written to the record on the appliance, and it waits in a queue for the named engineer who owns that repository.

What an agent never does

An agent on a Czar Forge does not merge. It does not promote a build, cut a release, push to a protected branch, or change anything a customer can reach. These are not instructions the agent is asked to follow; they are routes the agent does not have. Local Bridge carries the declared routes to source control and the build and test system, and the actions that merge or release are permitted only for a person's action. An agent that writes a flawless change still cannot land it.

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 named engineer

The engineer reads the packet from the team's own record, not from a vendor's workspace. They can see what the agent read, which passages of the code and the runbooks it relied on, what it tried, and what failed before the version in front of them. They approve, send it back with a note, or reject it, and that decision is written beside the packet with their name. The merge happens through their action, over the route the team declared.

A team can keep the loop tighter for some repositories than for others. A library many services depend on might require two engineers; an internal tool might accept one. Those are choices the team authors into the agent and its queue in Agency Studio, versioned like anything else.

Where the agents fit beside the rest of the Forge

Coding agents are one of six things a technology team gets on a Czar Forge, and they lean on the others. The repository index is what the agents read. Adaptation is why their proposals match the team's conventions. Evaluation scores the agents against the team's own past resolved work, so the team knows which kinds of tasks to trust them with and which to keep for a person. Any run can be replayed to show how a proposal was reached, which is how a team learns what to change in an agent's authoring. Czar Forge is offered only to technology and AI teams; every other kind of team runs its agents on Czar.

The team's hesitation was never about whether agents can write code. It was about where the code would have to go for an agent to read it, and who would be answerable for what the agent did. On a Czar Forge the code stays, the record stays, and a named engineer decides. The agents do the reading and the drafting, which is the part the team wanted help with.