Full-Access Onboarding — What to Send Us

A one-page checklist for a client onboarding via the full-access route (typed, callable agent actions against your real systems — the "aevum pattern"). If you'd rather share nothing and let us crawl your public site instead, you want the crawl-only route — ask us for that checklist.

Full-access has two layers, and you can mix-and-match the options within each:

• Layer 1 — Content surface (your public pages → llms.txt, docs, context, changelog)
• Layer 2 — Actions (real operations agents can call against your backend)

You do not need to hand over your entire codebase. We only ever read your public, rendered pages — internal files, business logic, and secrets are never ingested.

Layer 1 — Content surface: pick ONE option

Option A — A built/exported static site (recommended, cleanest)

Send the output folder of your site build (e.g. dist/, out/, build/, public/ from Next/Astro/Hugo/etc.), as a zip or a repo we can clone.

• A folder containing already-rendered HTML (not raw framework source — our ingest does not run JavaScript, so client-side-only content will come through empty).
• A sitemap.xml at the folder root listing your public pages (recommended). Without it we ingest your homepage only.
• For every URL in the sitemap, a matching file at <path>/index.html or <path>.html (a normal static build already does this). Homepage → index.html at the root.

Option B — A git repository

Give us read access (or a zip) to a repo that contains the built HTML as above.

• Repo URL + access, or a zip of a checkout.
• Same file layout as Option A (sitemap.xml + <path>/index.html). If your repo only holds un-built source, run your build first and send the output, or use Option C.

Option C — A copy of your deployed site files

If your live site is already static HTML on disk somewhere, send us a copy of that directory.

• The directory of served .html files + sitemap.xml.
• Note if/how it changes, so we can arrange refreshes.

Option D — Send nothing; we crawl your live site

Fallback if you can't export files (or your site is a client-rendered SPA). We fetch your rendered public pages directly.

• Your public site URL.
• Confirmation we're allowed to crawl it (and any paths to avoid).

Minimum for any file-based option (A/B/C) to work: at least one readable HTML file that maps to a sitemap path — or just an index.html at the root if you send no sitemap.

Layer 2 — Actions: pick ONE option (this is the "full-access" part)

Actions are the operations an agent can actually do (submit an enquiry, create an order…). They require a backend endpoint for us to call, secured by a shared secret.

Option 1 — You expose existing backend endpoints

