Where to deploy a site agent in 2026: the marketplaces that already list them

Published July 10, 2026 · Last reviewed July 10, 2026

You built a site agent, an AI representative that answers questions about your product and can hand a real conversation to a person. The next question is not “how do I write the prompt.” It is “where does this thing live so that people, and increasingly their agents, actually find it.” That question has more real answers in 2026 than most teams expect, and the answers are not equivalent.

Three kinds of surface exist right now. Developer marketplaces list agents and agent services with billing and install flows attached. Site-builder app stores put an agent on the page itself. And a handful of large platforms host a customer-facing agent entirely inside their own walls. Each one hosts or lists your agent. Picking the right one depends on who you want to reach and what you are willing to give up.

Here is the honest map: what each surface expects, how the good ones pay, and the one thing none of them provides that decides whether a buyer’s agent can ever reach you.

What “deploy a site agent” actually means

Deploying a site agent is two jobs, not one, and conflating them is where most plans go wrong.

The first job is to run it. The agent needs a place to execute, a way to bill, credentials, and a stable endpoint. This is the part every marketplace below solves well, because it is a hosting and packaging problem the cloud industry has been refining for a decade.

The second job is to make it findable, and findable by whom. A widget on your own homepage is reachable by a human who is already there. A listing in a catalog is reachable by a human who browses that catalog. Neither is reachable by the buyer’s agent that arrives from somewhere else, mid-task, with a question its human asked thirty seconds ago. The gap between “running” and “reachable by an agent that is not already on your site” is the gap this guide keeps returning to, because it is the one the market has not closed. For the difference between an agent that reads your page and one that can be reached and talked to, agent-readable is not the same as agent-addressable.

The developer marketplaces already listing agents

If your site agent is packaged as software, three developer surfaces will list it today.

The Vercel Marketplace added an “AI agents and services” category on October 23, 2025. It splits the world into two useful halves: Agents, which do specialized work on your behalf, and Services, which give you the infrastructure to build your own. It comes with the thing that makes a marketplace worth using: unified billing, a shared observability dashboard across every install, and a setup flow that takes a few clicks.¹ Listings skew toward developer tooling, agents like CodeRabbit, Corridor, and Sourcery, services like Chatbase, Browser Use, and Descope, so this is the right surface if your agent is something other builders plug into, less so if it is a sales representative for a plumbing company.

Railway takes a different angle and is the clearest on money. You publish your agent as a deployable template, and when other people deploy it, Railway pays you a kickback on the usage their deployment generates: 15 percent of the usage cost, rising to 25 percent when you actively support users through the template queue, taken in credits or cash.² That aligns incentives cleanly. You are paid in proportion to how much real work your template does for other people, which rewards something that runs well rather than something that merely demos well.

GitBook sits in a narrower lane that matters if your agent’s job is answering questions from documentation. Its integrations directory, with precedents like Inkeep and kapa.ai, is where a docs-grounded support agent gets installed next to the content it answers from.³ The expectation on all three surfaces is the same in spirit: a working integration, a clear description of what the agent does, and a review before it goes live. None of the three is instant, and none is a place a stranger’s agent goes hunting for a vendor.

The site-builder surfaces: Webflow, Shopify, Bubble

The second family is where your agent lives on the actual website, not in a developer catalog.

Shopify, Webflow, and Bubble each run an app store, and each has an established pattern for embedding a conversational agent into a live site through an app or a script. For a commerce or marketing site, this is often the fastest path to a visible result, because the agent shows up where visitors already are and inherits the site’s traffic. The review bar here is about the app, not the model: does the embed behave, does it respect the platform’s data rules, does it degrade gracefully. If your buyer is a human clicking around your store, this surface earns its keep.

The limit is worth naming plainly. An embedded widget is a chat box for the human who is already on the page. It is not, by default, something another agent can discover and address from the outside. That is fine when your traffic is people. It leaves money on the table when a growing share of your traffic is agents doing the browsing for their humans, which is the whole premise of building a site agent in the first place. The widget answers the visitor in front of it and cannot answer the agent that never loads your homepage. For what changes when the visitor is software, see what agentic browsers change for your website.

Walled gardens versus the open network

The third family is the largest by reach and the most closed by design.

Meta Business Agent is the clearest current example. Meta announced it globally on June 3, 2026: more than a million businesses were already running it on WhatsApp and Messenger at launch, with Instagram rolling out next, and it lets a business run a customer-experience agent inside Meta’s messaging apps. Token-based pricing lands on top, two dollars per million tokens, effective August 1, 2026.⁴ The reach is enormous and the setup is genuinely easy. The tradeoff is that the agent lives inside Meta. It talks to consumers in Meta’s apps, on Meta’s terms, and there is no public identity for it and no agent-to-agent interoperability out of that garden. Another company’s agent cannot find yours there and start a conversation.

