Buying Czar Forge: one subscription, one appliance

A technology team that wants agents inside its own perimeter usually expects to buy them the way it has bought everything else: hardware from one vendor, licenses from another, a support contract on top, and a meter somewhere that nobody can forecast. Czar Forge is bought differently. It is one subscription for one configured appliance, and the subscription is the whole of it.

One subscription for one configured appliance

A Czar Forge is Czar configured for a technology or AI team, and the subscription covers the configured appliance: the hardware in the team's rack, the platform license for Substrate and Agency Studio, and sustainment, in one line, fixed for the term. There is no separate hardware purchase, no software license to true up, and no support agreement to renew on a different calendar.

Usage does not change the bill. A team that authors more agents, indexes more repositories, tunes more adapters, or serves more of its own applications from the Forge is using the appliance as configured, and the line stays where it was set. This matters more for a technology team than for most, because a technology team's use of its tools grows quickly once they work. A meter would turn every new agent into a budget question. One line makes it an engineering question.

What the subscription includes

The configured appliance arrives loaded for the team. Coding agents on the team's own repositories; the repository index over code, design notes, tickets, runbooks, and documentation; Adaptation on the team's own code and data; Evaluation before anything is promoted; serving for the team's own applications; and the team's agents in Agency Studio, with review, build-and-test triage, incident diagnostics, release notes, and dependency and vulnerability review ready to be authored and bounded by the team's own engineers.

Underneath those are the seven Substrate services: Inference, Retrieval, Memory, Adaptation, Evaluation, Watchman, and Local Bridge. Sustainment covers the signed updates that keep them current, support through the customer portal, and remote sessions that the team initiates when it wants one and that never begin from the outside. All of this is in the one line. Nothing is sold alongside it.

Declared routes at commissioning

The Forge sits inside the team's perimeter, on the segment the team chooses. It can run with no route out at all, for a team whose code must never be reachable from anywhere. 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. A route that was not declared does not exist, and adding one later is a deliberate act by the team, on the record.

Commissioning is where the subscription becomes a working appliance. The team's engineers name the repositories the index will hold and the agents may read, the test suites Evaluation will score against, and the applications that will call the models. The named engineers who may merge, promote, and release are recorded then too, because the boundary is set at commissioning and holds from that day. 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.

Signed updates

The appliance never reaches out for its updates. They arrive as signed bundles, by media for a team that runs with no route out, or over the team's own network where the team has permitted one. The team decides when a bundle is applied, and Watchman verifies afterward that what is running is what was signed and what the team approved. An update to Substrate or to Agency Studio arrives the same way, and a team that has adapted models or authored agents keeps them through it; an update does not reset the team's work.

This is sustainment as a technology team would want it: predictable, on the team's own schedule, and verifiable from the team's own record rather than from a vendor's status page.

Growing into a Grid

One Czar Forge serves one team or a small floor. When a team grows past it, more Czars join as a Czar Grid: a pool the team's agents, index, adapters, and applications draw from as one. Nothing the team has built is rewritten; the agents in Agency Studio run as they did, the index and the adapters move to the pool, and the declared routes carry over. Joining more Czars is a change to the configured appliance described in the agreement, and the line is set again for the new configuration and fixed for its term. Within a configuration, growth in use does not move it.

For a team that occasionally has a batch job larger than its Forge, the Compute network is being built so that a long fine-tune or a large evaluation sweep could leave as a sealed overnight job and return as a signed bundle, to be evaluated and promoted on the Forge like any other result. It is optional and designed for the exceptional run.

A technology team buying a Czar Forge is buying one thing: a configured appliance inside its own walls, with the platform and the sustainment in the same line, fixed for the term, on routes it declared. The decisions that follow are about the team's code and the team's agents, which is where a technology team wants them to be.