Coding agents have warped the conversation about enterprise AI. They look magical because the context they need is already on disk: the repository, the tests, the configuration, the recent diffs. The user is technical enough to paste whatever else is missing, so the agent never has to go hunting for what a decision actually means. Nothing about that generalizes.
Translate the same agent into a sales operations team, a claims department, or a clinical workflow, and the illusion collapses. The work depends on information scattered across a CRM, a billing system, an email thread from two quarters ago, a spreadsheet on a personal drive, and a rule that lives only in the head of the person who handled the last edge case. The model is fine. The retrieval is fine. The context is the bottleneck, and it is not an AI problem — it is a data, permissions, and knowledge-capture problem that has to be solved before the agent is worth building. A state of AI study (McKinsey, 2024) finds most organizations adopting AI and only a minority scaling beyond proof-of-concept, with the gap traced to data and integration rather than to models.
The most literal version of this problem ML LABS has shipped against is HL7 messaging. On the cloud ECG backend built for HeartSciences, the same clinical result — the same standard, the same message type — has to be constructed differently for every hospital that receives it, because the specification refuses to decide: an analysis of HL7 v2 optionality (JAMIA, 2009) counted 4,132 data elements in the standard result message with 85% of them designated optional. Which subset a given hospital accepts is not written in the standard. It lives in that hospital's interface configuration and in the head of the analyst who maintains it, and the only way an automated system learns it is by being told, field by field. That is enterprise context in one sentence, and it is why the fix is engineering rather than prompting.
Two Halves Of Context
The first half is digital context: data and decisions that exist somewhere in a system but are not reachable in a form an agent can act on. The second half is tacit context: knowledge that never entered a system at all, because the people doing the work carry it as patterns, exceptions, and inherited judgment. An agent that solves only one half produces confident output that is wrong in ways the business notices late.
The instinct to solve this with a bigger model or a longer context window misreads the failure mode. Research on long-context retrieval (Liu et al., 2023) shows that even when relevant facts are present in the prompt, models fail to use information buried in the middle of the window. Capacity is not the constraint. Curation is.
Digital Context Is Fragmented And Gated
Enterprise data is not missing in the absolute sense. It is fragmented across systems that predate any agent strategy, encoded in schemas that do not match the workflow, and gated by access controls written for human reviewers who chase exceptions by phone. A retrieval layer that ignores those realities will surface stale records, miss the row that matters, or expose data the agent should never have seen.
Access control is the quiet killer, because permission models built around job titles do not decompose into the capabilities a workflow actually needs — an agent acting for a claims processor inherits a permission set shaped for a person, and the result is either over-permissioning or constant escalation. Identity reconciliation is the other half: the same customer is CUST-00417 in billing, acme-corp in support, and Acme Corporation, Inc. in the CRM, and no prompt bridges that gap. Something has to build the layer that does. Research on hidden technical debt (NeurIPS, 2015) named data dependencies as the dominant source of long-term debt in machine learning systems a decade before agents arrived, and agents inherit that debt with interest, because they act on what they can reach.
Tacit Context Lives In People's Heads
The harder half is the knowledge that was never digitized: why a particular customer gets a manual review even though the account looks routine, why orders above a certain size take a specific approval path because of an incident three years ago, when a refund is worth more than the policy says. Work on how organizations turn experience into knowledge (Organization Science, 2011) describes the gap between what an organization does well and what it can explain about how it does it — and that gap is exactly where enterprise agents fail, because a system can retrieve every document the company has written and still miss the rule that governs the work.
Asking people to write down what they know is the obvious move and the weakest one, because a documentation exercise produces the sanitized procedure rather than the exceptions, and the exceptions are the whole value. The HL7 layer is the counter-example worth studying: the site-specific knowledge that decides whether a message is accepted — facility identifiers, patient identifier formats, provider reference schemes, diagnosis code subsets — was not written down by asking anyone to describe it. It was surfaced by instrumenting the rejections, reading the field-level error locations the receiving system returns, and turning each one into a per-organization configuration value. Capture has to happen against real work, in the moment, with the reasoning attached.
graph TD
A["Agent"] --> B["Context Layer"]
B --> C["Digital Systems"]
B --> D["Tacit Knowledge"]
C --> E["CRM, ERP, Email"]
C --> F["Permissions, Identity"]
D --> G["Decision Rationale"]
D --> H["Process Exceptions"]
B --> W["Useful Work"]
style A fill:#1a1a2e,stroke:#16c79a,color:#fff
style B fill:#1a1a2e,stroke:#ffd700,color:#fff
style C fill:#1a1a2e,stroke:#0f3460,color:#fff
style D fill:#1a1a2e,stroke:#0f3460,color:#fff
style E fill:#1a1a2e,stroke:#0f3460,color:#fff
style F fill:#1a1a2e,stroke:#0f3460,color:#fff
style G fill:#1a1a2e,stroke:#0f3460,color:#fff
style H fill:#1a1a2e,stroke:#0f3460,color:#fff
style W fill:#1a1a2e,stroke:#16c79a,color:#fffWhy This Problem Is Underestimated
Coding agents create false confidence because the context problem barely exists in their domain. The repository is the world, the tests reveal the unwritten contract, and the pull request history captures most of the reasoning. Point the same architecture at a knowledge-work problem and it stalls on inputs that look straightforward from the outside and are not.
The second reason is that the work does not look like AI work. It looks like data integration, permission redesign, and structured interviews with experienced staff — none of which produces an impressive demo, and all of which decides whether a pilot becomes a system. On the ECG platform, the context layer is what makes onboarding a new organization a configuration task rather than an engineering project: a new hospital is defined by its HL7 field mappings, its enabled AI models, its invoice pricing, and its storage provisioning, and each of those is a configuration surface rather than a branch in the code. That property was designed in from the start, not refactored in later, and it is the difference between a system that scales to the second customer and one that forks for them.
The companies that figure out context engineering will get the most out of the next decade of AI. The ones that buy more model capacity without solving it will keep funding pilots that never reach the work that matters.
How To Make Context Agent-Ready
The first move is to inventory the digital surface the agent has to touch — not the systems the team believes it touches, but the actual sources of truth: upstream feeds, cached projections, exports nobody owns, the manual override somebody performs every Friday. Skipping this makes every subsequent decision a guess.
The second move is to redesign access around agent workflows rather than human roles. The question is not "what is this agent's job-title equivalent?" but "what data does this workflow require, and what is the smallest permission set that supports it?" Published guidance on building effective agents (Anthropic, 2024) argues for simple, composable patterns where the boundaries of agent action are explicit rather than inherited — which is the same argument the ECG platform's per-organization isolation makes in a regulated setting, where cross-tenant access is blocked as a system invariant rather than an application convention.
The third move is to capture tacit context as a side effect of running the system, not as a separate documentation project. Each human review, override, or escalation of an agent output carries reasoning with it, and that reasoning is provenance the system should keep. Accumulated over months, it becomes the judgment the agent needed in the first place. Bolted on afterward, it never happens at all.
When Context Is A Data Problem
Some context failures are upstream data plumbing wearing a context costume, and there is a threshold where the honest answer is that the agent is not the next project. On the clinical operations automation ML LABS built for HeartSciences, the signal that stops the work is concrete: when extraction produces more than 15–20% of records with missing critical fields, or the same clinical event is coded differently across sites, the automation produces more exceptions than it processes and the billing automation case study says so in exactly those terms. No retrieval design rescues that. No prompt does either.
When those conditions hold, the intervention is upstream: define the entity, fix the schema, build the system of record, then point an agent at it. Treating it as an AI problem is the most reliable way to spend a budget on a sophisticated agent that produces confident, structurally wrong output — and the data foundation an AI build actually needs is the piece of work that comes first.
First Steps
- Map every system an agent in scope would read from or write to, and document the access boundary on each: who can do what today, and what the agent's permissions must look like to complete the workflow end to end.
- Pick one critical workflow and sit with the two or three people who handle it best. Capture the unwritten reasoning behind their exceptions — when they deviate from the documented process, and why.
- Write a context spec for one agent before building the agent: sources of truth, access requirements, the tacit rules from step two, and the failure modes the agent should escalate rather than handle.
Make Context A First-Class Product
Treat the context layer as a product with an owner, a roadmap, and a definition of done. Inventory the digital surface, redesign access for agent workflows, capture decision provenance while the system runs, and build identity reconciliation as a reusable component rather than as per-agent glue. Every agent that ships afterward inherits that layer, which is the difference between paying the context cost once and paying it per agent, forever.
The bar is checkable without help: the sources of truth are named, the permission set for one workflow is written down, the exceptions have been captured from the people who make them, and someone owns the layer. Where that bar is not met, the model is not the blocker and no model will be. Context work is buyable as a design engagement: an AI system design turns one workflow into an architecture, a written build plan, a fixed-price quote, and a working spike that runs in your stack against your real data — which is the point where the context path stops being a theory and starts being demonstrated. The agent stack that sits on top of it is the deployment problem the market keeps underestimating.
References
- Liu, N. F., Lin, K., Hewitt, J., Paranjape, A., Bevilacqua, M., Petroni, F., & Liang, P. Lost in the Middle: How Language Models Use Long Contexts. arXiv preprint arXiv:2307.03172, 2023.
- Anthropic. Building Effective Agents. Anthropic Engineering, 2024.
- Sculley, D., Holt, G., Golovin, D., Davydov, E., Phillips, T., Ebner, D., Chaudhary, V., Young, M., Crespo, J.-F., & Dennison, D. Hidden Technical Debt in Machine Learning Systems. Advances in Neural Information Processing Systems 28 (NeurIPS), 2015.
- Argote, L., & Miron-Spektor, E. Organizational Learning: From Experience to Knowledge. Organization Science, 2011.
- McKinsey & Company. The State of AI. McKinsey Global Survey, 2024.
- Sujansky WV, Overhage JM, Chang S, Frohlich J, Faus SA. The Development of a Highly Constrained Health Level 7 Implementation Guide to Facilitate Electronic Laboratory Reporting to Ambulatory Electronic Health Record Systems. Journal of the American Medical Informatics Association, 2009.