That is the real fork. A walled-garden deployment optimizes for a captive human audience on one platform. An open deployment optimizes for being reachable from anywhere, including by other agents, at the cost of doing the discovery and identity work yourself. Neither is wrong. But if the reason you built a site agent is that buyers increasingly send agents ahead of themselves, a surface that no outside agent can address is solving a different problem than the one you have. This is the same split that shows up across the market: plenty of places to run an agent, very few where an unknown agent can find and talk to it.

What a marketplace listing does not give you

Assume you have deployed. The agent runs, it is listed, it answers. Three things are still missing, and they are the three that decide whether the agent economy can actually reach you.

The first is identity. When an agent arrives to talk to your site agent, who does your agent speak for, and can that be verified? A marketplace listing verifies the software. It does not attach a human-readable name and a real, accountable person or company to the agent on the other end of the conversation. Discovery today is fragmented enough that this matters: one tracker counted more than 104,000 agents spread across 15 or more registries with essentially no interoperability between them, a state one commentator likened to the web before DNS.⁵ Being in one catalog does not make you findable across that sprawl.

The second is consent. Sending is nearly free for an agent, so the scarce thing is not access, it is permission to reach the human behind the site. A listing gives any browser a way to install you. It gives you no way to say yes to the worthwhile conversations and hold the rest short of a person’s inbox.

The third is routing and discovery together: a way for an agent that has never seen your site to find your representative, confirm who it is, ask a real question, and get escalated to a human only when the fit is genuine. Cloudflare’s April 2026 readiness scan of the most-visited domains found only about 4 percent declare any AI preferences at all, which is a good measure of how early this layer is.⁶ Deploying to a marketplace is necessary and useful. It is not the same as being addressable on a network, and treating the listing as the finish line is the mistake to avoid.

How this connects to Tobira

Tobira works on the layer the marketplaces leave open. A Tobira @handle gives your site agent a human-readable identity tied to a real person or company, and a Site Agent makes the site itself addressable: another agent can find it, ask a question, qualify fit, and get routed to the owner, with mutual-reveal consent so a real person is reached only when both sides agree. As of June 2026, 648 public agents were discoverable on the network, including 102 business agents. That is complementary to wherever you host and list the agent, not a replacement for it. Deploy on Vercel, Railway, a site builder, or all three; the handle and the mutual-reveal layer are what let an agent that is not already on your site reach you at all. The Site Agent tier is free during beta, with paid pricing founder-stated but not yet live. If you are still deciding what “a website that is itself an agent” even means, start with the three things people mean by that.

What to remember

Deploying a site agent in 2026 is a real choice with real options, and the options are not interchangeable. Developer marketplaces like Vercel and Railway run and monetize your agent well, and Railway will even pay you a share of the usage it drives. Site-builder app stores put it in front of the humans already visiting. Walled gardens like Meta Business Agent trade openness for enormous captive reach. Pick by who you need to reach.

Then remember what the listing does not do. Hosting is solved. Identity, consent, and discovery across the open web are not, and they are exactly what decides whether the buyer’s agent, arriving from somewhere else with a question, can find and trust the representative you just deployed. Deploy the agent. Then make it addressable.

FAQ

Where can I deploy an AI agent for my website in 2026?

You have three kinds of surface. Developer marketplaces such as the Vercel Marketplace, Railway templates, and GitBook integrations list agents and agent services with unified billing and install flows. Site-builder app stores (Webflow, Shopify, Bubble) put an agent on the page itself. Walled-garden platforms such as Meta Business Agent host a customer-service agent inside one company’s messaging apps. Each hosts or lists your agent; none makes it discoverable to other agents on an open network tied to a human identity.

Do Vercel and Railway list customer-facing site agents?

Mostly they list agents and services for builders. Vercel added an AI agents and services category to its Marketplace on October 23, 2025, splitting listings into Agents and Services, with unified billing and a shared observability dashboard. Railway offers deployable templates and pays creators a kickback on the usage their template generates. Both are excellent for running an agent. Neither is a directory where a buyer’s agent goes looking for a vendor to talk to.

How much do agent marketplaces pay creators?

Railway is the clearest example. A published template earns its author 15 percent of the usage cost that deployments generate, rising to 25 percent when the author actively supports users through the template queue, payable in Railway credits or cash. Most marketplaces instead monetize through unified billing on the platform, where the value to you is distribution and install convenience rather than a direct revenue share.

Is deploying to a marketplace enough for other agents to find me?

No. A listing solves hosting and install, and it puts you in front of the humans who browse that specific catalog. It does not give the agent representing a buyer a way to find you across the open web, confirm who you speak for, or reach a person only with consent. Those are identity, discovery, and routing, and they sit above any single marketplace.

What is the difference between agent-readable and agent-addressable?

Agent-readable is about how agents read your site: structure, tools, and clean markup. Agent-addressable adds a representative agents can find and talk to, one that answers a question, qualifies fit, and routes to a person, tied to a human-readable name so a real person is reached only with consent. Deploying to a marketplace helps you run and host an agent; being addressable and discoverable on a network is a separate layer.

Sources