When Two Companies’ AI Systems Trade, What Counts as Valid Authority and Record?

Geoffrey Chen

After AI Enters the Workflow · Season Three: “When AI Starts Acting for the Organisation” · Article Nine

A buyer’s AI detects inventory below a safety level and requests prices from three suppliers. Supplier systems respond according to stock and customer tier. The buyer selects the lowest total cost and asks for faster delivery. The supplier agrees but increases freight. The systems exchange confirmations, a purchase order is created automatically and an invoice later enters finance.

The process takes seconds. No person reads every message. When the goods arrive, the buyer says the agreement guaranteed expedited delivery; the supplier says the premium only meant priority processing. Each company has preserved a natural-language conversation, but they do not possess the same final version of conditions.

Machines being able to speak to each other does not prove that companies formed a demonstrable transaction. Automated trade needs four things at once: identity, authority, shared semantics and a final record. Without any one, speed produces disputes faster.

Treat the transaction as a state machine, not a chat

People infer differences among “we probably can”, “please proceed on that basis” and “confirmed”. Machine-speed interaction should not depend on the same ambiguity. A transaction needs explicit states:

REQUEST_FOR_QUOTE
→ QUOTE (non-binding)
→ COUNTEROFFER
→ PENDING_APPROVAL
→ ACCEPTED
→ ORDERED
→ FULFILLED / CANCELLED / DISPUTED

A structured event should trigger each transition and identify who may trigger it. Natural language can explain conditions but should not carry transaction state alone. Otherwise a friendly “no problem” may be parsed as acceptance by one system and continued discussion by the other.

Every transition should also bind a complete version of conditions. After price changes, does the old delivery date remain? After quantity changes, is discount recalculated? The system should produce a new whole version rather than expect both parties to assemble the same answer from scattered messages.

Verify the organisation before the agent

“Who” in an electronic transaction has at least three levels: the legal entity, the system account representing it and the agent instance acting on this task.

A domain or API key proves that a technical credential was used. It may not prove that the credential remains valid, the call came from an approved workflow or the agent can make this category of transaction. A stolen token, test environment or integration left by a former employee can issue a perfectly formatted order.

The parties should exchange and verify entity identifier, service or access point, agent role, authority scope, credential status and time. A higher-value transaction needs stronger confirmation rather than permanent expansion of trust after several low-value orders.

Australian eInvoicing uses the Peppol framework to exchange structured invoice data over a standardised network. Australian Taxation Office, “eInvoicing” Electronic invoicing is not autonomous AI negotiation, but it shows the direction: reliable machine commerce depends on network rules, participant identity and structured business documents, not merely two chatbots understanding one another.

Authority must travel with the transaction

A buyer may permit AI to purchase routine supplies only from approved vendors, within a per-order amount and monthly budget. A supplier may let AI accept standard terms without changing liability or delivery warranty.

An order or acceptance should carry verifiable authority context: policy version, value range, product category, approval identifier and validity period. The counterparty need not see every internal policy, but it should be able to verify that this action came through a channel authorised for the transaction.

Authority checking is mutual. The buyer must confirm not only its own right to purchase but the supplier system’s right to commit price and delivery. The supplier should confirm that the order is not an exploratory request lacking approval.

Australia’s Electronic Transactions Act 1999 provides rules concerning attribution, dispatch and receipt of electronic communications. Federal Register of Legislation, Electronic Transactions Act 1999 Legal effect depends on facts and applicable law, but system design cannot assume that “it came from the other server” resolves every authority question.

Shared semantics matter more than shared language

Two AIs using English may define “business day”, “delivery”, “received”, “cancel” and “total price” differently. One may include tax in total; another may not. One may treat dispatch as performance and the other require receipt.

Structured transactions need dictionaries for unit, currency, time zone, tax treatment, product identifier and referenced terms. Natural-language explanation should point to fields, not replace them.

For example:

price_total: 12,500 AUD including GST
delivery_commitment: received_by
delivery_time: 2026-08-20T17:00:00+10:00
quantity: 500 units
terms_version: SUPPLIER-STANDARD-4.1
status: PENDING_BUYER_ACCEPTANCE

