What Changes When MCP Connects Agents to Your Decision Layer
MCP crossed 97 million monthly downloads and became infrastructure. Here is what actually changes when agents gain standing access to operate your portfolio and its decision ledger, not just answer questions about it.
The Model Context Protocol crossed 97 million monthly SDK downloads in March 2026. Anthropic donated it to the Linux Foundation, and the protocol now carries backing from OpenAI, Google, Microsoft, and AWS. [2] [1]
Most operators barely registered it.
That asymmetry is worth understanding, not because the download figure is intrinsically interesting, but because of what it signals about where the protocol sits now. MCP has cleared the viability threshold. It is not an experiment. It is infrastructure, and the kind that changes what an agent can do with the systems your company already runs on.
Here is the actual problem most operators are living with right now. Every new agent session starts from nothing. You open a chat, paste in where each product stands this week, describe the budget call you made last month, explain the metric you decided to chase, and try to get somewhere useful before the context window runs out. Then the session ends. You open a new one and do it again. The agent knows nothing between sessions unless you tell it again. Context is not free. It costs time on both ends, and running a portfolio makes the bill worse, because the state you have to re-explain is now several products deep.
MCP is the shift that changes this. Not "AI got smarter." The agent's relationship to the systems the company runs on got structurally different. An agent with an MCP connection to your decision layer can read the portfolio, the weekly evidence, and the standing decisions, hold that context across turns, and draft the next call from it. The session stops being stateless. The agent stops being a text generator that waits for whatever you paste in. It becomes something that operates the tool you steer.
That distinction changes what agents can do in the running of your company. The rest of this is about what that looks like.
What MCP actually is (the one paragraph an operator needs)
MCP is a protocol that lets AI systems connect to external tools and services through a standardised handshake, rather than requiring a custom integration for every pairing. [1] Engineers have been building these connectors since Anthropic released the spec in late 2024. By March 2026, the reference repository had more than 80,000 GitHub stars. [3] Every vendor that matters, including OpenAI, Google, Microsoft, AWS, and Cloudflare, supports it through the Linux Foundation's Agentic AI Foundation.
That breadth matters for a simple reason. A protocol that only one or two vendors support is a bet. A protocol that clears this kind of adoption and moves under neutral governance is a foundation. You can reason about it the way you reason about any settled infrastructure: not "if" but "what changes because of it."
From pasted context to standing access
The operational pain is familiar to anyone who has crossed from running one product to running several. Focus and budget compete across products. Weekly evidence piles up faster than you can read it. And the reasoning behind last month's bet lives in your head, or in a spreadsheet cell that has since been overwritten. Every time you bring an agent in to help, you start by reconstructing all of it from memory.
Karri Saarinen, CEO of Linear, put the precondition plainly: "Agents are not mind readers; they become useful through context. Customer feedback, internal ideas, strategic direction, decisions, and code all need to be captured in a system that humans and agents can work from together." [4]
Read the list in that quote again: strategic direction and decisions, captured in a system humans and agents work from together. That is not an argument for a specific tool. It is a statement about what any agent doing useful steering work actually requires. MCP is the mechanism that delivers that context without a human carrying it there by hand each session.
This is where a decision layer earns the connection. Agimon exposes the portfolio, the weekly evidence, and the decision ledger as MCP resources, so an agent reads live company state, active postures, standing budgets, the latest signals per product, and the open decisions, rather than a snapshot you pasted ten minutes ago. The session is no longer stateless because the source of context is not.
For the discipline that produces those decisions in the first place, turning a week of evidence into decisions you can defend covers the upstream step. What the agent can do once that state is standing and readable is a different problem.
The agent that drafts, not just answers
There is a mode of collaboration the stateless chat session structurally prevents, and a standing MCP connection makes possible.
A chat with no access can only answer the question you paste. An agent with standing access to the decision layer can do something more useful: read this week's evidence and the existing ledger, then draft the next calls from them. Shift focus to the product with momentum. Cut budget on the stalled one. Raise the activation metric on a third. The agent is not waiting for you to assemble the review. It opens with a proposal grounded in live state.
That is the human-plus-agent seat, and the division of labour is deliberate. Agents record the evidence and draft the proposed focus, budget, or metric decision. The operator approves or supersedes. The decision still has more than one reader, so the call, the evidence behind it, and who approved it all land in an append-only ledger. Propose-then-approve keeps the operator in the seat while the agent does the reading and the drafting. For what one week of that loop produces end to end, see the weekly evidence-to-decision cycle.
Progressive disclosure, not a wall of tools
There is a failure mode in connecting agents to a real system: you hand them fifty tools and a schema, and the model burns its context deciding which one to reach for.
Agimon's MCP surface is built around meta-tools instead. describe_capabilities and use_capability let an agent discover capability depth on demand, so it sees the shape of what it can do first and reaches for a specific tool only when the work calls for it. Planning becomes progressive disclosure rather than a menu the agent has to hold all at once. The point is not more tools. It is an agent that can find the right one without drowning in the list.
What MCP does not fix
There is a version of this story that ends with "connect the right MCP servers and your portfolio steers itself." This is not that story.
A live, perfectly delivered feed of bad decisions is a faster path to steering the company wrong. If your postures are set by gut, your evidence is stale, or your past calls were never recorded as decisions, MCP gives the agent a richer view of that incoherence. The context-delivery problem is solved. The judgment problem is still yours.
The cleaner version of this point is in why AI coding agents fail: agent failures almost always start before the first prompt, in under-specified inputs that leave the model filling gaps with training priors rather than intent. MCP changes the source of the context. It does not change the quality of the thinking that shaped it. Connect it to a portfolio where the wrong bets just ship faster, and you get wrong allocation delivered with perfect fidelity.
The ceiling MCP removes is real. Most agents are genuinely limited today by the absence of persistent, structured access to the system they are supposed to operate. Removing that ceiling is useful. Treating the removal of a ceiling as the whole solution is the error.
The shift MCP represents is not that AI got smarter. It is that the system the agent can reach got structurally different. That is a smaller and more useful frame than "AI now runs your company," and it leads to a more tractable question.
Not "which MCP servers should I install?" but "which of my company's decisions and evidence are worth making legible to an agent?"
That is an operator judgment question. It requires knowing what an agent needs to draft a defensible call, which decisions have to be recorded for it to act on them, and which ones still live only in your head. Answering it is the work that makes everything downstream faster.
The protocol has cleared the viability threshold. The context-delivery problem has a solution. What sits on the other side of it, deciding what the company should steer toward, is still an operator's job. That is the right problem to be working on.
If you know an operator who has spent the last year pasting portfolio state into a chat window, send this their way.
References
- GitHub Blog. "MCP joins the Linux Foundation: What this means for developers." https://github.blog/open-source/maintainers/mcp-joins-the-linux-foundation-what-this-means-for-developers-building-the-next-era-of-ai-tools-and-agents/ . Published 2025-12-09. Accessed 2026-06-14.
- West, Alan. "MCP Hit 97 Million Installs. The Protocol War Is Over." dev.to. https://dev.to/alanwest/mcp-hit-97-million-installs-the-protocol-war-is-over-47ab . Published 2026-04-06. Accessed 2026-06-14.
- Digital Applied. "MCP Adoption Statistics 2026: Model Context Protocol." https://www.digitalapplied.com/blog/mcp-adoption-statistics-2026-model-context-protocol . Published May 2026. Accessed 2026-06-14.
- Saarinen, Karri (via Tessl). "Issue tracking is dead: Linear CEO explains why the company is betting on agents." https://tessl.io/blog/issue-tracking-is-dead-linear-ceo-explains-why-the-company-is-betting-on-agents/ . Published 2026-03-31. Accessed 2026-06-14.