Intent is the missing API
Software exposes capabilities. Almost nothing exposes what the user is actually trying to do.
Think about the shape of every API you have ever used. It exposes functions. Send an email. Write a row. Resize an image. Query a table. Deploy a container. Every endpoint is a verb — a thing the system can do for you, cleanly scoped, well-documented, waiting to be called.
Now think about what you were actually trying to accomplish when you called it. Launch a product. Fix a regression before the demo. Coordinate three people who don't talk to each other. Plan an event with a budget that keeps shrinking.
There is no API for any of that. There never has been.
We have spent decades building extraordinarily capable plumbing — task queues, orchestration layers, service meshes, event buses — and all of it speaks the language of what systems can do. Almost nothing speaks the language of what humans are trying to achieve. The gap between those two things is where most of the friction in software actually lives.
The gap that tools cannot close
This used to be a tolerable problem. Humans were the bridge. You understood your own intent, you knew which functions to call, and you stitched them together with judgment and context. The API didn't need to know your goal because you were standing right there, holding the goal in your head.
That assumption is breaking now. AI tools can execute. They can call APIs, generate code, write documents, manage deployments. But they operate in the same paradigm as the APIs they call — they understand capabilities, not outcomes. Give a language model access to your entire tool chain and it will ask you the same question a junior developer asks on their first day: what are we actually trying to do here?
The common answer is "just prompt it better." Write a more detailed prompt. Add more context. Be specific. This works, in the same way that writing a detailed Jira ticket works — it transfers intent from your head into text, once, for one reader, with no structure and no state. Tomorrow you will re-explain the same thing to a different tool. Next week the context will have drifted.
Prompts are utterances. They are not architecture.
Intent as a data structure
What if intent were not a sentence you typed into a chat box, but a structured object that lived alongside your code? Not a prompt — a specification. With goals, constraints, success criteria, current state, and a record of what has already been tried.
Consider what that object might contain. A raw statement of what you are trying to do, in your own words. A distilled goal extracted from that statement. A set of constraints — budget, timeline, technical boundaries, things you refuse to compromise on. Success criteria that are specific enough to be evaluated. Inputs you are working with. Outputs you expect to produce. A list of tasks with real states: open, done, blocked. An execution phase — are you still clarifying, or are you already executing? And, critically, adapter targets: instructions for how different AI platforms should interpret all of the above.
This is not a wishful abstraction. Every field in that structure maps to something you already carry in your head when you sit down to work. The difference is that right now it stays in your head, or it gets scattered across twelve tabs, four documents, and a Slack thread that no one will ever re-read.
The problem is not that tools lack capability. The problem is that intent has no address.
What changes when intent is portable
Something interesting happens when you give intent a stable shape. It becomes readable by anything. Your editor can read it. Your CI pipeline can read it. A language model can read it. A project management tool can read it. They are all looking at the same structured object, not at their own siloed copy of what they think you meant.
Right now, every tool you use maintains its own notion of your project. Your IDE has a workspace configuration. Your AI assistant has a system prompt. Your task tracker has a board. Your deployment tool has a manifest. None of these talk to each other, and none of them capture the why behind what you are building. You are the integration layer, re-explaining your intent to each tool in its own language, over and over, absorbing the translation cost yourself.
A portable intent object inverts that. You describe what you want once — goals, constraints, current state — and tools compile themselves to serve it. The language model reads your constraints before generating code. The task tracker derives its structure from your execution state. The deployment pipeline knows which phase you are in and behaves accordingly. You stop configuring tools. You start declaring outcomes.
This is not orchestration in the traditional sense. There is no central controller dispatching commands. It is more like a shared gravity well. The intent object sits at the center and everything in the project orients toward it.
Files, not endpoints
Here is the part that feels almost too simple to be right. The best place to put a structured intent object is in a directory, in your project, as files.
Not behind an API. Not in a database. Not in a SaaS platform that requires authentication and a subscription. In a directory that ships with your code, versioned by the same system that versions everything else, readable by any tool that can open a file.
A directory of structured files is, in a meaningful sense, an API. It has a schema — the shape of the files and what goes in each field. It has state — the files change as the project evolves. It has access control — whatever controls access to your repo controls access to your intent. And it has the one property that most APIs lack: it is portable by default. It does not depend on a running service. It does not require network access. It travels with the project.
Every AI platform has a concept of "projects" now. Anthropic has project instructions. OpenAI has custom instructions. Cursor has rules files. None of them are interoperable. Your project context is locked inside whichever platform you happened to set it up in. But if your intent lives in files, adapters can translate it into any of those formats. The files are the source of truth. The platform-specific configurations are just views.
The compiler, not the runtime
There is a pattern here worth naming. Most tools position themselves as runtimes — they execute things for you. But the harder problem is not execution. The harder problem is compilation: taking messy, incomplete, contradictory human intent and turning it into something structured enough that execution tools can act on it without constant hand-holding.
People do not think in structured specs. They ramble. They contradict themselves. They know what they want but cannot articulate the constraints until they bump into them. A useful system would accept that raw input and compile it — extract the goal, surface the constraints, identify the gaps, produce a structured object that machines can read and humans can audit.
The output of that compilation is not a plan. Plans are disposable. The output is a specification of intent that updates as the project evolves, that carries its own history, that any tool in the ecosystem can read without needing to ask you what you meant.
Ship the protocol. Let the ecosystem figure out what to build on top of it.
What this implies
If intent becomes a first-class data structure — portable, structured, versioned, readable — a few things follow quietly.
Tool switching stops being a migration. Your intent travels with you. Move from one AI assistant to another and your context comes along, not as a prompt you paste in, but as a structured spec the new tool can parse on its own.
Collaboration becomes legible. When two people work on the same project, they can read each other's constraints and success criteria, not just each other's code. The intent object is a shared reference point that is more honest than a project brief and more durable than a conversation.
AI systems get dramatically better at helping you, not because the models improve, but because they finally have access to the thing that was always missing: what you are actually trying to do, in a format they can reason about.
And the directory where all of this lives — unassuming, just files, no infrastructure required — turns out to be the most powerful integration point in your entire stack. Not because it does anything. Because everything else can read it.
Intent has always been the missing layer. We just never gave it an address.