Retrieval is not context
Most enterprise AI projects start with retrieval: index the documents, fetch the most relevant chunks, hand them to the model. That serves question answering. It does not serve operational work.
The problem is not only that retrieved text is incomplete. Retrieved text does not define the operating context.
An agent helping with supplier disruption, customer onboarding, regulatory evidence or product classification needs more than paragraphs. It needs to know which business situation it is in, who it acts as, which actions are allowed, which concepts matter, which outcomes define success and which checks decide whether a proposed change is acceptable.
That context is scattered across places machines cannot use reliably: slide decks, governance documents, process diagrams, tickets, wiki pages, prompt templates and the heads of domain experts.
A knowledge graph improves retrieval by making relationships explicit. Agent work needs one step more: the use case itself becomes the container for context.
A use case is a boundary
A use case is usually a project label. In a use case tree it is a semantic package: a scoped business capability with its own concepts, personas, stories, outcomes and lifecycle. That makes it a natural boundary for an agent.
Instead of turning an agent loose on "the enterprise knowledge graph", bind its session to one use case, or a small adjacent set. The boundary narrows the world without destroying meaning. It says which part of the graph is relevant and which is out of scope.
"Customer" means different things in onboarding, support, billing, risk and marketing. The graph connects those views, but an agent should not flatten them into one universal customer every time it acts. A support use case can reuse a shared customer lookup story while keeping its own language, evidence, permissions and outcomes.
That is the practical value of open-world modeling. The graph holds several partial views of the enterprise. The use case says which one applies.
Personas are business semantics
Personas are misread in AI discussions as style instructions: "act like a senior analyst." In a use case tree a persona is a business object. It describes a kind of player in a use case, a person, system, role or stakeholder, with the language the business uses, the responsibilities expected in that context and the viewpoint from which stories are written.
When a session is bound to a persona, the persona is not decoration. It is part of the authorization and context model. It decides which stories are visible, which vocabulary applies, which outcomes matter and which constraints hold.
The goal is not to make a model sound like these people. It is to bind work to the roles the business already uses.
Stories are tool boundaries
Stories describe the work a persona performs in a use case. They start as business language: who needs what, and why. In a graph-native model a story becomes a typed unit of work:
- exactly one persona that performs it;
- the concepts it takes as input and produces as output;
- the outcome it contributes to;
- the named graph or branch it operates on;
- the scenarios that prove it behaves.
That makes stories the right boundary for agent tools. An agent should not get a general graph mutation interface and a warning to be careful. It gets a tool list derived from the stories available to its use case and persona. A story outside that context is not a tool in that session.
This is the structural move. The allowed action surface is not a prompt convention; it derives from the graph.
For customer onboarding the tools might be "find customer by registration number" and "request compliance review." The transport varies; the boundary does not. Everything is a story invoked in a use case.
Bind the session
An agent session on Legra is provisioned with a binding: workspace, use case, persona. The workspace is the data environment. The use case is the business context. The persona is the declared viewpoint and role. Together they define the session's world, and each agent's job description names them, with the permitted stories and a budget.
That binding answers the basic questions before any tool runs:
- Which stories are visible?
- Which concepts define the inputs and outputs?
- Which branch receives proposed changes?
- Which named graphs are in scope?
- Which provenance is attached to every call?
- Which validation rules and story tests apply?
The session is bounded in time and traceable to the caller's identity. It is not a local process that promises to follow the rules. It is a server-side session whose tool list comes from the story metadata, and whose calls go through the same governed path as every other client.
That is how context becomes infrastructure rather than prompt engineering.
Context includes outcomes
Outcome modeling is easy to skip because it feels less technical than schemas and tools. For agents that would be a mistake.
An agent needs to know not only what action is permitted but why it exists. A procurement story produces a substitution candidate. That is not the outcome. The outcome is protecting committed delivery, reducing regulatory exposure or keeping margin without an unsafe substitution.
Outcomes keep stories from becoming isolated automations. They tie work to business value and give people a way to judge whether the agent helped.
Stories need red and green
Context without tests is fragile. A story is not ready because it has a name, a description and an input schema. It needs scenarios that prove it behaves.
Story conformance is model-driven testing. Scenarios are graph resources attached to a story: the given data, the parameters and the expected result. A read story is compared with expected rows. An update story is compared with the expected graph. A story is red while its scenarios fail and ready only when they are green.
That is the discipline software teams apply with unit tests, applied to business work. For agents it matters because a typed tool surface is not enough; the story should carry evidence that it works for the cases the business declared. When an agent invokes a story on its branch, the change is validated and the story's scenarios add a second, business-facing check. That is more grounded than asking a model to grade its own answer.
Why this is not generic RAG
Generic retrieval returns fragments. A use-case-bound session provides an operating model: the system knows who acts, which stories are available, which branch isolates the change and which tests decide acceptance before the model writes a word.
Retrieval still has a place. Text, documents, policies and examples matter. They are retrieved into a structured context, not used instead of one.
The rule is short: do not give an agent "the graph." Give it a workspace, a use case, a persona and a set of tested stories on its own branch.
Try it in Legra
For a runnable starting point, connect an AI client through MCP. Review the actual tools and permissions it receives; a default workspace selection is not an authorization boundary.