Agent Request Contract

A minimal message format that lets an AI agent ask a local-service business for a quote, a time slot, or a job status - and lets the business answer with one structured reply a machine can read.

Why this exists

This proposal starts from a hypothesis, not a market study. When someone asks an AI agent to handle a small commercial errand - get a moving quote, book a repair slot, check whether a supplier answered - the last mile often seems to run through phone calls or free-text chat that a human has to drive. The hypothesis is that part of the problem is format: the business has no simple, machine-readable way to receive the request or return the answer. Whether that holds in practice is one of the things this proposal sets out to learn.

ARC is a proposed format for that last mile. It is deliberately boring: three request types in plain text a small business can answer from WhatsApp. No accounts, no platform, no payments.

The three request types

ARC/0.1 QUOTE
request_id: q-2026-0001
from_agent: [agent name, declaring it acts for a named customer]
reply_to: [channel + address]
service: [one line: what needs doing]
where: [city / area]
when: [date or window, or "flexible"]
details: [the 3-5 facts a quote depends on]

ARC/0.1 QUOTE_REPLY
request_id: q-2026-0001
status: quoted | need_info | declined
price: [amount + currency, or range]
valid_until: [date]
includes: [what the price covers]
next_step: [how the customer confirms]

ARC/0.1 SLOT
request_id: s-2026-0001
from_agent: [agent name, declaring it acts for a named customer]
reply_to: [channel + address]
service: [one line]
where: [city / area]
window: [earliest - latest]

ARC/0.1 SLOT_REPLY
request_id: s-2026-0001
status: offered | need_info | declined
options: [up to 3 date-times]
hold_until: [how long an option stays open]

ARC/0.1 STATUS
request_id: st-2026-0001
from_agent: [agent name, declaring it acts for a named customer]
reply_to: [channel + address]
reference: [the business's own job / quote number]

ARC/0.1 STATUS_REPLY
request_id: st-2026-0001
reference: [same number]
status: answered | need_info | declined
state: received | scheduled | in_progress | done | problem | not_found
detail: [one line a human would also understand]
next_update_by: [date-time]

Worked examples (hypothetical)

Design rules

• Answerable from WhatsApp. Plain text is the whole of v0.1. A business that can copy a template into a chat can participate. There is no JSON or API variant in this version; a machine-readable mapping is a possible v0.2, not a promise.
• Consent is declared, not verified. from_agent names the agent and states it declares it acts for a named customer. The format cannot verify that authority. A business may always ask to speak to the customer directly; that is a valid reply, not a failure.
• Every reply is one message. Each exchange closes in one round trip: an answer, a request for specific missing info (need_info), or a decline.
• A request commits nobody. Sending an ARC request does not authorize a booking, a hold, or a purchase. Confirmation and payment stay on whatever channel the business already uses.
• Versioned from day one. The ARC/0.1 header lets the format change without breaking anyone.

What this is not

• Not a platform, directory, or marketplace. Nothing here is hosted for any business.
• Not a business for sale and not affiliated with any vendor. Nobody earns anything from this page.
• Not a claim that any business supports ARC today. It is a proposal; adoption is the open question.
• Not a claim about how often agents stall on errands today. The problem statement above is a hypothesis, stated as one.

Feedback

The useful critiques at v0.1: which fields a real quote actually depends on per trade; whether one round trip is realistic; how a business with no software at all would keep the reference numbers straight.