How the patterns fit | Jivoo
The factory is the pattern. The runtime is a detail.
Claude on Azure is one implementation of a software factory. Cline, with its own orchestration and harness, is another. Both run the same six stations, the same tiers and the same evidence, because the design is held in configuration rather than in a vendor's product.
What never changes between implementations.
The spine every product selects, the extension a later stage owes, and the catalogue that makes it a framework.
The stations
Six, each with a named person who decides.
The tiers
The smallest model that does the task well, and escalation by decision.
The thread
One work item ID from request to release.
The record
Runtime, model, tier and policy version, on every step.
Two implementations, side by side.
Where the drafting happens in each implementation, and the four things both keep.
A hosted runtime, behind one model gateway.
Implementation A
Interactive work runs on the vendor's own seats, with the assistant at the person's keyboard. Automated and product calls run through a single model gateway in front of a cloud-hosted model service, so identity, network, logging, token budgets and failover are applied in one place.
- People at keyboards call the model direct, on non-production systems and synthetic data.
- Automation, autonomous jobs and product features call the gateway, which applies the tier.
- A second source per tier, so an outage is a failover rather than a stop.
- Where the data class demands a region the vendor does not serve, that work runs on a region-resident model.
- The gateway meters tokens per team, per runtime and per tier, which is what makes the cost visible.
Cline, with its own orchestration and harness.
Implementation B
An agent that works in the editor and the terminal, with its rules as configuration, tool connectors for the systems it may reach, and a headless mode so the same agent runs unattended in a pipeline. It is the same harness design, applied to a runtime that lives next to the code.
- Rules as configuration, so the standard is checked in with the repository rather than remembered.
- Tool connectors give controlled, scoped access to work items, documentation and cloud state.
- Headless runs make automation and review a pipeline job rather than a desk task.
- The model behind it is a setting, so the tier rule survives a change of provider.
- The same evidence record, because the record is written by the pipeline, not by the runtime.
How to choose between them.
| Question | If yes |
|---|---|
| Does unattended work touch customer data in cloud storage? | Put that plane behind the gateway, in the cloud account that already holds the data. |
| Does a data class forbid a region the vendor does not serve? | Route that work to a region-resident model, and record the decision. |
| Do teams work in the editor, on small changes, all day? | An editor-native agent pays for itself fastest, because the drafting happens where the code is. |
| Is security worried about an AI identity with standing access? | Non-production, person-scoped access and federated pipeline identities, whichever runtime is chosen. |
| Will the vendor change in two years? | Keep the standard in one canonical file and generate it per runtime. Then it is a configuration change, not a migration. |
The decision rules for choosing an implementation, and what holds either way.
The site states no price for either. A hosting decision is made against the data, the identity model and the audit, and priced for the estate it is made for.
Neither one is the architecture.
That is the point. The architecture is what survives a change of runtime, a change of model and a change of vendor, and it is written down before either is installed.