Retrieval Is Not Enough Context
Most enterprise AI projects start with retrieval. Put documents in a vector index, retrieve the most relevant chunks, and pass them to a language model. That pattern can be useful for question answering, but it is not enough for operational agentic work.
The problem is not only that retrieved text may be incomplete. The deeper problem is that retrieved text does not define the operating context.
An agent that helps with supplier disruption, customer onboarding, regulatory evidence, product classification, or legal-entity maintenance needs more than paragraphs. It needs to know which business situation it is operating in, who it is acting 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 usually scattered across places that machines cannot reliably use: slide decks, governance documents, process diagrams, Jira tickets, wiki pages, architecture models, prompt templates, and the memory of domain experts.
A knowledge graph can improve retrieval by making relationships explicit. But agentic work needs one step more: the use case itself should become the context container.
This is product and architecture direction for WWKG. It should not be read as a claim that WWKG already ships a production agent runtime. The claim is more specific: WWKG is building the semantic data logistics substrate that can make agent context explicit, governed, testable, and versioned.
A Use Case Is A Context Boundary
A use case is often treated as a project label. In the Use Case Tree model, it is much stronger than that. A use case is a semantic package: a scoped business capability with its own concepts, personas, stories, outcomes, dependencies, and lifecycle.
That makes it a natural boundary for agent context.
Instead of asking an agent to operate against “the enterprise knowledge graph”, the session should be bound to a specific use case or a small adjacent set of use cases. That boundary narrows the world without destroying meaning. It tells the system which part of the graph is relevant and which part is out of scope.
For example, “customer” means different things in onboarding, support, billing, risk, and marketing. Those views can be connected in the graph, but an agent should not flatten them into one universal customer concept every time it acts. A customer-support use case can reuse a shared customer lookup story while still carrying support-specific language, evidence, permissions, and outcomes.
This is the practical value of open-world semantic modelling. The graph can hold multiple partial views of the enterprise. The use case tells the system which view is relevant for the work at hand.
Personas Are Business Semantics
Personas are often misunderstood in AI discussions. They are not merely prompt style instructions such as “act like a senior analyst.” In the Use Case Tree model, a persona is a business-semantic object.
A persona describes a type of player in a use case: a person, system, role, stakeholder, or other party that matters in the business domain. It carries the language used by the business, the responsibilities expected in that context, and the viewpoint from which stories are written.
That distinction matters for agents.
If an agent session is bound to a persona, the persona is not decoration. It is part of the authorization and context model. The persona can determine which stories are visible, which vocabulary should be used, which outcomes matter, and which constraints apply.
In a legal-entity use case, an auditor persona, a data-owner persona, and a signator persona may all touch the same entity. They should not receive the same tools or evaluate the same situation in the same way. In a supply-chain disruption use case, procurement, compliance, logistics, and customer-success personas may all need different story surfaces around the same supplier delay.
The goal is not to make a model sound like those personas. The goal is to bind work to the same semantic roles the business already uses.
Stories Are Tool Boundaries
Stories describe the work a persona needs to perform in a use case. They start in familiar business language: who needs what, and why. But in a graph-native operating model, stories can become much more than requirements text.
A story can define a typed unit of work:
- the persona that performs it;
- the input concepts it requires;
- the output concepts it produces;
- the outcome it contributes to;
- the named graph or branch context it operates against;
- the validation and conformance scenarios that prove it behaves correctly.
That makes stories the right boundary for agent tools.
An agent should not be given a general-purpose graph mutation interface and told to be careful. It should receive a tool list derived from the stories available in the bound use case and persona. If a story is not part of that context, it is not a tool in that session.
This is the important structural move. The allowed action surface is not a prompt convention. It is derived from the graph model itself.
For a customer-onboarding use case, the tool surface might include stories such as “find customer by registration number”, “collect missing onboarding evidence”, “flag sanctions-screening exception”, or “request compliance review.” For a semantic-modelling use case, the tool surface is different: “define concept”, “attach shape”, “register story”, or “link outcome.” The transport can vary, but the boundary stays the same: everything is a story invocation in a use-case context.
Sessions Should Bind Workspace, Use Case, And Persona
The architecture direction for WWKG is to make agent sessions explicit. A session should be provisioned with a binding like:
(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.
That binding gives the gateway enough structure to answer basic questions before any tool is invoked:
- Which stories are visible?
- Which concepts define the input and output schemas?
- Which branch receives proposed changes?
- Which named graphs are in operational scope?
- Which provenance should be attached to calls?
- Which validation rules and story tests apply?
The session should also be bounded in time and traceable to the caller’s identity. A future MCP session should not be a local process under the agent’s control that merely promises to follow rules. It should be a server-side session whose tool list is provisioned from WWKG’s story metadata and whose calls go through the same governed execution path as other clients.
This is how context becomes infrastructure rather than prompt engineering.
Context Must Include Outcomes
Outcome modelling is easy to skip because it feels less technical than schemas, APIs, or tools. For agentic systems, that would be a mistake.
An agent needs to know not only what action is permitted, but why the action exists. A procurement story may produce a supplier substitution candidate. That is not the outcome. The outcome may be protecting committed delivery, reducing regulatory exposure, shortening review cycle time, or preserving margin while avoiding unsafe substitutions.
Outcomes are what keep stories from becoming isolated automations. They connect work to business value. They also give humans a way to evaluate whether the agent’s work helped in the intended way.
When outcomes are graph resources, they can be linked to use cases, stories, measurements, evidence, and conformance results. That gives both people and future agents a clearer explanation of why a tool exists and what success means in context.
Stories Need Red Green Checks
Context without tests is still fragile. A story should not be considered ready just because it has a name, description, and input schema. It needs declared scenarios that prove the story behaves correctly.
The story conformance direction in WWKG is model-driven testing for stories. Scenarios are graph resources attached to stories. A scenario can define Given data, When parameters, and Then expectations. Read stories compare actual output with expected rows. Update stories compare the resulting graph state with the expected graph state.
This is the same discipline software teams use with unit tests, applied to business-semantic work. A story is red while its scenarios fail. It is ready only when the declared scenarios are green.
For agents, this matters because a typed tool surface is not enough. The story should also carry evidence that it works for the business cases it claims to support. If an agent invokes a story on a staging branch, the resulting graph changes can be validated and the story’s conformance scenarios can provide a second layer of business-facing checks.
That is a more grounded model than asking a model to self-evaluate its own answer.
Why This Is Different From Generic RAG
Generic RAG retrieves fragments. A use-case-bound session provides an operating model.
The difference shows up in the questions the system can answer before the model generates anything:
- What business capability is this work part of?
- Which persona is acting?
- Which stories are available?
- Which inputs and outputs are valid?
- Which concepts define the vocabulary?
- Which outcomes matter?
- Which branch isolates proposed changes?
- Which tests decide whether the work is acceptable?
This does not eliminate the need for retrieval. Text, documents, policies, and examples still matter. But they should be retrieved into a structured context, not used as a substitute for one.
Knowledge graphs provide relationships. Use Case Trees provide intent and scope. WWKG provides the data logistics layer: branches, commits, validation, history, provenance, and review. The combination is what makes large-scale agentic work plausible in an enterprise setting.
The practical rule is simple: do not give agents “the graph.” Give them a workspace, a use case, a persona, and a set of tested stories on a staging branch.
This article is part of the WWKG article series on semantic data logistics, business intent, and knowledge graph infrastructure for future agentic enterprise systems.