We gave our website an AI agent endpoint. Here is how.

Why agent-friendly matters now

For twenty years we built websites for human eyes. That assumption is breaking. People increasingly ask an AI assistant to research, compare, and even act for them, and that assistant arrives at your site as software, not as a person with a browser and patience.

Three open standards landed in the last year that make this real. Anthropic's Model Context Protocol connects assistants to tools. Google's Agent2Agent protocol lets independent agents discover and talk to each other. Google's Agent Payments Protocol adds signed mandates so agents can transact with accountability. The common thread is that machines are becoming first-class visitors, and a site that only speaks to humans is invisible to them.

We build AI agents for a living, so it would be strange to have a website that agents could not read or engage. We fixed that. Everything below is live on this domain right now.

Two kinds of agent-friendly

It helps to split the work into two goals that need different solutions.

• Readable. Can an AI system fetch your pages, understand what you do, and cite you accurately? This is about access and structure.
• Actionable. Can an agent actually do something with you, like check availability or start a booking, through a defined interface rather than by guessing at your forms? This is about exposing real capabilities.

Most sites are weak on both. The good news is that the readable half is mostly configuration, and the actionable half is smaller than it sounds if you already have an API.

1Let the AI crawlers in, on purpose

The first job is access. Many sites accidentally block AI crawlers, or name them with typos that match nothing. We rewrote our robots.txt to stay open and to name the current crawlers correctly, because the list has changed and old guides are out of date.

The ones that matter today include ClaudeBot for Anthropic, GPTBot and the separate OAI-SearchBot and ChatGPT-User for OpenAI, PerplexityBot, Google-Extended for Gemini, and CCBot for Common Crawl, which feeds many open training sets. We had an old CC-Bot entry with a hyphen that quietly matched nothing, so we fixed it.

One structural point is easy to miss and more important than any crawler rule. Most AI crawlers do not run JavaScript. If your content only appears after a client-side render, an agent sees an empty shell. Our site ships its real content in the HTML, which is the single biggest thing you can do for machine readers.

2Add an llms.txt

An llms.txt is an emerging convention, a short Markdown file at the root of your site that gives a language model a clean map of your most important pages with a one-line description for each. Think of it as a curated table of contents written for machines instead of a sprawling sitemap.

Ours opens with a small block of facts for accurate citation, the company name, location, focus, and notable work, then lists flagship pages, services, research, and contact. When an assistant summarizes us, it now has a reliable source rather than a guess. It is not a ranking factor and not every engine reads it yet, but it is cheap and points in the direction the web is moving. You can read our llms.txt directly.

3Make your actions machine-readable

Structured data turns prose into facts a machine can trust. Our pages already carry schema.org JSON-LD that declares the organization, services, location, and reviews. The gap was that none of it described what an agent could do.

So we added a potential action to our business entity. In plain terms, it tells an agent that this organization supports a booking action, and here is the endpoint and the platforms it works on.

"potentialAction": {
  "@type": "ReserveAction",
  "name": "Book a free AI consultation",
  "target": {
    "@type": "EntryPoint",
    "urlTemplate": "https://www.elephantclock.ae/get-free-consultation.html"
  }
}

This is the difference between an agent knowing you exist and knowing how to engage you.

4Publish an A2A Agent Card

The Agent2Agent protocol gives agents a standard way to discover each other. The discovery document is an Agent Card, a JSON file served at /.well-known/agent-card.json. It states who you are, how to reach you, and the skills you offer.

Ours declares two skills, one to describe our services and one to book a consultation, along with the endpoint and protocol version. Any A2A-aware tool that scans for a card will now find ElephantClock, read its skills, and know where to connect. You can fetch our Agent Card and see the whole thing.

A small but real detail we hit along the way. Most web servers deny every path that starts with a dot for security, which also blocks the .well-known directory the protocol depends on. We added a narrow exception that opens .well-known only, while files like .git and .env stay blocked.

5Make the endpoint actually callable

A card that points to a dead endpoint is just decoration. So we made ours respond. An agent can send a standard JSON-RPC message/send to our endpoint and get a real answer. Ask about our services and it explains them. Ask to book and it pulls live availability from our calendar and returns the next open times with a link to confirm.

POST https://www.elephantclock.ae/a2a/v1
{ "method": "message/send",
  "params": { "message": { "parts": [
    { "kind": "text", "text": "book a consultation" } ] } } }

-> "The next available times (Asia/Dubai) are:
    Wed 1 Jul, 09:00 ... plus a link to confirm."

We built this as a small separate service that only reads our existing booking API. It runs in its own process, so the agent endpoint cannot affect the live chat or the real booking flow. If it ever fails, nothing else does.

Be honest about what it can do

Our endpoint is deliberately read-only for now. It shows availability and hands off to the booking page, but it does not create bookings by itself. That is a choice, not a limitation we forgot about.

A public endpoint that writes to a real calendar is an open door for spam and abuse. Before an agent can complete a booking end to end, it needs verification, rate limits, and clear accountability for who authorized the action. This is exactly the problem the new agent protocols are built to solve, and we wrote about the infrastructure side of it in our Agentic Linux Runtime whitepaper. Shipping the safe version first, and saying so plainly, is the honest way to do this.

What you can take from this

You do not need all five steps to start. The order we would recommend is simple.

• Open your robots.txt to current AI crawlers and make sure your content lives in real HTML.
• Add an llms.txt so assistants can describe you accurately.
• Add a schema.org action that names what an agent can do.
• Publish an A2A Agent Card if you want to be discoverable by other agents.
• Make the endpoint callable, starting read-only, when you have an API to expose.

The agentic web is early, and most of these conventions will keep changing. That is the point of doing it now. The cost is low, the signal to your market is strong, and you learn how agents actually behave against a real site instead of a slide.