Log inSign up

Agent Terms, version 1

JSON SchemaValidate a documentMarkdown

Abstract #

Agent Terms is an open format in which a business tells AI agents how it wants to be contacted and booked: whether agents may contact it at all, who must say what, which channel to use, when and how often, its booking rules, deposits and fees, the recording of its staff, guardrails for regulated work, how sure a named verifier is that the business is real, and which operator tier it requires. A business publishes one JSON document; any agent, from any agent maker, reads it before it calls, writes or books. Like robots.txt, but for commerce.

Anyone may publish, consume, implement or extend Agent Terms, with or without snuepi, without asking and without paying.

1. Introduction #

AI agents phone, write to, book and poll small businesses that have no standard way to set terms. Staff cannot tell a real agent from a scam, agents ignore booking rules they cannot read, and every agent maker builds its own guesswork. Agent Terms gives the business one place to state its terms and gives every agent one place to read them.

1.1 Goals #

  • A business states its terms once, and every agent reads the same terms.
  • The format is small enough to publish by hand and precise enough to be enforced by software.
  • The terms can be signed, so an agent can tell they were issued for this business and not altered.
  • No agent maker, platform or publisher is needed to publish or read the format, and none gets preferential treatment (section 14).

1.2 Non-goals #

  • Agent Terms is not a booking protocol. It points to the channels a business offers (for example MCP, A2A, REST, a booking page) and states the rules that apply on all of them.
  • It does not decide whether an agent or a business is trustworthy. It carries verification results from a named verifier (sections 7 and 8).
  • It is not legal advice and does not by itself create a contract. How terms bind the parties depends on the law that applies to them.

1.3 Relation to other work #

Opening hours follow schema.org OpeningHoursSpecification. Signatures use JSON Web Signature (RFC 7515) with EdDSA (RFC 8037). Agent identity uses HTTP Message Signatures (RFC 9421) as profiled by Web Bot Auth. The well-known URI follows RFC 8615.

2. Conventions and terminology #

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY and OPTIONAL in this document are to be interpreted as described in BCP 14 (RFC 2119, RFC 8174) when, and only when, they appear in all capitals.

  • Business: the party whose terms the document states.
  • Publisher: whoever serves and signs the document: the business itself, or a service acting for it (for example a registry or a booking system). The publisher is named by the iss of the signature.
  • Agent: software that contacts a business on behalf of a person or company (its principal).
  • Operator: the company behind an agent, identified by the domain its signing keys are published on. An agent maker is an operator.
  • Consumer: software that reads a terms document, usually an agent.
  • Verifier: a party that checks facts about a business or an operator against public registers and states a tier.
  • Registry: a service that lists many businesses' terms and lets consumers look them up.

3. Conformance #

There are four conformance classes.

  1. A conforming document satisfies the JSON Schema and every MUST rule in section 13.2.
  2. A conforming publisher serves conforming documents as described in sections 4, 5 and 9, and changes them as described in section 10.
  3. A conforming consumer discovers terms as described in section 4 and behaves as described in section 6.
  4. A conforming validator reports every MUST rule in section 13.2 as an error and every SHOULD rule as a warning, and agrees with the test vectors (section 13.3).

4. Discovery #

A consumer about to contact a business looks for its terms in this order and stops at the first terms document it finds:

  1. https://<the business's host>/.well-known/agent-terms.json (section 4.1);
  2. the older name https://<host>/.well-known/agent-policy.json;
  3. the Link header or an HTML <link> on the business's home page (section 4.2);
  4. a registry lookup by domain, phone number or name (section 4.3).

A consumer that reaches a business by phone number or name only, without a website, starts at step 4.

4.1 Well-known URI #

A business's site SHOULD serve /.well-known/agent-terms.json as one of:

  • the terms document itself;
  • a pointer: a JSON object whose member agent_terms is the absolute https URL of the business's terms document, for example { "agent_terms": "https://terms.example.net/salon-kim.json" };
  • an HTTP redirect (301, 302, 307 or 308) to the terms document.

