By now, it's nothing new that AI agents are used a lot, whether it's a simple task or the most complicated task. Some are using it as a tool, while some are using AI agents to automate every aspect.

For so many years, we've built products for humans. Every onboarding flow, every tooltip, every "click here to get started" was designed around a person who could read a screen, get confused, poke around, and figure it out. Humans are forgiving users. They infer, they guess, they fill in the gaps you left in your docs.

Agents may not do any of that.

And agents are now a real chunk of who's showing up. Mintlify — one of the biggest documentation platforms — reported in 2026 that nearly half of the traffic to developer docs sites now comes from AI agents like Cursor, Claude Code and ChatGPT, not human browsers. For API-first products, the share is often higher. Read that again: for a lot of tools, the majority of readers of your documentation are now machines.

This isn't a someday thing. It's already happening. So the question to ask now is your product built for it?

What's actually going on in the market

Let me set the scene quickly, because the context matters.

The thing that made all of this possible is a protocol called MCP — the Model Context Protocol. Anthropic introduced it in November 2024 as an open standard for connecting AI models to external tools and data, and then something unusual happened: everyone agreed on it. OpenAI adopted it in early 2025; Google DeepMind followed. In December 2025 Anthropic handed it over to the Linux Foundation's Agentic AI Foundation, so it's now a vendor-neutral standard rather than one company's pet project.

The adoption numbers are genuinely hard to argue with. By early 2026 there were over 10,000 active public MCP servers, and the official SDKs were seeing roughly 97 million downloads a month. It went from one vendor's spec to industry infrastructure in about eighteen months — the web took most of a decade to travel the same distance.

So the plumbing is standardised, the big labs all speak it, and agents are moving from demos into actual production workflows. That's the market.

Now here's the part nobody wants to talk about.

Getting an agent to connect is easier than getting it to do something.

This is the lesson I keep having to relearn while building Garchi CMS, and it's the one I want you to take away from this edition.

In my opinion, building for agents can be split into 2 major parts: connection and conversion/activation, and everyone obsesses over the first one while ignoring the second.

Part 1: Can an agent connect to your product? (connection) This is the plumbing, and yes, it could be difficult, but if you follow the docs, it's pretty straightforward. There's a spec; there are SDKs; documentation; all of these make it easier to create an MCP server.

Part 2: once it's connected, does anything actually happen? (conversion/activation) This is the most important part and one of the most ignored as well. If not done right, this is where products quietly die.

I'll be honest about my own numbers here. When I looked at Garchi's data, a large majority of the people who had connected an MCP token had never actually created anything with it. They'd done the discovery phase — found us, connected, authenticated — and then… nothing.

When we did thorough research, we realised it wasn't a connection problem, but rather it was an activation problem. The agent got in the door and then couldn't figure out what to do next, or hit friction, or didn't have a clear first action — so it did nothing or just went back to the user, where a new user themselves isn't sure what to expect.

Here's why this matters more for agents than it ever did for humans: a confused human hangs around and might navigate their way. They read another page, they try again tomorrow, they email support.

A confused agent keeps it simple and just moves on. There's no frustration, no second visit, no "let me figure this out." If the path from connected to the first useful action isn't smooth, the agent silently gives up, and you never even see it happen.

When we fixed our activation pipeline, we saw the activation rate improve by 8x.

So when I say "build for agents," I don't mainly mean "add an MCP server." I mean: make the road from connected to activated so smooth that an agent with no ability to guess can still succeed on the first try.

Three things that actually move the needle

1. An MCP server — but treat the first-run experience as the product

Yes, you need the MCP server. That's the entry point, and in 2026 it's becoming table stakes rather than a differentiator — most of the tools in a typical stack already have one (Slack, GitHub, Stripe, Notion, Shopify, HubSpot and hundreds more).

But the server getting an agent in is not the win. The win is what happens in the first thirty seconds after.

Think about what an agent needs to succeed on its first call: an obvious first action, clear tool descriptions and annotations that explain themselves, sensible defaults, and errors that tell it how to recover rather than just failing. A human would brute-force past a bad first-run experience. An agent won't. So the real work isn't "expose the tools" — it's designing that first successful action so it's almost impossible to get wrong.

If you build the server and stop there, you've built the door and forgotten the room behind it.

2. Documentation an agent can actually read

Here's a line from the State of Docs Report 2026 that I haven't been able to shake, from Dachary Carey at MongoDB: good for humans is not good for agents. Agents work inside a token budget. They can't skim your beautifully designed docs site, ignore the nav, and intuit what matters. Every bit of page chrome, every clever layout, every "as we discussed above" costs them.

This is why conventions like llms.txt have taken off — a clean, markdown-based file that strips out the CSS and navigation and hands an agent just the structured content it needs. Snowflake, for example, now serves a hierarchical llms.txt and lets you get the markdown version of any docs page just by adding .md to the URL, specifically so agents can pull only the section they need instead of drowning in HTML.

The reframe I'd push you toward: you're not writing more docs, you're writing docs for a reader who cannot infer context and cannot ask a colleague. That means one concept per page, code samples first, plain structure, and — interestingly — FAQ-style question-and-answer formatting, which turns out to be close to ideal for machines because it's a clear question with a clear answer that's trivially parseable.

If an agent can't parse your docs, it doesn't email you for clarification. It returns a wrong answer to your user or skips your product entirely. Same failure mode as before: silent.

3. JSON-LD, so the agent knows what your thing even is

This one feels like an SEO tangent, and it isn't, so stick with me.

When an agent lands on your page, it has to work out what it's looking at. Is this a company? A product? A service? Who makes it? What does it cost? A human reads "$49.99 next to Add to Cart" and just knows. A machine has to infer all of it from messy HTML — and inference means guessing, and guessing means errors.

JSON-LD is structured data you drop into the page that states, unambiguously and in machine-readable form: this is the organisation, this is the product, this is the founder, this is how they connect. It's the difference between an AI system guessing what your business does and knowing it. Sites with properly structured data are meaningfully more likely to be cited in AI search answers than sites relying on raw HTML.

It's the same principle as the docs point, just one layer down. Docs tell an agent how to use your product. JSON-LD tells an agent what your product is before it ever gets that far. Both are removing ambiguity so a reader who can't ask questions doesn't have to guess.

So here's the bet — and here's how people botch it

Building for agents is worth it. Agents are already a huge slice of your traffic; they're becoming a genuine discovery and distribution channel, and the products that are legible to them will get recommended, cited and used while the ones that aren't quietly fall out of the answer.

That's the whole game. Build the door if you like. But spend your real energy on the room behind it.

This is something I'm living through in real time, building Garchi CMS — an agent-native content platform with its own MCP server. The activation numbers I mentioned are mine, and fixing them is most of what I think about right now. If you're wrestling with the same problem on your product, reply and tell me where your agents are getting stuck. I read everything.

— Aditya