MCP is the contract. Production is the system.

The host is the control plane. It can create multiple clients, and each client speaks to one server. The server publishes what it can do; the client negotiates capabilities; the host decides how those capabilities enter a larger workflow.

That boundary is the important idea: MCP standardizes the exchange, while the surrounding product still owns consent, identity, model behavior, observability, and recovery. The official architecture overview is the reference point for this model.

The fourth step is the one demos skip. A result has to go back to whoever asked, and the product has to say what actually happened. Deyaf puts the same boundary in plain words: the model is one step of four (listen, look it up, check the rules, reply), and everything around that step is the harness's job.

The DEV guide correctly makes these primitives central. The production refinement is to treat every primitive as a policy object: attach ownership, sensitivity, allowed identities, audit expectations, and a failure mode before it reaches a model.

Anthropic's guidance on writing tools for agents reaches the same place from the model's side: fewer, clearly named tools with readable output behave like a contract. A short, deliberate tool list is also easier to govern than a long one.

Protocol compliance is a starting point. The official security best practices also cover confused-deputy risks, session hijacking, local-server compromise, and scope minimization.

A harness operationalizes those rules across many agents and servers. Deyaf's trust and control principles start from the same place: choosing a channel records intent and does not connect anything, and the starting plan requires human review before external messages, record changes, or commitments.

Simon Willison's lethal trifecta names the combination to avoid: private data, untrusted content, and a way to send data out, all reachable by one agent. Every MCP server you add can quietly complete that set.

Read her against the five layers of section 05. Identity: her name and per-language voices are fixed, and approved Feniex operators manage her rules and knowledge. She recognizes a returning customer's account context, limited to that one account; when several accounts match, she asks the customer to clarify.

Policy: the tool list and server-side queries hold her to four public actions. She checks the applicable record before any exact product, compatibility, warranty, price or software claim, because a convincing product name is not evidence. Approval: the public ladder has three levels (answer only, prepare for approval, run an approved task), set per workflow and per channel, with no single switch that lets her do everything.

Evidence: she describes only what the result proves: saved, drafted, sent, uncertain, acknowledged or resolved. Saving is not delivery, and drafting is not sending; that is step four of the trace in section 01. Recovery: an unanswered question on the web, phone, text or email becomes a durable item, and a ticket is filed when contact details are available. On the phone there are no transfers, by design: she answers from her library or takes a name and number for the team. What happens when she doesn't know is worth studying first.

Memory is layered, not total: four kinds of memory, each with one job. Customer notes are short and historical, never current facts; orders, invoices, shipments and balances are looked up fresh. When a person answers an unknown once, it is checked, then taught, in a supervised loop that measures before it teaches. Meet Eve, Feniex's assistant, for more.

Read the two racks against section 05. Identity, policy and evidence sit in the harness, so they hold at the counter: chat, website voice, phone, text and email all answer from one assistant, every way in. Only the delivery changes. Eve on the phone shows the second door up close.