Every founder I talk to right now believes they need to build agents. It's the assumed unit of progress. If you're serious about AI, you're building agents; if you're not building agents, you're playing with chatbots.
I've spent two years building an AI-native company — a services business and a software product, both built on AI from the first line. Somewhere north of six thousand hours. In that time I have built exactly one autonomous agent system. We ran it for about three weeks and then quietly stopped using it.
I want to be precise about what I mean, because "I don't build agents" is the kind of claim that falls apart under a definition. I run headless Claude Code sessions. I run skills that call MCP tools which write into live systems. By the common definition — a model in a loop with tools — I build those things constantly.
What I stopped building is the unattended kind. The kind that owns its own loop and reports back when it's done.
The agent isn't a capability. It's a maintenance contract.
What is context engineering?
Context engineering is the discipline of structuring what a model knows before and during a task, rather than trying to make the model itself smarter or more autonomous. Anthropic's engineering team frames it as curating the smallest set of high-signal context that lets the model do the job. In practice, it splits cleanly in two.
Procedural context is loaded ahead of the work. It's the how: how we do things here, who you are for this task, what good looks like, what we're trying to achieve. It lives on the client side, in skills and system prompts and frameworks. You write it.
Data context is retrieved during the work. It's the what: what you have to work with, what's true right now, and — the part most people miss — what intelligence exists in your business that a general model has no way to possess. It lives in the source system. MCP serves it.
The model sits between them. It supplies the reasoning. It supplies nothing else.
The order matters more than people expect. Procedural context goes first, because it puts the model in the right headspace before it touches a single record. Handing a model a pile of retrieved data without telling it who it's being is how you get fluent, confident, off-target output.
If that feels abstract, use the onboarding analogy. When a new sales rep starts, you don't hand them a CRM login and wish them luck. You give them the playbook first — how we sell, who we sell to, what a good discovery call sounds like, what we never say. Then you give them the pipeline: the accounts, the open opportunities, the contacts. The playbook is procedural. The pipeline is data. Give someone one without the other and you get a confident person doing the wrong thing quickly.
That's the whole architecture. Everything below is what happened when I tested it against the alternative.
We built an agent. What actually happened?
In March 2026 my CTO and I wrote a full agent implementation plan for our development process. Not a prototype — a real spec, version 1.0, seven weeks across four phases with a human gate before each one.
The architecture had three agents. A backlog agent that read raw tickets, explored the codebase, checked the database schema, and wrote structured requirements. A dev agent that picked up assigned tickets in headless Claude Code, created a branch, implemented the fix, and opened a PR. A doc writer agent that cleaned up completed implementation plans for the knowledge base.
We were not naive about it. The plan specified read-only deploy keys, a bot account that could only push to agent/* branches, a whitelisted tool set, no production database writes, and an instruction to stop and flag rather than assume when requirements were ambiguous. Six human checkpoints were defined as never-automated, including the merge to main. Estimated spend was $80–280 a month.
We built it. It worked, in the sense that it did what the spec said.
We used it for about three weeks.
It didn't fail dramatically. Nothing caught fire. It just didn't save us much time — and once we'd built out our MCP layer, working with a human in the loop turned out to be roughly 90% as fast as letting the agent run unattended.
Why did human-in-the-loop win?
Because that last 10% bought something the agent couldn't: I never had to go back and review the work.
This is the part I didn't anticipate, and it's the finding I'd most want another founder to take from this. Agent output doesn't remove the work. It defers the work into review. And review-after-the-fact is a worse trade than it looks, because you're reconstructing decisions you weren't present for, on code you didn't watch get written, without the context that would have told you which choices were load-bearing.
When you're in the loop during execution, you're reviewing as you execute. The two activities collapse into one. The time I would have spent auditing agent PRs turned out to be roughly the time I spent doing the work alongside the model in the first place — except at the end of it I actually understood the change.
Agent output creates a review debt roughly equal to the work it saved.
And the results were better. Not marginally. Being present in the process meant catching the thing that was technically correct and strategically wrong, which is most of what goes wrong in a small company shipping fast.
Anthropic's own guidance in Building Effective Agents points the same direction — find the simplest thing that works, and reach for agentic autonomy only when the task genuinely requires it. I'd add the operational version: the maintenance and review burden of an autonomous agent is a real line item, and almost nobody prices it before they build.
I'm not telling you never to build one. I'm telling you that "we should build an agent" is a conclusion, and most teams are treating it as a premise.
What actually replaced it?
Context. Specifically, five things, in rough order of how much they mattered:
- → Skill orchestration. Procedural context, written down once, versioned, and loaded when relevant. The judgment lives in the document instead of in whoever happens to be prompting that day — I've made the longer argument for where the reasoning lives separately.
- → The procedural/data split. Knowing which half of the context a given piece of knowledge belongs to — and never mixing them.
- → Databases. Not glamorous. The single highest-leverage thing we did was model our data so that an LLM could understand why one record relates to another, not just that it does.
- → DevOps. Understanding deployment, environments, and permissions well enough to know what an AI system should never be allowed to touch.
- → Knowing when a problem needs code and when it needs reasoning. This one deserves its own piece, and it'll get one.
None of that is agent building. All of it is context engineering.
Why shouldn't procedure live in an MCP?
This is the rule I'd most want to hand to someone starting today, and it took me a while to arrive at.
An MCP server should expose two things: what is true, and what you can do to the system. It should never carry how to think about it.
The moment you write methodology into a server — "when summarizing a customer call, always lead with the objection" — you've hard-coded reasoning into a layer that can't see the situation. That same server is going to get called for a dozen different jobs by a dozen different clients, and your embedded procedure will be wrong for eleven of them. Procedure is situational, so it belongs on the client side, where it can change per task. Truth isn't situational, so it belongs at the source.
Here's the version of that rule I can point at. Our own MCP server exposes twelve tools. Nine of them retrieve — quotes, interviews, contacts, companies, assets, account context, plus a planner-driven strategic search that traverses the relationships between them. Three of them let a user view an asset or create one.
Not one of them tells the model how to write a case study, how to position a product, or what makes a quote good. All of that lives in skills, on the client side, where I can change it for a specific client without redeploying anything.
That's the rule enforced in production. If you look at our server and can't find the methodology, that's the point.
What happens when every system of record becomes an MCP?
This is the shift that's actually underway, and it's less discussed than agents because it's less exciting.
Before MCP, every AI integration was bespoke. Now the systems your company already runs on — Salesforce, HubSpot, Jira, Linear, GitHub, Stripe, Snowflake, Google Drive, Gong — are becoming addressable context layers that any model can query without a custom build.
If you want to see which GTM systems already expose serious MCP surfaces — and which are still shipping brochureware — we scored 14 of them, startup-weighted, in our report on the best MCP tools for startups.
That produces an asymmetry that nobody has named clearly enough:
Functions with a good system of record get a step change from AI. Functions without one get fluent guessing.
Finance has a system of record. Engineering has one. Support has one. Sales operations has one. Each of those functions is about to get very good AI, because there is a structured, current, queryable source of truth underneath the reasoning.
Product marketing does not have one.
Picture the session most of our client work actually runs in:
Why doesn't product marketing have a system of record?
First, the term, because I'm not assuming you carry the title. Product marketing is work every startup does whether anyone owns it or not: deciding what you say the product is, who it's for, why it wins, and what actually made customers buy. At most startups it lives with the founder until the first marketing hire inherits it. It's the messaging — and the customer voice that's supposed to sit underneath it.
There's a structural reason that work has no system of record, and it's worth understanding because it explains why the gap persists rather than closing on its own.
Every system of record that exists got built as a byproduct of doing the work. You cannot close a deal without touching the CRM. You cannot ship code without touching the repo. You cannot invoice without touching the billing system. The forcing function is the work itself, so the data accumulates whether anyone intends it to or not.
You can run product marketing for three years and never once record why a customer actually bought.
There's no forcing function, so the data never accumulates. And it's worse than simple absence, because there's a decoy sitting right there: the CRM looks like the marketing system of record.
It isn't. A CRM records the transaction, not the reasoning. Closed-Won tells you what happened. It doesn't tell you what the buyer was afraid of, what they'd tried before, what finally made it obvious, or the specific phrase they used to describe the problem — the one your product team has never said out loud. That reasoning is exactly what win-loss analysis exists to capture, and it's telling that it lives in a separate tool category from the CRM at all. Call recordings hold some of it, but they're structured for coaching and compliance, not for messaging. The evidence exists as exhaust — scattered across the calls and tickets that voice-of-customer software tries to mine after the fact. It never becomes an asset.
That bottom lane in the diagram is the part we had to build — for ourselves first, then for clients. Here's what building it actually looked like.
A messaging framework is procedural context. Here's how we filled its slots.
A value messaging framework — positioning statement, ICP, differentiators, value pillars, proof points, objection handling — is procedural context. It's a "how to think and how to say it" artifact, exactly the sort of thing you load ahead of the work. And most companies fill its slots with internal assumption: what the founder believes, what product wishes were true, what a competitor's homepage said, what sounded good in the offsite.
Perfect procedural context. Fabricated data context.
So when we built our own messaging stack — for Proofmap first, then as the thing we run for clients — we split it along the same line as everything else in this piece.
The framework became a skill. The structure of the argument, what each slot means, what counts as evidence, what we never claim — written down once, versioned, loaded at the start of any session that touches positioning. That's the procedural half, and it lives on the client side like all procedure should.
The slots fill from the record. The data half is a proof of record: stakeholder interviews captured on video, dual-consent, attributable to a name and a title — structured so the relationships between a buyer, their objection, and their outcome mean something, and served to the session over MCP. When positioning work starts, the model doesn't reach for what we believe about our differentiators. It queries what buyers actually said about them, and the output carries the quote it drew from.
An empty slot is a finding. This is the part I'd defend hardest. When retrieval comes back with nothing — no customer has ever said the thing a slot claims — the slot doesn't get filled with plausible copy. It gets flagged. That differentiator is now an assumption, on the record as one, and it becomes an interview question instead of a headline.
Why this strict? Because of what happens at volume. A framework filled by assumption was survivable when a human carried it around in their head, because humans hedge. A good rep notices a line isn't landing and adjusts mid-sentence. The framework was always a little wrong, and the humans running it quietly corrected for it in real time.
A language model does none of that. It takes the guess and renders it fluently, consistently, across every channel, at volume, forever.
The framework was always a little wrong. AI makes it reliably wrong, everywhere, at once.
That's not an AI problem. The model is doing exactly what you asked. It's a data context problem in the one function that never built a place to keep its data.
The diagnostic
If you want to know whether any of this applies to you, don't audit your AI stack. Audit your context — both halves of it.
The procedural half. How much of "how we do things here" is written down somewhere a model can load it? Not in someone's head, not in a deck nobody opens — written, versioned, loadable. If your best prompter leaving tomorrow would take the output quality with them, the judgment lives in a person, not in your context layer.
The data half. For the claims your company runs on, can you trace each one to a source system a model could query? Deals trace to the CRM and code traces to the repo — those are easy. The test that bites is the messaging framework, the doc your team actually works from: for each claim in it, can you name the customer who said it, when they said it, and in what words?
If the answer is mostly yes on both counts, you have a context layer, and you should be pointing every model you own at it — including an agent, if the task genuinely earns one.
If the answer is no, you don't have a model problem or an agent problem. You have a context problem — and every tool you buy this year will faithfully amplify whichever half is missing.
That's the audit. It takes about twenty minutes and it's the most useful twenty minutes I know of in this category right now.
I write about building an AI-native company at Proofmap. The diagram above is free to use with attribution.
