In practice, and what's coming
The framework on a single ticket, where to start tomorrow, and what changes as agents go from a handful to a fleet.
Ground, Govern, and Graduate are not stages you finish; they run at once, on every action.
A support triage agent
A support triage agent reads inbound tickets, gathers context, and resolves or routes them. Here is what Lattice wraps around it.
Context it receives
- Customer context: who they are, tier, account health, recent history
- Contract / SLA context: entitlements and the response clock running on this ticket
- Ticket state: new, in progress, escalated, or awaiting customer
Ontology it operates in
- A ticket belongs to an account, which holds a contract, which sets an SLA.
- A ticket in
escalatedallows different actions than one that isnew.
Actions and approvals
| Action | Authority at Level 4 (within guardrails) |
|---|---|
| Categorize and tag the ticket | Autonomous |
| Reply with a known-good answer | Autonomous |
| Route to a specialist queue | Autonomous |
| Issue a credit under $X | Autonomous |
| Issue a credit over $X | Requires human approval |
| Touch a top-tier account's Sev-1 | Escalate to a human |
Accountability
Every action is logged with the context the agent saw and the reason it acted. The support lead is the named owner, so if the agent mishandles a case, there is a trail to review and a person who answers for it.
A trace, end to end
Put it in motion. Run the same ticket three ways and watch what changes:
Nothing here required the agent to be told "ask before issuing large credits to big accounts." The agent reasoned; Lattice decided what that reasoning was allowed to do.
At Level 1, this same agent only suggests the category and the reply for a human to approve. Onboarding is not a one-time switch from "off" to "on." It is a dial Lattice turns in either direction as the evidence accumulates.
Before Lattice: the agent has a database login and a model. It answers fast, occasionally refunds a strategic account it shouldn't, and no one can reconstruct why.
After Lattice: the same agent, grounded in account and SLA context, gated on the two risky actions, scored, and owned. It clears the routine cases and escalates the rest, with every step on the record.
Where you start
You don't deploy all of Lattice at once. The minimal useful version is one role, one bounded job, with just enough of each pillar to be safe:
- Ground: a context pack for that one role, including whatever dark context you can capture today. Not an ontology of the whole company.
- Govern: a short policy that gates its two or three risky actions. Not every action it could take.
- Graduate: one scorecard and one named owner, starting the agent at Level 1 (Recommend) or Level 2 (Draft).
Pick a job that is high-volume and observable (ticket triage, not refunds), run the agent where a human still approves, and let it earn its way up on evidence. No platform migration, no full ontology, no autonomy on day one. The first version is a single onboarded worker; the platform is what you get once you've onboarded a hundred.
A starter prompt you can run today
You can stand up the Level 1 version in a single prompt. Paste this into Claude, then paste a ticket and its context:
You are a support triage agent running at Level 1: you recommend, you do not act.
Context you get with each ticket:
- Account: name, tier (standard or strategic), health
- Contract: plan, SLA (e.g. Sev-1 = 1 hour), time remaining
- Ticket: text and current state (new / in progress / escalated)
For each ticket, return:
1. Classification: category and severity, with one line of reasoning.
2. Draft reply: what you would send the customer. Do not send it.
3. Proposed action: e.g. "issue a $200 credit", "route to billing", "no action".
4. Gate check: flag anything that needs a human first, using these rules:
- Any credit or refund over $500 -> needs approval.
- Any money or status change on a STRATEGIC account -> needs approval.
- A Sev-1 on a strategic account -> escalate to on-call now.
- Missing tier or SLA -> ask for it, do not guess.
5. Owner: name the person or team who signs off.
Rules:
- Never invent account details. If context is missing, say so.
- You only recommend. A human approves every external action.
- Keep reasoning to a line or two, not an essay.
Reply "Ready. Paste a ticket and its context." and wait.That is Level 1: useful immediately, and safe because it only recommends. Notice what the prompt is doing by hand: supplying context, gating risky actions, naming an owner. That is the structure a real onboarding layer provides and enforces, once one agent works and you want a hundred.
This prompt advises; it does not enforce. It can flag that a credit needs approval, but nothing stops the model from acting anyway, and a tricked or careless run can ignore every rule. There is no logged trail, no enforced owner, and no real check on what comes in or goes out.
It is safe only because it drafts and never acts. The moment the agent can actually send the reply, issue the credit, or change the account, flags stop being enough: the gates have to be enforced outside the prompt, and every action recorded against an owner. That is the line between a prompt and an onboarding layer.
Three shifts make this harder fast, and the same framework is what absorbs them.
Fleets: the ratio flips
The number of agents per company will climb fast, and the human-to-agent ratio will flip: soon a few people oversee a fleet, not the other way around. You cannot review every action of fifty agents, so supervision shifts from reviewing everything to reviewing the exceptions. Graduation is what makes that safe, because an agent only skips the human on the actions it has earned. Onboard a role once and instantiate many, watch the fleet at the portfolio level where small per-agent error rates add up, and retire agents the way you offboard people.
Authoring spreads beyond IT
Anyone with a prompt or a low-code tool can build an agent now, and soon agents will build agents, well outside IT. The old control point, gatekeeping who may build and deploy, stops working. So the gate moves to the action, not the creation: anyone can author an agent, but nothing it does touches the business until it is onboarded and bound to a role, a policy, and an accountable human. Accountability has to terminate in a person. An agent can create another agent, but it cannot create accountability.
Agents working with agents
Workflows will span many agents, kicked off by different people, some spawned by other agents. Reliability needs contracts: a typed request, what is authorized, and a way to undo a step when a later one fails, which is what a per-action contract layer like Concord provides, carried across agents. Ownership needs assigning: when a refund is the product of five agents' subtasks, the workflow needs one named owner and one trail tying every sub-action, agent, and human together. Delegation stays scoped, never the full authority of the caller.
One-slide summary
Digital labor needs onboarding.
Onboarding is three jobs: Ground (context and ontology: what matters, what things mean), Govern (the control plane: what agents can do), and Graduate (evaluation, graduation, accountability: how they're doing, when they're ready for more, who owns the outcome).
Lattice is the enterprise control plane for digital labor: the operating layer that provides all three.
| Job | Layer | What it provides |
|---|---|---|
| Ground | Context | What matters |
| Ontology | What things mean | |
| Govern | Permissions · Tools · Policy (the control plane) | What agents can do |
| Graduate | Scorecard | How well they're doing |
| Graduation | When they're ready for more | |
| Accountability | Who owns the outcome |
Agents will keep getting more capable. That makes onboarding more important, not less. The hard question is no longer what an agent can do. It is what it is allowed to do, for whom, up to what limit, and who answers when it gets it wrong.
That is what Lattice decides, and what it keeps deciding as the agent earns or loses trust.