Your Next Customer May Arrive as Someone Else’s Agent

Most “AI on the website” projects assume a person is clicking through pages. Many of those people now send an agent instead.

OpenAI’s ChatGPT Work lives inside a product millions already use. It connects to apps and files and tries to turn a goal into finished work. Coding and research tools do the same.

The visitor already has a worker that can read, call tools, and come back with a recommendation or a booking attempt.

When that worker shows up, can it finish one real job against your business, or must it scrape a brochure and guess?

Two different agent problems

Agents you operate sit in your stack: intake, triage, drafting, dispatch. You pick the model, the tools, the authority, and the human gates. Earlier notes on this site cover how to score a workflow, when to keep models off deterministic steps, and how to design oversight.

Agents you host for belong to the customer, a coordinator, or someone at another company. They arrive with a task. Hours and next opening for a consult. Price range for a service. Book Thursday after 3.

They will try your site, your schema, and your tools. If that fails, they call a competitor whose facts are easier to consume.

The second problem looks like an ordinary website: hero copy, a phone number, a form that emails someone on Monday. Teams skip it because it looks unlike an AI project.

Cloudflare has described an “agentic internet” as readable, discoverable, callable, and payable. Agents need structured ways to find services, invoke them, and settle. Skip unused protocols. If the next visitor is software acting for a person, treat a PDF of your services menu as a dead end.

What the visiting agent needs

The Model Context Protocol is one open attempt to standardize how an LLM app shares context and exposes tools. In the 2026-07-28 spec, hosts start connections, servers expose resources and tools, and the contract is JSON-RPC with explicit capabilities.

Skip MCP if you like. Offer something an agent can treat as a tool, not a mural.

For a local or professional-services business, the useful surface is boring:

• Hours, locations, service names, duration, what is included, what is not, cancellation rules, languages, and who is eligible.
• A named job with a finish line: request a consult, check the next slot, submit a scoped quote. “Learn more” fails.
• Callable actions with schemas. The agent fills service, date window, contact, constraints. It can verify a confirmation id, a waitlist position, or “a human will confirm by 4pm.”
• Authority and refusal. What it may complete alone, and what needs a person. Booking inside published hours is not the same as a custom medical exception.
• Receipts. What was asked, what was done, what is still pending.

Anthropic’s guidance still applies: start with the simplest thing that works, get ground truth from the environment, and add complexity only when it earns its keep. A structured availability tool beats a “virtual receptionist” that invents policy.

Why the marketing site fails as an API

Agents can browse. Browsing is still a weak contract.

Marketing pages optimize for persuasion. They bury the price, rotate offers, and hide exceptions in FAQs. A person can squint and call. An agent that must not invent facts will refuse, or it will hallucinate a package you do not sell.

Forms that only produce an email fail the same way. The visiting agent cannot tell whether the request landed, who owns it, or when a human will answer. From its point of view the job did not complete.

On-site chat widgets make this worse when they are treated as “agent-ready.” They compete with the visitor’s own agent, add another untrusted voice, and still dump into the same inbox.

The visitor already has ChatGPT, Claude, or Codex on the open page. Be a reliable counterpart.

A three-step maturity ladder

Phase 1. Humans only, off-site. Phone, text, walk-in. The website is a brochure. Fine if volume is low and staff always answer. Fragile when a valuable customer is comparing three providers at 9pm through an assistant.

Phase 2. Humans can finish the job on the site. Real booking, real quote request, real portal. Ordinary good software. Many businesses are still here, or halfway here with a third-party widget that does not expose clean data.

Phase 3. The visitor’s agent can get service facts and finish a bounded job. Same outcome as phase 2, offered as structured tools and evidence. Same authority limits you would give a careful junior employee. A machine acting for the buyer can finish the path you already trust a human to finish. A chatbot leaves you short.

Sell ahead to phase 3 if the buyer already uses agents. Catching up to phase 2 is still worth doing. It is a different product.

What to ship first

Pick one job that already costs money when it fails: missed consults, after-hours inquiries, repeat reschedules. Watch how a person does it today. Write the outcome as a verb plus a proof.

Then implement, in order:

1. Canonical facts in one place the site and any tool both read. No conflicting hours across Google, the footer, and a PDF.
2. A machine-readable description of services and constraints. A well-maintained JSON or schema page is enough to start.
3. One tool with a tight input schema and a verifiable result. Read the record back after a write.
4. Gates on irreversible or regulated steps. The visiting agent can request. A person still confirms when blast radius is high.
5. Logs the owner can sample: who called, which tool, which arguments, which result, which refusal.

If you later expose that tool over MCP, a plugin, or a site-level WebMCP-style surface, you are packaging work you already trust.

Limits

Decide whether one high-value path can be completed by a careful agent without inventing facts. Leave forecasts about replacing bookers, or machine-to-machine traffic on someone else’s timetable, to other people.

Keep write access off systems the agent has no business touching. Keep authority in the workflow. A booking endpoint with a cap and a confirmation is safer than a general “do anything on our CRM” server.

If an assistant cites you, that is a side effect of being factual and callable. The product is completed jobs and fewer dead-end inquiries.

A short test

Ask a colleague to use their existing assistant, not your widget, on your public site:

1. What services exist, with duration and constraints?
2. Next availability in a stated window?
3. Complete or request the job, and show proof.

Where the assistant guessed, you have a content or schema gap. Where it could not act, you have a missing tool. Where it acted without a receipt, you have an audit gap.

Fix those three. Until then, an after-hours agent still waits for someone to read email.