Build for AI, Not Just With AI

A prospect who would have called your work impossible eighteen months ago now opens the sales conversation by saying they'll build it themselves this weekend. They will have something running in an hour. It will be wrong in ways they won't discover for two months.

That is the shape of the market right now: delivery has never been cheaper, and selling that delivery has never been harder. The same tool that compressed your build time convinced your buyer that build time was the whole product.

The takeaway: AI cut your delivery time and handed your buyer a plausible-looking version of your product in an hour. Competing on build speed is a losing race. The move is to build for AI — publish an MCP so your service is reachable from inside the tools your customers already work in, and pick a stack your AI can operate directly. Then sell the part the artifact can't do: verification.

What follows are notes from this week's Executive AI Roundtable discussion, shared under the Chatham House Rule.

Your Champion Is Now Your Competitor

Execution has gotten cheap and distribution has gotten expensive, at the same time, for the same reason. One operator put the past few months this way: "the work has never been easier in terms of execution and automation and scalability, but then sales and marketing is also much harder, more confusing." Their conclusion was the uncomfortable one: "in a way, we were further ahead" a year ago — the work was harder, but nobody showed up to the demo with a competing prototype.

The mechanism is specific. Custom reporting and data-ingestion work that used to end the objection now starts one. "A year or two ago, some of the custom reporting and dashboard and data ingestion stuff that we were doing, there's no question, nobody would even attempt to do this themselves. They'd be like, that's impossible, you've done all the API stuff, you've done all the data — it wouldn't even enter their mind. But now that's a serious sales objection."

The prospect who never buys is the smaller worry. Watch instead for who inside the account has changed sides. The person who used to champion the purchase is now the person who gets credit for avoiding it. In the room's words: the champion "is the same person who probably feels like a superhero, and when they fire up Claude and spin up some artifact and some little vibe-coded thing, they look amazing in their company." Your internal advocate has a cheaper, faster way to be the hero, and it doesn't involve your invoice.

That resets the bar rather than removing it. "We have to be 10 times better," one operator said — more depth, more granularity, more filtering, an actual product opinion about what the customer should be measuring — "and we have to be able to do it in 24 hours. Still not as fast as an hour, but it can't be 30 days."

And you deliver all of that without being paid a premium for it, because the depth is invisible until something breaks. Buyers are "not going to appreciate the nuance and difference, and be willing to pay for it, and give up the direct dopamine hit of Claude" — so you have to deliver it anyway. It's becoming table stakes.

Ten times the product, in a thirtieth of the time, against a competitor who is free and already inside the building.

Build For AI: Your Product Needs an MCP Front Door

The reframe that cut through this came in five words: not just building with AI, but building for AI.

Everyone in the market has spent two years on the first half — using AI to write code, draft copy, compress delivery. The second half is the one most companies haven't started. Your customer no longer wants to visit your interface. They want to reach your service from inside whatever tool they already have open. That means your product needs a front door an AI can walk through, which today means an MCP server.

The pressure this creates is real, and it was named plainly: "It's easier than ever to build stuff, but now we have five more interfaces. You need to have an MCP, you have to have a CLI, you have to have whatever other kind of interfaces that they want. People now expect there's a dozen new workflows."

Plenty of operators have already lived through the precedent. "It's like when the mobile phone came out, and all of a sudden we had to do responsive design, and every website also had to have an iPhone app on the App Store. We're kind of in that space." Nobody built an iPhone app back then because it was strategically elegant. They built it because customers stopped accepting a website-only answer.

What the MCP buys you is context the generic connector doesn't have. A customer might check a dashboard every Monday, but at 11pm on a Thursday they want to ask Claude who's behind on their tasks. That query can go to a generic Asana MCP and get a thin answer, or it can go to your MCP — the one that reaches your full historical dataset and carries context about their business and the people who work there.

The mercy is that the bar for a first version sits far lower than it looks. "My general experience with a pretty bad MCP is an amazing experience to most people." Descriptions can be mediocre, discoverability can be so-so, because users are still in the phase of asking for things by name — I want to use X for Y — and being delighted when it works. Getting from nothing to something is the step change. Getting from something to excellent is a smaller jump than it will ever be again.

