Three Waves of Integrating Agentic Experience
Agentic experience reaches the product core in three waves: ship an MCP server, hit the context-engineering ceiling, then move the harness inside the product. A maturity map of what breaks at each stage — and what to build toward.
This post lays out a simple way to think about how agentic experience integrates into your product. Three waves. Each one shifts where the intelligence lives, who controls quality, and what the product actually owns.
These waves aren't strictly sequential in time. They're a maturity curve. Some teams have already moved past Wave 1 and are building toward owned intelligence. Much of the market is still shipping its first MCP server and about to hit the same wall those early movers already hit. If you're ahead, you'll recognize the pattern. If you're catching up, this maps what breaks next and what to build toward.
Wave 1: Hello (Agentic) World
The first thing most companies ship is an MCP server that maps tool calls to REST endpoints. Claude or ChatGPT call the tools, the product receives the writes. The integration is correct. The outcome is inconsistent.
Adding a contact met at a conference to your CRM over MCP. Orchestration is solid, the records are unusable. Placeholder company name, free-text notes stuffed into structured fields, no link between person and company. The model hands back a five-item cleanup list and pushes the hard parts back to the user. The user opens the UI to fix it and blames the product, not the client.
The fix everyone reaches for is shipping context alongside the tools. Passive context loaded at session start, on-demand skills the model pulls in when relevant, live retrieval for changing data. Tell the model how the software works and how the org uses it. Cleanup list shrinks. Quality goes up. This is where most teams are right now in April 2026, and it's also where learning starts to compound.
It works. Until it doesn't.
Wave 2: Context Engineering Hits a Ceiling
Wave 1's answer to inconsistent quality was ship better context. The problem is that context isn't storage, it's an attention budget. Every token loaded displaces another. And the thing managing that budget on every turn isn't your product. It's the harness, the layer around the model that decides what enters context, what stays, what gets summarized, what gets dropped. Whoever owns the harness owns the experience. Once you start taking this seriously, four things become hard to ignore.
- Tool schemas eat the budget before work begins. One MCP server is fine. Ten and the context window is a battlefield. Each ships its own naming conventions, semantics, behavioral notes, and the calling client holds all of them at once. Each one made the others slightly worse.
- Long workflows quietly lose the plot. Short tasks mask this. Multi-step ones expose it. As context fills up, the model gets worse at reasoning over it, the rule it followed perfectly at turn three gets diluted by turn twenty-five, and old tool outputs sit alongside fresh ones with no signal about what's stale. Coding agents that drift produce bad code. Product agents that drift produce business damage.
- Short-term memory is the harness. Within a session, what survives compaction, what gets summarized, what stays verbatim. The harness decides all of it. If your product's intelligence is composed by ChatGPT or Claude on the go, you don't get a vote.
- Long-term memory is also the harness. Across sessions, what the agent remembers about an account, a workflow, a recurring edge case. If the harness is closed, that memory is locked into someone else's platform. The agent might get smarter over time, but the smartness belongs to whoever's harness is doing the remembering.
And the whole thing is a black box. The product sees tool calls in and writes out. It doesn't see what the model reasoned over, where it started drifting, or why a decision produced bad data. When something breaks, you can see the broken record but not the state that produced it.
The industry has good answers to most of this. Dynamic tool loading instead of upfront schema dumps. Progressive disclosure that loads knowledge at the moment of relevance. Compaction to reclaim space. Sub-agents with fresh windows for subtasks. These are real advances and they buy real headroom.
But they're all engineering inside someone else's loop. You can ship the cleverest skills, the tightest schemas, the best AGENTS.md in your category, and you're still optimizing a system whose memory, context management, and observability live with the calling platform. Reasoning quality is rented. The data flywheel belongs to whoever owns the harness.
This is the wall.
Wave 3: The Product Gets Its Own Brain
After enough engineering iterations, teams arrive at the same conclusion. Stop trying to make the external client smarter about your domain. Move the harness inside the product, and let the calling client be a transport layer that hands you intent and gets a quality response back.
The harness is everything that isn't the model. The system prompt, the tools the agent can reach for, what runs around each tool call, the environment the agent works in, what survives compaction, what gets remembered between sessions. When that lives in the calling client, you can't touch any of it. When it lives in your product, all of it is something a team can engineer, test, and improve.
Telemetry and reasoning traces are what unlock everything else. MCP-level telemetry tells you what tools were called and what data went in and out. A reasoning trace is the recording of how the agent got there. What it understood the request to be, what context it pulled in, which options it weighed, why it picked one and ignored the others, where it hesitated, where it corrected itself. The first is a security camera at the door. The second is the deliberation inside the room. Without traces, every other part of the harness is something you change and hope. With them, you can see which specific part failed and fix that part. This is what turns "we shipped an agent" into "we have a feedback loop."
Once you have that loop, four parts of the harness become things you can actually work on.
The four parts you now own
Which tools the agent can reach for, how they're described, when to load which capability, what runs before and after each call, how the agent recovers when something fails. Most agent quality issues you can identify in traces resolve here.
Within a session, what survives compaction, what gets summarized, what stays verbatim. If a long workflow keeps losing the rule it set in step three, traces show you the moment it dropped out and you can ship a fix.
Across sessions, what the agent remembers about an account, a workflow, a recurring edge case. The signal from one interaction informs the next, and it stays with your product instead of with whichever client the user happened to invoke that day. This is also where lock-in flips.
Where the agent's work actually happens. What tools are pre-installed, what the filesystem looks like, what the agent can and can't reach. Also a cost question that often gets ignored. Spinning up a full Linux VM for every session sounds safe until you do the math on a thousand concurrent users. A lot of agent work fits in a V8 isolate that starts in milliseconds. Some genuinely needs a container with a real shell. Almost nothing (except hardcore coding) needs a full VM. Owning the harness means picking the right environment for the task instead of paying for the heaviest option by default.
The result is an actual flywheel. Traces show you which workflows succeed, which inputs are ambiguous, where guardrails are needed. That signal feeds memory and informs the next change to the harness. The system around the model keeps getting better even when the model itself doesn't. Models get commoditized. Accumulated domain intelligence secures the edge.
Building This Is Non-Trivial
The runtime is the easy part. The operational layer around it is where the real engineering lives. How agents start, recover, get configured, stay alive, isolate tenants, manage state across sessions. Most teams underestimate the surface area on the first attempt.
We'll get deeper into the agentic infrastructure challenge in upcoming posts. But for now, here's the list of frameworks, libraries and platforms we've been using or seen leading projects use as a starting point for their journey — each with its own pros and cons from a SaaS CTO/CEO perspective, which we'll cover more thoroughly soon.
The Gap Widens Every Week
Category leaders didn't jump from MCP server to owned agentic system overnight. They shipped the integration, watched what users actually tried to do with it, learned where quality broke down, and built internal knowledge about what good agentic experience looks like for their domain. Then they built their own intelligence layer, informed by months of compounding learning.
A competitor starting today can copy the architecture. They can't copy what shaped it.
Every week your product is live in the agent ecosystem, you accumulate signal that feeds the next wave. Call patterns, failure modes, tool adoption curves, edge cases your documentation doesn't cover. You don't get this from a strategy deck. You get it from shipping and observing.
The companies that started in 2025 have a year of this data already. The gap widens every week.
Your board isn't asking whether AI matters anymore. Your competitors aren't debating whether to ship agent features. The question now is whether the intelligence lives in your product or in someone else's.
Ship the MCP server if you haven't already. Start learning. Start climbing. Time to #playoffense.
A few category leaders worth studying, if you haven't already:
Last updated .