The Agent Gateway Is the New Front Door to Your Website

Your next website visitor may never load your website.

They may ask an AI agent to compare three products, check an integration, clarify pricing, test a requirement, and return with a recommendation. The agent will do the research. The buyer will see the result.

Most companies are preparing for that world by making their pages easier to scrape.

We think that stops one layer too early.

The more interesting architecture gives the buyer's agent a front door: a discoverable, governed endpoint where it can talk directly to the company's agent, carry context across turns, qualify fit, and bring in a human when judgment is required.

That is what we mean by an Agent Gateway.

"Agent gateway" currently means two different things

The infrastructure market already uses AI gateway or agent gateway for a control point between an application and its models, tools, and agents.

Cloudflare AI Gateway sits in front of model providers and adds logging, analytics, caching, rate limits, retries, and fallback. Kong AI Gateway extends the same pattern across model traffic, MCP, and Agent2Agent (A2A), with provider-independent routing, access controls, guardrails, and observability.

That is an outbound infrastructure gateway:

your application → gateway → models, tools, and internal agents

It is necessary infrastructure. It answers questions like:

• Which model should handle this request?
• Is this caller allowed to use this tool?
• How much did the request cost?
• What should happen if the provider fails?
• Which prompts, responses, and tool calls need to be logged?

We are building the gateway on the other side of the company boundary:

buyer's agent → gateway → your company's agent, knowledge, workflows, and team

This is an inbound business gateway. It answers a different set of questions:

• How does an external agent discover that your company has an agent?
• What can that agent safely ask or do?
• How does a conversation survive across separate calls and agent sessions?
• When does research become qualification, a trial, a meeting, or a human conversation?
• How does your company observe and govern a machine-originated buyer journey?

These two gateways are complementary. One governs how your software uses AI. The other governs how outside AI agents interact with your business.

Why this is moving from idea to infrastructure

Three layers are converging.

1. AI clients can now call remote tools

This is no longer limited to a local developer running a tool server.

ChatGPT developer mode supports remote MCP servers over Streamable HTTP or SSE, including read and write tools with confirmation controls. Claude custom connectors let users add a remote MCP server by URL and selectively enable its tools in a conversation.

The important point is not that every buyer does this today. They do not.

The important point is that the dominant agent clients now have a common way to connect to remote, company-operated capabilities. The transport layer is becoming real before the distribution layer is automatic.

2. The protocols are becoming gateway-friendly

The July 2026 MCP specification moved its core protocol from stateful sessions to stateless request/response. Requests now identify their method and tool in HTTP headers, making it practical for gateways and WAFs to route, meter, and authorize agent traffic without parsing every JSON body.

A2A addresses the adjacent problem. The A2A Protocol distinguishes agent-to-agent communication from MCP's agent-to-tool communication and uses an Agent Card to describe what a remote agent can do without exposing its private memory, tools, or implementation.

The shape is familiar to anyone who watched web infrastructure mature: common transports first, then discovery, identity, policy, observability, and increasingly capable transactions.

3. The web is becoming machine-readable at request time

The llms.txt proposal gives agents a concise map of a site's important, LLM-readable content. It is useful, and it is still a proposal—not a universal discovery standard or proof that a major assistant will automatically prioritize a company's file.

That distinction matters.

An llms.txt file makes a website easier to read. A gateway makes a company possible to converse with. One curates documents; the other exposes a live capability.

Reading the website is not the same as talking to the company

A crawl is one-way and usually stateless.

An agent fetches a pricing page, a security page, and three docs pages. It decides which passages matter, resolves contradictions as well as it can, and writes an answer. If the pages are stale or ambiguous, the agent either guesses or reports uncertainty.

A conversation is different:

• The company can ask a clarifying question.
• The buyer's agent can test a specific edge case.
• Each turn can carry the context of the previous one.
• The company can distinguish a general research question from real buying intent.
• The interaction can move to a person when policy, pricing, or technical nuance demands judgment.
• The result can be an outcome rather than another document.

This extends the argument we made in AI-Native Buyer Experiences in 2026: the buyer journey is becoming more self-directed. The new wrinkle is that "self-directed" increasingly includes software acting on the buyer's behalf.

The architecture of a public agent gateway

Here is the public architecture we have built at Aimdoc. The implementation will evolve, but the layers are the important part.

Layer 1: discovery

A company first needs a machine-readable way to say: there is an agent here, this is what it represents, and this is how to reach it.

Aimdoc provides a discoverability kit with:

• An llms.txt entry that points agents toward the gateway
• A small JSON manifest at a well-known path
• An HTTP Link header or HTML link marker for clients inspecting normal pages
• Direct URLs for the conversational and MCP surfaces

We deliberately support more than one marker because discovery is still fragmented. llms.txt is an emerging convention. A2A defines Agent Cards for A2A-speaking agents. MCP standardizes interaction with a known server, not universal website discovery. Calling any proprietary manifest the standard today would be premature.

The practical goal is graceful adoption: work with fetch-only agents now, MCP clients now, and more automatic discovery later without requiring a customer to rebuild the underlying agent.

Layer 2: two transport surfaces

The Aimdoc Agent Gateway exposes the same company agent through two public interfaces.

