Every developer who has worked with an LLM-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. 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.
