I've now run 215 tests of how coding agents choose external services. One thing becoming clear: agents will do the easiest thing (for them) unless asked, and even then they bring a ton of their own priors to your question. Some interesting implications for software distribution.

Related: I've notice our household has diverted spend from Amazon to Walmart since the latter plays nicely with Muse.

If you're building APIs, MCP servers, or skills, your main distribution question is: how do you get an AI agent to choose your service? We've been running controlled experiments with coding agents and have learned some thing about how they "choose." A few early lessons: - Agents are lazy. Agents repeatedly chose keyless workarounds instead of credentialed APIs. Make the path to a successful first call as frictionless as possible. - Context is distribution. One line in AGENTS.md specificying a provider was followed in 100% of trials. Give developers agent-ready instructions they can drop directly into their projects. - Pay attention to how agents frame choices. Even when deferring to humans, agents frequently presented their preferred provider first, sometimes explicitly as "Recommended." - Don't assume agents will somehow magically discover you. Claude Code chose Anthropic 100% of times when asked for the cheapest AI provider. Explicitly telling it to compare alternatives changed the outcome in 80% runs. Being better doesn't help if you're never considered. The emerging lesson: agent-mediated markets won't necessarily reward the objectively "best" service. Before agents can optimize their allocation of resources, something has to determine which resources are available for consideration.

YMMV may vary with "figure out commercialization later." At my last startup this thinking led us to building an awesome tool for an ICP who really loved us but could never ultimately pay us

A big question in agentic commerce: if coding agents are going to become buyers of software, who decides what's on their shopping list? I ran 215 trials and watched. Turns out the modes have some pretty entrenched favorites, even when told to shop around.

When you ask an agent to build something without specifying which services to use, how does it decide? I ran an experiment with Claude Code and Codex. Turns out a lot of the provider decision happens before the agent ever short-lists suggestions.

“ALWAYS use claude-opus-5-5… Never downgrade for cost — that's the user's decision.”

Agentic commerce assumes agents shop. I tested Claude Code: “use the cheapest AI provider” chose Anthropic 5/5 times. Only when told to compare providers did 4/5 leave Anthropic. Optimization, at least here, is downstream of choice-set formation.

One thing I've underestimated about agentic software distribution: the “integration surface” extends well beyond the protocol layer. We integrated the same service into Claude Code, Lovable, Replit, v0 and Bolt. All could access the tools, but the same instructions produced different behavior across them. Instructions live in different places across the platform. Some agents see intermediate UI; some don't. Some platforms inspect tool responses. Some connectors authenticate at install; others behave differently at runtime. We're starting to treat “supports MCP” a little like we once treated “supports HTTP.” Necessary interoperability, but nowhere close to saying the experience actually works. And so there's another compatibility layer emerging above the protocol: how the agent interprets, chooses and operates the service.

Okay one more round: - the agent inside a hosted builder does not search some neutral universe of software: the platform's own integrations often come first - ask for email, storage, auth, etc. and the default may be whatever the builder already provides - this of course is rational. The platform knows that integration works, controls the UX, can support it, and may have economics attached to it - we learend a short saved instruction like "check X first when you need Y" can materially change what the agent chooses - but - where that instruction lives matters a lot - on one builder, conditionally loaded instructions worked fine for capabilities the platform didn't sell/offer natively - for capabilities where the platform had its own competing service, the same instruction lost to the platform default - putting the same text into always-loaded workspace context changed the result in every run I tried - so instructions that load only when the agent decides they're relevant seem to carry less weight than the platform's own defaults, even once they're loaded. On capabilities the platform sells, only always-loaded context beat the default - auth should happen before the agent starts building. Stopping halfway through a build to ask the human to sign in destroys a lot of the magic - fortunately many builders already support OAuth when a connector is added. Authenticate there and the agent knows who it's acting for from the first call - connectors are often installed once per workspace rather than once per project. If your own service assumes one authenticated user = one application, you need another way to keep project identity straight All in all "distribution to agents bit more than exposing an MCP server and waiting for discovery.

Another lesson from testing across hosted AI builders: MCP means every agent can call your service, but it doesn't mean every agent can actually use it. - The same instruction can work perfectly in one environment and fail badly in another: eg "show the user the sign-in link, then wait for them to finish" works fine in a terminal agent that streams output as it works - in a builder that doesn't show anything until the turn finishes, the agent can be patiently waiting for the user while the user is staring at a spinner and never sees the link - "open this link for the user" works on a laptop, but in a hosted agent it runs in a cloud sandbox, where nobody can see it - even setup differs: persistent instructions go into workspace knowledge on one platform, a skill on another, a skill plus switching the connector on in every chat on a third, and one needed nothing at all - then there's where the generated code runs: some builders put your API call in server code; others put it in the browser, which suddenly means CORS matters - redirects that are invisible in your normal setup can fail - generated project structures differ enough that even assumptions like "there will be a src/ directory" aren't safe So there are at least two layers of compatibility: 1 can the agent technically call your tools? 2 does the surrounding environment let the agent use them correctly? MCP helps with 1, but 2 is still hard.

I've been testing what it takes to make an external service work well inside hosted AI builders (Replit, Lovable, etc). Not official integrations for now, just MCP. Some notes on MCP and AX: - on a hosted builder, your MCP tool descriptions are basically your whole onboarding - with Claude Code or another local agent you can ship rules files, project instructions, docs, etc. With hosted builders, you generally can't ship that context yourself; the user has to manually add in a nonobvious UI (and most won't IMO) - that means don't treat tool descriptions like tiny API reference blurbs, biut rather as instructions that explain when the tool should be used, what assumptions to make, what to do before/after calling it, etc. - so “tool description” is a slightly misleading term. In agentic systems it's closer to a compact operating manual attached to the capability - I assumed shorter + cleaner was obviously better. Now I think the measure is decisions per token, not tokens. Guidance that stops the agent from making a wrong call is cheap at almost any length; reference detail the agent could fetch later isn't cheap. - related: keep tool results boring. Results should mostly be data; instructions should live in the description - some platforms inspect tool output and can suppress things that look like commands. If an auth response says something like "end your turn and run open ", there is a nonzero chance the user never sees it - agents take returned fields literally. Don't use false to mean 'we don't know.' If a value is a guess, a default, or extracted by a model, say so in the response, because the agent will treat it as a rule. - this matters more than it sounds. A human might skim past a weird field. An agent may use it as a hard constraint and decide not to use your service at all - they cross-check you against yourself. If your tool description defines a term and your data doesn't fit the definition, or your docs and your responses disagree, assume the agent will notice, and that it may trust you less for the rest of the session. Overall the machine-readable surface of a product is part of the product, not documentation about it.

IMO services are going to start competing on AX, creating a classic innovator’s dilemma for incumbents (eg Amazon): optimizing for agents undermines the human-facing surfaces and economics their business is built around, while agent-pilled customers migrate to agent-native options

Heidegger’s equipmental totality is relevant here

Finding myself sharing this Wendell Berry quote more and more: It is easy for me to imagine that the next great division of the world will be between people who wish to live as creatures and people who wish to live as machines.

With a toddler, an infant, and two large furry Maine coons, our @maticrobots has become critical infrastructure. Though it still makes the toddler nervous!

I'm such a sucker for printed design. At @OrbitModel we did a couple editions of "Gravity," a print magazine about community building, which became a favorite swag item among our users.

Air-3-to-a-bed-n-breakfast