The framework: Ground, Govern, Graduate

Context

Context tells agents what matters.

Raw data access is not context. An agent can query every table and still not know what it is looking at. Context is what turns rows into situations.

A new hire picks up context no one writes down: from a meeting, a Slack thread, a hallway aside, the last call with the account. An agent gets a prompt, some tool access, and a few database rows. Most of what a human would know never reaches it. That gap is the main reason capable models still fail at real work.

An agent doing real work needs to understand:

• Business objects: what a customer, contract, ticket, or opportunity actually is
• States: open vs. escalated, trial vs. paid, at-risk vs. healthy
• Relationships: which account this ticket belongs to, which contract sets its SLA
• Ownership: who is responsible for this object and its outcome
• Policies and constraints: what the rules say about this kind of case
• Decisions and risks: what has already been decided, and what could go wrong
• Outputs and escalation rules: what a good result looks like, and when to hand off

Without this, an agent treats a "Sev-1 from your largest account" the same as a routine question, because both are just rows. Context is what makes those two rows different.

Lattice treats context as a curated, versioned, per-role asset, not something the agent rebuilds from scratch on every task.

And most of what matters never reaches a system at all. Call it dark context: the decisions, exceptions, and judgment that live in DMs, shared drives, meetings, calls, offsites, all-hands, and most of all in people's heads.

The catch is that the most decision-relevant context is the least captured. The pricing exception agreed on a call, the "never auto-close this account" said at an offsite, the reorg announced at all-hands: none of it is in any database the agent can query. A human absorbs it by osmosis over months. An agent sees only the lit fraction and acts, confidently, as if that were the whole picture.

So the first job of the Grounding layer is to capture dark context: to pull those decisions and exceptions out of DMs, Drives, calls, offsites, and all-hands and turn them into something an agent can actually consult. The lit fraction in the systems of record is the easy part; the work is surfacing the rest before an agent acts without it.

Ontology

Ontology tells agents what things mean.

If context is the situation, ontology is the map: a model of the business (customers, accounts, contracts, tickets, opportunities, workflows, approvals, policies, decisions, agents, humans, and outputs) and how they connect.

A working ontology tells an agent four things about every object:

1. What it is: the type and its meaning in the business
2. What state it is in: and which transitions are legal from here
3. What actions are valid: what may be done to it, by whom, under what conditions
4. Who owns the outcome: the accountable human or team

This is deliberately not academic ontology. It is not a debate about whether a contract is-a agreement. It is an operational map: this is a contract, it is in renewal, you may draft a summary but not send a notice, and the account owner signs off. The agent never has to guess what an object means or what it may do with it.

The ontology is also what makes the rest of Lattice enforceable: permissions, policies, and the graduation ladder all attach to ontology objects and states. "Issue a credit over $X requires approval" is only meaningful if the system knows what a credit is, which account it touches, and what state that account is in. Without a shared model, every policy collapses into a brittle string match against raw data. With one, you write the policy once (agents may not send renewal notices on contracts in dispute) and it holds no matter which system the underlying data lives in.

The control plane

The control plane tells agents what they can do.

Context and ontology give the agent understanding. The control plane gives the enterprise control. It governs:

• Which agents exist and what role each performs
• What tools each may use
• What data each may access
• What actions each may take
• What requires approval before it executes
• How activity is logged: every action, with its justification
• Who is accountable for each agent's behavior

The key shift is from tool access to actions in context. Most security stops at the grant: does this agent have the refund tool, the database connection, the send-email scope? Access is the easy part. The same tool is safe in one context and damaging in another. A large refund is routine on a small billing error and a serious mistake on a strategic account mid-renewal. The tool did not change; the context did. So Lattice governs the action in context, not the grant: what the action is, which object it touches, what state that object is in, and who has to sign off before it runs.

Crucially, the control plane is a chokepoint, not a guideline. An agent does not "try to follow" the rules: its actions pass through Lattice, anything outside its granted authority does not execute, approvals hold until a human clears them, and logging happens at the point of action. Nothing depends on the agent choosing to comply.

The chokepoint also sits on the way in and the way out, not only on the action. These are guardrails in the usual sense. On the way in, an agent can be tricked: a support email, a web page, or an uploaded file can carry hidden instructions that try to hijack it into issuing a refund or exporting a customer list. Lattice screens the input before the agent acts on it, so a planted instruction never becomes an action. On the way out, it screens what the agent is about to send, which matters most when the recipient is high-risk: a customer, an executive, an outside party. A reply that leaks another account's data, or a number that looks wrong, is held before it leaves.

And someone owns the result. In a human-only world, access really was enough, because people came with accountability built in. Give an employee the refund tool and they also bring the judgment to use it well and their name on the line when they don't. An agent brings the capability and none of the accountability, so Lattice attaches it. Every action has a named human owner who answers for the outcome, the way a manager answers for a report's work. No enterprise will accept "the agent did it," even when the agent acted on its own.

Where humans stay in the loop

None of this removes people. Lattice draws the line between what an agent does on its own and what it hands to a human, so the two work as a team. Most real workflows are a mix of both, and the handoff is the part that has to be explicit.

There are three handoff points, and the control plane decides when each one fires:

The triage agent uses all three. It answers the routine ticket on its own, sends the large credit to the support lead to approve, escalates the top-tier Sev-1 to on-call, and leaves a trail the lead can override later.

The graduation level just sets the default. Level 1 hands almost everything to a person; Level 4 hands only the exceptions. Raising the level moves the handoff line. It never removes the human.

The graduation ladder

Agents earn trust over time.

No one gives a new hire signing authority on day one; they watch, then suggest, then act under supervision, then act on their own. Agents should earn authority the same way. Lattice defines a graduation ladder, and an agent occupies exactly one rung per role.

The ladder is per-role, not per-agent. The same agent might sit at Level 4 for ticket triage and Level 1 for issuing credits. Trust is scoped to a domain, never granted globally.

The agent scorecard

You cannot graduate what you do not measure, and model accuracy is the wrong measure. An agent can be 95% accurate and still be untrustworthy if its 5% of errors all land on high-risk actions, or if it never escalates when it should. Lattice scores agents on business trust, across dimensions a model benchmark ignores:

An agent that confidently handles the easy 90% but cannot recognize the dangerous 10% is not ready, regardless of its accuracy score. The scorecard is not a single number; it is the evidence file the graduation gates read from, and the same file consulted when something goes wrong and someone asks how the agent was allowed to do that.

Graduation gates

Graduation tells the enterprise when agents are ready for higher-stakes work.

An agent moves up a level only when it clears explicit thresholds, conditions checked against the scorecard rather than a judgment call:

• No critical policy violations in the evaluation window
• Override rate below threshold for the target level
• Strong escalation judgment: it hands off the right cases
• Complete audit trail: every action is logged and justified
• Good outcome quality: results hold up to review
• Explicit sign-off from the business owner or risk owner

The last gate keeps a human in the loop on the promotion, even as the agent grows autonomous in the work. An agent never promotes itself.

Regression and demotion

Graduation runs both ways. Trust that can only increase is not trust; it is drift. If an agent's behavior degrades (a drop in scorecard performance, a policy violation, a spike in override rate, a rise in surrounding risk), Lattice can pull it back. The responses escalate with the severity:

• Reduce scope: narrow the domains it operates in
• Require human approval: drop it from guardrails back to per-action sign-off
• Remove tools: revoke a capability that is being misused
• Pause execution: freeze the agent pending review
• Move it down a level: formal demotion on the ladder

Demotion is not a failure of the system; it is the system working. The machinery that earns trust is the machinery that revokes it.