The first is plain HTTP. An agent can fetch an introduction, send a message with GET or POST, receive a reply, and read the conversation later. This matters because many research and browsing agents can fetch URLs but are not operating as full MCP clients.

The second is a public MCP endpoint over Streamable HTTP. It exposes a deliberately small tool surface:

• Discover the agent's capabilities
• Ask the agent a question
• Read an existing conversation, including a later human reply

The channel is intentionally text-only. It does not expose the website widget's question cards, embedded calendar, or page-navigation controls; scheduling and other handoffs happen through conversation and human escalation.

Both interfaces are documented in the public Agent Gateway technical guide.

Protocol purity is less important than reach. A gateway that only works with the newest client is a demo. A gateway should degrade cleanly from structured tool use to ordinary HTTP.

Layer 3: explicit conversational state

The web request may be stateless; the buying conversation should not be.

After the first turn, Aimdoc returns a conversation token. The calling agent passes that token on later turns and can reuse it in a future session. That makes asynchronous workflows possible:

1. A buyer's agent asks a technical question.
2. The company agent answers or escalates.
3. A human joins after the original request has ended.
4. The buyer's agent returns later, reads the reply, and relays it to the buyer.

The state belongs to the conversation, not to an open socket or one model's context window. This is a small architectural choice with a large product consequence: agent-to-agent buying does not need to happen in a single synchronous burst.

Layer 4: one runtime across human and agent channels

The gateway is not a second FAQ bot.

An Aimdoc gateway conversation enters the same core agent runtime used for the website experience. It can use the same published knowledge, qualification criteria, escalation logic, contact workflows, and human handoff.

That continuity is the product.

A buyer researching through an agent should not receive one set of answers while the website agent gives another. If the interaction becomes a trial or an in-product journey, it should not restart from zero. We have written about this continuity from the human side in The AI SDR Is Finishing the Sentence the Website Started and AI Support for B2B SaaS. The gateway adds a new starting surface to the same journey.

Layer 5: identity, policy, and human judgment

A public gateway has a different trust model from an authenticated internal MCP server.

Aimdoc's public gateway can accept a self-declared agent name, model, and the email of the person it claims to represent. Those fields are useful context, but they are explicitly treated as unverified hints—not authenticated identity.

That boundary is important. Public research access should never silently become authority over private account data or destructive actions.

The gateway is therefore:

• Off by default and enabled per published agent
• Limited to the business's public-facing agent, not its private Aimdoc account data
• Constrained by message bounds, traffic limits, configurable daily capacity, and session logging
• Designed to separate machine-originated sessions in the operator view
• Able to escalate to a human instead of inventing certainty

Aimdoc also has an authenticated MCP server for customers working with their own Aimdoc data. That is a different surface with a different identity model. Combining the two because they share a protocol would erase a security boundary that should remain obvious.

What we are not claiming

The fastest way to make this category untrustworthy is to overstate what exists.

So, precisely:

• We are not claiming that ChatGPT, Claude, Gemini, or Grok automatically discover and call every published gateway today.
• We are not claiming that llms.txt is a ratified universal standard.
• We are not replacing an infrastructure AI gateway that routes model or internal tool traffic.
• We are not exposing a company's private systems to anonymous agents.
• We are not treating a caller-provided email as verified identity.

We are saying that the client support, protocols, and web conventions needed for a direct company-to-buyer-agent channel are arriving quickly—and that the company-side endpoint is worth building before distribution becomes default.

What will matter over the next six months

The next phase will not be won by the longest tool list. It will be won by trust and useful outcomes.

Discovery will remain plural for a while

Expect llms.txt, HTTP link relations, MCP server URLs, A2A Agent Cards, directories, and vendor-specific connectors to coexist. Companies should publish portable descriptions and avoid coupling their business logic to one discovery mechanism.

Public and authenticated capabilities will separate

Research, qualification, and public product guidance can be open. Account-specific data and consequential actions require stronger identity, scoped authorization, and often explicit approval. Good gateways will make that distinction visible to both the calling agent and the operator.

Agent analytics will become part of go-to-market analytics

Teams will want to know which agents arrive, what they ask, where they get stuck, what they hand back to buyers, and when the interaction turns into a human conversation or product event. A gateway makes that traffic observable in a way anonymous scraping is not.

The endpoint will need to produce outcomes

Static answers are the first rung. The higher-value path is a governed progression from answer, to qualification, to scheduling, to a provisioned and configured trial—with human confirmation wherever the risk demands it.

That is the direction of Aimdoc Website, the Agent Gateway, and Aimdoc Application: one agent and one context layer across the buyer's agent, the website, the human team, and the product.

The website is not disappearing. Its audience is expanding.

Humans will keep visiting websites.

But a website built only for human eyes assumes the buyer is the first system to arrive. Increasingly, the buyer will send software ahead to gather facts, test fit, and compress the shortlist.

The first generation of agent-ready websites will publish cleaner text.

The next generation will publish a controlled way to talk back.

That is why we believe the Agent Gateway becomes a meaningful piece of company infrastructure: not another chatbot on the page, and not another proxy in front of a model, but a front door for the agents acting on behalf of the people you want to serve.

Want to see the public interface in practice? Explore the Aimdoc Agent Gateway, read the technical guide, or book a demo.