And it is less work than the thing it replaces. "The engineering previously was: okay, you gotta make an app, and the app's gonna have 50 screens, and it's going to have all these different ways you're interacting with people." Now the interface is the assistant. You ship the capability and skip the screens.

Let Them Try It — and Be There in Two Months

Arguing a buyer out of the do-it-yourself build doesn't work, because the failure hasn't happened yet. So one operator has stopped arguing: "Okay, go try it, and can I check in with you in a month or two and see how that's going?" They're clear-eyed about the cost — "which is not ideal in a sales process, but I think there's people that I'm gonna lose anyway."

It works because the vibe-coded version breaks on the second question, not the first. The first question — show me revenue by month — is a pie chart. The second question is where the engineering lives:

• Volume. Pulling five years of history and slicing it by person, monthly and quarterly, runs into API rate limits the demo never touched.
• Data you can't get on demand. "If you want to get every comment for every task, you have to get it one by one, so you really do have to do data extraction and then do your analysis separately." That's a pipeline, not a prompt.
• Wrong numbers that look right. "As soon as Claude spits up a few pie charts and some graphs that look nice, they think it's done, but the devil is in all these details. I've seen it hallucinate data, which is way worse than having no data is having wrong data."

None of those limits are visible in hour one. "They don't know any of those limits" — and the education has to happen before the invoice. Winning that argument up front is, in one operator's words, "kind of a losing battle."

Some of those buyers do come back. I've seen companies where a prospect walked away to build it with AI and returned three months later saying, in effect, you know what, I don't like doing my own laundry — we're going to cancel our AI project and pay you to do the maintenance work.

Do you want to be in the laundry business? is the question worth putting to a buyer, and to yourself. Joel Spolsky's rule from In Defense of Not-Invented-Here Syndrome still holds: if it's a core business function, do it yourself, no matter what — and if it isn't, don't. Anything you build with AI still has maintenance. Security issues, API changes, and the fact that the AI itself changes every week. If you couldn't run that thing as a business, you probably shouldn't be running it as a side project.

Which is why I keep pushing back on one specific pattern I've seen a lot of lately: companies building their own CRM. You're not in the CRM business. Why are you building a CRM? You'll spend your attention making your CRM better instead of making your product better.

The analogy I use is the car. You have a Mercedes. Are you going to change the oil yourself in your garage, or are you going to pay $600 to have the dealership do it? Most people don't hesitate. But when it comes to software, they think they can change their own oil, because they have AI.

The counter-move is to give the buyer the drill-down. If they're going to keep the artifact, insist it be checkable: "you should be able to verify every single number, and you should QA it." Verification is the thing the one-hour version cannot fake, and it's the thing you can sell. For the full playbook on this objection, see addressing the vibe-coding objection.

Budget Engineering to Get Past the Chat Layer

Those of us using Claude Code and Codex in a terminal all day live in a bubble. Go look at what a normal team has, and the drop is steep. Projects in Claude Team or Claude Enterprise are a lot less powerful, and workflows that look obvious from the terminal turn out to be hard to assemble. It's trapping a lot of businesses at the chat layer.

Here's a concrete version. You want your senior leadership team collaborating around a common set of documents, with AI answering questions against them. The documentation makes it sound like a settings change. In practice the built-in connectors are the weak link — the Claude Desktop Google Drive connector seems to struggle just finding the files. A C-suite that keeps a few Word docs, a deck, and a spreadsheet in Google Drive or Microsoft 365 does not have a working path to this out of the box.

This is what MCP is for: it "allows you to have things like go talk to your firm's internal resources," and it's how "you fill in all the gaps of — wait, it doesn't work with X. You make an MCP, that's a relatively short amount of time, and the experience of the client's magical."

Which means somebody has to build it. That's the part leaders keep discovering late: getting a team past chat requires engineering, even though the promise was that it wouldn't.

The second half is harder and less solved. Resources are one thing; triggers are the other, and nobody has done them well yet. The framing that stuck was two kinds of trigger: the user pulls (ask Claude a question, get an answer from your systems), and something outside the user pushes (a schedule, an event, a cron job). Getting scheduled automations to run through the same tools your people already use is "pretty jankily implemented in the current harnesses," and what exists is built one-per-user, not at a team or institutional level.

