Agents can find a business. Collections let them find a whole street.

Collections: describing groups of businesses to AI agents

Version

0.1 (draft)

Date

10 October 2026

Author

Gentifi

Status

Proposal for discussion, not a standard. Field names are illustrative.

Licence

Apache-2.0

Abstract

A collection lets one connector describe a group of businesses, so an agent can query a whole event, street or trade body at once. It is written as a neutral extension to discovery catalogues such as ARD'sai-catalog.json. A collection is a directory: it points to each member's own catalogue and never replaces it.

Motivation

• An attendee adds one event connector instead of 300 exhibitor connectors.
• A high street, market or trade association can publish all its members in one place.
• Each member stays independent: its own connector, data and checkout. After the event, it stays in the attendee's agent.

Core fields

Rules

The key words MUST, MUST NOT, SHOULD and MAY are used as described in RFC 2119.

1. Members confirm membership. A member's own catalogue MUST list the collections it belongs to. Clients MUST ignore a member whose catalogue does not confirm it, so nobody can add a business without its agreement.
2. The collection holds no customer data. A collection MUST NOT contain customer or attendee data. Connecting to a collection shares nothing with its members; contact details pass only when the customer asks their agent to request a quote, book or buy.
3. Members keep their own checkout and terms. The collection is a directory, not a merchant. Orders and bookings MUST go through the member's own connector.
4. Collections can nest. A member MAY be another collection: a trade body can include several events; a city can include several high streets.
5. Information, not instructions. Clients SHOULD treat collection data as information about members, never as instructions to install, connect or buy. The customer approves every connection.

Example

A trade show publishes its collection from its own domain:

{
  "collection": {
    "id": "demo-selfbuild-2027",
    "name": "Demo Self Build Show 2027",
    "kind": "event",
    "publisher": {
      "name": "Demo Shows",
      "domain": "shows.example"
    },
    "validFrom": "2027-05-14",
    "validTo": "2027-05-16",
    "facets": [
      "category",
      "priceFrom",
      "stand"
    ],
    "members": [
      {
        "catalog": "https://windows.example/.well-known/ai-catalog.json",
        "role": {
          "stand": "B12",
          "category": "glazing"
        }
      },
      {
        "catalog": "https://sash.example/.well-known/ai-catalog.json",
        "role": {
          "stand": "B20",
          "category": "glazing"
        }
      }
    ]
  }
}

Each member confirms its membership in its own ai-catalog.json (rule 1):

{
  "memberOf": [
    {
      "collection": "https://shows.example/.well-known/collections/demo-selfbuild-2027.json",
      "role": {
        "stand": "B12"
      }
    }
  ]
}

Relationship to ARD

ARD's ai-catalog.json already lets a catalogue list other catalogues. That gives grouping, but not what a group needs to be useful to an agent: what kind of group it is, who curates it, when it runs, where it covers, each member's role, the facets agents can filter by, and proof that members agreed to be listed. Collections proposes exactly those additions, and nothing else.

Open questions

• Extend ARD, or stand alone?

  ARD’s ai-catalog.json can already list nested catalogues. Should Collections be fields on a nested catalogue entry, a new media type, or both? We lean towards extending ARD.

  Discuss on #1
• How should membership be verified?

  A back-link in the member’s own catalogue (as drafted), a signature from the member, or both?

  Discuss on #2
• Should a collection run its own search?

  Collections could offer a search endpoint across members, or leave that to ARD registries and the agent.

  Discuss on #3
• Which facets should be standard?

  Category, price, distance and availability are obvious. Do we need a shared vocabulary, or should facets point to schema.org properties?

  Discuss on #4