AI has taken extraordinary leaps over the past couple of years. Newer LLMs and AI agents are now capable of generating complex codebases, end-to-end applications, comprehensive documentation, images, and video — increasingly getting large chunks of work done on behalf of humans. Frontier reasoning models have pushed this further by automating chain-of-thought over logical, mathematical, and multi-step tasks. Yet, at the end of the day, the truth remains: an AI is only as good as the context it is given.

For enterprises, that context lives inside operational systems — relational databases, NoSQL stores, object stores, and SaaS applications — accumulated over years of running the business. Today, teams try to bridge this gap by hand: authoring elaborate prompt files, curating skill markdowns, and stitching together RAG pipelines. The result is tedious, duplicated, and unmanaged. Every team ends up rebuilding a partial, drifting copy of the same organizational knowledge, and every new agent or hire starts from scratch. What enterprises need is a shared, structured representation of context — one that all users and agents can read from and contribute to.

At Tursio, we call this representation the context graph: a schema-level metadata structure that captures the semantics, the relationships, and the domain annotations over an organization's underlying data, and serves as the translation layer between operational systems and the humans or agents reasoning on top of them. The following sections describe the four operations that make a context graph work in practice: Initialize, Specialize, Localize, and Improvise.

Initialize — Build the Initial Map

The first task is to connect to all of the enterprise data sources and infer a complete picture of what exists and how the pieces relate. Tables, columns, relationships, semantics, document collections, object stores, and application APIs all carry latent structure that, taken together, describes a business's operating shape. The goal at this stage is not to reproduce the physical schema but to elevate it: low-level entities are lifted to agent-understandable descriptions grounded in data semantics, so that what the database calls cust_acct_xref becomes "the relationship between a member and their accounts."

Tursio approaches the context graph with an automated approach. It infers join paths via inclusion-dependency discovery, classifies columns by type and role, and flags ambiguous or overloaded fields for resolution. The output is a shared, consistent structure that spans heterogeneous sources — SQL, NoSQL, object, and application data — and that any user or agent can read against. Crucially, this initialization process is fully automated and requires no manual effort—a step that is often painful for organizations with large and legacy schemas that are poorly documented.

The key design principle here is unambiguity. A context graph that hedges — that lets the same concept appear under three names with no canonical form — pushes the disambiguation burden onto every downstream prompt. By doing the work once at the structural level, we make the rest of the pipeline usable and more accurate.

Specialize — Ground It in the Business

A generic map of the data is necessary but not sufficient. The same column named amount means premium written at an insurance carrier, loan principal at a credit union, and billed charges at a hospital. Within each of those, the business rules for when to use it differ further. Specialization grounds the context graph in the specific organizational way of doing things: the kind of business it is, the meaning of its core entities (claims, policies, loans, members, encounters), how concepts are referred to internally (LTV, ARR, net revenue, charge-off), and the rules that govern their use (which date field drives renewals, which hierarchies are implicit in the org chart, when an amount is gross versus net).

These nuances are extracted from sources the organization already has public information about the company, internal knowledge documents and wikis, existing semantic models and BI definitions, prior query histories, and feedback from expert users. Tursio refines the context graph through ambiguity detection, annotation rules, query-history learning, and expert-user feedback — folding each of these signals back into the same shared structure rather than scattering them across as one-off prompts. The same context graph structure that serves a credit union's loan-portfolio analyst can be re-specialized to serve an insurance underwriter or a hospital revenue-cycle team, because the structure is general and the specialization is layered.

The discipline here is that every specialization lives in the context graph, not in a sidecar prompt. A definition of "active member" that exists only in an analyst's head or in their saved query is institutional knowledge waiting to be lost; the same definition encoded as an annotation on the context graph is available to every agent and every user from the moment it is written.

Localize — Retrieve What the Agent Needs

Once the context graph is initialized and specialized, the next problem is getting the right slice of it to an agent at the right moment. Dumping the entire graph into a prompt is wasteful and harmful: it inflates tokens, dilutes attention, and increases the chance that the model latches onto an irrelevant relationship. Localization is the inverse — interpreting the agent's intent, narrowing the graph to the relevant neighborhood, and returning a focused subgraph plus the supporting data the agent needs to reason.

Tursio's query planning pipeline implements this end-to-end: LLM-assisted compilation turns natural language into a candidate plan. This plan is grounded against the context graph, so every reference resolves to a valid entity, and rewriting produces an executable, accurate query. This is the same mechanism that powers various querying modes in the Tursio product — each being a different localization strategy over the same underlying graph, ranging from tightly guided semantic-model walks to open-ended exploratory retrieval.

Agents can invoke localization repeatedly within a workflow. Each call can be independent — "give me the zip codes with the highest member longevity" — or chained, e.g., followed by "which of these zip codes have the most expansion opportunities", where the result of one retrieval shapes the intent of the next retrieval from a different portion of the context graph. This is the pattern that protocols like the MCP standardize at the transport layer; the context graph is what makes the responses to those calls trustworthy rather than merely well-formed. Without grounding, an MCP server is a faster way to be wrong; with a context graph behind it, every retrieval is anchored to a structure the organization has already vetted.

Improvise — Let the Context Tune Itself

An organization is not static, and neither is its data. New products launch, definitions shift, regulatory regimes change, and the questions people ask of the business evolve. A context graph that cannot adapt becomes a liability faster than a static prompt would, because more workflows depend on it. The fourth operation, Improvise, is the mechanism by which the graph tunes itself in flight.

Three signals drive this tuning in Tursio. The first is implicit agent interaction: which paths through the graph are taken often, which retrievals fail to ground, and which queries get rewritten before they succeed. The second is explicit user feedback: an analyst confirming that "yes, renewal_dt is the right date for cohort analysis" or correcting a wrong join. The third is agentic tuning processes running on top of the graph itself — either autonomously on a schedule or triggered by an administrator — that propose annotations, retire stale ones, and reconcile conflicts. The system records every interaction, and once an improvement is accepted, it's visible immediately to every user and every agent, without anyone having to re-author a prompt or update a skill file.

Constant improvisation is what makes a context graph behave like an organizational brain rather than a snapshot. A new employee joining on a Monday inherits everything the organization has learned about its own data through the prior week. A new agent deployed against the platform is immediately as capable as the most experienced one — not because it has read every wiki page, but because the relevant knowledge has already been encoded in the structure it queries.

Why Context Structure Matters?

Treating context as a first-class data structure rather than an accumulation of prompts and skill files pays back across the AI stack:

• No ad hoc prompts or skills are required for making agents behave as expected — the structure carries all the instructions.
• Duplicated and siloed context work across teams is eliminated because every team writes into and reads from the same graph.
• AI workflows become consistent and accurate across the organization, because they share a grounding rather than each inventing their own.
• The organization develops a systematic brain every day, accumulating knowledge instead of resetting it.
• General-purpose LLMs become specifically useful — customized not by fine-tuning, but by the context they are given.

For regulated industries — credit unions, insurance carriers, healthcare providers — the value compounds further: an on-premises context graph keeps sensitive schema metadata and prompts within the customer's environment, which is sometimes a hard requirement for those organizations. The context graph is what makes structured data search work at all in those settings; it is also what makes it work the same way on Tuesday as it did previously on Monday.