Two layers people conflate
When a client asks us to “build an AI agent,” there are really two separate engineering problems hiding inside that request: exposing the right tools to the agent in a way it can reliably call, and building the harness that governs how the agent uses those tools — state, retries, limits, and human handoff. We covered the conceptual split in what is agent-native software; this post is about the two pieces themselves.
MCP servers: giving agents real tools
The Model Context Protocol standardizes how an agent discovers and calls a tool — what it does, what parameters it needs, what it returns, and what an error looks like. Before MCP, this was a bespoke JSON schema per project, hand-maintained and easy to let drift out of sync with the real system.
- An MCP server exposes a client's internal systems — a database, a CRM, a simulation pipeline — as a set of well-documented, callable tools any compatible agent can use.
- Because the interface is standardized, the same server can serve multiple agents and use cases without re-integration. Our work with Upfreq Robotics is a direct example: their simulation and testing infrastructure, exposed once as an MCP server, can be called by their own testing agent and by any future agent they build.
- Good MCP servers return structured, typed errors rather than bare exceptions — this alone fixes a large share of the “the agent did something weird” bug reports we've debugged for clients.
Agent harnesses: the part that actually breaks in production
The harness is the code that runs the agent loop: it holds conversation and task state, decides when to retry a failed tool call versus try something different, enforces which actions need human approval, and logs everything for audit. It's unglamorous, and it's where almost all the reliability engineering actually lives.
- State management: the harness has to track what the agent has already tried, so it doesn't repeat a failed action in a loop.
- Policy enforcement: a reversible, low-risk action (drafting a message) can run autonomously; an irreversible one (sending it, writing to a production database) needs an approval gate. We go deeper on this in our research notes on guardrails and policy engines.
- Error recovery: what the harness does after a tool call fails matters more than how often it succeeds — see error recovery patterns in agent tool-calling for what we're seeing across client work.
Why we treat this as a repeatable practice
Early on, we rebuilt harness logic from scratch for every client. It generalizes far more than the domain logic does — the same state, retry, and policy patterns show up whether the agent is doing clinical intake for Physiolaxy or driving a robotics testing pipeline for Upfreq. That's why MCP server creation and agent harness engineering are now dedicated service lines for us, not implementation details buried inside a bigger project.
Frequently Asked Questions
Can I use an off-the-shelf agent framework instead of building a custom harness?
For prototypes, yes. For production systems with real approval and audit requirements, most off-the-shelf frameworks need meaningful customization at the policy and error-recovery layer — that's usually where we get pulled in.
Does every AI agent need an MCP server?
Not every agent needs its own server, but if more than one agent (or more than one vendor's agent) needs to call the same internal system, standardizing that interface with MCP pays for itself quickly.
Conclusion
The model is the part everyone talks about. The MCP servers and the harness around it are the part that determines whether the agent is still working reliably three months after launch. We build both, deliberately, on every engagement.