Agents need your decision model, not just your data

Every enterprise agent is sold with the same sentence: it understands how your company works. The sentence hides a question. Understanding a company can mean having read its documents. It can mean knowing who works with whom on what. Or it can mean knowing what the company is allowed to do, who has to sign, and what happened last time. Those are three different kinds of knowledge, and an agent that is going to act rather than answer needs the third.

We call the third kind the decision model. It is the part of enterprise context that no document contains: what counts as an approval, who can grant one, what a threshold is, what the precedent says, what must never happen without a person, and where each piece of work stands right now. It is the difference between an agent that can draft a journal entry and one that can be trusted to route it.

This piece lays out the three layers, how each one is built from the one beneath it, and why the top layer is the one an institution has to own.

Layer one: documents

The first thing any enterprise AI does is read. Files, tickets, wiki pages, messages, records, indexed and retrieved when a request looks related. This is what most enterprise chat deployments still are: a model with a search index in front of it.

It answers one question well: what do we know about X. It cannot answer any of the questions that matter for action. It does not know who X belongs to, what state X is in, what may be done to X, or who decides. Retrieval returns passages, and a passage about a refund policy is not the authority to issue one. Agents built on this layer are helpful and inert: they can tell you the policy, and a person still has to do everything.

The layer is necessary, and it has a ceiling. Every improvement to retrieval makes the answers better and does nothing for the actions.

Layer two: the graph

The second layer connects the documents to the world they describe. People, teams, projects, customers, products, and systems become entities. The relationships between them, and the activity that ties them together, become the structure the agent reasons over. Which project this document belongs to. Who owns this account. Which ticket this thread was about. What changed on this system last week and who changed it.

This is what Fig's Enterprise Graph is: the relationship layer behind enterprise intelligence, built from the connected systems with their permissions intact, so that the agent understands how the company works and not only what it knows. A graph answers "who owns X, what is X connected to, what is happening around X," and it lets an agent follow multi-step connections across company work instead of matching keywords.

It is a large improvement, and it is still a description. A graph can tell an agent that the operations director owns carrier claims. It cannot tell the agent that claims above a threshold need that director's approval, that the last rejection was for a missing photo timestamp, or that submitting a claim is irreversible and leaves the company. Those facts are not relationships between entities. They are rules about action.

Layer three: the decision model

The third layer models the verbs. Strip away the vocabulary and a decision model has five parts, and every one of them already exists in your company, scattered across systems, policies, and people's heads.

Actions. The things the business does, with their preconditions and side effects. Post an entry. Issue a refund. Change a customer's tier. Send a document outside the company. Each has inputs, a system it lands in, and consequences that may not be reversible. An agent that does not know an action is irreversible treats it like a draft.

Owners and thresholds. Who may take each action, up to what amount, in which entities, and who approves above that. This is the segregation-of-duties matrix a controller keeps, the discount authority a sales leader sets, the change board an IT team runs. It is the most legible part of the model and the part most often flattened into "the admin approved the integration."

Precedent. What was decided before and what happened. The prior period's accruals. The last three times this exception was granted, and why. The correction a reviewer made to the last draft. Precedent is what turns a policy into judgment, and the work itself creates more of it every day.

The boundary. What must never happen without a person, and what must never happen at all. Outbound messages to customers. Payments above a floor. Deletion. Access to a class of record. The boundary has to live outside the model, because a model can be talked into anything by content it reads, and that failure sits at the top of the OWASP Top 10 for Agentic Applications.

State. Where each piece of work is right now: open, staged, approved, posted, disputed. Without state an agent re-proposes what is already done and misses what is stuck.

Documents carry none of the five. A graph carries the owner. The decision model carries all five, and that is what an agent needs in front of it before it does anything that matters.

How each layer is built from the last

The three layers are not three products. Each one is built out of the one beneath it, and the path from documents to decisions is the path an agent program actually takes.

From documents to graph. Connect the systems, not only the files. A connector that reaches the CRM, the ticketing system, the ledger, and the document store brings the entities with the documents: the account behind the contract, the ticket behind the thread, the owner behind the record. The graph assembles itself from the structure those systems already have, with the source permissions carried along, so the agent never sees more than the person operating it could.

From graph to decision model. Three sources, and the balance between them is the real design choice.

From the systems: most of the decision model is already encoded in the tools a company runs. The approval chain lives in the ERP's workflow. Discount thresholds live in the CRM. Change windows live in the ticketing system. Connectors that carry actions as well as data surface most of the model without anyone declaring it, which is why connectors with actions matter more than connectors that only read.

From observation: every completed workflow leaves a trace. Who proposed, who approved, what was changed, what was rejected. A platform that records its own actions and the human corrections to them is building precedent as a byproduct of work. Command Center holds that record on Fig. The discipline is that precedent is evidence to curate, not training data to trust automatically.

By declaration: some decisions are policy and should be written down. The charter for a workflow, the playbook for a review, the house style for a document. Plugins package that layer as installable expertise, with the connectors and skills a workflow needs, so the declared part of the model is versioned and governed rather than living in a prompt.

The boundary sits outside all three. Whatever the model proposes, approval gates decide whether it may execute, bound to the exact operation, with the approver seeing the records affected and the expected side effects. The gate is not part of the context; it is what the context is checked against.

Two failure modes bracket the right answer. Model the whole enterprise up front, before the first agent runs, and the program spends a quarter on ontology and ships nothing. Skip the model and let the agent read everything, and you get an agent that is allowed to do nothing, or worse, allowed to do everything. Assembling the decision model one workflow at a time, from systems first, is how you avoid both.

Why this is the layer you have to own

Documents export. A graph can be rebuilt from the same source systems. The decision model cannot be reconstructed from anywhere else, because most of it is created through use: the thresholds you tuned, the precedents the work produced, the corrections reviewers made, the boundary you drew after the first near miss. It is the most valuable context asset a company builds and the least portable, and it is what makes an agent yours rather than generic.

That makes it the sharpest test of the sovereign AI argument in our operating playbook. Retaining value means keeping this model in a form that outlives the platform that first captured it. The proof is not an export button. The proof is moving one workflow to a second environment, restoring its actions, owners, thresholds, precedent, and boundary, running the same cases, and measuring what was lost. A decision model that cannot make that trip is a dependency, not an asset. Fig keeps all three layers exportable for exactly this reason.

What to do this quarter

You do not need a platform decision to start. You need one workflow.

1. Pick a workflow where an agent would act, not only answer: reconciliation, ticket triage with resolution, contract redlines, access requests.
2. Write its decision model on one page: the actions, the owners and thresholds, the boundary, and where the state lives. If the page takes more than an afternoon, the workflow is too big.
3. Check which of the five parts your systems already encode and which live only in someone's head. The second list is your risk.
4. Run the agent with the boundary enforced in the system, not the prompt, and record every proposal and correction. In a month you have precedent.
5. Export it. If you cannot, you have learned the most important thing about your platform.

Key takeaways

• Enterprise context has three layers: documents, graph, and decision model. Only the third lets an agent act.
• A decision model has five parts: actions with side effects, owners and thresholds, precedent, the boundary, and state.
• Each layer is built from the last: connectors turn documents into a graph, and systems, observed work, and declared playbooks turn the graph into a decision model.
• The decision model is the least portable context asset. Owning it means being able to move it, which is the sovereign AI test.

An agent that knows what the company knows can answer. An agent that knows how the company decides can work.