Two consequences for a CEO. First, while a market moves this fast, "there's more money to be made in services than product. When markets move fast, there's more money in services. And when markets start to stabilize, there's more money in product." Second — and this is the one I find uncomfortable as an advisor — the pace makes it hard to hand a client a finished thing and walk away. My preference is to set an organization up and leave it self-sufficient. With AI tooling changing weekly, a ten-person company may simply not have anyone who can maintain what you built. The productivity on offer really is immense, and large enterprises are still years from being able to absorb it. Those two facts don't cancel; you have to plan around both.

If you're trying to work out which tier actually unlocks what, Claude Team vs Pro vs Enterprise walks through the differences.

Pick a Stack Your AI Can Edit

"Building for AI" has a second meaning that's easy to miss: the tools you run should be ones your AI can operate directly. A marketing site is the clearest case, and the example on the table was porting a site to Astro and managing it with Claude.

Astro is an open-source framework for content-driven sites — "basically like WordPress, but without all the crap we hate about WordPress." It sits in the same family as Hugo, Jekyll, and Gatsby, and it gives you the structure a real site needs: component libraries, plus taxonomies, tags, relationships, post types, and templates. You define a blog-post template, every post uses it, and the one page that needs to be different can be custom. In January 2026 the Astro team joined Cloudflare; the framework stays open source.

Three properties explain why it keeps coming up.

It's static, and that's the point. Pages are files on a file system, not rows in a MySQL database being assembled by PHP on every request. Astro's own design goal is that "it should be impossible to build a slow website in Astro," and it ships zero JavaScript by default. For dynamic pieces — a signup form, a survey, anything that needs a server — it uses what Astro calls islands — isolated interactive components that load their own JavaScript while the rest of the page stays static HTML. Anything needing a server (a form handler, a database call) goes to a server endpoint or an edge worker. You get dynamic behavior where you need it without paying for it everywhere else.

The attack surface mostly isn't there. "Astro is so fast and so much more secure. You don't have SQL injection or PHP injection or anything — there is no runtime." A static file has no database to inject into and no plugin ecosystem to patch on a Tuesday.

An AI can edit it. A site that lives as files in a repository is a site Claude can read, change, preview, and deploy. A site that lives behind a CMS admin panel is a site an AI has to click through. One operator reported doing "10 times more marketing in the last two months" after the switch, simply because the friction was gone. I run the same pattern here — these pages are plain files deployed to Google App Engine, and Claude can do whatever it needs to with them.

The prediction that came with it: "There's going to be a mass exodus from WordPress, Squarespace, Webflow, Wix, Weebly. The old CMS page builder model is so broken and so pointless for so many sites" — said by someone who spent years in the WordPress community and liked it. I logged into a WordPress admin recently for the first time in years and felt like I'd been dropped back in 2007.

The cost is real and lands on the person you least want to inconvenience. When one operator finished the migration, their marketing lead's immediate reaction was to ask how on earth they were supposed to edit the site now. That's the trade: you gain a codebase your AI can drive, and you take away the click-to-edit box from the teammate who edits the most. Solve that before you migrate, not after — otherwise you've optimized the site for the one person who was never the bottleneck.

Push Work to Subagents Before Compaction Eats Your Process

Long-running AI tasks fail in a specific way that most operators misdiagnose as the model getting dumber.

When a model fills its context window, the harness compacts — it summarizes what came before to make room. As one operator put it: "as soon as it compacted, it acted like an amnesiac." Not because it lost everything, but because of what compaction leaves behind. "It's like a book you read five years ago, and you go, oh, I don't need to read that again, because I read it five years ago. Only the outline is remaining in your brain." The model concludes it has already read your instructions, so it doesn't go back — and what it retained is a summary.

Which puts the summary in charge of the process: "when that outline is supposed to be the instructions as to how we do business, that's a problem."

I've been hitting the same wall from the other side. I'll put the process in a CLAUDE.md — this is how we want you to do things — and it holds for a few rounds, then loses its mind. I've been hunting for a more deterministic way to make it follow the workflow I actually want.

The tempting fix is orchestration: graph builders like Langflow or Flowise that let you draw the workflow as a diagram. The verdict was blunt — those are "very, very 2025 solutions," and "this idea of graph engineering flounders on the engineering part." You end up maintaining a diagram instead of shipping work.