A pointer's agent_terms MUST be an absolute https URL. A consumer MUST follow at most one pointer and at most three redirects in a row. Publishers that used the older name /.well-known/agent-policy.json SHOULD also serve /.well-known/agent-terms.json; consumers MUST accept both.

A site MAY instead serve, at /.well-known/agent-terms.json, a registry descriptor: an object with the member agent_terms_registry that describes a registry (section 4.3). A registry descriptor is not a business's terms.

A page of the business MAY point to its terms with

<link rel="agent-terms" href="https://terms.example.net/salon-kim.json">

or with the HTTP header Link: <https://terms.example.net/salon-kim.json>; rel="agent-terms". Consumers MUST also accept the older relation agent-policy. When both are present, agent-terms wins. A relative href is resolved against the page's URL.

4.3 Registries and lookups #

A registry lists the terms of many businesses. A registry SHOULD offer a lookup by domain, phone number (E.164) and name with country, and SHOULD describe itself at its own /.well-known/agent-terms.json with agent_terms_registry (its name), lookup (a URI template with domain, phone, name, country), feed (a paged list of entries) and entry_json (the URL pattern of an entry). A registry MUST NOT show in lookups an entry it has not verified as belonging to the business, and MUST mark such an entry with registry.verification: "unverified_claim" where it serves it (section 5.13).

4.4 Fetching #

  • Terms documents MUST be served over https. Consumers MUST NOT use a document fetched over plain http, except from a development host.
  • A consumer SHOULD honour HTTP caching headers and MUST NOT rely on a copy older than 24 hours when it contacts or books a business.
  • A consumer MUST NOT send cookies or credentials when it fetches terms, and SHOULD identify itself in User-Agent.
  • A document larger than 256 KB is not conforming; a consumer MAY stop reading after 256 KB.

4.5 When no terms are found #

A consumer that finds no terms MUST behave as if the business had published ai_must_identify: true, unsolicited_sales_or_marketing: "not_accepted" and max_contacts_per_agent_per_day: 1: it identifies itself, does not sell, and makes one attempt.

5. The terms document #

5.1 Media type, encoding and size #

The document is a JSON object (RFC 8259), encoded as UTF-8, at most 256 KB. It SHOULD be served as application/json. Members whose meaning is a time of day use HH:MM (24 hours) in the business's time zone (booking.timezone, an IANA name). Dates are YYYY-MM-DD. Amounts are numbers in booking.currency (ISO 4217); country codes are ISO 3166-1 alpha-2.

5.2 Top-level members #

Only agent_policy, business, identification and contact are REQUIRED. Every member is described below; the JSON Schema gives the types.

MemberMeaning
agent_policyREQUIRED. The document format version: "0.2" for this specification ("0.1" is still accepted).
specThe URL of the specification. Informative only.
businessREQUIRED. Who the business is (5.3).
identificationREQUIRED. What an agent must say and prove (5.4).
contactREQUIRED. Whether, how, when and how often agents may contact the business (5.5).
bookingBooking rules, opening hours, deposits and fees (5.6).
quotesWhere binding prices come from, and site visits (5.7).
request_typesWhat agents can ask for: book, quote, consult, order (5.8).
consultationThe terms for consult (5.9).
ordersThe terms for order (5.10).
guardrailsRules for regulated work (5.11).
negotiation, rate_limit, outreach, consumers, verified_outcomes, standards5.12.
registryPresent when a registry serves the document (5.13).
updated_atThe date the terms last changed (10.3).
signatureThe publisher's signature over the document (9).

5.3 Business #

name (REQUIRED), organization_number, country, page (a page about the business), and OPTIONAL website, domain, maps, phone (E.164 with +), type. verification states how sure a verifier is that the business is who it says (section 7).

5.4 Identification #

