Implementation: — (terminology) · Exposure: —. See status labels.
A model is never the brain. In Allternit the system is the agent. Models are interchangeable cognitive components that the system calls for specific steps. State, authority, lifecycle and completion belong to the system. If swapping one model for another changes the agent loop, the state model, tool authority, completion semantics or the workflow graph, the implementation does not conform to the architecture.

​
Architecture contract

​
What an agent is

An agent is one external identity backed by a system:
  • a typed task and agent state record, not a transcript;
  • explicit, scoped, expiring authority checked by policy;
  • a durable run carried by the work runtime;
  • completion decided from verification evidence;
  • receipts for every effect, input and verdict.
A model contributes to some steps inside that system: a bounded decision, a piece of generated text, a proposed plan. Its output is a proposal. It carries no authority, owns no durable state, and cannot declare the work complete.

​
Terms

​
The product metaphor

Allternit’s product story is “One Brain, Many Faces, One Nervous System”. It still describes the product, and it sits under the rule above:
  • The Brain is the whole runtime system (the kernel and the Gizzi runtime), not a model.
  • The Faces are the surfaces: desktop, web, extensions, CLI. They hold no agent logic of their own.
  • The Nervous System is the SDK and communication layer that connects surfaces to the runtime.

​
Current implementation

The Gizzi runtime and the work runtime in the Allternit Factory engine implement the system-owned parts that are live today. The full split, including what is not built, is in what is live today. Architecture pages never name a specific model or vendor: which model serves a step is execution evidence recorded in receipts, not part of any contract.

​
Availability

​
Developer relevance

Do not build against a specific model’s behavior. Build against contracts: request a capability or a model class, supply completion criteria, and read receipts. That is what keeps your integration working when the model behind a step changes.