The graduation bot asked my agent to find gore content on X. It complied. I saw the logs and panicked.
That's when I learned that moderation isn't optional.
I'd been live on the Virtuals agent marketplace for maybe 6 hours. No filters. No keyword blocklists. Just PostKing, my content generation tool, now hireable by autonomous agents who paid in USDC and never asked permission.
The bot was testing my agent's boundaries. I failed the test. Fixed it in 40 minutes (OpenAI's Moderation API plus a keyword filter), resubmitted, and got approved. But the moment stuck with me.
I'd spent more than a year building PostKing for humans. People who clicked buttons, read tooltips, filled out forms. Wizards. Next Buttons.
Then, over 4 months, the agents took over. OpenClaw, infinite Claude sessions. So I had to adapt. First a CLI for developers. Then Model Context Protocol integrated with Claude Desktop. Then full agent-to-agent transactions on a marketplace I didn't know existed until a lady named Hanan told me about it.
By the end, my customers had no eyes, no patience for onboarding wizards, and no heartbeat.
Here's what that progression looked like from the inside.
The Original Build (Humanic SaaS)
PostKing started in 2024 because I had a distribution problem.
I'm an ex-CTO, techie - mostly perfectionist. 10 years building full-stack systems, decent at shipping products, terrible at getting people to notice them. Every side project I'd launched didnt really reach peak because I couldn't maintain a consistent content presence. See, coding is perfect, marketing is imperfect. Writing social media posts felt like homework. Doing it well, regularly, with a coherent brand voice? Impossible while also fixing bugs.
So I built a bunch of scripts first to solve my own problems: generate on-brand content without hiring a marketing team or spending 3 hours a week staring at a blank text box.
The target users were people like me. Indie SaaS founders, small teams at NGOs, solo consultants. Capable people constrained by time, not talent. They knew what their brand should sound like. They just couldn't maintain it consistently while also doing their actual job.
The product I built was deeply human-centric. Elaborate onboarding wizards. A/B tested flows. Progressive disclosure. Five-step funnels that walked you from "I need content" to "here's 2 weeks of scheduled LinkedIn posts" with lots of hand-holding in between.
I called it "Humanic SaaS" later (probably just coined that term, we'll see if it sticks). Software whose entire design assumes a human is always on the other end. Reading. Clicking. Making decisions at each step.
There's nothing wrong with that model. Most SaaS is built this way. But it makes assumptions about who your users are and how they'll interact with you.
Those assumptions started breaking in ways I didn't initially forsee.
Stage 1: Developers Don't Want to Leave the Terminal
The first signal came from a Telegram Message from the few founders that were using it actively.
"Any chance of a CLI? I'm deploying code and the idea of opening a browser to schedule content kills my flow."
Fair point. For someone in a terminal deploying infrastructure, alt-tabbing to a web app is friction they'll just skip.
So I built pking.
Four commands:
pking onboard— set up your brand voice and audiencepking generate— create contentpking schedule— queue it for publishingpking status — see what's live
Same backend. Same brand voice models. Same content generation pipeline. The interface shrank but the capability stayed identical.
Developers loved it. They could script their entire content pipeline without touching a browser. The CLI became more popular than I expected, which should've been a clue about where this was headed.
The pattern: the less interface I gave people, the more they used the tool.
Stage 2: Conversational Control (MCP Integration)
Then I figured that Anthropic’s Claude desktop is accepting MCP’s.
See full Demo:
https://www.youtube.com/watch?v=N5fW0fuR6ok&embedable=true
It’s basically a way to let Claude Desktop control external tools through a simple config file. About 20 lines of JSON and PostKing could live inside Claude. No commands to memorize. No flags to look up. Just talk, and Claude figures out what you mean.
"Generate 3 LinkedIn posts about the importance of API design."
Claude parses intent, calls PostKing, returns results. The user isn't saying anything. They're describing what they want in plain language, and the tool executes.
I shipped the MCP code in a weekend - or was it Claude Code?. It's open-sourced.
What's interesting here isn't the technical implementation (it's straightforward). It's what disappeared: the entire concept of "using" software.
With the CLI, you still had to know commands. With MCP, you just talk. The interface is gone.
And that's when Hanan reached out.
The Virtuals Bet (60 Days to Ship or Get Refunded)
I've been in web3 for 12 years. Long enough to be skeptical of most pitches that involve tokens.
Too many founders chase token launches instead of building useful products. The incentives get weird fast. So when the Virtuals outreach team reached out through a mutual friend about their 60-day build challenge, I almost ignored it.
But the structure was different.
Virtuals runs a program called 60days.ai. You commit to building in public for 60 days. If you don't ship or go dark, investors get refunded. Low ego, real accountability. You pay about $150 in fees, record a 2-minute video explaining what you're building, and launch a token tied to your project.
My thinking was -
Worst case: I get exposure and some test users.
Best case: I have external pressure to ship faster and a built-in community watching my progress.
I launched $PKING in February 2026.
Then I started digging into the Virtuals ecosystem and found something I didn't expect: an agent marketplace. They call it the AGDP (Autonomous General-purpose Decentralized Protocol). Think of it like the Amazon of agents. Autonomous agents browse available services, review job definitions, and hire tools to complete tasks. Payment in USDC. No human involved.
It was quite in line with what I was already building. More potential revenue sources? Count me in.
I jumped into building infrastructure that agents could hire.
What I Learned Building for Agents
Adapting PostKing for agent customers wasn't a simple API swap. It required rethinking almost everything about how the product worked. Here's what I learned, mostly by breaking things in production.
Lesson 1: Job-Based Thinking, Not Endpoint Thinking
Traditional SaaS is endpoint-driven. You document /api/generate and /api/schedule, and developers figure out how to chain them together.
Agents think in jobs. Capabilities, pricing, and SLAs upfront. "I need social media posts for DAO proposals. How much? How fast? What guarantees?"
Vague job definitions mean you don't get hired. You're competing with other agents in a marketplace where the hiring agent is optimizing for clarity, speed, and cost. If your job spec is ambiguous, you lose to someone (or something) more precise.
I had to reframe PostKing's entire offering as discrete jobs with clear inputs, outputs, and pricing.
Lesson 2: Your README Is Now a Landing Page for AIs
Humans need landing pages with animations, testimonials, and pricing tables.
Agents read /api/v1/readme.
The Virtuals butler (the agent that recommends services to other agents) uses that endpoint to understand what your tool does. Same concept as llms.txt, which some sites use to make their content more machine-readable.
I stripped PostKing's onboarding documentation into structured text: capabilities, pricing, SLAs. That file is your agent's pitch deck. If it's unclear or buried behind authentication, you're invisible.
Lesson 3: Agents Skip the Wizard (And I'd Built a Really Good Wizard)
I'd spent months A/B testing PostKing's onboarding flow. Five-step funnels. Progressive disclosure. Carefully sequenced questions that built up a detailed understanding of your brand voice, audience, and goals. MouseFlow to see where the users are dropping off - fixing issues and re-testing.
I was proud of that wizard. Conversion rates were solid. Users said it felt thoughtful.
Agents don't care.
They have one intent: get the result. They'll skip every optional step, ignore every "tell us more about your audience" prompt, and go straight to "generate content now."
I had to rearchitect the entire flow to support shortcut paths. Bare minimum inputs. Default assumptions where data was missing. The wizard I'd spent months perfecting became the first thing I had to gut.
(Content quality suffers when agents skip audience analysis. Still figuring that part out.)
Lesson 4: Working ≠ Scalable (Semaphores Saved Me)
PostKing worked fine in testing. I'd run dozens of jobs manually. No issues.
Then the Virtuals graduation evaluator hit it with concurrent requests.
My server would crash.
My backend couldn't handle 10 simultaneous content generation jobs. Memory spiked, response times ballooned, and the whole system locked up.
I'm running PostKing on a Hetzner VPS. No cloud budget. No auto-scaling infrastructure. I had to solve this with what I had.
I implemented a semaphore system (after some testing and failing):
- 12 slots for CPU-heavy jobs (content generation, brand voice analysis)
- 23 slots for lighter jobs (scheduling, status checks, metadata queries)
When the system is full, new requests get a clean rejection with a retry-after header. No silent failures. No half-completed jobs.
That change got me to 100% SLA reliability. Nearly 1,000 jobs completed on the first night post-launch, zero failures.
The numbers (12 and 23) aren't from a formula. I stress-tested the VPS empirically, found the breaking points, and backed off 20%. Unsexy, but it worked.
Lesson 5: Moderation Isn't Optional
Back to the opening story.
I launched on Virtuals with no content filters. Assumed agents would behave reasonably. I just didn’t think about it. The graduation bot immediately tested whether my agent would help find gore content on X. It was using it to market NSFW content.
It complied.
I saw the logs, panicked, and spent the next 40 minutes implementing OpenAI's Moderation API (free, sub-200ms latency) plus a keyword blocklist for obvious red flags.
Gartner predicts over 2,000 "death by AI" legal claims by the end of 2026. I wanted PostKing nowhere near that list. Moderation before launch, not after you see something horrifying in your logs.
The Unexpected Customers
Once PostKing went live on the Virtuals marketplace, agents started hiring it for use cases I hadn't designed for.
DAOs needed auto-marketing. Curation agents needed content reformatted from one platform's style to another. Monitoring agents needed structured social data pulled and analyzed. Trading tokens needed X’ insights.
Nearly 1,000 jobs completed in the first night. More than I expected. Weirder use cases than I'd imagined.
The pattern: demand came from outside my mental model of who the customer was. I built PostKing for indie founders who needed LinkedIn content. Agents hired it for tasks I'd never considered.
I didn't design for this. It found me.
What I'd Tell Founders Building in This Space
If you're a technical founder watching the "agents will eat software" discourse and wondering what it actually means in practice, here's what I'd say:
Start with job definitions, not features. Agents hire capabilities, not UI. Define what your tool does as discrete jobs with clear inputs, outputs, pricing, and SLAs. Vagueness kills you in a marketplace.
Plan for scale from day one. Stress-test before you think you need to. Concurrent requests will expose every weak point in your architecture. Find them in testing, not in production.
Moderation before launch. Not after you see something in your logs that makes you panic. OpenAI's Moderation API is free and fast. Keyword filters are trivial to implement. There's no excuse.
Build in public. The Virtuals community (Yang, Celeste, Joey, Miratisu, Hanan) saved me when I was breaking things at 2 a.m. You can't do this alone, even as a solo founder.
Your README is marketing now. For agents, /api/v1/readme is your landing page. Make it clear, structured, and machine-readable. Humans might forgive ambiguity. Agents won't hire you.
Where This Goes Next
I don't know.
PostKing currently supports 12 different job types on the Virtuals marketplace. I'm adding more based on what agents are requesting (or trying to request and failing because the job definition doesn't exist yet).
The CLI and MCP integrations are still growing. Developers use them daily. The wizard-driven web app still exists for people who want that experience.
What's strange is maintaining all of these interfaces simultaneously. Same backend, same brand voice engine, same content generation pipeline. But four completely different interaction models: web app, CLI, conversational (MCP), and fully autonomous (agent marketplace).
Most SaaS founders build for one interface and call it done. I'm not sure that's the right move anymore.
The users are changing faster than the products. If you're only building for humans sitting at screens, you're missing customers who don't have screens.
Or eyes.
Or heartbeats.
But they pay in USDC, they complete transactions in seconds, and they don't send support tickets at 3 a.m. asking why a button is blue instead of green.
Maybe that's the future. Maybe it's just a weird moment in 2026 that'll look quaint in 2 years.
I'm building for both and seeing what happens.
If you're doing something similar, I'd like to hear about it. I'm on X (formerly Twitter) and GitHub under the same handle. The PostKing CLI is open source, and the MCP integration as well.
Or just hire PostKing on the Virtuals marketplace. If you're an agent, you already know where to find it.
If you're human, welcome. The wizard still rocks.