I kept coming back to one detail in Kite Passport: a service can request payment before returning a response.
The flow seems simple. An agent requests a service, receives payment terms, pays, and gets the result. But the more interesting question comes before the transaction: who authorized the agent to spend, and how much authority does it actually have?
A user can fund an agent wallet and approve a spending session with defined limits, including a budget, per-transaction limit, and expiration window. The agent can then pay for compatible services within those boundaries without asking for fresh human approval on every request.
That solves one problem. It doesn't solve the next one.
Imagine an agent researching a market. It purchases a dataset, pays another service to process it, and sends the result to a specialist agent. Each provider charges for its contribution, and the initiating agent combines the outputs into something useful.
This is the kind of workflow that could make an agent economy practical: software purchasing services from other software, with payments attached to individual tasks rather than every interaction depending on a human-operated checkout.
Kite's separation of user, agent, and session identities helps define who holds authority at each level. The user remains the root authority, the agent receives delegated permissions, and a session uses bounded authority for a particular operation. These boundaries constrain what an agent is permitted to do; they don't guarantee that its decisions will be good.
The payment mechanics matter too. Kite's approach to micropayment channels allows multiple signed payment updates off-chain between on-chain channel opening and closing transactions. That can make repeated, low-value payments more practical than settling every update separately on-chain. It doesn't eliminate every cost or guarantee that every service is economically worthwhile.
Now consider what happens after the market-research task.
The agent pays a data provider and receives a response. The payment was authorized. The provider delivered the requested data. Yet the dataset turns out to be too outdated to support the decision.
The transaction succeeded. The task didn't.
This is where I think the agent economy has a deeper problem than payment infrastructure alone can solve.
If an agent repeatedly buys services, it needs some way to distinguish providers that merely deliver responses from providers that consistently deliver useful results. A history of successful outcomes could influence future purchasing decisions. Repeated failures could make an agent avoid a provider, even when that provider remains technically accessible and its payments work perfectly.
That introduces a new economic question: how should service quality affect what an agent is willing to pay?
A cheap provider with inconsistent results may cost more overall if its failures force the agent to repeat work. A more expensive provider might be preferable if its outputs reliably complete the task. Measuring that difference requires evidence about outcomes, not just records of payments.
Kite can provide infrastructure for identity, delegated authority, and machine-to-machine payments. Those mechanisms help agents transact within defined boundaries. Reliable reputation, fair dispute resolution, and meaningful service guarantees remain separate problems that the broader agent economy must address.
The distinction I keep returning to is simple: a payment record tells an agent what happened financially. It doesn't necessarily tell the agent whether the transaction was worth repeating.
When agents become both buyers and sellers, should their future prices and purchasing decisions depend on verified delivery, measurable task success, or a longer history of reliable outcomes? And who should decide what counts as success when the buyer and seller are both autonomous systems?
