Agentic coding on one Czar inside the bank

A bank's technology team wants the agents everyone else has. It has watched other teams let agents read a repository, propose a change, write the tests, and explain a failure, and it knows what that would do for a backlog of its own. What it cannot do is send its source code, its incident data, or its change records to a vendor's cloud to get the same thing. One Czar inside the perimeter runs the coding agents on the bank's own repositories, prepares the change, reads the incident, and assembles the evidence. A named person approves anything that touches production.

What the team is asked to do

The work has three shapes. The first is writing and maintaining code across many services, most of them old enough to have no one left who remembers why they were built. The second is changing production safely, which means a change packet, a rollback plan, test evidence, and an approver who can defend the decision afterward. The third is responding when something breaks: reading logs and traces across systems, finding the cause, fixing it, and producing an account of what happened that a reviewer can read later.

Every one of these is reading a large amount of the bank's own material and drafting from it, which is what agents are good at. Every one of them is also something the bank is answerable for, which is why each team has so far been offered an assistant and told it cannot use it.

Why a cloud assistant fails here

Source code, incident data, and change records cannot leave the perimeter. A cloud assistant works by sending them out, whatever it promises about what it keeps. That alone settles the question for most teams in a bank, but it is not the only constraint. An agent cannot be the approver of a production change: a change that was proposed, tested, and promoted by the same assistant has no person behind it, and the bank needs one. Evidence assembled in a vendor's tool is evidence the bank does not hold; when the review comes, the bank wants the pack on its own record, not in someone else's workspace. And each team's assistant would be a separate path out of the perimeter, each one to be reviewed, each one to be explained.

Coding agents on the bank's own repositories

On one Czar inside the perimeter, agents in Agency Studio read, write, and test code against repositories that never leave the building. Local Bridge carries the declared routes to source control, the build and test system, and the ticketing system; there is no other route. Inference runs an open-weight model on the appliance, Retrieval gives the agent the service's code and its history, and Memory keeps what the agent has learned about the codebase between tasks. Adaptation can tune the model on the bank's own conventions, on the appliance, so that the proposals read like the bank's code rather than someone else's.

The agent is bounded to the repositories and branches it was authored for. It opens a change, writes the tests, runs them, and reports; it does not merge, and it does not promote.

A change prepared; a person approves

For a production change, the agent assembles what the approver needs to decide: the change packet, the rollback plan, the test evidence, the services affected, and the open questions. The packet waits in a queue for the named approver, who approves, sends it back, or rejects it, and that decision is written beside the packet. The promotion itself happens only through the approver's action.

That is the boundary this solution is built around. Agents prepare and propose; a named person approves. Nothing customer-facing, client-facing, or production-changing leaves the appliance without that approval, and every step is on the record the team holds.

Incident diagnostics with the evidence pack

When something breaks, an agent reads the logs and traces on the appliance across the systems involved, correlates them with the recent changes on the record, and proposes a cause with the evidence that supports it. The engineer on call decides whether the proposal is right and what to do about it. As the incident is worked, the agent assembles the pack: the timeline, the traces, the changes, the proposal, the fix, and who approved what. The pack is the bank's, on the appliance, and Evaluation scores the agent's proposals against incidents the team has already resolved, so the team can see where to trust it. Watchman verifies what is running, and any run can be replayed to show how a proposal was reached.

One Czar, placed and bought

The Czar is a sealed node in the bank's own rack, inside the perimeter, on the segment the bank chooses. Its routes are declared one by one at commissioning: source control, build and test, ticketing, the log and trace stores, change management. Nothing else. It can run with no route out at all, or connected only to systems the bank already secures. The team holds one subscription for the configured appliance, with the hardware, the platform license, and sustainment in one line, fixed for the term, so adding an agent or a repository does not move it. A solution brief for a bank technology team describes the intended architecture; it is substantiated at commissioning and makes no customer claim.

The bank's constraint was never that agents are unsafe. It was that the only way to have them was to send the bank's material away and let a service act without a name on the result. One Czar inside the perimeter keeps the material, keeps the record, and keeps the approver, and gives the team the agents it has been waiting for.