The agent your team built last quarter can do things your CRM never could. It drafts responses, summarises case notes, flags anomalies before a human would notice them. The demo ran well. The board was impressed. But it is February, you have been nearly in production since November, and nobody has a straight answer for why.
Usually the answer is integration. Not the model. The model is fine. It is the wiring between the agent and your actual systems that stalls production deployments.
Anthropic’s engineering guidance for production Claude agents identifies three integration approaches. Every team encounters all three. Understanding why most deployments converge on one of them is the most useful thing you can know before you start building.
Option 1: direct API calls
This is where every team begins. The agent executes HTTP requests directly, either through a code-execution sandbox or via generic function-calling tools. For a single agent talking to a single service, it works well.
The problem appears when you add the second agent. Or the third service. Each new combination requires a bespoke wiring job: authentication logic, error handling, retry behaviour, tool descriptions, rate limit management. None of it carries over to the next integration. By the time you have four agents and five internal systems, you are maintaining twenty separate integrations. At a senior developer rate of $150–$180/hr, a team spending two days per quarter maintaining each integration is spending $60,000–$90,000 a year on invisible plumbing.
This is the M×N problem. M agents, N services, M×N integrations to build and maintain. It is a workable architecture for a prototype. It is not a workable architecture for a production system expected to grow.
Option 2: CLI tools
The agent runs a command-line tool in a shell. Your existing CLI does the actual work; the agent calls it. Lightweight, fast to set up, and your existing devops tooling already understands the surface area.
The limitation is the shell itself. Mobile clients do not have shells. Cloud-hosted Claude products do not have shells. The Claude.ai web interface, Claude Code running in a browser, a Claude instance embedded in a customer portal — none of these can execute shell commands. Your CLI integration is functional in a dev container and dead everywhere else.
For a Sydney-based financial services firm running Claude in a browser-based document review workflow, a CLI integration is a non-starter on day one. Not a question of effort. The interface simply does not exist.
MCP is the production layer
Anthropic published the Model Context Protocol to solve exactly this. The architecture is straightforward: the agent talks to an MCP server via a standard protocol. The MCP server talks to your system: your CRM, your document store, your data warehouse. The interface is uniform regardless of which Claude surface calls it: desktop app, Claude.ai, Claude Code, the Anthropic API, or a custom embedding.
Build the MCP server once. Every Claude product that supports the protocol reaches your system through it. That is M+N: M agents, N services, N servers total, each reusable across every agent. The M×N problem disappears.
The protocol handles the low-level work: tool discovery, capability negotiation, structured calls and responses. What it does not handle is the MCP server itself. That is your implementation work. But that work is bounded and repeatable. A well-built MCP server for a single system is a defined engineering task. Twenty bespoke integrations across the next two years are not.
The auth story improves as well. One server, one OAuth or API key pattern, one place for your security team to inspect. When an APRA CPS 230 operational risk review asks how Claude accesses your systems of record, “we have one server that mediates all Claude requests” is a considerably cleaner answer than “it depends on which agent and which workflow you are auditing.”
When MCP is the wrong move
None of this means MCP is right for every team at every stage. Be honest about where you actually are.
If you are running a genuine proof-of-concept (one agent, one API, internal users only, no production data), direct API calls are faster to wire and easier to change. MCP adds a server to maintain. For a two-week spike, that overhead has no payback.
CLI integration holds up in environments where it holds up: developer tooling, locally-run Claude Code workflows, internal scripts running on managed machines. If your entire Claude footprint is desktop-based and confirmed to stay that way, CLI is a reasonable choice.
The scope is fixed. One agent, one service, nothing else will ever share that connection. The indirection costs more than it saves.
The agent is not proven yet. Build the thing that proves the concept. Rewrite for scale when you know the agent is worth scaling.
You have one Claude surface. MCP’s reuse value is real only when multiple agents or Claude products need the same underlying connection.
The Australian enterprise picture
Most Australian mid-market teams start with direct API integration because it ships fastest. Some move to CLI tools before realising those do not work in the browser. The ones that reach production at scale almost always end up at MCP, usually after rebuilding something once.
Building the MCP layer as part of the initial implementation is faster in aggregate. A well-scoped MCP server for a single system (a document management platform, a CRM, a reporting database) typically runs $40,000–$80,000 as a standalone build. That is a fraction of what a year of M×N maintenance costs, and it is an asset your second and third agents reuse without additional wiring work.
Australian banks, insurers, and professional services firms in Melbourne and Sydney operating under APRA oversight have one additional reason to get this right the first time. The audit trail for how AI accesses regulated systems is not optional. MCP gives you one well-defined surface to audit. Twenty bespoke integrations do not.
The pilot that wins the internal bake-off is rarely the prettiest demo. It is the one that still works when the mobile team wants access, when audit asks how authentication is managed, and when the product manager for team B asks whether their new agent can use the same CRM connection.
Pick the approach that matches your current reality. Direct API calls for a two-week prototype. CLI for a locked-down developer workflow. MCP for anything that needs to reach production across more than one surface, more than one team, or more than one quarter. If you are past the prototype stage, that choice has largely already been made for you.