a tool call is not a market transaction

When an agent from one organization hires or uses capacity from another, seven questions appear. How is the capability discovered? Who vouches for the actor? What offer was accepted? Which unique events count as usage? What settles the invoice? Who hears a dispute? How does the outcome alter future trust?

M-7 gives those questions seven explicit ports. Its metering design derives from unique ledger events so a retry need not become a second bill. Contracts carry typed inputs, outputs, prices and service expectations. Settlement and dispute attach to evidence rather than a narrative of what probably happened.

The adjacent I-7 work asks a different question: who may govern the standard, protocol, operator and runtime as these institutions mature? The economic and constitutional designs belong together in a public research route, with clear labels for specification, proposed theorem, implemented software and observed transaction.

what the buyer actually buys

A company can ask an outside agent to classify a document, book a service, run a campaign or settle a claim. The call might be cheap and fast. It is still a purchase of some result under some rule. Before the work starts, the buyer needs to know what the seller offers, what inputs it may receive, which output counts as delivery, when a charge is earned, and what happens when the output is wrong.

M-7 separates those concerns into seven ports. Discovery makes a capability findable. Attestation gives the buyer a basis to identify the actor and its claims. Contracting binds an offer to terms. Metering identifies billable events. Settlement moves the economic obligation to a completed state. Dispute gives both sides a route when the records conflict. Reputation carries information from one transaction to the next. Remove one port and the missing question does not disappear; it moves into a support inbox or a lawsuit.

the meter has to survive retries

An agent may call the same service twice because the first response timed out. If both calls produce invoices, the buyer pays for a network problem. If neither is recorded because the reply was lost, the seller loses revenue. M-7’s unique-event metering asks which event is the economic unit and how retries refer back to it. That is a practical design choice. “Per request” and “per accepted result” are different businesses.

A usage record also needs a route back to the contract in force at the time. A later price change cannot silently alter an earlier episode. Nor can a dashboard total substitute for the underlying events when the parties disagree. The buyer and seller need enough shared history to argue about one charge without reopening their entire relationship.

settlement is not the end of the story

Suppose an agent produces an analysis the buyer accepts, then the analysis turns out to contain a bad source. Can the buyer dispute it? What kind of correction is owed? Which actor decides? How does a corrected result affect the seller’s standing? Reputation built from star ratings is too thin for such a market. The relevant signal may be that a seller corrects errors quickly, gives a clear source trail or consistently handles a narrow class of tasks well.

There is also a constitutional problem. Whoever runs the registry, protocol and settlement infrastructure can privilege participants or change terms. The adjacent I-7 design asks where those powers sit as a market grows. That inquiry belongs beside the mechanics of metering. Markets do not become neutral just because the participants are software.

No universal agent marketplace needs to exist before these questions matter. Any company buying work from outside automation already faces them. Write one cross-company transaction from offer to dispute. If the answer to “who owes what?” depends on a chat transcript and everyone’s memory, the economic interface is still missing.

a contract should fit the work

There is no reason every transaction needs a thick legal packet. The protocol can start with a small, typed offer: input class, output class, price basis, deadline, acceptance test, correction rule. A buyer should be able to compare two offers on those terms. A seller should know which obligations it took on before an agent begins spending compute or contacting other systems.

For complex work, the contract may need staged acceptance. A researcher may deliver sources before synthesis; a creative producer may deliver a concept before the final edit. Paying only at the end can put all risk on the seller. Paying at invocation can put it on the buyer. Metered milestones are one answer, but only if both parties can inspect the same event history.

This is why agent commerce is not reducible to a directory of tools. Discovery helps parties find each other. The rest of the design decides whether they can keep doing business after something goes wrong. The dispute path is part of the product, not a regrettable exception.