Prototype on MCP, Productionize in Code

I can build an agent that reads every deal in my CRM through MCP tool calls and tells me where to focus. It costs $15 a run and the output is mediocre. The same answer from an algorithm over a Postgres table costs fractions of a cent. That gap is not a model problem. It is an architecture problem, and most teams shipping agents have not confronted it yet.

Here is the pattern that works. Prototype on pure reasoning — let the agent call MCP tools freely while you figure out what the workflow actually requires. That phase is legitimate and fast. But then read the logs. Wherever the model rebuilds the same bash script, the same search, the same data pull every single run, you are paying model prices for deterministic work. Extract it. Make it a Python function the agent calls as a tool, with a SQL query that hands the model exactly the data it needs and nothing more. The teams doing this well treat skills as real software, not markdown instructions.

The same curve applies to the integration layer itself. Aggregator MCP providers — the services that hand you a hundred OAuth connectors in an afternoon — are the prototyping medium for connections. They are an easy button of variable quality: when a connector works, you have built nothing and shipped something. When it turns out to be mediocre — and you usually find out the moment a real workflow leans on it — you write the native integration and swap the agent over with a one-line instruction. The decision rule is identical to the one for reasoning: pay the convenience tax while you are learning what the workflow needs, then harden the parts that matter.

The serious operators go further. One team I work with — automating tax and payroll for German SMEs — runs a small, cheap model as a triage layer in front of every task: how big is this, how many cycles does it deserve, which model should handle it, where is the cutoff. Frontier reasoning is reserved for genuine ambiguity. Everything else flows through code paths that cost almost nothing and never hallucinate.

They have also started automating the hardening itself. After every successful run, a background agent reads the execution logs and asks a simple question: what did this run do that the next one should skip? When it catches the model writing the same bash script for the fifth time, it proposes promoting that script to a skill and tightening the prompt — posted to Slack, approved with a thumbs-up, shipped as a reviewable change in git. Every successful run improves the next one — run data plus human feedback compiling down into cheaper, more deterministic agents over time.

This is the same maturity curve software has always followed — explore expensively, then optimize what repeats. What is different now is the bill. Token costs that look tolerable at ten runs a day become a line item the CFO notices at ten thousand, and the reckoning on token spend is coming faster than most agent roadmaps assume.

Production agents will not be pure LLM loops. They will be mixed flows — traditional software doing the repeatable ninety percent, model reasoning handling the ambiguous ten. If you want to know where you stand, take your most expensive agent, read its last ten runs, and count how many times it did the same work twice. That number is your roadmap.