# Why your context layer breaks the minute you use it for something new > Source: > Published: 2026-08-03 09:00:00+00:00 Every developer who has worked with an [LLM](https://www.infoworld.com/article/2335213/large-language-models-the-foundations-of-generative-ai.html)-powered application has hit a familiar wall. You hard-code context into a prompt, and it works great for the thing you built it for. But when you try to have the system do something slightly different, something goes wrong. So you add more context. Then more conflicts show up, and you end up trying to hopelessly maintain a web of hand-tuned strings that nobody on the team fully understands. The comparison I keep coming back to is an [API](https://www.infoworld.com/article/2269032/what-is-an-api-application-programming-interfaces-explained.html). An API is a handshake: it defines what you can ask for and what you’ll get back, without forcing you to know how the data was produced or stored underneath. Call an endpoint for a news article, and you know you’ll get a title, a description, and an author. The endpoint doesn’t need a separate, hard-coded entry for every article that could ever exist. It describes a type of thing and lets you retrieve any instance of it. Context should work the same way. Instead, most teams build the opposite of an API. They write context that says “this specific article is about X and Y,” then write another block for the next article, and the next, until they’ve built something that only works for the narrow case it was written for. Use it outside that case, and it breaks. What actually scales is treating context the same way an API treats data: as an interface, not as the content itself. I call this the metadata layer, which describes what a given piece of data is, what it relates to, and how an agent should interpret it, without hard-coding the data itself into every prompt. But an interface isn’t just a description. This is the part teams tend to skip, and it’s where the API analogy actually earns its keep. An API contract does two jobs at once. It documents what an endpoint is for: semantics, the human-readable meaning. And it enforces what a valid call to the endpoint looks like, the schema: required fields, types, allowed values, and the shape of the response. You don’t get to send a string where the contract expects an integer. You don’t get a response with fields the contract didn’t promise. The constraint is what makes the contract trustworthy enough for a stranger to build against it without reading your source code. A metadata layer needs the same duality, and this is where the analogy to a context graph is exact rather than loose. Each entity in a context graph (a customer, a deal, an article) carries both halves of the contract. The semantic half says what the entity is and how it relates to neighboring entities (a deal belongs to an account, an account has a health score, and so on). The schema half says what’s structurally valid: which fields exist, what types they hold, which relationships are legal to traverse, which values are out of range. An agent querying that entity doesn’t just get a definition; it gets boundaries. It can’t hallucinate a field that isn’t in the schema, and it can’t misinterpret a metric because the entity already declares what that metric means and how it’s derived. Skip the constraint half, and you’ve only built documentation, not an interface. Agents can still read what a field is supposed to mean, but nothing stops a new use case from bending that meaning, querying a relationship that doesn’t exist, or returning a shape the next consumer wasn’t expecting. The semantic layer without the schema layer is a description you hope people follow. With both halves, you get something a second agent can build against without ever talking to the first. That distinction sounds small. It isn’t. Hard-coded context works for a single run because it’s fast to build and immediately useful, which is exactly why it’s most people’s first instinct. But every new use case means writing new context, and now you’re maintaining multiple versions that drift out of sync. A layer that describes the types of information available, how to retrieve them, and the boundaries on both ends lets you pull exactly the context a task needs without rewriting the underlying definition every time. Three effects follow, and I see all three constantly with engineering teams: I recently talked with a VP of sales who had built his own AI dashboard. No platform, no infrastructure team, just him wiring data sources directly into an agentic application to get a health view of his reps and accounts: deal history, prior calls, account status, all in one place. It worked. But that was also the problem. Two things happened immediately. First, other teams wanted the same thing. His customer success counterpart wanted an equivalent dashboard, but the logic distinguishing one data field from another—what each source actually meant, and what was and wasn’t a valid way to combine them—lived only in his head. There was no entity definition to hand off, only tribal knowledge. Anyone rebuilding it would have to re-derive both halves of the contract from scratch: the meaning and the boundaries, without his familiarity with either. Second, he didn’t want to keep solving infrastructure problems himself. Caching, data freshness, and access control (the plumbing under an agent that talks to your data) aren’t sales work, and he had no interest in rebuilding the dashboard for every new use case. This is the pattern across most teams that reach for agents without a context layer underneath them. Building an agent is no longer the hard part; you can spin one up on any major model provider in an afternoon. The hard part is what happens after the first one works. Every additional use case re-derives the same understanding of your own data by hand, with no schema to check it against and no guarantee the next person gets it right. The shift here is from a one-time context to a durable context. Hard-coded context has a shelf life of exactly one use case. Context that lives as a described, bounded, retrievable entity survives future use cases, because you wrote down what the data means and what’s valid to do with it, not just what one agent needed once. This matters more as agent use spreads. Once more than one agent touches the same underlying data for different purposes, they need a shared contract: the same semantic definitions, the same enforced boundaries, the same context graph. Multiple agents can’t each carry a private, hard-coded understanding of shared data. Before adding more context to your next prompt, ask whether you’re patching a current issue or defining a contract that will outlast it. Hard-coding is faster for a one-off. Building something multiple people or agents will interact with means investing in a context layer that states both what the data is for and what it will and won’t return. That investment pays off the moment someone else builds on it without starting from zero. That’s the actual shift underway in how teams manage context. It isn’t about bigger models or longer context windows. It’s about giving data and its description a different relationship, where the second use case is cheaper than the first. Because the contract, not just the content, was built to last. *—* *New Tech Forum*** provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all ****inquiries to *** doug_dineley@foundryco.com***.**