Agents & Infrastructure · July 2026 · 5 min read

MCP Solved Agent-to-App. App-to-Agent Is Still Missing.

MCP covers agent to app. There is no standard for app to agent. The missing piece is a protocol, and a small local daemon to prove it.

Priyansh Srivastava

Co-founder & CEO, Raven

Our manufacturing MIS at Raven does something slightly unusual when it needs a plan drafted or a report reconciled. It posts the job to a small service on the same machine, and that service hands the work to the Claude CLI. The agent runs on our own subscription, with the file access, permissions, and MCP servers we had already configured for ourselves.

The application carries no API key and pays no inference bill. It treats the agent the way it treats a printer: something the machine already has.

That arrangement is about to stop being unusual. Within a couple of years, a Claude or Codex subscription will be as common on a working machine as a browser. Each one is a personal plan with a full agent harness behind it: tools, file access, retries, permissions, and MCP servers.

So why can't your application use it?

One direction is solved. The other doesn't exist.

MCP, for all the momentum behind it, runs in exactly one direction. The agent reaches into your application, reads its data, and calls its tools, on whatever schedule the agent and its user decide. The agent pulls. Your app waits.

The reverse direction has no standard at all. There is no protocol by which an application says: here is a job, go do it, tell me when it's done. A builder who wants agent capability in a product today integrates an API, manages keys, and pays for inference by the token, while a fully configured agent sits idle on the same machine.

There are two near-misses. MCP has a reverse channel called sampling/createMessage, which lets a server ask the host for a completion. But it only covers single completions, almost nobody implements it, and the app still cannot start anything. Zed's Agent Client Protocol runs in the right direction: the editor spawns the agent and drives it over JSON-RPC, and JetBrains, Neovim, and more than 25 agents already speak it. But it was built for code editors, and nobody has generalized it to any application.

BYO-agent economics

The user is already paying for an agent. The application has no way to reach it.

Handing work to the local agent changes the arithmetic more than it first appears. A long agentic job, the kind that reads files, retries, and checks its own output, routinely runs through millions of tokens. At metered API rates, that is real money per run, every run, indefinitely. On the seat the user already carries, the marginal cost of that same job is zero.

For internal tools the conclusion is immediate. An operations app can hand work to each employee's own Claude seat instead of metering a shared company key that scales with every job anyone runs.

The economics are only half of it. The app also inherits the whole harness: file access, shell, retries, context management, and the user's own MCP servers and permission decisions. An API integration has to rebuild all of that from nothing.

The shape of the fix: a protocol, then a broker

Generalize the service from the opening and the missing piece turns out to be a protocol, not a product. Take the direction ACP already runs in, lift it out of the editor, and publish it as the reverse twin of MCP. Any application speaks JSON-RPC to a well-known local endpoint, creates a job, streams its progress, and negotiates what it is allowed to touch.

The natural reference implementation is a local agent broker, a small daemon on the user's machine that accepts jobs from any app and drives whatever agents the user has installed. The app owns the plans, templates, and state. The broker owns the queue, permissions, and agents.

The precedent is Ollama: a local daemon with a plain API and your own runtime underneath. It became infrastructure. The broker is the same move one level up the stack, for agents instead of models. Under the hood it should speak ACP to the agents rather than scraping CLI output. On top it adds what ACP leaves out: multiple apps, a job queue, persistence, and jobs that go beyond editing code.

A thing like this needs a name before anyone can argue about it, so: the Agent Dispatch Protocol. ADP for short, with apologies to the payroll company. The name matters less than the direction it encodes. MCP is how agents call into applications; ADP would be how applications call back.

The hard part is the product

The protocol framing changes the vendor question. If this were only a product, Anthropic or OpenAI shipping an OS-level agent service would kill it. For a protocol, that is the win condition. The best outcome is that agents implement the app-to-agent direction natively and the broker becomes optional, the way Microsoft publishing the Language Server Protocol made every editor better rather than protecting any one of them.

What no single vendor will do is implement it neutrally. That keeps an independent broker useful for as long as people run more than one agent.

The hard problem is security, and it is the same in either framing. A local endpoint that any application can drive agents through needs a real permission model: which app gets which working directory, which tools, and who approves what. That permission model is the hardest part of the specification. It is also the actual product.

The bet

The wager underneath all of this is that both halves of the opening become universal: the subscription on every working machine, and applications that want to hand real work to it, internal tools most of all. Meanwhile the piece standing between those two facts stays small. A protocol, a port, a permission model.

We built a business application whose backend worker is the user's agent. It works today. Someone will ship the polished version. I think it will look less like a framework and more like a port number.