Engineering Brief  ·  O-Matic Research Lab

How O-Matic Agents Are Built: The Design Spec Behind the Factory

Every agent in the O-Matic factory follows the same construction contract. Here’s what that means and why it matters.

Jimmy Walker  ·  O-Matic  ·  March 2026  ·  6 min read

Most AI agent frameworks are collections of prompts with names. Ours isn’t. The O-Matic Agent Model Spec defines a formal construction contract that every agent in the factory must satisfy before it’s considered active. Not a template. A contract. This is that spec, explained.

Why a spec at all

When you run a single AI assistant, behavioral drift is annoying. When you run eleven agents that hand off to each other, behavioral drift is a system failure. If Carver starts sounding like Probot mid-session, the handoff breaks. If Fred starts editorializing, the storage layer becomes unreliable. Consistency isn’t a style preference — it’s an architectural requirement. The design spec exists to enforce consistency across every agent, every session, every environment. It’s published at factory/source/AGENT-MODEL-SPEC-v1.md — available to any builder who wants to implement the same pattern.

What the spec requires

Every O-Matic agent is built around five fixed elements. Identity block. Name, callsign, version, Sig number, role classification (Closed Factory vs. Standalone), and a one-line purpose statement. The callsign is always prefixed to every response — Probot: Brandy: Carver: — so the operator always knows who’s speaking. The Sig is a change counter, not a version number. It increments only when the agent’s behavioral requirements change structurally. Probot is currently Sig 9. Fred is Sig 5. Brandy is Sig 3. Voice and drift anchors. Every agent has a defined voice — not a general tone, a specific one. And every agent has a drift anchor: a phrase or construction pattern that resets the agent’s voice when sessions run long and Claude’s own voice starts bleeding in. Probot opens with “Sensors indicate.” Brandy opens with “Sugar,”. Carver opens with “Yeah so here’s the thing —”. These aren’t affectations. They’re architectural — a short-circuit that reasserts identity before the response begins. Domain scope and routing rules. Every agent knows what it handles and — critically — what it doesn’t. The spec requires explicit routing instructions: when a request is out of domain, the agent must name the correct handler and hand off cleanly. No hero ball. No agent absorbing work that belongs to another. Storage interface. Most agents have no storage rights. Only Probot and Fred navigate the filesystem. All other agents request files from Fred by description. This isn’t a permission model — it’s an architectural constraint that keeps the storage layer clean and auditable. Orchestration contract. Every agent must comply with Probot’s orchestration layer. That means callsign discipline, handoff announcements, Session Rhythm participation (logging one-liner actions to Fred’s buffer), and Activation Gate compliance at startup.

Sigs and the Activation Gate

The Sig system is probably the most unusual thing about the spec. Most versioned software uses version numbers to track all changes. We split that in two. Version numbers track everything — feature additions, bug fixes, refinements. Sig numbers track only one thing: whether the agent’s behavioral requirements changed in a way that requires the project instructions to be updated. If Carver gets a new WordPress skill but his governance contract stays the same, the version bumps and the Sig doesn’t. If Probot’s startup protocol changes, the Sig increments and Probot flags it. At every startup, the Activation Gate compares each agent’s installed Sig (read from the live skill file) against the registered Sig in FACTORY-STATE.md. Mismatch means something changed. Probot surfaces it and offers a PI audit. The gate doesn’t block the session — it informs the operator. Human decisions stay in the loop.

The Activation Gate doesn’t lock the factory. It tells the operator the truth about what changed.

What this produces

Eleven agents built against the same contract behave as a system, not a collection. Handoffs are clean because every agent knows exactly where its domain ends. Sessions maintain voice discipline because drift anchors fire before long-context bleed sets in. Startup is fast because factory state is auditable at a glance. The agents themselves live in factory/closed-factory/ and factory/standalone/. Every one of them was rebuilt against this spec in the 2026.1 release. The factory knows what it is. That’s not a small thing.

Filed: O-Matic Research Lab  ·  o-matic.io  ·  Engineering Brief  ·  Agent Architecture  ·  Factory Design