Lattice
The policy and action execution engine of AlfredOS
Overview
Lattice is the execution layer of the agentic operating system. It turns objectives into verified, typed, composable actions and runs them on a signed trust boundary. An agent in AlfredOS is not an opaque conversational process, it is a structured set of typed actions with explicit contracts, and Lattice is what selects, composes, and executes them.
Because the execution model is discrete and typed, every decision the system makes is inspectable, you can see what it planned, what it attempted, and what it concluded.
Primitives
Action
The smallest primitive: a typed, signed, pre-compiled unit of work with an explicit contract (schemas, method, path, timeouts). Actions are registered to Lattice and can only run in approved, compiled form.
Objective
A composition of actions negotiated and compiled into an executable workflow. Objectives are planned before they run.
Workflow
A compiled objective. Because everything composes like building blocks, an entire workflow can itself be collapsed into a single action and reused.
Execution Model
No Tool Calls
Lattice does not rely on model-triggered tool calls, a common failure mode in other agent systems. Actions are invoked through a hard schema, which removes a whole class of misfires and makes execution fully asynchronous: work is dispatched and runs in parallel where dependencies allow, rather than blocking a chat loop.
Plan Before Executing
Higher-order agents build a dependency graph of what must happen and in what order, then coordinate sub-agents through explicit interfaces rather than unstructured prompt delegation.
Compile → Execute → Record
An objective is negotiated, compiled, executed, and every outcome is written to an execution ledger: the lineage of what succeeded, what failed, what has already been solved. The 5/4 demo ran this end to end in roughly one minute per policy.
Objective Negotiation (Actor–Critic)
Lattice negotiates objectives through an actor–critic loop. Today the user is the critic with the model assisting; the roadmap moves toward making negotiations legible enough in plain English that an LLM critic can reliably catch bad compositions, evolving toward a hybrid user/LLM critic model.
Until that hardening lands, the safe default is to deploy pre-compiled actions and hand out keys that can only invoke them, avoiding catastrophic failures from over-delegating objective creation to the model.
Deployment Topology
01
Customer
The tenant boundary and authority domain.
02
Lattice Deployments
One or more privileged deployments, scoped per team or division.
03
NOD3 Deployments
Per-user consumers connected through scoped API keys.
Customer → team-scoped Lattice authority → user-scoped NOD3 workspaces.
Lattice is a privileged system, only a system administrator / key holder operates it; NOD3 instances are consumers connected via scoped API keys.
Backed by Postgres; does not itself need artifact storage beyond backups.
Separating Lattice deployments per team contains failure and limits blast radius: a compromise or bad command in one team's deployment cannot reach another's. If Betty in HR runs the wrong command, only HR is affected. This decentralization is also a core security selling point.
Security Model
The signing and trust boundary, root key, derived per-action keys, signed registration, and Lattice-public-key-verified invocation are documented separately on the Lattice Security Model page.
In short: only holders of the Lattice root key can register actions, and only Lattice-signed requests can invoke them; the action surface needs only the Lattice public key.
→ Read the Lattice Security ModelStatus & Roadmap
Operational model proven; first secured deployments in progress. Near-term: an action builder so teams can author and publish their own actions/workflows safely; stronger objective-negotiation critics; the security-model hardening path (per-action key provisioning, replay protection, KMS/HSM, result signing).