Glossary.

Agentization Core OS, written >æ-c os., is the gateway to a client's products: every delivered repository, every agent and service, the hosts they run on and the pipelines that ship them, in one place. It runs as an application on the architect's machine and on the client's servers. It is not a computer operating system. The operating environment →

a-c os is the short ASCII spelling of Agentization Core OS; the wordmark sets it as >æ-c os. The a-c stands for agentization-core, the company. It names the operating environment that runs the client's cores and agents, not an operating system for hardware.

Architect Wizard is the desktop application that generates agent resources, applications and their code from versioned flows. It is delivered with Agentization Core OS and bound to a client's core at handover; it is not a public download. Every generation it writes lands as a commit in the client's own repository. Architect Wizard →

A CLI agent is an agent that works in a terminal, inside the client's repository and under one enforced harness. Each holds a single tier and role: development, operations or infrastructure. It is built from the core record, it cannot act outside its tier, and every tool call, refusal and approval it makes is written to its audit channel. The CLI agents →

A core is one delivered environment: a repository of agents, workflows and generated code, its core record, its audit channel and the hosts it runs on. Cores run in the client's own infrastructure. A consultancy holds one core per client engagement; an enterprise fleet is many cores under one organization. The enterprise core →

An OS tier is the level of the OS set in an engagement. Operate is the OS itself: observe, control, approve, raise support. Build adds Architect Wizard with the engagement's flows. Build and Support adds the three support levels through the console. Accounts and wizard flows follow the tier.

core.json is the signature of a delivered repository: the record the client owns with the code. It names the framework services installed, their versions, the guardrail patch level and the support channel, so the tools know what to do. It moves no data, holds no secrets and is plain JSON anyone can read. The published shape →

The core signature is what makes a repository an official one: it binds the delivered code to a framework release, a guardrail patch level and a support channel. The compiler reads it to rebuild or retarget the core, so moving between agentic technology providers is a compile step rather than a rewrite. Delivery →

A wizard flow is one guided generation path in Architect Wizard: a named, versioned recipe that writes a piece of agent infrastructure into a core. Flows are delivered into Architect Wizard and installed into the client's core as part of an engagement. The core record names the flow version each application came from. Flows follow the tier of the engagement.

An audit channel is the ordered record every governed action writes to: each allow, block, flag, approval and support step, with who or what took it. Channels are created, assigned and reviewed by the client's administrators, and a core reports to the one its core record names.

An image is the deployable form of a repository, produced from the OS. The client may branch from it and live on the branch; the original stays with the OS, and security patches reach the image from there.

A helper is a versioned component the compiler needs to upgrade, migrate or patch a repository. The core record names each helper and its version, so an upgrade starts from accurate input.

A target is a host the OS connects to for deployment: a dedicated server, the client's own server, or the client's cloud account. Targets are named in the core record.

A2A, agent to agent, is the connection agents use to hand work to each other inside a core and across cores. Application agents, terminal tiers, teams and named external entities all use it. Every connection carries an identity, a scope and an allowlist of routes, and every one of them is recorded. The protocol reference →

The ATO, the agent task object, is the object one unit of work moves as. It records the data path, the execution order, the model usage and the alerts raised, so the audit travels with the task instead of being reconstructed afterwards. Deterministic checks run on it before any model is called. The task object →

Guardrails are enforced in three layers: deterministic hooks in the execution path, machine-learning detection that scores behaviour, and guardrail agents that apply policy judgment under human gates. All three write to one audit channel, and the layers a repository runs are named in its core record. The three layers →

A worker is one running agent process; a session is one bounded run of a task by a worker. The OS starts, stops, resumes and audits both, and each ATO runs in one session of one worker.

Delivery runs through consultancies. Agentization Core builds the framework; Exceed Solutions is the main consultancy and handles contracts, onboarding and direct clients; partner consultancies deliver to their own clients on their own accounts. The client keeps custody of its cores, data and repositories throughout. Partner consultancies →

A support grant is the client's approval that lets support reach a core: a session with a named scope, a set of paths and a time limit, opened on request and closed when it expires. Support acts only within the granted scope, and every action it takes, allowed or refused, is recorded on the audit channel. The three support levels →

A support account is an account issued from the console for a client organisation. It lets the OS use Architect Wizard with the flows of the organisation's tier and, at the Build and Support tier, raise support requests.