Agentic Systems and MCP Server Architecture

The model is not the system

An agent that works in a demo and an agent that works in production differ in everything around the model: which tools it may call and with whose permissions, what it is allowed to read, how you know it still behaves after the next model release, what happens when it is wrong, and what one conversation costs.

I design that surrounding system. Most of it is ordinary backend architecture with unusually sharp boundaries, and the same discipline that keeps a payment system honest keeps an agent honest.

Tool boundaries and permissions

Every tool an agent can call is an API with a blast radius. I define the tool surface deliberately: read-only tools separated from tools that change state, per-tool authorization tied to the calling user rather than a shared service account, explicit budgets per call and per session, and an audit trail that records which tool was called with which arguments and what came back.

MCP servers

The Model Context Protocol has become the standard way to expose tools, resources and prompts to agents. I design MCP servers that are stateless where they can be, versioned like any API, authenticated with the transport's own mechanisms, and discoverable through the registry and the well-known files that agents now read. The public MCP server for this site is the small worked example; the same structure scales to an internal platform with dozens of tools.

Retrieval and knowledge bases

Retrieval-augmented generation is only as good as the corpus, the chunking and the freshness of the index. I design the knowledge layer: what goes in, how it is split and embedded, how provenance travels with every chunk so an answer can cite its source, and how updates reach the index without a full rebuild. Where a knowledge base already exists, I review it against the questions the agent actually receives.

Evaluations

An agent without an evaluation suite is a system without tests. I build the harness: recorded scenarios with expected outcomes, deterministic checks where the output is structured, judge prompts where it is prose, regression gates in CI, and a way to replay production traffic against a candidate model or prompt before it ships.

Guardrails

Input policies that reject what the agent should never process, output policies that catch what it should never say, hard limits on spend and on the number of steps, and a kill switch that a human can reach in seconds. Guardrails are architecture, not a filter bolted on at the end.

Cost and latency

Model calls are the most expensive and the slowest thing in the system. I set the budget: caching of repeated context, routing simple requests to smaller models, streaming for anything a person waits on, and instrumentation so that cost per task is a number on a dashboard instead of a surprise on an invoice.

What you receive

1. Tool surface and permission model. Every tool, its scope, its authorization rule and its budget, written down.
2. MCP server design. Transport, session and auth decisions, versioning, discovery and deployment topology.
3. Retrieval architecture. Corpus, chunking, embedding, provenance and refresh strategy.
4. Evaluation harness. Scenario format, judge prompts, CI gates and a replay procedure.
5. Guardrail and budget policy. Input and output rules, spend and step limits, kill switch procedure, and the operational runbook.

How it runs

A free 30-minute call to understand what the agent is for and what it must never do. Then a written scope, one to two weeks of design and review, and a walkthrough with the team that will operate the system.