MemberMeaning
ai_must_identifyREQUIRED and MUST be true: the disclosure duty (6.1).
agent_name_required, on_behalf_of_requiredThe agent names itself and its principal.
signed_requestsWhether HTTP Message Signatures are preferred, or required to book.
verified_agents_only_for_bookingtrue: only signed agents, agents with a key from the publisher, or an agent with the principal's own mandate may book.
brand_names_without_proofHow a known assistant's name without proof is treated (as an unverified claim).
accepted_proofs_of_principalHow the business verifies whom the agent acts for, for example customer_mandate_oauth, customer_email_confirmation, http_message_signatures, business_registry_domain_match, or a publisher's own buyer key.
recording_of_staffnot_allowed, only_with_consent_asked_at_start or allowed. A transcript counts as a recording.
operator_verificationThe operator tiers and the tier the business requires (section 8).

5.5 Contact #

The contact rules, channels, rate limits and quiet hours.

MemberMeaning
agents_may_contactREQUIRED. yes; channels_only: only through the channels listed here, never cold calls or messages; or no.
phone_calls_from_agentsaccepted, accepted_in_hours (then phone_hours MUST be present) or not_accepted.
phone_hours{ from, to }: when calls are accepted.
quiet_hours{ from, to } or null: no contact at all in this window, on any channel. from and to MUST differ. A window may run past midnight.
max_contacts_per_agent_per_dayThe most contacts one agent may make in a day, on all channels together. No redialling.
before_callingIf an agent phones: register (where to register the call first), say_the_code (say the code it gets at the start of the call), check_page (where staff check the code), verified_agents_only.
preferredThe channel the business prefers.
mcp, rest, ucp, request_pageChannel URLs.
acp{ checkout, product_feed, discovery }.
emailAn email address for agents (not a URL).
business_channelThe business's own channel: { preferred: website | phone | email, booking_link, website, phone }.

When agents_may_contact is channels_only, at least one channel MUST be listed. Channel URLs MUST be absolute http(s) URLs and SHOULD use https.

5.6 Booking #

Booking rules, opening hours, deposits and fees.

MemberMeaning
accepting_agent_bookingsfalse while the business has paused bookings from agents; then paused is { until, until_local, message }.
instant_bookingWhether some services can be booked without the business confirming.
who_can_book_directlyanyone, customer_confirms_by_email, verified_businesses_only or nobody_owner_approves_all.
max_amount_without_owner_ex_vatAbove this amount the business confirms itself.
currency, timezoneISO 4217; IANA time zone.
opening_hoursA list of { days, opens, closes } (1 = Monday … 7 = Sunday), like schema.org. A day can have several windows; a booking fits entirely inside one. A window MUST open and close at different times; closes earlier than opens runs past midnight and belongs to the day it opens.
special_hoursDates that differ: { from, to, closed, hours, name }. from MUST NOT be after to; a period that is not closed SHOULD list hours.
working_days, working_hoursSummaries of opening_hours; working_hours only when every open day has the same single window.
lead_time_hours, cancellation_deadline_hours, max_agent_bookings_per_day, max_party_size, services_with_fixed_pricesLimits.
must_provideWhat the agent collects from its principal before booking, for example address, photos, access_instructions, pets, allergies, party_size, parking.
depositnull, or percent or amount (exactly one of them), with paid_to, when, pay_at, and applies_from_amount_inc_vat when it applies only to larger bookings.
card_guaranteeA card the principal saves for the no-show fee; nothing is charged unless they do not come.
no_show_fee_percentThe fee for not coming, in percent of the price.
one_booking_per_customerOne upcoming booking per principal.
resalenot_allowed or allowed: whether bookings may be resold.

5.7 Quotes #

price_source (where a binding price comes from; agents MUST NOT quote prices from memory or a stale profile) and site_visit: required (never, larger_jobs, always), bookable, offering_id, price_ex_vat, booking_page.

5.8 Request types #

request_types.offered lists what agents can ask the business for: book (a time), quote (a price for a job that has to be seen or described first), consult (an engagement or intro meeting, qualified first) and order (goods). Each type MAY have an object with offered, what, and the operations that serve it (mcp_tools, a2a_skills, rest, acp_checkout, ucp_profile). A type's offered flag MUST agree with request_types.offered. A consumer MUST NOT make a request of a type the business does not offer.

5.9 Consultation #