• Your backend base URL (e.g. https://api.acme.com).
• For each action: the path, method, request shape, and response shape.
• Confirmation your endpoint will verify our HMAC signature on incoming requests (we generate and share a per-tenant ORIGIN_SECRET; you check it — reference: aevum's POST /api/agent/enquiry).

Option 2 — We add agent endpoints to your backend (collaborative)

• Access/PR path into your backend, or a contact who can merge a small addition.
• The list of operations you want agents to perform, and the business logic each should run.
• A place to store the shared ORIGIN_SECRET in your environment.

Option 3 — You already have an OpenAPI spec → we import it (fastest, no hand-coding)

• Your OpenAPI 3.x spec — a URL (e.g. https://acme.com/openapi.yaml) or the raw JSON/YAML file.
• The API base URL, if the spec doesn't declare it.
• The API credential (bearer token / API key / HMAC secret) for any operation that changes data — we store it envelope-encrypted; it's never echoed back.
• Written confirmation of exactly which write/mutating operations you authorize us to switch on (read-only operations go live automatically; anything that changes data stays off until you sign off, one operation at a time).

Regardless of options — always send us

• Business name + one-line description (for your agent manifest).
• The agent subdomain you want (typically agents.<your-domain>), so you can point a CNAME at us. That DNS record is the only change we require on your side — see the three strongly-recommended additions below for what makes the surface findable.
• A technical contact for the HMAC secret exchange and go-live check.
• How your content stays fresh (repo/CI hook, a re-export cadence, or "please re-crawl on a schedule") — so your agent surface never goes stale.

Three one-line additions so agents can actually find you (strongly recommended)

Everything above gets your surface built, served and callable. Three lines on your live site get it found.

Your surface ships every discovery mechanism an agent looks for — llms.txt, a manifest at /.well-known/b2a.json, HTTP Link: headers, a generated OpenAPI document, an MCP endpoint — and every one of them fires the moment a client visits agents.<your-domain>. What none of them can do is announce that the address exists: search engines learn about a new address by following ordinary links and reading sitemaps. Give them one of each and your surface — plus the actions behind it — enters the index that ChatGPT, Claude and Gemini answer from. Skip it and your actions can be fully live, signed and working, and still nobody finds them.

Three additive one-liners on your live site. If your site is built from the repo or export you're already sharing with us, all three are ordinary template/config edits:

• One link from your website to your agent surface — an ordinary anchor pointing at https://agents.<your-domain>/, with text like "For AI agents" or "Agent & API access". A footer link is enough: it needn't be in your main navigation, and most human visitors will never notice it. This single link is the one mechanism every search crawler follows.
• One line in your live site's robots.txt: Sitemap: https://agents.<your-domain>/sitemap.xml. Unlike a comment, a Sitemap: directive is a real machine-read instruction — and it's the only discovery mechanism robots.txt actually has.
• One entry in your live site's sitemap.xml for https://agents.<your-domain>/. (This is your public site's sitemap, not the one inside the export you send us.)

We pre-fill them for you. Once your surface is live we publish a ready-to-paste pack at https://agents.<your-domain>/docs/discovery-pack.md — all three snippets with your real domain already substituted, the search-console steps below, and your MCP Registry namespace. Your engineers copy and paste rather than composing anything.

One step only you can take: submit https://agents.<your-domain>/sitemap.xml in Google Search Console and Bing Webmaster Tools. Verification is restricted to the domain owner, so we can't do it on your behalf. Do both — Bing feeds ChatGPT's search, Google feeds Gemini.

What you lose without them

Nothing about the surface breaks. Any agent given the URL gets the whole thing — artifacts, typed actions, signed receipts — and anything that discovers you through the MCP registry works too. What won't happen is your surface appearing in Google or Bing, and therefore it won't come up when someone asks ChatGPT, Claude or Gemini about you: those products answer from a conventional search index rather than crawling the live web. This is not a limitation of our platform; it's how search discovery works for any new address on the web.

No new access needed: these three edits ask nothing more of you than what you've already shared — no extra repo permissions, no backend change, no additional secrets. They touch only your public site's page template and two text files, they're purely additive, and they cannot break your site.

Business details for AI search (optional — recommended)

We automatically publish a machine-readable entity record of your business (schema.org structured data) that AI search engines — ChatGPT, Perplexity, Google's AI overviews — use to identify and quote you accurately. From your content alone we can derive the basics; if you send the details below, the record is upgraded to the kind search engines show rich results for:

• Business type (e.g. local business, clinic, professional service).
• Registered/legal name (if different from your brand name).
• Phone number and full address (street, postal code, country).
• Opening hours (if you have physical premises or fixed service hours).
• Your official profiles — LinkedIn, Facebook, Instagram, Google Business Profile URLs (these disambiguate you from similarly named businesses).
• Your key services/offerings — name + one line each (5–10 is plenty). On the full-access route these sit alongside your callable actions: the entity record is what AI search quotes; the actions are what AI agents call.

None of this is published anywhere it isn't already public — it just makes the machine-readable version authoritative instead of guessed. We'll also send you a small snippet your web person can paste into your site's <head> so classic search engines pick it up too — one paste, alongside the three additions above — unless your pages already carry schema.org structured data, in which case we leave yours in place.

Make your content produce a great surface (optional, but it raises your audit score)

The higher-quality your rendered HTML — whether you send it (Options A/B/C) or we crawl it (Option D) — the richer and more accurate your agent surface. Ideally every page has:

• A sitemap.xml listing your public pages (Options A/B/C: at the folder root — without it we ingest your homepage only; Option D: at https://<your-domain>/sitemap.xml).
• Already-rendered HTML — real content in the page source. Our ingest does not run JavaScript: a client-rendered SPA comes through mostly empty. Send a static build, or server-render/prerender before we crawl.
• A <title> and <meta name="description"> on each page.
• Clear <h1>/<h2> headings and readable body text (this is what agents read).
• Internal links between pages (on a crawl, we follow same-site links to discover content).

Quick reference — minimal file layout (Options A/B/C)

your-site-export/
├── sitemap.xml          # lists your public URLs (recommended)
├── index.html           # homepage  → "/"
├── about/index.html     # → "/about"      (or about.html)
├── pricing/index.html   # → "/pricing"    (or pricing.html)
└── contact/index.html   # → "/contact"    (or contact.html)

What we read: <title>, <meta name="description">, <h1>/<h2> headings, visible text, and same-site links — from the rendered HTML only. What we never read: source code, server logic, databases, config, or secrets.