Part 1 of 3 · Onboarding Digital Labor

The problem: capability is arriving before onboarding

Onboarding digital labor is the hardest challenge the enterprise faces in the agent era. It leaves every company with three options. Move fast and break things: unleash agents and absorb the damage. Brand harm, AI slop, work no one can trust. Or move slow but safe: hold them back and forfeit the productivity. Most companies are stuck on these two. The fix is the third: onboard each agent like a worker, with the context to do the job, limits on what it can touch, and a named owner for the outcome.

Read ~6 minPart 1 of 3

Model capabilities keep climbing. The productivity enterprises actually get from agents has not kept pace. Why?

Because capability is no longer the bottleneck it used to be. Capable models are becoming common. What is scarce is the structure around them: the context to understand the business, the controls on what an agent is allowed to do, and the accountability for the result. That structure is the hard part, and it has to be built.

A prompt configures a model, and for most agents that is where onboarding stops. But onboarding a worker is everything around the model. When a human joins a team, they inherit a role, the context behind it, permissions, the policies that bound their judgment, a manager who reviews their work, and an accountable place in the org chart. An agent arrives with none of that. We hand it a prompt and an API key, then act surprised when it behaves like a contractor who started an hour ago and already has the keys to production.

Capability is arriving before onboarding

The enterprise agent stack is improving from the bottom up. Models are getting better.

But the onboarding layer is missing.

And it is missing right when it is needed most. Models have just crossed the line from answering to acting. A system that only answers can be wrong harmlessly: a human reads the output and decides what to do with it. An agent that acts is wrong in production. That moves the hard part from intelligence to authority, and it is happening now, not someday.

That is the layer Lattice occupies. It is the control plane for digital labor: it gives agents business context, models the business through an ontology, governs what they can see and do, scores their performance, and graduates them into higher-trust work over time.

Filling the gaps your tools leave

IAM, workflow engines, observability, vector databases, agent frameworks: each solves part of the problem. Lattice is easiest to place by what it is not:

Lattice is not…Because that only gives you…
an agent registrya list of agents, not their authority or fitness
IAMrow-level access, not action-level judgment
workflow automationexecution, not meaning or accountability
observabilitya record of what happened, not control over what happens next
a harness or meta-harnessa place to run agents, not the meaning, authority, or trust around them

Take IAM. It answers can this identity read this row? It never answers the question agents raise: should this agent take this action, on this object, in this state, given this policy, and who answers for it if it's wrong? Access control is binary and static; agent authority has to be conditional and dynamic: allowed here, in this state, up to this threshold, and only while the agent's track record holds. None of that fits in an access-control list.

Or take the harness. A meta-harness that runs Claude Code, Codex, or your own agents behind one interface gives you a lot: a uniform runner, a sandbox, cost caps, network limits. But those controls are about the session and the machine, not the business. The sandbox can stop an agent from reaching a secret. It cannot tell you that a refund on this account needs the owner's sign-off, or that this agent has earned the right to issue it. The harness runs the agent. It does not know what the work means or who answers for it.

Each of these systems is necessary. None is sufficient. Lattice connects them around the three things they individually ignore: what the business means, what an agent is allowed to do in a given situation, and who is accountable for the result. It does not replace them; it sits above them and gives them a shared frame. Everything below answers what happened or what is technically allowed; Lattice answers what should happen next, and who stands behind it.

Concretely, that draws a clean line between what Lattice owns and what it composes with:

Lattice ownsLattice composes with (does not own)
the agent's meaning: context and ontologythe model, the agent framework, the harness
its authority: roles, policy, what needs approvalIAM / identity, the policy engine that enforces
its trust trajectory: scorecard, graduation, demotioneval and observability tools that emit the signals
the accountable owner behind each actionthe runtime, durable execution, vector and memory stores

The rule: Lattice owns the decisions, and composes with everything that stores, retrieves, or executes. You should be able to swap the model, the agent framework, or the database under it without touching Lattice.

Granting an agent database access is not onboarding. It's giving a new hire a master keycard and no manager.

The primitive model

Lattice onboards digital labor through a chain of primitives. Skip a link and the agent runs with a blind spot.

Role Context Ontology Permissions Tools Policy Evaluation Graduation Accountability
PrimitiveThe question it answers
RoleWhat job is this agent here to do?
ContextWhat does it need to know to do that job?
OntologyWhat do the things it works with mean?
PermissionsWhat is it allowed to see?
ToolsWhat is it allowed to use?
PolicyWhat requires approval, and what is forbidden?
EvaluationHow well is it actually doing?
GraduationHas it earned more trust?
AccountabilityWho answers for the outcome?

These nine collapse into three jobs, and the rest of this note is organized around them, in order:

JobPrimitivesWhat it does
GroundRole · Context · Ontologygive the agent meaning
GovernPermissions · Tools · Policy (the control plane)bound what it can do
GraduateEvaluation · Graduation · Accountabilitymeasure it, then grant or pull back authority

Ground and Govern make an agent useful and safe on day one. Graduate is what lets its authority grow after that. Part 2 builds the framework, one job at a time.