The simpler answer is delegation. "What I'm finding increasingly is just use subagents. Wait, you got something to do? Send it to a subagent." No roles, no graph, no complexity. The research happens in the subagent's context; only the answer comes back into yours. "Even if all you're doing is waiting for the subagent, that allows you to use context better, because you don't wind up with the context pollution." Your main thread stays short enough that compaction never has to touch the instructions.

Models are getting harder to steer for a structural reason. The labs are tuning against several traits at once — call them intelligence, judgment, and persistence — and persistence is what pushes against the other two. Persistence is what lets a model run for an hour instead of quitting after two steps. It's also what makes it march forward on a bad approach. "Dogged persistence can crowd out judgment. You're not doing it the smart way, because you keep on trying, you're just marching forward." The aside that followed: how many times have I seen that in a founder, too?

If you're thinking about how to structure delegation across multiple agents, your AI agents need an org chart covers the same ground from the management side.

Reprice for the Customers AI Doesn't Take

This one shows up in your numbers before you have a name for it.

AI doesn't take your hardest customers. It takes your easiest ones. The casual user who bought the high-end package but only needed a few charts a month can now get those charts from an artifact. The demanding customer who needs five years of history sliced six ways still can't.

"The good news is AI doesn't compete for those customers. The bad news is it's a smaller set, and those customers previously were free-riding off the payments of the other guys."

That is a pricing problem, not a churn problem. The casual tier wasn't a low-margin nuisance; it was cross-subsidizing the service you give your best accounts. Lose it and the arithmetic changes: "you have fewer customers. Now you need to charge them higher prices. You haven't been charging them higher prices. That becomes new market friction." What looks like AI eroding demand is often AI removing a subsidy — micro-segmentation, splitting one blended price into the two very different products it was always hiding.

Underneath all of it is the constraint that doesn't move. There's a reason a company that gets past a certain number of customers hires more people: one person can only hold so much in their mind. Even with a model smarter than the smartest human who ever lived, someone has to tell it what to do, and someone has to notice when the output isn't what they meant and say so. There is not enough attention in the world to do everything. Whatever AI gives you, it does not give you more of that — which is exactly why offloading judgment-free work to it matters, and why the judgment work is what you should be charging for.

Where to Start

• Audit your front door. List the tools your customers work in all day. If your service can't be reached from inside them, scope an MCP — a rough one beats none, and the first version is smaller than an app.
• Change your answer to the do-it-yourself objection. Stop defending. Let them try it, book the follow-up for 60 days out, and use the interval to prepare the second-question answer: rate limits, data that can't be pulled on demand, numbers that need verifying.
• Apply the laundry test to your own roadmap. Anything you're building that you couldn't run as a business — start with the CRM — hand back to a vendor and reclaim the attention.
• Budget for the engineering that gets your team past chat. Assume the built-in connectors won't carry a real document set, and staff or contract accordingly.
• Move your marketing site to something your AI can edit — and solve the non-technical editing path in the same project, before your marketing lead discovers it's gone.
• Delegate long tasks to subagents so your process instructions never reach the compaction boundary. Check that the model still follows your written process late in a session, not just early.
• Reprice before the subsidy disappears. Identify which customers AI can now serve, and set prices for the remainder that don't assume the volume you're about to lose.

Resources From the Roundtable

• Astro — open-source framework for content-driven sites; static by default, with "islands" for interactive pieces. The team joined Cloudflare in January 2026 and the framework remains open source.
• Model Context Protocol — the standard for exposing your service to AI assistants; introduced by Anthropic and since adopted across the major providers.
• Hugo, Jekyll, Gatsby — the static-site generators Astro was compared to.
• Langflow and Flowise — visual graph builders for AI workflows, both spun out of the LangChain ecosystem and both judged past their moment.
• Claude Code and Codex — the terminal-based coding agents that define the "bubble" most business users aren't in.
• Cloudflare — hosting and edge platform, and now Astro's corporate home.
• Asana — cited as an example of a vendor MCP that answers the easy question but not the hard one.
• In Defense of Not-Invented-Here Syndrome — Joel Spolsky, 2001. The core-competency rule behind the laundry test: if it's a core business function, do it yourself, no matter what.
• Bending Spoons' agreement to acquire Airtable — August 2026, $1.285B enterprise value. Discussed at the table as the live example of a company with roughly a billion in cash choosing a sale over redeploying it.