This record looks less elegant than chat but lets both systems and later reviewers determine the same facts. AI can map complex discussion into fields, but required fields should agree before state changes.

The Peppol BIS Billing specification demonstrates how machine-readable commercial documents use common business terms and validation rules. OpenPeppol, “Peppol BIS Billing 3.0” Automated procurement uses more document types and terms, but the principle is the same: interoperability comes from agreed semantics rather than model inference.

The final record must be confirmed by both sides

If each business saves only its own conversation summary, a dispute produces two “true versions”. An automated transaction should create a mutually verifiable final record containing:

  • entity and authorised identities;
  • complete terms and referenced versions;
  • every material variation;
  • formal acceptance event and time;
  • unique transaction identifier;
  • integrity proof such as hash or digital signature; and
  • withdrawal, replacement and correction history.

The parties need not share one database, but each should preserve an identically linked and verifiable version. A later AI summary can aid reading but cannot replace original structured events.

The record should also distinguish commercial documents. Quote, purchase order, order response, dispatch advice, invoice and credit note perform different functions. An invoice cannot retrospectively prove acceptance of a condition never confirmed.

Error handling belongs in the protocol

Machine commerce encounters duplicate messages, delay, timeout and inconsistency. If the buyer retries, does the supplier create two orders? If acceptance arrives but acknowledgement is lost, can the buyer resend safely? If price changes mid-exchange, which version applies?

Systems need idempotency identifiers, acknowledgements, timeout states and conflict rules. Silence should not be treated as acceptance unless the governing arrangement clearly provides for it.

UNCITRAL’s Model Law on Automated Contracting addresses contracts involving automated systems, input errors and attribution as a legislative model jurisdictions may adopt. UNCITRAL, Model Law on Automated Contracting Technical protocol cannot replace law, but it can remove factual disputes that good system design should prevent.

Errors should be classified. Format errors can be rejected automatically. Inventory change can require a new quotation. Excess authority should reach a person. Suspected credential compromise should suspend the channel. AI should not attempt to resolve an identity or security incident through free-form negotiation.

People should not appear only after dispute

Full automation does not mean nobody is responsible. Each business needs a transaction owner, authority-policy owner and dispute contact in advance. Thresholds for value, new terms, new vendors and anomalous behaviour should pause before formal acceptance.

The human interface should show state differences and unresolved conditions rather than a complete transcript. A decision-maker needs to see deviation from standard terms, total cost change, which agent proposed it, whether the other party has relied and whether acceptance is reversible.

Completed transactions also need sampling across machine record, actual delivery, invoice and payment. If orders complete automatically but generate repeated credits and disputes, automation has moved the problem downstream.

Two AIs still need data minimisation

Negotiation does not require full customer profiles, internal stock forecasts or unverifiable model reasoning. Each party should disclose only conditions and evidence necessary to transact.

External messages remain untrusted. A transaction gateway should validate schema, size, attachment and permitted fields, separate natural language from system instructions, then provide content for AI interpretation. The execution layer should not let counterparty text trigger payment, permission change or sensitive-data access directly.

Machine commerce is an interface between institutions, not a private conversation between models. Protocol, identity, authority and records create trust; AI improves understanding and negotiation inside those boundaries.

Conclusion: a valid transaction is not two machines agreeing; it is two organisations proving agreement

AI can exchange language quickly while interpreting identity, state and condition differently. Maturity does not remove every person. It makes each automated step reconstructable and owned.

The final principle is:

A machine-generated order should enter formal execution only when both identities are verifiable, agent authority is proportionate, terms use shared semantics, acceptance state is explicit and both organisations retain the same verifiable final version.

Speed should not come from omitting formation. Good automated commerce removes duplicate entry while preserving the questions companies must answer together: who agreed to what, when, under which version and how error can be reversed.

Primary sources and further reading

Continue reading: Explore the After AI Enters the Workflow series.

Discover more from Geoffrey Chen

Subscribe to get the latest posts sent to your email.