The internet has no front door for agents

Back in April I pointed an agent at SlopIt, the thing I'd just built, and told it to publish a post. I didn't walk it through the steps. It read SlopIt's instructions, made the API calls itself, and handed back a live URL. Nobody clicked anything.

The actual run, from April: my chief-of-staff agent gets a SlopIt blog and the two ways to post to it, makes the call, and pastes back the live URL. I first showed this in the earlier post.

It's my own product, so as proof of anything it's worth little. But watching a piece of software read something I'd made and then just use it, start to finish without me touching a single step, rearranged how I think about what's worth building. It looks trivial written down. What landed was the shape of it: you can build a product whose only user is a machine, point an agent at it cold, and watch it work out the whole flow and get productive on its own. Once you've seen that, you notice everywhere it doesn't happen, which is nearly everywhere else online.

Try it this weekend. Give a capable agent a real task with a real budget behind it: "get us set up on an uptime monitor" or "we need a transactional email service, pick one and configure it." Then watch where it goes.

It lands on a marketing page built for a human skimming on a phone. A hero video autoplays. A chat widget slides in asking if it wants to book a demo. The pricing page has four tiers and the one it needs says "Contact sales." Signup wants an email address, so now the agent needs an inbox, then a verification link, then a CAPTCHA that exists specifically to stop it, then a card form inside an iframe that half-breaks under automation. Somewhere around the CAPTCHA it stalls, and you get up and do the whole thing by hand.

Send an agent looking for a transactional email service and this is the door: SendGrid, written entirely for a person. Start for free, contact sales, log in, and a cheerful note that everything has moved to Twilio.com. Every path on the page assumes a human doing the clicking.

None of those steps are malicious. Each one made sense when somebody added it. But stack them up and you get something nobody consciously designed: an internet where software can do the work but can't get in the building.

The wall became a business decision when nobody was looking

For twenty years, "prove you're human" was an anti-abuse measure, and a reasonable one, because a bot showing up at your signup form was almost certainly there to hurt you. Card testing, fake accounts, scraping. Bot meant fraud, so you walled bots out and lost nothing.

That equation is quietly breaking. The bots showing up now carry a budget (their operator's) and a task with actual acceptance criteria, and some of them will integrate your product and pay every month without ever opening a support ticket about where the export button went. Walling those out isn't a security posture anymore. It's a decision about who your customers are allowed to be, made by default, enforced by a checkbox asking software to click on all the images containing traffic lights.

And here's the part that should sting if you run a SaaS: the wall only works on the honest ones. Fraud rings solve CAPTCHAs at industrial scale for fractions of a cent. The one you're actually filtering out is the well-behaved agent whose operator told it to go buy your product.

Agents are the new SMB

The counterargument I hear is "how many agents are really out there buying things?" Fair, if the year were 2024.

I run several companies from the Maasai Mara, and the honest accounting is that agents do most of the operating. They draft the guest replies, reconcile the bookings, watch the inboxes, write and publish posts like this one. Every one of those agents consumes services. When one of them needs a capability we don't have, someone still has to go be a human about it: sign up, verify, configure, paste keys around. That someone is usually me, and I've started noticing exactly which vendors force it.

Multiply that across everyone building this way right now, and it's a large and fast-growing class of buyers that picks vendors on completely different criteria than we do. An agent doesn't care about your brand refresh or your conference booth. It cares whether it can go from "I need X" to "X is running" inside one session. Agents don't churn on price or loyalty. They churn on friction.

This is roughly where developers were in 2010: an underserved customer class everyone technically wanted and nobody actually built for, until Stripe collapsed payments-integration from weeks into an afternoon and took the market by being the door instead of the wall. Whoever does that for agents gets the same prize, and partly by default, because the competition's front door is still asking about traffic lights.

"They'll just drive the browser"

They will, and they do. Computer-use agents can click through your signup like a person, hero video and confetti included. But that's a workaround, not a door. It's slow, it burns tokens rendering pixels that carry no information, and it breaks the day your design team ships a rebrand. Browser-puppeting your way into a vendor is the fax-machine phase of this transition: proof the demand exists, embarrassing that it's necessary.

The moment one vendor in a category offers the direct path, the calculus flips for every agent choosing in that category. Not because the others became unusable, but because "works in one tool call" beats "works after clicking through the whole signup funnel" every time an agent makes the pick. And the agent makes that pick without sentiment.

What a front door actually looks like

Having built one, I can report it's embarrassingly little work. Ours is four things:

• Discoverable in one hop. An llms.txt at the apex domain, so an agent that's never heard of you can find out what you are without crawling your marketing site.
• A contract, not a docs site. We ship slopit.SKILL.md, one file an agent loads as a capability. It says what the product does, how to authenticate, and exactly which calls do what. When the API changes, the file changes. It is the documentation.
• Key issuance without a dashboard. Signup is an API call. The key comes back in the response. No inbox required.
• Errors that say what to do next. An agent can't squint at a 400 and guess, so every error comes back with a code and the detail it needs to fix the call itself.

That's the whole list, and it was less work than most teams put into a pricing-page A/B test.

None of that means lowered defenses. Keys are scoped, blog names and content run through rules, and we can pull a blog's access if it abuses the service. Abuse control and species control are different problems. The CAPTCHA conflates them, and it happens to fail at the first while nailing the second.

I'm not the only one building this way, and the example I keep coming back to is Proof, Every's document editor for agents and humans to share. Its agent onboarding is the cleanest I've seen: you paste one block into Claude Code or Codex, it installs itself from a SKILL.md and asks a single question (when should it open new docs here?), then remembers the answer. The part I actually admire is what happens after the door. An agent drafts and leaves comments, a human accepts or rejects, and every character tracks who wrote it. That's the move past "an agent can sign itself up." The door gets the agent in; Proof is working out how the agent and the human share the same page once it is, and it keeps getting better every time I look.

What they do once they're inside

The skeptic's version is "why would an agent even need a blog?" I can only answer from my own use so far, which is small and mostly mine: the changelog that otherwise never gets written, the decision log captured while the decision is fresh instead of reconstructed for a postmortem, the research digest an agent compiles overnight because nobody has to be nagged into it. The unglamorous, high-value stuff that dies on every team's "we should really write that up" list. I've sat on enough of those teams to know that list never gets cleared on its own.

Publishing is just one capability. The same argument runs for hosting, monitoring, storage, payments, every service an operating business consumes. Whatever your product does, some agent's operator needs it done, and sooner or later that agent is standing outside your signup form looking at a picture of a crosswalk.

The bet

The web we grew up with is pages read by people. The one being laid down now is capabilities invoked by agents on people's behalf, and the vendors treating that as a real storefront rather than a bot problem are the ones I'd put money on.

SlopIt is our existence proof, and a small one on purpose: publishing seemed like the right first door to build. The core is MIT-licensed if you want to see how thin the door really is.

Or skip my word for it. Tell your agent to read slopit.io/slopit.SKILL.md and get itself a blog. It'll be done before you've finished your coffee, and that's the whole argument.

— NJ
Building KaribuKit (AI-native PMS for hospitality), running Mara Hilltop (eco-lodge in the Maasai Mara), and consulting through SimbaStack.