How Task-Specific MCP Helped vs. Just Connecting Every System Into LLMs
One LLM chat can’t know every system. Task-specific MCP servers scope data to each job, so answers are accurate and traceable.
Sep 24, 2026
Context layer series, part 2 of 3
Second of three posts on enterprise context for AI. The first argued that context turns into a swamp when it is collected indiscriminately, and that useful context is task-specific. This post is for readers who want to see what building that looks like. The third covers why context needs its own security model.
If context is not a pool of knowledge we pour into a model, harder questions follow. How is it gathered? How is it organized? What happens when it conflicts with itself? How does a system decide what a task needs? And most important:
How do we know what context an AI system actually used when it reached a conclusion?
These are not implementation details. They are the foundation of a new piece of enterprise architecture: the context engine.
Context has to be built, not indexed
Enterprises do not lack context. They lack access to it.
Some is explicit: policies, data dictionaries, contracts, operating procedures, system configurations. Some is implicit in systems: approval flows, exception handling, routing logic, thresholds, workflow history. And some lives only in people, behind statements like these:
“We normally use this metric, except for this category of customer.”
“That supplier always looks late in the system, but its feed is delayed by a day.”
“That opportunity should not be in the forecast yet, whatever the CRM says.”
For AI to be useful inside an enterprise, some of this has to become accessible to machines. That means context is captured and constructed, not merely indexed.
Four ways context enters the system
Documents. Policies. Playbooks, contracts, wikis. Models are good at extracting knowledge from them, but documents are routinely outdated, duplicated, or contradictory. On their own they are not enough.
Systems and workflows. An approval workflow reveals how a business actually operates. A CRM configuration encodes territory rules. An ERP exception path shows what operations teams really do. This matters especially for agents, which do not just answer questions. They act inside these systems.
Data and metadata. Schemas, lineage, definitions, ownership, and quality signals. A model computing gross margin needs more than a column location. It needs to know what the metric means, how it is derived, and which source is authoritative.
People. Some context has to be contributed directly by the people who hold it. AI can help extract it, but the enterprise still needs a way for people to supply judgment, corrections, and explanations. This is not a weakness in the architecture. It is how organizations work.
The hard problem: your organization disagrees with itself
Two documents describe the same process differently. A policy changed, but the old version is still linked from somewhere. Two business units read a rule differently. A system configuration does not match the documentation.
Models are very good at producing coherent answers. Give one two conflicting pieces of context and it will rarely say, “Your organization appears to disagree with itself.” It reconciles the contradiction and answers, convincingly.
A logistics company I will call Crestline learned this with a customer service agent. Crestline had two definitions of “on time.” Customer contracts said delivered by 5 p.m. local. The operations dashboard measured against a 6 p.m. dock cutoff, because that was when carriers got penalized. The operations definition was better documented and more recent, so the agent picked it up. For six weeks it told customers that late shipments were on time. Nobody caught it quickly, because every answer matched the dashboard.
The data was accurate. The context was wrong for the task. This is the failure mode I worry about most: not hallucinated data, but accurate data interpreted through the wrong context. Nothing looks broken.
People do this every day too. Two analysts see revenue down 15 percent. One calls the account at risk. The other knows purchasing moved to a new contract that has not reached reporting yet. Same data, different context, different conclusion. An AI system with incomplete or stale context reaches the wrong one with the same confidence.
Context needs lineage
Data engineering spent years building lineage, provenance, and ownership. Context needs the same.
For any significant AI-generated conclusion, an enterprise should be able to answer: What context was retrieved? Where did it come from, and when? Is it still valid? What conflicted with it, and which source was treated as authoritative? What data was joined to it? Which model used it?
A citation is a start. What you actually want looks more like this:
Task: Approve a 12 percent discount on account 4471. Context retrieved: Discount policy v4 (effective March 2026, owner: RevOps). Strategic account list (refreshed weekly). Exception log: three approved exceptions in this segment in the last two quarters. Conflict detected: Discount policy v3 still embedded in a sales enablement deck. v4 selected on validity date. v3 flagged to its owner. Data joined: Current ARR, renewal date, projected deal margin. Outcome: Within threshold. Routed for VP sign-off because the account is strategic.
That is inspectable. It is what lets an enterprise trust a conclusion, and what lets you debug the system when it is wrong.
Where human judgment belongs
The goal is not to remove humans from the loop. Human judgment is usually where context came from in the first place.
The goal is to capture it once and reuse it. People should not supply context every time an agent runs. They should establish the durable things: which source is authoritative, what the corrections are, which exceptions exist, how long something stays valid. That judgment then serves thousands of runs. Human judgment becomes reusable organizational context.
Retrieval is a reasoning problem
Suppose an agent receives this task: “Determine why campaign efficiency declined this month and recommend what to change.”
The relevant context might include how efficiency is defined, campaign objectives, benchmarks, budget constraints, channel rules, recent pricing changes, attribution methodology, and known data anomalies. A search index can find everything related to “campaign efficiency.” It cannot decide which of it matters for this task.
For that, the engine needs a task model: the objective, the systems involved, the data needed, the decisions and actions that may follow, who is asking, what constraints apply, and what authority the agent has. Once the system understands the task, it can retrieve with precision.
This is why task-specific context is an architectural principle, not a prompting technique.
The context engine, layer by layer
At a high level, a context engine has seven responsibilities.
Select a responsibility to see what it does
Continuously gather candidate context from documents, applications, data systems, workflows, metadata, prior decisions, conversations, and people. Ongoing, not a one-time migration.
Turn raw information into usable knowledge: entities, relationships, policies, rules, procedures, tasks, users, validity periods. This is where a Slack thread becomes “an unadopted proposal” rather than “a policy.”
Every piece of context keeps its origin, contributor, version, and last update. Without this, nothing downstream can be trusted.
Do not silently flatten contradictory knowledge. Surface it, rank it, scope it, or escalate it. Sometimes there is one authoritative answer. Sometimes there is not, and the architecture has to represent both.
At runtime, select the smallest useful set of knowledge required to perform the task correctly. Not everything related to the topic.
Bring together task, context, and live data. That combination is what lets a model or agent reason meaningfully.
Record what context was actually used. This produces the lineage above, and it is how you inspect, debug, and improve AI behavior over time.
Data and context need a common runtime
The sixth layer deserves a closer look, because it is where the architecture matters most for agents.
An agent resolving a customer escalation needs, on the context side, the escalation policy, account tier rules, refund thresholds, and prior exception guidance. On the data side, it needs current account status, recent tickets, payment history, usage, and contract terms.
Keep those in two systems that never meet and the model has to assemble them, which is exactly where things go wrong. Assemble them around the task instead. The context tells the agent how to think. The data tells it what is happening.
How we are approaching this at Nexla
Our lens is simple: context should be owned by the enterprise, organized around tasks, and delivered alongside the data required to perform those tasks.
Nexla starts from the systems enterprises already run: operational applications, databases, SaaS tools, files, APIs, and data platforms. Those connections expose not just data but the structure and behavior of the systems themselves, which is where much of the implicit context lives. Our Context Layer captures knowledge about systems, data, tasks, workflows, schemas, transformations, policies, and operational know-how, and retrieves the slice a specific task needs. That task may be exposed as a data product, an API, an agent, or a task-specific MCP server.
The model never needs the whole repository. It gets the context required for the task and the data required to complete it, and the enterprise keeps control of both.
We are still early
Vector databases did not solve this. Longer context windows do not solve it. Knowledge graphs, data catalogs, and RAG do not solve it on their own. All are useful components. None is the answer, because the real challenge is harder:
How do we continuously turn fragmented organizational knowledge into reliable, task-specific context an AI system can use at the right moment?
That takes data infrastructure, knowledge management, retrieval, provenance, and human judgment working together. This area will move quickly. But one principle already seems clear. The quality of enterprise AI will depend not just on the model or the data, but on the context engine sitting between organizational knowledge and the task being performed.
That engine has to do more than return a few similar documents. It has to know what matters.
If context represents an organization’s accumulated judgment and operating know-how, it may be some of the most sensitive information the enterprise owns. The next post is about protecting it.
This series. Part 1: Don’t Turn Context Into the Next Data Swamp. Part 2: Building the Context Engine (this post). Part 3: Context Is Enterprise IP.
Related. The Context Layer for AI Agents: Definition, Five Capabilities, and How It Works, The Future Is Not One MCP Server Per Application, and the Helix Context Layer.
