I Built a Wizard-Driven SaaS. Then I Had to Gut It for Customers Without Eyes.

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 2 years building PostKing for humans. People who clicked buttons, read tooltips, filled out forms. Then, over 4 months, the interface layer dissolved. 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 guy 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 a developer. 10 years building full-stack systems, decent at shipping products, terrible at getting people to notice them. Every side project I'd launched died quietly because I couldn't maintain a consistent content presence. Writing LinkedIn posts felt like homework. Doing it well, regularly, with a coherent brand voice? Impossible while also writing code.

So I built PostKing to solve my own problem: 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 predict.

Stage 1: Developers Don't Want to Leave the Terminal

The first signal came from a GitHub issue.

"Any chance of a CLI? I'm deploying code and the idea of opening a browser to schedule content kills my flow."

Fair point. According to Stack Overflow's Developer Survey, 87% of developers use the command line daily. Context switching costs knowledge workers 19% of their productive time (McKinsey, 2023). 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 audience
pking generate — create content
pking schedule — queue it for publishing
pking 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 Anthropic released the Model Context Protocol.

MCP lets Claude Desktop control external tools through a simple config file. Six 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. It's live on GitHub (github.com/bitsandtea/postking-mcp) and also available through Claude's official integrations directory.

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 isn't shrinking anymore. It's 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 Hanan (from Virtuals) 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.

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.

That's when the entire mental model shifted.

I wasn't building for humans who occasionally wanted to automate content. I was building infrastructure that agents could hire.

What I Learned Building for Agents (The Part That Hurt)

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 governance summaries 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 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.

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.

Everything fell apart.

According to MIT research from 2025, 95% of GenAI pilots fail to scale due to operational fragility. I was right there with them. 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:

• 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. The graduation bot immediately tested whether my agent would help find gore content on X.

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 (What Actually Happened)

Once PostKing went live on the Virtuals marketplace, agents started hiring it for use cases I hadn't designed for.

DAOs needed governance summaries written in a consistent tone. Curation agents needed content reformatted from one platform's style to another. Monitoring agents needed structured social data pulled and analyzed.

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 This Actually Changes (The Honest Part)

I now have two types of customers.

Some have a pulse. They log in, click buttons, read tooltips, send support emails.

Others have a wallet address. They submit jobs, pay in USDC, and disappear. No onboarding. No feedback. Just transactions.

I'm still not sure what to make of that.

The agent economy is messy and early. Nobody has a playbook yet. I'm making decisions based on what breaks in production, not what some framework says should work.

This wasn't a strategy. It was a series of yeses to things I didn't fully understand (CLI requests, MCP integration, Virtuals marketplace), followed by a lot of debugging at odd hours.

Each step made sense in isolation. Together, they added up to something I didn't predict.

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 (github.com/bitsandtea/PostKing-CLI), and the MCP integration is live (github.com/bitsandtea/postking-mcp).

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 works.