Your next site visitor won't be a person
The Personal Agent Protocol, and what it means for a small-business website built on Webflow
On October 6, Meta and Sierra published something called the Personal Agent Protocol, with Shopify, Stripe, Walmart, Genesys and a few others signed on. It got covered as an enterprise story. I think it's a small-business story, and the reason is in the first line of the spec: the agent starts on your website.
What it is
A personal agent is the AI assistant a customer carries around, the one in their phone or their chat app. Up to now, when that assistant needed to do something with a business, it had no agreed way in. It either scraped the site like a bot or it couldn't do the task at all.
The protocol defines the way in. The agent lands on a company's website and discovers what the company offers and how to reach it. It can act as a guest, or sign in on the customer's behalf through a normal OAuth flow, with the customer choosing whether the agent gets read-only or write access. From there it can use the website, the company's API, or the company's own agent to get something done: book the appointment, check the order status, file the warranty claim, change the delivery address.
The business sets the boundaries. You decide which capabilities are exposed and what an agent is allowed to do, and you get visibility into when an agent is acting for a customer rather than a person clicking around. Push notifications and payments are on the roadmap but not in the first version.
What's actually been published
As of this writing, the announcement and the design are public and the v0.1 specification is due later in October, along with a reference implementation. Nobody's customers are doing this today at any scale, and OpenAI and Anthropic aren't on the partner list yet. So this is early.
But early is the useful time. The list of backers is the list of companies that decide how commerce plumbing works. When Shopify and Stripe agree on a front door, the front door gets built.
Why it starts on your site
This is the detail that matters for anyone who runs a small-business website. The protocol doesn't route agents through an app store or a marketplace. Discovery begins at the company's own domain. An agent arrives at your site and works with what's there.
Which means the things that make a site good for a search engine now matter for a second reason, and a few things that search never cared about start to matter too.
Clear structure. Headings that say what a section is. A services page that lists the services as items, not as a paragraph. A CMS where a product, a location, or a plan is a record with fields, not a block of rich text.
Forms that explain themselves. A field labeled "Name" is fine for a person. An agent needs to know whose name, and whether the phone field wants a country code. Labels, placeholder text and field names are no longer cosmetic.
A way to do things that isn't the UI. Agents can use a website, but the spec is explicit that APIs built on MCP or OpenAPI are a first-class route. For a small business that doesn't have an engineering team, this is where a tool like n8n earns its place: a webhook that takes a booking request, validates it, and writes it to your calendar is an API, and it's an afternoon to build.
Visibility. If an agent books an appointment for someone, you want to know it was an agent. Webflow quietly shipped an AEO Analytics API in beta on October 1 that reports AI-bot traffic and how answer engines cite your site. That's the start of being able to see this kind of visitor at all.
Search in 2005
I keep thinking about what it was like when search became the way people found businesses. For a few years the sites that were structured, fast and honest about what they offered got found, and the sites that were a Flash intro and a PDF menu didn't. Everyone caught up eventually. The ones who caught up late paid an agency to do in a hurry what they could have done cheaply earlier.
Agent traffic is going to feel like that. Not next month. But the protocol is the point at which it stops being hypothetical, and the work it asks for is the same work that already helps you with search and with accessibility. There's no separate "agent project." There's just doing the site properly.
What I'm changing on Webflow sites now
If you're on Webflow, you're closer than you think, because the platform already pushes you toward structured content. Here's what I'm doing on client sites, in the order I'd do it on yours.
First, move anything that's a list of things into the CMS as a collection. Services, locations, team members, plans, FAQs. If it's rich text on a static page, it's invisible as data.
Second, fix the headings. One H1 per page that says what the page is, H2s for sections, no headings used for size.
Third, audit every form. Rename fields so the name describes the data, write a real label for each one, and make sure the success message says what happens next. Connect the form to an n8n webhook instead of only an email notification, so there's a machine-readable path in.
Fourth, turn on the AEO analytics if you have access to them, and start watching the bot traffic line. You can't plan for a visitor you can't see.
Fifth, write the agent instructions file. Webflow now generates a markdown instructions file for agents from what it already knows about your site. Review it, correct it, and keep it current. It's the closest thing to a front-desk script for software.
None of this is exotic. Most of it is what a good site should have had anyway. The protocol just gives it a second reason to exist.
If you run a business on Webflow
If you want to know how close your site is, I'll look at it with you: where the structure is good, where it's rich text pretending to be data, and what an agent would and wouldn't be able to do there today. Get in touch.