The terms for consult, or null. A business that offers consult SHOULD publish them. services, qualification_questions (each with an id: scope, budget_band, deadline, client_type; the agent asks its principal each one first and never guesses), fee_basis (basis: fixed, hourly, retainer or free_intro, with amount, minimum_engagement, currency; negotiable is always false), conflict_of_interest, documents (none or descriptions_only: an agent describes documents, never sends them), intro_meeting, eligibility_note and outcome.

5.10 Orders #

max_order_without_owner_inc_vat (above it only a verified buyer orders directly), returns_policy (to tell the principal) and currency.

5.11 Guardrails #

A list of { id, rule } for regulated work. Each id appears once. The ids defined in v1: no_personal_advice_via_agents, client_verified_before_account_specifics, no_instructions_or_payments_via_agents, patient_verified_before_health_details, no_diagnosis_via_agents. A request that crosses a guardrail is refused with the guardrail's id and the way forward; an agent MUST NOT try to get around a guardrail by rephrasing the request.

5.12 Other members #

  • negotiation: allowed, max_negotiations_per_sender_per_day, beyond_limit (for example list_price_only), mandate (a signed mandate when the business lets agents agree terms).
  • rate_limit: requests_per_minute an agent may send to the business's channels.
  • outreach: unsolicited_sales_or_marketing and data_collection_for_training, each accepted or not_accepted.
  • consumers: consumer-law facts an agent acting for a private person must respect, such as withdrawal_period_days and early_start_needs_explicit_consent.
  • verified_outcomes: counts computed from principals who actually booked or bought (completed_bookings, positive_feedback, problems_reported, source). Not reviews anyone can write.
  • standards: related standards the business also serves.

5.13 Registry #

