The agent economy has an imagination problem
For three years we’ve been wrapping better models in the same interface. A chat window, a copilot, a workflow with a language model bolted onto one step. We call all of it agents. The models moved quickly and our picture of what to do with them barely moved at all.
I build infrastructure for AI agents, which is a narrow vantage point but a revealing one, because a wallet is where the story meets the ledger. You learn fast whether someone is building an assistant that drafts a suggestion for a human to approve, or something that gets handed a budget and is expected to come back with a result. Almost everything I see is the first kind. The models are ready for the second. What’s missing is imagination.
Once an agent can plan, use tools, pay, and hand work to another agent, the question stops being whether it can finish a task. It becomes what a new kind of economic actor needs to operate. An identity that outlives the session, an address, spending authority with a limit, and a record of what it did and why.
The word stopped meaning anything
Agent now covers plugins, cron jobs, chatbot wrappers, retrieval pipelines, and genuinely autonomous systems. The vagueness isn’t harmless. It caps what people imagine building, because if a scheduled script counts, you’ve already shipped one and there’s nothing left to design.
The distinction worth keeping is determinism. A workflow follows a path someone drew in advance. An agent gets a goal and finds a route, sometimes a route nobody anticipated. Everything difficult about agents falls out of that one property: they need guardrails rather than error handling, context management rather than parameters, verification rather than assertions.
It also means bolting a conversational UI onto software still designed around a human clicking buttons doesn’t produce one. That’s a chat feature on a click-shaped product.
Products a machine can actually use
Agent-native is about treating the agent as a customer, which is a bigger ask than dropping the UI.
The test I use: can an agent complete the whole journey alone? Find the product, work out what it does, sign up, create an organization, authenticate, pay, pull a receipt, read a trace when something breaks, and recover from the failure. Every one of those is unremarkable for a person. Most are impossible for a machine.
DX made APIs usable for developers, UX made products usable for people, and the missing layer makes a commercial system legible to software. Pricing a machine can read. A signup that doesn’t need a human’s inbox. Errors that say what to do next instead of rendering a toast.
That’s already a distribution problem rather than a future one. Agents crawl, compare, and recommend today. A product with no API, no CLI, no machine-readable pricing, and no way to try it without a sales call isn’t ranked badly in that channel, it’s not in it. The indexing is happening while we’re still arguing about definitions.
The purchases that matter aren’t shopping
Most agent-payment demos are a person’s errands in a trench coat. Book the flight, buy the shirt, renew the subscription. Useful, and structurally boring.
The interesting case is recursive: the agent buys something it needs to do the next part of its own job. Compute for a run, a dataset it discovered it was missing, an hour of another agent that’s better at the task, a sandbox to test in. Each purchase changes what it can do, which changes what it buys next.
Picture an agent asked for a market-entry plan. It finds it has no regional pricing data, buys access to a source, spins up a research sub-agent, rents compute for a modelling job, and pays a specialist agent to check the output for compliance before it ships. A person asked for an outcome. The agent assembled the means.
That’s a budget-bearing operator inside a production system, not a checkout button with better manners, and it needs things checkout never had to provide: an identity that persists between runs, an inbox that belongs to the agent rather than forwarded from its owner, memory, scoped authority, a spending cap that actually binds, and an environment that survives the session. The startups issuing agents their own email addresses and phone numbers look like a joke until you notice they’re the first ones treating an agent as an entity instead of a feature inside somebody’s account.
No single agent wins
I don’t think one general assistant swallows this, and not because frontier models won’t get broadly capable. They will. Useful work needs specific context: domain knowledge, personal history, the last six months of a company’s decisions, industry rules, and a way to check the answer that a generalist has no reason to build.
A front-door assistant stays valuable, but mostly as a router. One system handles travel, another financial analysis, another code, another vendor management. The layer that wins might be the router itself, the portable context that moves between them, or the plumbing that lets specialists interoperate at all.
This is the ordinary bundling and unbundling cycle. General platforms expose a capability, specialists beat them on depth, and something eventually aggregates the specialists back into one coherent experience. Build a general agent if you want. Just don’t expect generic to be the moat. The moat is proprietary context, trusted execution, domain-specific verification, or sitting on a bottleneck in the network.
Which is why portability beats platform allegiance. There won’t be one model, one protocol, or one tool ecosystem. Can your tool run against several model providers? Can an agent’s memory and credentials move? Can a developer reach the same capability through an API, a CLI, a skill, or whatever replaces those, without rebuilding the integration each time? The protocol arguments (MCP, A2A, skills, plain CLIs) obscure the actual requirement, which is coordination. Locking an agent’s identity, memory, and tools into one ecosystem looks integrated this year and becomes the bottleneck next year.
The interesting part is the refusal
The workable arrangement is a human on the loop. People set the budget, the scope, and the permissions. The agent runs freely inside them. A person gets pulled in at the edges, not at every step.
I built a demo of this: an agent managing a small treasury on Base testnet. It could check its balance, move funds into a yield position, and pull them back out. What anyone remembers from it is watching the agent decide to call an unapproved protocol and get refused by the policy engine. That refusal is what makes the rest of it deployable.
It also took two separate policies to work, one bounding what the agent could do and another sponsoring the gas. Get the second wrong and the first quietly stops applying. Governance at this layer is plumbing, not a checkbox, and it raises questions most agent demos never have to answer.
- What authority was delegated, and by whom?
- What data can the agent reach?
- Which tools can it call?
- How much can it spend, and for what?
- Can you reconstruct why it acted, six weeks later, for an auditor?
- Do the permissions travel with it into another system?
Those are the reason serious deployments stay stuck as prototypes, not safety extras to bolt on once the thing works.
What I’d build
The safe move right now is another assistant that recommends and never acts. The opportunity is the bounded economic actor, and taking it means giving up a few comfortable assumptions. The product boundary is the API and the CLI, not the UI. A wallet is an authority and policy system, not a balance. Specialised context and verification decide who wins, not model access. The first big application probably isn’t a consumer chatbot but a service category that today’s click-shaped software renders invisible.
So the work I find interesting is unglamorous: persistent environments, portable memory and identity, delegated permissions with an audit trail, and a way for an agent to discover, buy, and pay for what it needs without a person in the middle. It’s the layer a thousand specialised agents will need, and most of it is still missing.