In July 2024, at a Melbourne Business School AI Challenge run by Microsoft, I proposed an idea that won the competition: a complete abstraction of the computer into just a text and voice prompt. No apps, no browsers, no storefronts. Just a black box you speak into, eventually replaced entirely by wearables. Every phone reduced to Siri and a prompt window. Everything else handled by agents.
Eighteen months later, we are almost there. AI agents are becoming the primary interface between people and businesses. A customer will not visit a retailer's website. They will tell an agent what they need, and the agent will find it, compare prices, and buy it. I call this AI-commerce: the next generation of commercial interaction, mediated entirely by agents.
Two days ago, Anthropic launched managed agents, and it prompted me to think carefully about who owns the layers that make AI-commerce work. What I found is that the model providers are building excellent infrastructure, and that the ecosystem is more open than I initially feared. But there are layers that nobody is building yet, and those layers will determine whether AI-commerce serves local markets or extracts from them.
This was written two days after launch. I am still unpacking what managed agents means. Some of this will turn out to be wrong, and I will write follow-up posts on the topics I am still working through: model lock-in, digital sovereignty, the economics of AI-commerce, and more.
What Anthropic built
Managed agents is genuinely impressive engineering. A three-way decoupled architecture: sessions for durable state, a hardened harness for orchestration, and sandboxed execution environments for running code. Crash-resilient. Context-engineered. Research-backed improvements to structured task performance. For enterprise deployments, it sets a new standard.
Importantly, managed agents is designed to be composable. The tools layer uses MCP, an open standard donated to the Linux Foundation. MCP servers can run anywhere: inside the sandbox, on a remote server, or on the developer's own infrastructure. The harness calls tools through a proxy. The developer retains ownership of their tools. This is a good design.
Rakuten deployed agents across five departments in a week. Sentry shipped a bug-fix agent with a single engineer. These are enterprise products where the business already has its own infrastructure, its own customer base, and its own tools. Managed agents provides the orchestrator. The enterprise owns everything else. For this use case, managed agents earns its place.
Five layers of AI-commerce
But enterprise orchestration is one product category. AI-commerce is a different one. To see the difference, it helps to map the layers.
AI-commerce requires five distinct layers. Who builds each one determines who captures the value.
| Layer | What it does | Enterprise | Consumer |
|---|---|---|---|
| Channels | Where users interact | Enterprise owns (their app, portal, API) | The user chooses: Claude, ChatGPT, Copilot, company chatbots, WhatsApp, Discord |
| Orchestrator | Session continuity across channels, routing, user data | Managed agents, excellent fit (single-channel) | Nobody yet. User switches between Claude, ChatGPT, Discord and loses context each time |
| Model | Reasoning, planning, tool selection | Claude (lock-in acceptable at enterprise scale) | Interchangeable. Lock-in is a liability at consumer margins |
| Tools | Domain functions: search, compare, order | Enterprise owns (internal MCP servers) | Independent developers. The unbuilt layer |
| Retailer integration | Connections to businesses | Enterprise owns (their systems) | Independent developers today, retailers eventually |
For enterprise, managed agents covers the orchestrator and model, and the enterprise keeps the rest. That is a clean split. The enterprise has contracts, negotiating power, and resources to migrate if needed.
For consumer products, the picture is different. The orchestrator needs persistent infrastructure: user accounts, order history, payment methods, family profiles. The managed agents sandbox is ephemeral, spins up for a session and is torn down after. A consumer product still needs its own servers, its own database, its own authentication. The model should be interchangeable because consumer margins cannot absorb vendor lock-in. And the tools layer, the cross-retailer comparison, the independent recommendations, does not exist yet. Nobody is building it. Retailers will not build it either. An open marketplace where an agent finds the cheapest provider for every item is a race to the bottom that no retailer would voluntarily enable.
What I built
I published Gombwe to npm on April 7, the day before the managed agents announcement. Gombwe is an open-source personal agent: it orders groceries, compares prices across Woolworths and Coles, manages family schedules, and runs on a home machine in Melbourne. My family interacts through Discord. Nobody in my household knows or cares that Claude exists. They text "we need milk" and it happens.
Gombwe makes the layers visible. The model is one component. The tools (grocery search, price comparison, cart management) are another. The channels (Discord, Telegram) are another. The user data (meal plans, dietary preferences, purchase history) is another. And the deterministic work, searching a website, comparing prices, adding to cart, does not need a model at all. Scripts handle it in milliseconds for free. The model is called only when reasoning is needed.
Even at one-household scale, the architecture reveals where the value sits. Not in the model or the orchestrator, but in the layers around them. The tools that know Australian grocery. The channels that reach people where they are. The data that belongs to the user. Those are the layers that make AI-commerce useful, and they are the layers that do not exist yet for most markets and most domains.
The layers nobody is building
Managed agents is an excellent orchestrator. MCP is a good open standard. The model providers are building real infrastructure. But here is what none of them will build:
The proprietary functions layer. Could Woolworths build an MCP server and list it in Claude's directory? Yes. Would customers then be able to say "order my groceries" inside Claude? Yes. But Woolworths will never build a tool that tells the customer "Coles has chicken cheaper this week." No retailer will build the functions that work in the customer's interest: the cross-retailer search, the price comparison, the independent recommendations. No model provider will build it either. They build infrastructure, not Australian grocery tools. Independent developers must build this. It works inside managed agents, inside ChatGPT, inside any MCP-compatible client. The point is not where it runs. The point is that it must be independent of both the model provider and the retailers.
The consumer channels. Most people in Australia, let alone Zimbabwe or Nigeria, are not going to interact with AI through a $20/month chat application. They will use WhatsApp, Telegram, Discord, SMS. The channel layer that connects AI-commerce to the interfaces people already use does not exist inside any model provider's product. It is a different layer, built by different people, for different markets.
The persistent user relationship. Order history, dietary preferences, budgets, family profiles, spending dashboards. For a consumer product, this data must live in infrastructure the developer owns, not in an ephemeral sandbox session. When the user switches models, from Claude to GPT or to an open-source alternative, their history and preferences should come with them. The user relationship belongs to the product, not to the model.
The zero-cost path. Searching a retailer's website is an HTTP request. Comparing prices is a sort. Adding to cart is a form submission. These are deterministic operations that cost nothing to execute locally. An architecture that routes every action through paid model inference burns money on work that does not require intelligence. For a family comparing grocery prices or a student checking textbook costs, the economics point to calling the model only when reasoning is needed and handling the rest with scripts.
The bigger questions
Writing this post, I found myself conflating several arguments that deserve their own treatment. Managed agents prompted me to think about them, but they are not critiques of managed agents. They are questions about AI-commerce itself:
- Model portability. What happens when a business builds entirely on one model vendor's infrastructure and a better model arrives? Is migration a config change or a rebuild? How should architectures be designed to treat models as interchangeable utilities?
- Digital sovereignty. Europe is moving away from US-owned platforms for sovereignty and independence reasons. The same AI companies building agent infrastructure are also defence contractors. When AI-commerce mediates a country's consumer transactions, where the infrastructure lives and who governs it becomes a political question, not a technical one.
- The economics of AI-commerce. Who captures the margin when an AI agent mediates a purchase? The model provider, the tool provider, the retailer, or the platform that owns the customer relationship? How does this compare to the economics of Amazon, Google, and Facebook?
- The end of websites. If every device becomes a prompt window, businesses that are not agent-accessible become invisible. What does this transition look like, and who builds the tools that make businesses discoverable by agents?
- Personal agents vs enterprise agents. Managed agents is designed for enterprise. What does the architecture look like for personal agents that run on a home machine, serve one household, and cost nothing beyond an existing subscription?
I will write about each of these separately. They are important enough to get right, and two days after an announcement is not enough time to get them right.
What we are building
At Agents Formation in Melbourne, we are building the layers that neither the model providers nor the retailers will build:
- The Australian MCP Registry: open-source, model-agnostic tools for Australian grocery, starting with Woolworths and Coles price comparison and ordering
- Gombwe: an open-source personal agent that lives in Discord and Telegram, orders groceries, manages family schedules, and runs on a home machine
- Channel adapters for WhatsApp, Telegram, and Discord, so end users never need to know about AI subscriptions
- A dashboard for users to manage their agent interactions, order history, spending, and preferences
These tools are model-agnostic. They work with Claude today and will work with any model tomorrow. The architecture separates each layer so that the model can be swapped without touching the tools, the channels, or the user data. Managed agents is one option for the orchestration layer. It is a good one for enterprise. For consumer products, we are building our own.
A call to action
To Australian developers: the tools layer for AI-commerce in this country is unbuilt. Every domain (grocery, energy, insurance, travel) needs independent, cross-provider comparison tools that work in the customer's interest. Build them as MCP servers. Make them model-agnostic. They work inside managed agents, inside ChatGPT, inside any MCP-compatible client. Own the layer that the model providers will never build and the incumbents have no incentive to build fairly.
To Australian businesses: in AI-commerce, the businesses that are agent-accessible get customers. The ones that are not become invisible. Publishing an MCP endpoint is the equivalent of building a website in 1999. The retailers and service providers who do it first will be discoverable by every AI agent. The ones who wait will lose share to those who did not.
To policymakers: AI-commerce will determine who captures the economic value of consumer transactions in the next decade. The model providers are building excellent infrastructure, but the layers around the model (tools, channels, user data, commercial logic) are the layers where value accrues. Policy should encourage local AI-commerce infrastructure: local tool development, local data governance, model portability, and competition in the orchestration layer so that no single foreign provider becomes a gatekeeper to Australian commerce.
The model providers are building good infrastructure. The ecosystem is more open than it could have been, thanks in part to MCP being an open standard. But the history of platform economics tells us that the layers between businesses and customers are too important to be left unbuilt by the countries they serve. The model is a utility. The value is in the layers around it. Those layers should belong to the developers, the businesses, and the countries they serve.
It's been two days since the managed agents announcement. I am still working through what it means. I'll follow this up with deeper posts on model portability, digital sovereignty, the economics of AI-commerce, and the end of websites. If that interests you, check back.
We're building AI-commerce tools for Australia. Open source, model-agnostic, locally hosted. We're looking for developers, retail partners, and anyone thinking about agent commerce in Australia or Africa.