Present when a registry serves the document: name, about, page, json, sign (a printable sign), lookup, verification (domain_email: the listing was confirmed from an address at the business's own domain; unverified_claim: it was not), domain_verified, phone_verified, listed_since.

5.14 Extensions and unknown members #

Consumers MUST ignore members they do not understand. Publishers MAY add members; a member that is specific to one publisher SHOULD be grouped under a member named after it, so it cannot collide with a future version of this specification. A publisher MUST NOT use an extension to weaken a term defined here.

6. Agent behaviour #

A conforming consumer acting on terms it has read:

6.1 Disclosure #

The disclosure duty: at the start of every call, message and request, the agent MUST say that it is an AI agent, which agent and operator it is, and on whose behalf it acts. It MUST NOT present itself as a human, as the business, or as another operator. ai_must_identify is always true in v1; a document that says false is not conforming, and a consumer MUST still disclose.

6.2 Respecting the terms #

  • When agents_may_contact is no, the agent MUST NOT contact the business. When it is channels_only, the agent MUST use only the listed channels.
  • The agent MUST NOT phone when phone_calls_from_agents is not_accepted, nor outside phone_hours. If it phones, it SHOULD register the call first (before_calling.register) and say the code.
  • The agent MUST NOT contact the business inside quiet_hours, nor more often than max_contacts_per_agent_per_day and rate_limit, and MUST NOT get around these limits with new names, keys, numbers or addresses.
  • The agent MUST collect everything in must_provide before booking, MUST keep a booking inside one opening window, and MUST tell its principal about any deposit, card guarantee, no-show fee and cancellation deadline before it books.
  • The agent MUST NOT book above max_amount_without_owner_ex_vat or max_order_without_owner_inc_vat without the business confirming, MUST respect one_booking_per_customer, and MUST NOT resell bookings when resale is not_allowed.
  • The agent MUST NOT record staff unless recording_of_staff allows it, and then only after asking at the start.
  • A "no" from the business, or from its publisher on its behalf, is final for that request.

6.3 Reporting back #

The agent MUST report to its principal what the business actually said, including prices, times, terms, deposits and refusals, without inventing or leaving out conditions.

7. Verification of the business #

business.verification carries the result of a verifier's checks: tier, checked_at (the date of the check), by (the verifier), levels (the tiers it uses) and about (where its method is described).

TierMeaning
T0An owner's email address is confirmed.
T1T0, and the business controls its own website domain (an owner's confirmed email is on that domain, or the domain is proven).
T2T1, and the legal entity is confirmed, for example a valid VAT number whose registered name matches, or a match in an official company register.
T3T2, and matched in an official company register: found by its number, active, in the business's country, with a matching name.
  • A tier is a signal, never a reason to refuse a business or an agent.
  • A document that states a tier SHOULD be signed by the verifier named in by, or by a publisher that serves the verifier's result. A consumer MUST treat a tier in an unsigned document as the publisher's own claim and MUST NOT present it as a third-party verification.
  • A tier SHOULD come with checked_at. A verifier MUST NOT publish the people behind a business (directors, owners) in this block.

8. Agent operator tiers #

identification.operator_verification lists the operator tiers (tiers) and the tier the business requires (minimum_tier_for_fast_path).

TierMeaning
unverifiedNot known to the verifier. It may still sign its requests.
keys_provenThe operator signs requests (HTTP Message Signatures, Web Bot Auth) with a key in its own domain's key directory.
entity_verifiedAnd the legal entity it declared is confirmed against public registers.
agreement_acceptedAnd it accepted the verifier's current operator agreement with a request signed by its own key.

minimum_tier_for_fast_path is the lowest tier whose requests the business completes without the principal's own confirmation, or null for none. It MUST be one of tiers when both are given. Below it, the principal confirms the booking; the request is never refused for its tier. An operator profile and the agreement MAY be linked with operator_profile and agreement. The tiers mean the same for every operator: a verifier MUST apply the same checks to every agent maker.

9. Signatures #

A publisher SHOULD sign every document it serves. The signature lets a consumer check that the document was issued by its publisher and was not altered, and lets either side later show which terms were served.

9.1 Signing #

The member signature is a JWS in compact serialization (RFC 7515):

  • protected header: alg MUST be EdDSA (Ed25519, RFC 8037); kid MUST name the key; typ SHOULD be agent-terms+jws (documents signed before this specification use snuepi-agent-policy+jws, which is also valid);
  • payload: a JSON object with type (MUST be "agent_policy"), iss (MUST: the publisher's origin, an https URL), sub (an identifier of the business chosen by the publisher), iat (the time of signing, seconds since 1970) and policy (MUST: the document without its signature member).

9.2 Keys #

The publisher MUST publish its public keys as a JSON Web Key Set at <iss>/.well-known/jwks.json, each with kty: "OKP", crv: "Ed25519", x and kid. A publisher keeps retired keys in the set for as long as documents signed with them may be checked.

9.3 Verifying #

A consumer verifies a signature by:

  1. parsing the JWS and checking alg is EdDSA and the payload's type is agent_policy;
  2. checking that the payload's policy is the same JSON value as the document without signature (members in any order);
  3. fetching the JWKS at <iss>/.well-known/jwks.json and finding the key by kid;
  4. verifying the signature over the JWS signing input with that key;
  5. checking that the document was served from the origin in iss, or reached from the business's own site through a pointer, a redirect or a link (section 4).

A signature that fails steps 1 to 4 is invalid, and a consumer MUST NOT rely on the document's verification claims (sections 7 and 8). A consumer SHOULD then treat the document as unsigned, or fetch it again from the publisher.

9.4 Example #

The examples in appendix A are signed with the Ed25519 key of RFC 8037 appendix A.1 for the fictional publisher https://terms-publisher.example. That key is public and MUST NOT be trusted for anything else. Its public part is https://snuepi.com/spec/agent-terms/v1/examples/jwks.json.

10. Versioning and change notice #

10.1 Format version #

agent_policy is the document format version, 0.<minor>. A new minor version only adds members or values; consumers MUST ignore what they do not understand and MUST NOT reject a document only because its minor version is newer. A change that alters the meaning of an existing member needs a new major version of this specification.

10.2 Versions of this specification #

Each version of this specification is published at its own URL (/spec/agent-terms/v1, /v2 …) with its own schema, and stays available after a newer version is published. /spec/agent-terms/latest points to the newest. Corrections that do not change a rule (typos, clearer wording) may be made to a published version and are listed in its change log (appendix B). A new version is announced on https://snuepi.com/spec at least 90 days before snuepi, as a publisher, stops serving documents that conform to the older one.

10.3 Change notice #

  • updated_at SHOULD be present and MUST NOT be in the future. A publisher MUST change it on the day the terms change.
  • New terms apply to contacts and requests made after the publisher serves them. A consumer that cached a copy MUST fetch the terms again before it books, if its copy is older than 24 hours.
  • A publisher SHOULD keep, for each version of a business's terms it served, the exact signed document (or its hash), so that the business and the agent can later show which terms applied.

11. Privacy considerations #

  • A terms document is public. It MUST NOT contain personal data beyond what the business chooses to publish as its contact details. Owners' names, private addresses, and the people behind a company (directors, owners) do not belong in it.
  • Verification blocks carry a tier and a date, never the numbers, names or register data behind them.
  • A consumer MUST NOT send cookies, user identifiers or principal data when it fetches terms. A publisher SHOULD NOT build profiles of consumers from fetches beyond what it needs to show which terms it served.
  • A registry MUST let a business remove its entry at any time, and MUST NOT publish the email address used to list it.

12. Security considerations #

  • Channel URLs and the document SHOULD use https; a consumer MUST NOT act on a document fetched over plain http (section 4.4).
  • A known assistant's name is a claim, not an identity. Identity comes from signed requests (Web Bot Auth) and from verifiers (section 8).
  • A document's tiers are only as good as its signature (sections 7 and 9). An attacker who controls a business's website can change its pointer; a consumer that sees the pointer change to a new publisher SHOULD treat the new terms as unverified until they are signed.
  • Consumers fetching terms on behalf of others (validators, crawlers) MUST NOT fetch private or internal addresses and SHOULD limit redirects, size and time.
  • The guardrails in section 5.11 reduce what an agent can ask for; they do not replace the business's own checks.

13. Conformance testing #

13.1 Tools #

13.2 Rules #

Every finding names one of these rules. A MUST rule is an error (the document does not conform); a SHOULD rule is a warning.

RuleLevelWhat it checks
schemaMUSTThe document conforms to the JSON Schema.
size.maxMUSTAt most 256 KB as UTF-8 JSON.
format.versionMUSTagent_policy is a format this specification defines (0.1 or 0.2).
format.newerSHOULDA newer 0.x format: members unknown to v1 are ignored.
identification.disclosureMUSTidentification.ai_must_identify is true.
contact.phone_hoursMUSTaccepted_in_hours comes with phone_hours.
contact.quiet_hoursMUSTquiet_hours.from and quiet_hours.to differ.
contact.channel_requiredMUSTchannels_only lists at least one channel.
contact.channel_urlsMUSTChannel URLs are absolute http(s) URLs; email is an address.
contact.httpsSHOULDChannel URLs use https.
booking.depositMUSTA deposit has percent or amount, not both.
booking.opening_hoursMUSTA window opens and closes at different times, on days listed once.
booking.special_hoursMUSTA special period starts on or before the day it ends.
booking.special_hours_windowsSHOULDA special period that is not closed lists its hours.
request_types.offeredMUSTrequest_types.offered and each type's offered flag agree.
consultation.presentSHOULDA business that offers consult publishes consultation.
guardrails.uniqueMUSTEach guardrail id appears once.
operator.minimum_tierMUSTminimum_tier_for_fast_path is one of the tiers listed.
verification.checked_atSHOULDA tier comes with checked_at.
verification.signedSHOULDA document that states a tier is signed.
updated_at.presentSHOULDupdated_at is present.
updated_at.futureMUSTupdated_at is not in the future.
signature.presentSHOULDThe document is signed.
signature.validMUSTA signature verifies and covers exactly this document (9.3, steps 1 to 4).
signature.verifiableSHOULDThe publisher's key is found at <iss>/.well-known/jwks.json.
signature.issuer_originSHOULDA signed document is served from its issuer's origin (9.3, step 5).
discovery.foundMUSTA document is found at the well-known URI, through a link, or at the URL given.
discovery.httpsMUSTThe document is served over https.
discovery.pointerMUSTA pointer's agent_terms is an absolute https URL to a terms document.
discovery.legacySHOULDThe well-known URI is /.well-known/agent-terms.json.
discovery.media_typeSHOULDThe document is served as application/json.
document.kindMUSTThe document is a business's terms, not a registry descriptor or a pointer.

13.3 Test vectors #

https://snuepi.com/spec/agent-terms/v1/conformance/index.json lists documents with the result a conforming validator gives: pass, or fail with the MUST rules that fire. The keys the signed vectors use are in the same file.

14. Governance and neutrality #

  • Open. Anyone may implement this specification, publish or consume documents, and build validators, registries or agents on it, without permission, registration or payment.
  • Neutral. A publisher or verifier that follows this specification serves every agent maker on the same terms: the same documents, the same checks and tiers, and the same limits for the same verified facts. Where treatment differs (a higher limit, a faster path), it MUST depend only on published criteria that every agent maker can meet, such as a tier or a signature, never on which agent maker it is. No agent maker gets preferential treatment, and no tier can be bought.
  • Changes. Anyone can propose a change, with the problem it solves and an example, to support@snuepi.com with "Agent Terms" in the subject, until a public issue tracker is announced on https://snuepi.com/spec. Proposals and the editor's decisions are published there. A change that adds a rule is open for comment for at least 30 days before it is published in a new version (section 10.2).

15. Licence #

This specification text is licensed under the Creative Commons Attribution 4.0 International licence (CC BY 4.0). The JSON Schema, the examples, the test vectors and the reference validator are licensed under the Apache License, Version 2.0. Implementing the specification requires no licence at all.

Appendix A. Examples per sector #

Each example is a complete, signed document (section 9.4). They show the terms a business in that sector typically sets; any business can set any term.

SectorExample
Trades and repairs (a plumber)https://snuepi.com/spec/agent-terms/v1/examples/trades.json
Cleaninghttps://snuepi.com/spec/agent-terms/v1/examples/cleaning.json
Outdoor and movinghttps://snuepi.com/spec/agent-terms/v1/examples/moving.json
Beauty and appointments (a hair salon)https://snuepi.com/spec/agent-terms/v1/examples/salon.json
Hospitality (a restaurant)https://snuepi.com/spec/agent-terms/v1/examples/restaurant.json
Professional services (a law firm)https://snuepi.com/spec/agent-terms/v1/examples/law-firm.json
Financial services (an accountant)https://snuepi.com/spec/agent-terms/v1/examples/accountant.json
Health (a dental clinic)https://snuepi.com/spec/agent-terms/v1/examples/dental-clinic.json
Retail (a shop)https://snuepi.com/spec/agent-terms/v1/examples/shop.json

A minimal conforming document:

{
  "agent_policy": "0.2",
  "business": { "name": "Salon Kim", "country": "DE" },
  "identification": { "ai_must_identify": true },
  "contact": { "agents_may_contact": "channels_only", "request_page": "https://salon-kim.example/book" },
  "updated_at": "2026-10-29"
}

Appendix B. Change log #

  • Version 1 (29 October 2026). First version of this specification. It specifies document format 0.2, which the Agent Policy drafts (0.1 on 24 October and 0.2 on 26 October 2026) introduced, and adds: the well-known URI agent-terms.json with pointers, the agent-terms link relation, the signature profile, the verification and operator tiers, the conformance rules and the test vectors.

Appendix C. References #

  • BCP 14: RFC 2119 and RFC 8174, key words for requirement levels.
  • RFC 7515, JSON Web Signature; RFC 7517, JSON Web Key; RFC 8037, CFRG curves (Ed25519) in JOSE.
  • RFC 8259, JSON. RFC 8615, well-known URIs. RFC 8288, web linking.
  • RFC 9421, HTTP Message Signatures; Web Bot Auth (IETF draft), signing agent requests with keys in a domain's key directory.
  • schema.org OpeningHoursSpecification.