Where we left off
In my last article, I argued that the meaning of enterprise data doesn’t live in the data. It lives in the applications built around it: in client-specific definitions, in the models that compute forecasts and lift, and in business rules spread across APIs and user interfaces. Pointing a large language model at the database skips all of that. The model we believe in is federated, where each application owns its semantics and exposes them through its own agent. At Cognira, that agent is Cora.
That raises a practical question. If an enterprise agent needs to work across promotions, pricing, and assortment, how should it actually connect to each application? The usual answer today is “build an MCP server.” My argument in this piece is that this answer is incomplete. Two MCP servers can look identical on an architecture slide and behave completely differently in production.
MCP or A2A is the wrong question
Most discussions frame this as a choice between two protocols. The Model Context Protocol (MCP) lets an agent call tools that an application exposes. Agent-to-Agent (A2A) lets agents talk to each other as peers, delegating work and exchanging results. Pick one, the thinking goes, and you have your integration strategy.
But the protocol matters less than what you put behind it. An MCP server is just a menu of tools, and the menu can be anything. It can offer a single tool that runs raw SQL against the warehouse. It can offer a tool that answers a merchant’s question in plain language. Both are “MCP,” but they have almost nothing else in common.
The real decision is where the reasoning happens. Does the calling agent have to understand your domain, or does your application do that work and hand back an answer? The answer sits on a spectrum, not a binary choice.
The spectrum
When I look at how enterprise applications are exposing themselves to agents today, I see four levels, each one moving more of the reasoning from the caller into the application.
- LEVEL 1
- Data access
- run_sql(query)
CALLER MUST KNOW
Every table, column, join and client definition
BUSINESS RULES
Bypassed
- LEVEL 2
- Entity tools
- get_offer (id) update_offer (...)
CALLER MUST KNOW
What the fields mean and how to combine them
BUSINESS RULES
Enforced on writes
- LEVEL 3
- Domain tools
- forecast_offer(...) event_performance(...)
CALLER MUST KNOW
Which tool answers which question
BUSINESS RULES
Built into every answer
- LEVEL 4
- Ask the agent
- ask_cora ("Should I rerun this promo?")
CALLER MUST KNOW
How to ask the question
BUSINESS RULES
Owned by the domain agent
- PEER AGENTS
- Agent to agent
- Delegate a task, clarify, report back
BEST FOR
Long running work and agents that need to negotiate
BUSINESS RULES
Owned by the domain agent
Level 1: Data access
The application exposes a tool like run_sql or read_table. This is essentially the “point the LLM at the database” approach, exposed through MCP. The calling agent has to know every table, every column, every join, and every client-specific definition. All of the business rules I described in the last article are bypassed. It’s the easiest server to build and the hardest one to use correctly.
Level 2: Entity tools
The application exposes its objects: get_offer, list_events, update_promotion. This is essentially the existing API, wrapped for agents. It’s a real improvement, because writes now go through the application and its validation. But the caller still has to know what the fields mean, which ones matter, and how to combine them into an answer. Ask it whether a promotion made money and it returns a dozen fields for the caller to interpret.
Level 3: Domain tools
The application exposes the questions it’s built to answer: forecast_offer, event_performance, recommend_promotions. Now the semantic layer and the models do the work. The caller gets back lift, baseline, and promoted margin calculated the way this client defines them. What the caller still needs is the judgment to pick the right tool, in the right order, for the merchant’s question.
Level 4: Ask the agent
The application exposes a single, high-level tool: ask_cora, with a question in plain language. The domain agent interprets the intent, decides which models and data to use, applies the rules, and answers in the merchant’s terms. The caller only needs to know how to ask. Technically this is still MCP, but functionally it’s one agent talking to another.
What changes as you move along it
Moving right on the spectrum trades control for leverage, and each step comes with costs.
The biggest shift is who owns the reasoning. On the left, the calling agent has to become an expert in your domain for every client, which is the problem I argued in the last article can’t be solved centrally. On the right, the application’s own agent carries that expertise, and the enterprise agent can stay a generalist that orchestrates.
Context and accountability move with it. Low-level tools flood the calling agent with schemas, fields, and raw rows, and past a point more context means more mistakes. When the enterprise agent assembles an answer from a dozen low-level calls, it’s also unclear who is responsible when that answer is wrong. When the domain agent answers, the vendor owns the answer and can evaluate and fix it.
The right side has real downsides too. Two agents reasoning means more model calls, more latency, and more cost, and the domain agent can feel like a black box to the orchestrator. The answer is for domain agents to show their work: which data, which models, and which assumptions they used.
Flexibility is the other trade-off. Low-level tools let a capable caller do things the application never anticipated, while high-level tools are only as broad as the domain agent behind them. That’s a feature for well-understood questions, but it can be a limit for genuinely novel analysis.
Where A2A earns its place
If a Level 4 MCP tool is already one agent asking another a question, why do we need A2A at all? Some work doesn’t fit into a single question and answer.
Take a request like “build me a promotion plan for the Thanksgiving event that hits our margin target.” That’s not a lookup: it takes time and needs clarifying questions along the way, such as which categories to include, which vendor funding is confirmed, and how aggressive to be on price. It may also need other agents. The pricing agent has a view on regular price and margin floors, the assortment agent knows which items are being delisted, and they might not agree.
They may not even use the same words. Within one retailer, promotions, pricing, and assortment each carry their own definitions, while the business wants one shared vocabulary across them. That puts the burden on each application to map its semantic layer to the retailer’s common terms when its agent talks to the rest of the enterprise, rather than leaving the orchestrator to translate.
This is where A2A is designed to help. It treats the work as a task that can run for a while, go back and forth, report progress, and come back with a result. It also lets agents discover what other agents can do and gives them a structured way to hand work off and negotiate.
So I don’t see MCP and A2A as competitors: a high-level MCP tool fits a question, A2A fits a project, and most enterprise applications will need both.
How we think about it at Cognira
Our view is that an enterprise application should expose more than one level, each for the job it does best.
For open-ended merchant questions, the right interface is Cora. An outside agent asks in plain language, and Cora works out what is being asked, routes it to our forecasting, evaluation, and optimization engines, and explains the answer in terms that already reflect the client’s definitions and business rules.
For well-defined, repeatable questions, domain tools make sense. When an orchestrator needs the forecast for a specific offer, it should call the forecast directly and get a consistent result rather than phrase a question.
For actions, every write goes through the application. Creating or changing a promotion has to respect the same validation, approvals, and permissions a merchant would face in the user interface, and Cora guards those writes when an agent makes them.
For outside agents, we don’t expose raw data access, because it invites exactly the confident, wrong answers the federated model exists to prevent.
The question to ask every vendor
Over the next year, almost every enterprise vendor will announce an MCP server. That announcement on its own tells you very little.
If you’re a retailer evaluating these, don’t stop at “do you have an MCP?” Ask where it sits on the spectrum. Does it hand my agent raw tables, or does it answer my merchants’ questions? Do writes go through your business rules? Is there an agent behind it that understands my definitions, and can my enterprise agent work with it as a peer when the task is bigger than a single question?
The answers will tell you whether you’re buying a connection to a database, or a connection to the expertise that makes the application worth having in the first place.
