M MCP field briefing / 2026 Build yours ↗

The future of connected agents

The connective layer becomes the product.

That layer is the Agentic Harness.

In 2026, capable models are abundant. What separates a demo from an operating system for work is controlled access: the right knowledge, the right tools, the right identity, and a harness that knows when to use each.

9 minute visual briefing Updated September 25, 2026 Enterprise architecture
See how an Agentic Harness works, end to end

Anand Topu’s central reading of David Soria Parra’s keynote is not that models suddenly learned a new trick. It is that connectivity became the bottleneck.

A production agent must cross boundaries a demo can ignore: SaaS applications, internal data, shared drives, long-running workflows, identity providers, approval chains, and audit systems. Every connection creates both capability and risk. That is why MCP’s evolution—and the harness surrounding it—matters.

2024 Prove it can act.

Demos and narrow proofs of concept establish the basic loop.

2025 Make local work useful.

Coding agents thrive where files, shells, and feedback are close.

2026 Connect governed work.

Knowledge-worker agents need remote systems, identity, and durable control.

The scarce resource is no longer a tool call. It is a trustworthy path from intent to enterprise action.

A mature agent should not force every task through one connection shape. It should select the lane that preserves the most useful semantics with the least friction.

Choose by the shape of the work

Skills

Portable instructions, domain knowledge, examples, and reusable procedures that tell the agent how to work.

Best for: know-how + repeatability

CLI / computer

Direct, sandboxed action where the filesystem, shell, and familiar local tools already express the task well.

Best for: local + file-shaped work

MCP

A shared protocol for tools, resources, Apps, Tasks, authorization, and rich interaction across clients.

Best for: remote + governed semantics
Agentic HarnessRoutes · constrains · observes

In the harness Deyaf packages, the connection question starts with customers: the same assistant and the same library behind every door, with only the delivery changing.

One assistant, every way in ↗

Loading every tool definition before the model understands the job is the connectivity equivalent of opening every drawer in a workshop. The agent sees more—and understands less.

Anthropic’s engineering guidance describes two complementary moves: discover tools only when needed, then use code to compose calls and filter intermediate results before they enter model context.

drive.searchLoaded for task
crm.updateLoaded for task
calendar.*Deferred
finance.*Deferred
support.*Deferred

Search, then load.

The harness begins with a capability index, loads only relevant definitions, and keeps unused systems out of the working context.

Definitions in context: 3 of 6

find("customer notes") → drive.search → crm.update

Call-by-call

Model→Tool
Model→Tool
Model→Tool

Each decision returns through the model loop.

Code mode

const notes = await drive.search(q)
const open = notes.filter(relevant)
await crm.update(open)
return summary(open)

Control flow and filtering stay inside the execution environment.

MCP provides reach. The harness makes that reach economical and governable.

Deyaf packages the harness that already runs Eve at Feniex. In it, the model is one step of four: listen, look it up, check the rules, reply.

The model is one step of four ↗

A one-to-one REST wrapper can technically expose an API while still giving the agent a poor operating surface. Good tools compress low-level calls into meaningful work and preserve the interaction patterns a person would recognize.

Decision REST-shaped wrapper Agent-first server
Tool surface

One tool per endpoint; the model reconstructs the workflow.

A smaller set of tools named for meaningful outcomes.

Granularity

Many chatty, low-level round trips.

High-value operations with code composition where useful.

Human input

Hidden outside the protocol or improvised in text.

Elicitation, approvals, or MCP Apps when interaction matters.

Long work

A request waits, times out, or loses state.

Tasks expose a durable, cancellable lifecycle.

If the tool surface would frustrate a human operator, it will probably confuse an agent too.

Since the Medium article appeared in April, official MCP updates have settled which parts of the 2026 connection layer landed in the core specification, which became extensions, and which remain separate efforts.

Apr 19, 2026

The connectivity thesis

Anand Topu publishes the source analysis: Skills + MCP + CLI, progressive discovery, agent-first servers, and production connectivity.

Source analysis
May 21, 2026

2026-07-28 release candidate locked

The official RC introduces a stateless core, first-class extensions, MCP Apps, a redesigned Tasks extension, authorization hardening, and a deprecation policy.

Release candidate
Jun 18, 2026

Enterprise-managed authorization becomes stable

The EMA extension enables organization-controlled MCP access through an identity provider, reducing per-server onboarding and centralizing policy.

Stable extension
Jul 28, 2026

The 2026-07-28 specification ships

The final specification makes the core stateless and adds multi round-trip requests, header-based routing, and cacheable list results. Tasks moves out of the core into an extension, beside MCP Apps and enterprise-managed authorization.

Final

The official 2026 roadmap prioritizes transport scalability, agent communication, governance, and enterprise readiness. The release-candidate announcement showed how quickly several of those priorities moved into an implementable shape, and the July 28 release made several of them final.

MCP reduces the cost of connecting agents to systems. It does not decide who may act, what should be loaded, how risk is escalated, or what counts as complete. Those are harness decisions, and they expand with organizational complexity.

