June 14, 2026Opinion
The Three Graphs Behind an Agent-First Enterprise
An agent that reaches the edge of what it knows does not stop. It returns a confident, well-formatted, wrong answer, and nobody notices for weeks. The fix is architectural: a semantic graph that binds the shape of your business to the system, table and column already recording it, a process graph that holds the real routing and escalation, and an activity graph that accrues from operations. You author two of them. The third fills itself in. Your data never moves. Here is what each one buys you, the order to build them in, and what you get for free.
The agent settled fourteen hundred claims in a quarter. Forty of them sat above the authority limit of the team it was acting for, and nobody found out until the quarterly file review, because a settlement outside the limit came back in the same format, the same register and the same eleven seconds as one inside it.
Nothing had told the system where its competence ended. There was no threshold it could read, no route it could take on hitting one, and no attributable record that would have made the pattern visible in week two rather than week twelve. No amount of prompt engineering closes that.
Hallucination at the edge of competence is a design failure, not a model failure.
Three graphs close it. The semantic graph holds what your business treats as a thing, which of those may connect to which and under what conditions, and the threshold at which a case stops being routine — each one bound to the system, table and column that already records it. The process graph holds the ordered steps, the conditions that select the next step, and who a case escalates to, in what order. The activity graph holds what happened: events, decisions and corrections, each attributable to an actor. You author the first two with the people who hold the knowledge. The third accrues from operations. Your data does not move.
§ 02
Exhibit 1 — the three graphs at a glance
| Graph | What it holds | Provenance | What it unlocks |
|---|---|---|---|
| Semantic | Types, permitted connections and their conditions, the thresholds at which a case stops being routine — and the system, table and column recording each one | Authored, then bound | Reasoning about consequence before acting, and reading a real value from a system of record instead of approximating a number out of prose |
| Process | Ordered steps; the conditions selecting the next step; escalation — to whom, in what order, with what standing to decide | Authored | Following the actual procedure, and handing off at the point the procedure says a human decides |
| Activity | The temporal record of events, decisions and corrections, each attributable to an actor | Accrues from operations | Applying precedent, and revising the map from what turned out to be wrong |
You author the first two once. The third fills itself in.
Read the provenance column first. Two graphs are written down with your people and the process documents that define them. One is not written at all; it is emitted by the systems doing the work, provided somebody turned the recorder on before the first agent acted.
That binary also fixes the boundary on tooling. We use language models heavily here — drafting candidate types from process documents, proposing bindings, surfacing the places two documents contradict each other. What no tool supplies is the knowledge, because the knowledge is not in the documents. It is in the four people who know why the exception path exists. Tooling makes the transcription faster; it does not make the transcription unnecessary. A vendor promising to generate the map from your document estate is selling an index of what your company wrote down, which is a different artefact and will not hold a decision.
§ 03
The semantic graph
Ask a retrieval system whether a deal can carry a particular risk and it has nothing to answer with. "Can carry" is a rule about the shape of the business and appears nowhere in the text being searched. You get the three most similar paragraphs and an invitation to infer.
The semantic graph states the shape, then does the thing that makes it operational: it binds every type to the system, table and column already recording it. Not customer means the following. Rather: customer is a type; the authoritative identifier is crm.accounts.id; billing's view of the same type is billing.customer.ref; exposure is measured by risk.exposure.value; and exposure stops being routine at 40 per cent of the facility cap.
Ontology plus relational mappings as one artefact is not our invention. It is Ontology-Based Data Access, and the W3C standardised the mapping half as R2RML, a syntax whose entire purpose is to say this table populates this class, this column populates this property. The tradition predates the agent boom by a decade. We are applying it, not proposing it.
Your data stays where it is. The agent is told which table and column to read.
No migration. No new system of record. No eighteen-month consolidation of three CRMs before anything ships. That converts the proposal from a platform decision into a modelling exercise, and a modelling exercise can be scoped to one workflow and cancelled cheaply if it disappoints. It removes more objections than every reliability argument combined.
Binding is also where the same-customer-three-ways problem gets solved, and the hard end of it is worth buying: Senzing for real-time resolution as a developer SDK, Quantexa where the identity graph faces financial crime, Reltio and Informatica at the master-data tier, Tamr for machine-learned matching. Buy the resolver. You cannot buy the statement that ties it to your threshold — that the entity it resolved is the same type your escalation limit is written against.
For the graph itself the field is mature: Stardog for native OWL reasoning, Ontotext GraphDB, Neo4j, TigerGraph, RelationalAI. Palantir Foundry's Ontology is the most operational binding of typed objects, links and governed actions into a single surface, at a cost we return to at the end. Metric-definition tooling — dbt, AtScale, Cube — solves a narrower problem: it makes "active user" mean one thing across dashboards. It governs calculations, not relationships. It will not tell an agent whether a commitment requires an owner.
The honest limit is scheduling, not technology. Four hours of a senior underwriter's attention is harder to obtain than a database credential, and it is the actual critical path. Plan the engagement around diary access, not infrastructure.
Now the type exists, the threshold has a number, and the agent can read the real value. It still does not know what to do next.
§ 04
The process graph
Verify limits. If exposure exceeds the cap, route to the approval gate. If the gate declines twice, escalate to the credit committee. That is the process graph: ordered steps, the conditions selecting the next one, and the escalation path — to whom, in what order, with what standing to decide. Written that way it is executable guidance rather than a diagram, and an agent follows it instead of improvising something plausible.
Two claims here are contested and both are worth defending.
Escalation belongs in this graph, not in a guardrail layer. The market's instinct is a control plane that sits above the workflow and vetoes it. That is backwards for a mechanical reason: a veto carries no destination. An agent blocked without a route does the worst available thing, which is to produce its best guess and present it with confidence. An agent that reaches a modelled escalation path hands the case to a named role with the case state attached. That line also separates this work from the AI-governance tier: Credo AI, Holistic AI, OneTrust and IBM watsonx.governance govern your AI systems and produce evidence on demand, but none of them hands an agent a rule to check before it acts, or a destination for the case when it stops.
A veto tells an agent to stop. Only a route tells it what happens instead.
A process graph is not a workflow engine and does not replace one. Camunda and Temporal execute processes very well; keep them. The process graph is the description an agent reasons over, including the parts of the procedure no engine executes because a human has always done them. Most of the interesting escalation logic in an enterprise has never been encoded anywhere, which is exactly why it must be elicited rather than imported.
It comes from the process documents read alongside the people who know where those documents are wrong. Both inputs are required and they contradict each other constantly. The contradictions are the most valuable material in the engagement: a documented step everyone routes around is a step the agent must not follow. Celonis and its peers are a genuine check on what you were told, since event logs show the paths actually taken — but mining is corroboration, not source. It shows what happened. It never shows what was supposed to happen, or why an exception was allowed.
The honest limit: process knowledge decays faster than semantic knowledge. Types are stable for years; routing changes with a reorganisation. Treat a process graph nobody has touched in two quarters as suspect.
Both of these you write down. Neither tells you whether any of it worked.
§ 05
The activity graph
When humans ran the floor every action had an obvious author, and work in flight was visible because people watched their own queues. Agents share service accounts, and a shared service account dissolves the link between an action and its actor at machine speed. Stalled work goes invisible. So does the pattern in the forty settlements.
The activity graph is the temporal record: events, decisions and corrections, each attributable. It is the only one of the three you do not author. It accrues.
Its defining design choice is that decisions and corrections are the same substance as events, recorded in time. A decision is an event with an author, an input state and a rationale. A correction is an event that supersedes an earlier one. Give events those fields and precedent becomes a query over the record rather than a second store to populate and reconcile against the first. Two stores of the same facts diverge. That is not a risk, it is a certainty.
That also settles the governance question. If decisions live in the record, the write path is the control point: agents emit events, agents do not edit history, and a correction is a new event pointing at the one it supersedes rather than an overwrite. A memory product that lets an agent revise its own history cannot offer that.
The tooling here is the most mature in the stack and built for the wrong purpose. LangSmith has the deepest integration for LangChain and LangGraph; Langfuse leads the open-source, self-hostable path; Arize Phoenix is OpenTelemetry-native through OpenInference; Datadog folds agent traces into existing enterprise observability; the OpenTelemetry GenAI semantic conventions are the emerging standard and still maturing. All of it is engineering observability. It answers what did the agent do and why did step three break very well. It does not answer which actor and which credential, human or machine, took this action, under which version of which policy in a form that survives an audit two years later. Capture is solved. Governed attribution across human and non-human actors is not, and that gap is where we would spend engineering effort rather than licence fees.
The limit no vendor escapes: you cannot capture intent. Intent is internal and unobservable. You capture the how — the policy applied, the evidence consulted, the exception granted, the approver — and infer the why from patterns over time. Anything claiming to store intent is overselling.
Attribution is the only thing in this architecture you cannot add retrospectively.
§ 06
Exhibit 2 — what falls out
Two of the most-requested capabilities in enterprise AI are not builds. They are edges between graphs you already have.
| Derived property | The edge | What it gives you | What it replaces |
|---|---|---|---|
| Gap | Escalation threshold in the semantic graph → escalation path in the process graph | The system knows where its authority ends and hands off with the case attached instead of guessing | A separate authority or guardrail layer, and the confident wrong answer |
| Correction | Correction in the activity graph → revision of the semantic graph | The map learns from being wrong, on evidence the record already holds | Quarterly model-review theatre, and the assumption that an ontology is correct the day it is signed off |
Gap answers the question every executive asks in the first ten minutes: how do I stop it doing something stupid? The mechanism is unglamorous. The semantic graph records that exposure above the facility cap is not routine. The process graph records that non-routine exposure routes to the credit committee. The agent reaching a case above the cap does not assess its own confidence. It has arrived at a modelled boundary, and the boundary has a destination.
Correction is slower and worth more. Every override is evidence about the map, and the activity graph recorded all of them with the names attached.
A threshold producing three overrides a month is not under-enforced. It is set wrong.
Neither property needs a product. Both need those two edges to be explicit, typed and traversable, which is a modelling decision you make on day one or retrofit expensively.
§ 07
Sequencing: one workflow, never the company
Start with one workflow. Not one department, not one domain, and emphatically not the enterprise. One workflow with a real decision in it, a named owner and a measurable outcome: credit exceptions, claims triage above a threshold, renewals with non-standard terms. Something where you can name the four people who know how it really works and get them into a room.
The reason is not caution. Ask an underwriter to describe the company's risk ontology and you get a taxonomy that sounds plausible and settles nothing. Put a specific declined case in front of the same person and ask why it was declined, and out comes the actual shape: the threshold, the exception, the person who can overrule it, and the condition under which the overrule is legitimate.
Elicitation only works at the size of a real decision.
Scope wider than that and you are collecting opinions about vocabulary. The failure mode at the far end is consistent and well documented — enterprise-wide ontology programmes fail on complexity and maintenance overhead, they fail after the budget is committed, and they fail without producing a single working agent, which makes the second attempt much harder to fund.
Exhibit 3 — the build order for one workflow
| Step | What you do | Who is in the room | Done when |
|---|---|---|---|
| 1 | Instrument attribution. Unique identity per agent and per human actor; every action emitted as an attributable event | Platform engineering | Nothing can act without leaving an attributable record |
| 2 | Author the semantic graph for this workflow only — types, permitted connections, thresholds — then bind each to system, table and column | The people who hold the shape; a data owner per bound system | An agent retrieves a real value for every bound property, and every threshold has a number |
| 3 | Author the process graph for the same workflow: steps, conditions, escalation paths and their destinations | The people who run the workflow; the process documents; mining evidence where you have it | Every branch ends in a step or a named human role. No dead ends |
| 4 | Ship the agent narrow, inside the modelled boundary, with escalation live from the first case | Delivery, workflow owner | Routine cases are handled and handoffs at the threshold are clean |
| 5 | Let the activity graph accrue, and read it | Workflow owner | Overrides reviewed monthly against thresholds, and at least one threshold revised |
| 6 | Take the second workflow. Reuse every type that recurs | As above, new workflow | The second workflow costs materially less than the first |
Step 6 is where the economics arrive. The first workflow pays for its own semantic graph. The second inherits most of the types it needs and the third inherits nearly all of them, so cost falls per workflow while coverage rises — the opposite of the usual trajectory, where every new system deepens the inconsistency. That compounding is the entire commercial case, and it is available only to people who resisted modelling everything up front.
§ 08
Sector read: where the value lands first
Exhibit 4 — where the three graphs pay back first
| Sector | The workflow to start with | Which graph carries the weight | Why here |
|---|---|---|---|
| Banking | Credit exceptions above a limit | Semantic — thresholds and bindings | The thresholds already exist and are already written down. No system holds them in a form an agent can check before acting |
| Insurance | Claims triage with a non-standard element | Semantic — bindings across claimant, policy and incident | The same claimant resolved across three systems is the binding problem in its purest form, and the resolvers are mature and buyable |
| Managed and professional services | Client work executed under delegated authority | Process — escalation paths | Authority is per-client and multi-hop. Modelled escalation is the only thing between a delegated agent and an action nobody authorised |
| Retail and consumer | Pricing and service exceptions at volume | Activity — attribution at scale | Thousands of low-value decisions a day. The record is worth more than any single decision, and it is the cheapest thing to start and the most expensive to retrofit |
| Public sector and regulated services | Eligibility and entitlement determinations | Semantic — the applicable law as constraints | The rules are published, stable and already contested in the open. Expressing the applicable subset as constraints is tractable in weeks |
The workflows that pay back first are the ones where a threshold already exists and a person is currently the only place it is stored.
§ 09
The leadership action list
Next 30 days.
- Pick one workflow. Real decision, named owner, measurable outcome. Write down the four people who know how it actually works and confirm you can get their time. If you cannot, you have chosen the wrong workflow or you lack executive sponsorship — better to find out now than in month four.
- Instrument attribution before anything ships. Unique identity per agent, every action emitted as an attributable event. It is the one element that cannot be added later, and it is unglamorous enough to be skipped under delivery pressure.
- Audit vendor claims against the provenance column. Ask where the escalation thresholds come from. The answer is people, and a vendor unwilling to say so has not done this work.
Next 90 days.
- Author and bind both authored graphs for that one workflow. Every property points at a system, table and column. Every branch ends at a step or a named human role. An unbound property is a guess; an unterminated branch is where the confident wrong answer comes from.
- Ship narrow, with escalation live from the first case. Success is not the proportion of cases handled. It is that handoffs at the boundary are clean and the case state travels with them.
- Adopt an industry vocabulary where one exists — FIBO, SNOMED CT, your regulator's own definitions — as the starting point for types, not as the deliverable. It saves weeks. It decides nothing.
Next 12 months.
- Read the corrections monthly and revise the map. Revising a threshold is the system working. If nothing has been revised after two quarters, your activity graph is not being read.
- Take the second and third workflows, and measure the marginal cost of each. If the second does not cost materially less than the first, your types were scoped too narrowly to recur and the compounding will not arrive.
- Decide the platform question deliberately. By month twelve you will know how much of your shape is genuinely idiosyncratic. That is the moment to weigh a single-platform bundle against an assembled stack — on evidence, not on a slide at the start.
The four wrong moves
- Modelling the enterprise before modelling a workflow. The most reliable way to spend two years and ship nothing.
- Treating the map as a place to put data. The moment the semantic graph becomes a store rather than a map of stores you have signed up for a migration, and no-migration was why the programme was affordable.
- Deploying before attribution exists. The record you did not keep cannot be reconstructed.
- Buying a guardrail product instead of modelling escalation. An agent stopped without a route produces its best guess.
Deploy agents exactly as far as your modelled boundaries reach.
§ 010
Why three, and not the six we published before
Why three, and not the six we published before. An earlier version of this framework named six graphs and sorted them by ownership — shareable infrastructure, shared standards with private content, irreducibly proprietary assets. That axis came from the vendor landscape and it holds up as a description of what you can buy. It does not survive a delivery engagement, where nobody asks which tier a graph belongs to; they ask what we are writing down, in what order, and when it stops. Four of the six turned out to be contents rather than containers. Regulatory and authority are constraints and thresholds in the semantic graph, enforced as escalation paths in the process graph; governed entity is the semantic graph's bindings; context — decision precedent — is the activity graph, once decisions are events with an author. Nothing was discarded and the inventory was accurate. What changed is the unit of work, and ownership is now a sourcing decision inside one graph rather than an axis the architecture is organised around.
§ 011
The opposing view, honestly stated
The bundle. A single platform holding meaning, entities, actions and audit in one governed surface beats an assembled stack of graphs, resolvers and observability tools joined together by your own engineers. Palantir Foundry is the clearest expression of this and where it lands it lands very well: the ontology, the bound data, the actions an agent may take and the record of what it did are one system, with one permission model and one place to look when something goes wrong. Three graphs, in that world, are three things you keep consistent yourself — and consistency across systems is what enterprises are worst at.
For an organisation with the budget for a forward-deployed engagement, a genuine need for one governed surface across many domains at once, and no appetite for owning integration, buying the bundle is the rational move, and this piece is a description of what they would be paying someone else to do. The case against is platform dependency, total cost, and the fact that the artefact you most need to own ends up expressed in a vendor's model. One further point from the field: the bundle's strength is that everything sits in one place, which is precisely what makes starting small structurally awkward — and starting small is the only way the elicitation works.
You can buy one governed surface. What you cannot buy is the shape of your own business.
Three is a judgement call, and that objection is fair. Merge process into semantic and you have a shape that includes how work moves, which is defensible; we do not, because process knowledge decays far faster than type knowledge and merging them hides which half went stale. Split the bindings out and you have four; we do not, because OBDA has treated ontology and mappings as one artefact for a decade, and separating them invites exactly the drift where the map says one thing and the mapping says another. Both alternatives are arguable. Neither changes what you do on Monday.