What Czar Forge is

A software team, a platform team, a data team, or a machine-learning team has the same wish and the same constraint. It wants agents that read its code, answer questions about its systems, tune a model on its own data, and serve that model to its own applications. It cannot send its repositories, its tickets, its datasets, or its traces to a vendor's cloud to get any of that. Czar Forge is Czar configured for exactly this kind of team: the same sealed appliance, the same subscription, loaded for the work of engineering and machine learning, and placed inside the team's own perimeter.

The same appliance, configured for one kind of team

Czar is the appliance. One Czar serves one team or a small floor on its own subscription, air-gapped or connected only to systems the customer already secures. Czar Forge is not a second machine; it is Czar with Substrate and Agency Studio loaded for what technology and AI teams do. The Substrate services are the same seven as on any Czar: Inference, Retrieval, Memory, Adaptation, Evaluation, Watchman, and Local Bridge. What changes is what they are pointed at. Retrieval indexes repositories and runbooks rather than a clinical record. Adaptation tunes on code and datasets rather than on a floor's captures. The agents in Agency Studio are authored for review and triage rather than for a ward or a program office.

Czar Forge is offered only to technology and AI teams: software engineering, platform, data, and machine-learning teams. A hospital department, a legal practice, a program office, or a control room runs on Czar, not on Forge. The distinction is about who the appliance is loaded for, not about which appliance it is.

Six things a team gets

The first thing a team gets on a Czar Forge is coding agents on the team's own repositories. Agents read, write, and test code against repositories that never leave the building. They open a change, write the tests, run them, and report. They do not merge, and they do not promote.

The second is the repository index. Code, design notes, tickets, runbooks, and documentation are indexed on the appliance and questioned in place, and every answer carries the passage it came from.

The third is adaptation on the team's own code and data. Open-weight models are tuned on the team's own repositories, conventions, and datasets, on the appliance, and the adapter stays inside.

The fourth is evaluation before anything is promoted. A harness on the appliance scores models, prompts, and agents against the team's own test sets and past resolved work. Nothing is promoted on a feeling.

The fifth is serving for the team's own applications. The team's internal tools and products call the models on the Czar Forge over the team's own network, with no vendor in the path.

The sixth is the team's agents in Agency Studio: review, build-and-test triage, incident diagnostics, release notes, dependency and vulnerability review. Each is authored, bounded, approved by a named engineer, versioned, and recorded, and any run can be replayed.

What the agents may not do

Everything on that list ends at the same line. 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. An agent can write a change and show that it passes the tests; a person merges it. Adaptation can produce a tuned model and Evaluation can score it; a person promotes it. The boundary is not a setting a team can forget to turn on. It is how the agents are authored and how the routes are declared.

How it is placed

A Czar Forge sits inside the team's perimeter, on the segment the team chooses. It can run with no route out at all. Where the team permits connections, they are declared one by one at commissioning: source control, the build and test system, ticketing, the log and trace stores, the artifact store. Local Bridge permits those routes and denies everything else. Updates arrive as signed bundles, by media or by the team's own network, and Watchman verifies what is running.

Where a team wants optional overnight batch work, such as a long fine-tune or a large evaluation sweep, the Compute network is being built so that a job can leave the Czar Forge as a sealed job and come back as a signed bundle, with the appliance's own record of what went and what returned. It is a technical preview, and the Forge does not depend on it.

How it is bought, and how it grows

The team holds one subscription for the configured appliance: hardware, the platform license, and sustainment in one line, fixed for the term. Usage does not change the bill. Adding an agent, indexing another repository, or running another adaptation does not move it.

When a technology team grows past one Czar Forge, more Czars join it as a Czar Grid: one pool with the same services, the same agents, and the same record. Nothing is rewritten, and the team's work carries over as it was.

The team's wish was never unusual, and neither was its constraint. Czar Forge is the appliance every other team has, configured for the one kind of team whose work is code, data, and models, and placed where that work already lives.