From assistants to participants in markets

In The Agentic Economy, researchers at Microsoft Research consider agents representing consumers and businesses in programmatic transactions. Their focus is how easier communication could change markets, discovery and access to economic opportunity.

The paper distinguishes what agents can technically express from the interactions that market rules permit. An open network and a closed platform can therefore produce different outcomes even when both use capable agents. The later Communications of the ACM article develops this discussion. Ghast did not originate the broader term or these researchers’ work.

Questions a buyer still needs answered

Delegating an action does not remove the need to agree on its scope. Before buying an AI service, a buyer needs to know the accepted inputs, promised result, time limit and relevant restrictions. After execution, the buyer needs evidence that can be compared with that agreement.

These are practical questions for service design, not findings that the cited paper certifies for Ghast. A useful evaluation separates the ability to communicate and transact from the ability to establish that a particular service delivered its promised result. Neither a fluent reply nor a successful payment establishes the latter on its own.

The missing unit of AI work: Ghast’s design question

Ghast’s proposal asks whether one defined service can be a useful unit for purchasing and evaluating private AI work. This is our design position, not an industry consensus that no tradable services already exist. APIs, applications and service contracts already offer ways to buy work; our question concerns the boundaries and evidence attached to a particular AI service.

Agent access describes a resource a customer can use. A service promise describes the outcome being purchased. Usage tokens describe consumption. Those can all be useful measurements, but they answer different questions. A service-level agreement needs to make the promised result and its checks clear without assuming that a model’s usage or the agent’s own completion message proves delivery.

A concrete example: a bounded code repair

Consider an illustrative service to repair a small function. A reviewable promise could name the input revision, permitted source file, expected calculation and required test output. Delivery evidence could include the diff and the actual command result. The buyer would check that evidence against the promise, including whether the task stayed inside the agreed scope.

Our existing Workbench coding walkthrough demonstrates a bounded task and two passing tests in stable 0.1.33. It is a product example, not a Protocol purchase or proof that a marketplace has been implemented. Passing those tests also does not establish correctness for every input or every environment.

How the Capability Economy fits

An open market where Capabilities are discovered, purchased, verified, and scaled, by humans and agents alike.

This is the existing glossary definition of Ghast’s proposed Capability Economy. In that proposal, the service unit is a Capability:

One defined AI service a buyer can purchase and verify. It carries a Defined Claim, Verifiable Delivery, and Economic Accountability. The workflow and method behind it stay under the Creator's control.

A Defined Claim would state the promise; delivery evidence would support checking it; the Protocol design would govern accountability and resolution. These are proposed mechanisms. They should be assessed separately from the broader research question of how agents participate in markets.

What is available, and what remains proposed?

Ghast Workbench is the released workspace for Chat, Coding and Team. Ghast Protocol, Capability purchasing, settlement and financing are not live. A clear task in Workbench does not automatically create a Protocol transaction or enforce every written restriction as a technical permission.

Private work also does not mean every task runs offline. Model requests and tools can send selected context to configured services. Review the current privacy boundaries alongside the proposed service model.

Sources and further reading