Illustrative example

One governed connection layer across growing teams.

A mid-market harness benefits from reusable skills, shared identity, environment-aware permissions, and traces that show how work crossed systems.

  • Reusable Skills for repeatable operating procedures
  • Central identity and role-aware connector access
  • Progressive discovery across a growing tool estate
  • Traces, approvals, and recovery for cross-system work
These scenarios illustrate architecture choices; they are not customer outcome claims. Start with one good job, then grow ↗
The harness control loop, as it runs in Eve
Understand intentIn EveFive languages in; one English library searched.
Discover capabilityIn EveFour public actions on her tool list. Nothing else is offered.
Check authorityIn EveThe model never picks the account or where a reply goes.
Execute + observeIn EveChecks the record before any exact price or warranty claim.
Verify outcomeIn EveSays only what the result proves: saved is not sent.

Everything above is architecture. Eve is what it looks like with a customer on the other end: Feniex’s assistant, in production, helping people choose equipment, make a buying decision, or get support for equipment they already own.

Eve runs on the Agentic Harness Deyaf packages: her knowledge, memory, doors, rules and learning loop. An Agentic Harness is everything around the AI model: what the assistant knows, what it remembers, where it meets customers, what it may do, and how your team teaches it. MCP answers one slice of that, how an agent reaches a system. The harness behind Eve answers the rest.

Field plate / 02Mood illustration
Overhead view of a wiring-harness board on cream graph paper: five coiled cable bundles in rust, teal and mustard, pinned along a pencilled outline, braid into one trunk that ends in a single dark connector block.
Many lines, one tidy trunk. An illustration only: the working parts are listed below.
Who she is

A knowledgeable customer desk.

Feniex’s warm, composed public face (Feniex is said like “Phoenix”). She answers first, offers one useful next step, then stops. She is software with a named personality, not a person.

Meet Eve, Feniex’s assistant ↗
What she knows

One library, checked first.

A versioned reference layer of catalog, manual, software, fitment and policy records, plus reviewed lessons. A convincing product name is not evidence: she checks the record before any exact product, compatibility, warranty or price claim.

Where customers reach her

One Eve. Every door.

Website chat and voice, phone, text and email, in five languages. On the phone she is the overflow line: the team’s phones ring first, and she answers when no one is free or the office is closed.

Every door, the same library ↗
What she may do

Four public actions.

Look something up, search the taught library, take a message, record an unanswered question. She claims no authority to approve returns, change accounts or place orders.

Answering is not acting ↗
When she doesn’t know

Unknown stays unknown.

The question becomes a durable unanswered item and, when contact details are available, a support ticket. She says it is with the support team only once the ticket is confirmed. No transfers, by design.

What happens when she doesn’t know ↗
What she remembers

Four kinds of memory.

This conversation, one operator-readable record, short customer notes and her library. Orders, shipments and balances are always looked up fresh, never recalled from notes.

Four kinds of memory, each with one job ↗

She is measured, not promised. On 100 fixed test questions, graded September 23, 2026:

86%Handled well
10%Material error
0Critical errors

As of September 24, 2026 · Feniex’s internal Eve 3.0 report · machine-judged and provisional. Eve’s report card, weak spots included ↗

When she cannot answer, a person answers once; the answer is checked, then taught. She is measured on a frozen test set before and after, and only explicitly approved lessons are published. The loop that makes her better is supervised, not training on every raw conversation.

Saved is not sent. Sent is not resolved. The harness lets her say only what the result proves.

Every connection in this briefing runs out of sight. A customer judges the whole system by the two doors in front of them, and for Eve those doors are small on purpose.

Where the harness meets a customer

The chat box

Streaming text, with the page and product context riding along, structured product tiles, and a history bounded to this conversation.

She answers first, gives one useful next step, then stops. She checks the exact record before any product, warranty or price claim, and never pretends to be a person.

The phone line

The team’s phones ring first. When no one is free or the office is closed, Eve answers instead of voicemail: “Hello, this is Eve, Feniex’s intelligence. How can I help you?”

She is never silent: “One moment” after about 1.5 seconds, “Still checking” about every 4. Callers in Spanish, French or Portuguese hear that language’s own voice.

The hand-off

No transfers, by design. Routing in is overflow: the team first, then Eve. Routing out is a hand-off of details: a name and number for the team.

In chat, an unanswered question becomes a durable item, and a ticket when contact details are there. She says “with the support team” only once it is confirmed accepted.

Agentic HarnessSame identity · same library · same rules

Chat, website voice, phone, text and email read from one library under one set of rules. Only the delivery changes.

One assistant, every way in ↗

The Deyaf bridge

Connect the agent. Govern the work.

MCP can standardize how systems expose capability. The harness decides what an assistant knows, what it may do, and when a person takes over. Deyaf is built from Eve, Feniex’s assistant, who already answers customers at every door. Deyaf’s early-access builder lets your business set up its own; live doors switch on one at a time.

Build your assistant ↗