I've been in web3 for 12 years. Built startups, shipped products, watched markets flip inside out. But I'd never launched a token.
The whole setup felt rigged for disappointment. Founders get distracted, communities get rug-pulled, or everyone chases the next shiny thing. When Hanan from Virtuals reached out through a mutual friend, I wasn't exactly jumping at the opportunity.
Then she explained the 60-day build challenge at 60days.ai. Build in public for 60 days, let the community watch your progress, then decide if you're committed. If not, investors get refunded. Simple.
I'd just wrapped the PostKing MVP and was hunting for users everywhere I could think of. The deal was straightforward: make a 2-minute video, pay around $150 virtuals in fees, and launch the $PKING token. Worst case, I'd get exposure and test users. Best case, I'd have a fire under me to ship for 60 straight days.
I was in.
What I didn't expect was discovering Virtuals' agent marketplace (they call it the Amazon of agents). That's where things got interesting, and where I learned more about building scalable systems in one week than I had in the previous six months.
1. Job-Based Thinking vs Endpoints
SaaS products are built around endpoints. You hit /api/users, you get users. You POST to /api/content, you create content.
Agents don't think that way.
They think in jobs. What can you do for me? How much does it cost? How long will it take? When I started building for the Virtuals marketplace, I had to rewire my brain from "here's an endpoint that does X" to "here's a job I can complete, and here's the contract."
It's a small shift that changes everything about your architecture. You're not just exposing functions anymore. You're advertising capabilities, pricing, and turnaround times upfront. The agent-to-agent economy runs on clarity, and if your job definitions are vague, you won't get picked to fulfill a service.
2. Build an Agentic Landing Page (Without the Visual Part)
When I first heard "create a resource file," I thought it was just documentation. Turns out, it's more like a landing page for agents.
Humans need beautiful PostKing sites with animations and testimonials. Agents need a plain text API response at api/v1/readme that tells them exactly what you do.
Think of it as your agent's elevator pitch, except it's delivered in milliseconds and read by other AIs. The Virtuals butler uses this file to understand your agent and recommend it in the right context. If you've seen the llms.txt movement (where companies publish machine-readable files for LLMs), this is the same concept applied to agent marketplaces.
Here is our llms.txt btw — every one of our landing pages gets one automagically.
Back to the agent: I stripped everything visual from PostKing's onboarding and condensed it into a structured text file. APIs, capabilities, pricing tiers. Done.
3. The Jobs JSON Is Your Agent's Contract
Once your agent is discoverable, other agents and humans need to know how to hire you. That's where the jobs.json file comes in.
This isn't just metadata. It's a binding contract that defines:
- What jobs your agent can perform
- How to call those jobs
- How much each job costs
- Expected turnaround time
The Virtuals ecosystem handles discovery, payments, and evaluation based on this file. It's like Airbnb for agents. You list what you offer, the platform intermediates payments and disputes, and an evaluator checks if you delivered what you promised.
I spent hours tweaking my jobs JSON because every field mattered. Too vague, and agents won't know if I'm a fit. Too specific, and I limit my addressable market. Getting this balance right felt like writing a freelancer profile on Upwork, except my client base is mostly non-human.
4. Implementation Means Externalizing Your Credit System
PostKing already ran on a credit-based system, which gave me a head start. I just needed to externalize those credits so agents could consume them directly.
The acp-node module from Virtuals had examples that made this way easier than I expected. I forked their code, adjusted a file called seller.ts to match my architecture, and exposed most of my functions for anonymous use (where it made sense).
The trick was making sure the Virtuals ACP system could discover and interact with my endpoints without breaking my existing user flows. I ended up creating parallel paths: one for human users going through the UI, and one for agents hitting the API directly.
It worked, but it required rethinking some assumptions I'd baked into the system early on.
5. Agents Skip the Wizard (Intent-Driven Architecture Required)
SaaS products love onboarding wizards. Sign up, connect your brand, generate themes, create content. It's sequential, hand-holdy, designed for humans who need context. Throw in some funny memes in the mix while at it.
Agents just want results.
They don't care about your 5-step wizard. They have one intent:
"I want content."
And they expect you to deliver it without making them jump through hoops.
I had to rearchitect parts of PostKing to allow more direct access to result-oriented endpoints. Instead of forcing agents through audience analysis, brand setup, and theme generation, I created shortcuts that let them get what they needed faster.
The problem? Content quality suffers when you skip audience analysis. Many agents hit my "create content" endpoint without giving me enough context, and the output was generic.
I'm still iterating on this. Right now, I nudge agents toward the audience analysis job first, but I can't force it. Balancing speed with quality is tricky when your users are optimizing purely for efficiency.
6. Stress Testing Revealed My Agent Couldn't Scale
When I first got my agent working, I was thrilled. It responded to requests, completed jobs, and didn't crash. I thought I was done.
Then the Virtuals team introduced me to their graduation evaluation agent.
This thing is brutal. It throws concurrent requests, NSFW requests, broken requests, and normal requests at your agent to see how it holds up in real-world conditions.
According to a 2025 study from the MIT State of AI in Business 2025 report, 95% of GenAI pilots fail to scale to production. The primary reason cited is "Operational Fragility" — the inability of agents to maintain reasoning quality when moved from a controlled demo to a high-traffic environment.
My agent was no exception and initially failed spectacularly.
It worked fine under light load, but as soon as concurrent requests spiked, it stopped responding in time and broke its SLA (service level agreement). Making an agent work and making it scalable are two completely different challenges.
7. Semaphores Saved Me — When Cloud Infrastructure Wasn't an Option
I'm a bootstrapped solo founder running PostKing on a Hetzner VPS. It's cost-efficient, but it's not built for massive scale.
When my agent started failing under load, I had two options: throw money at cloud infrastructure or get creative with what I had.
I chose creative.
First, I optimized every function for speed. That helped, but it still wasn't enough to meet the SLA requirements. Then I implemented a semaphore system that controlled how many concurrent requests my server could handle at once.
I created separate semaphore slots for CPU-heavy functions (like content generation using 8 different AI models) and lighter functions (like audience analysis). Through testing, I found the sweet spot: my server could handle 12 heavy jobs and 23 light jobs concurrently without breaking.
Once the semaphore slots filled up, new requests got rejected cleanly instead of crashing the system.
Rejecting a job upfront is way better than accepting it and failing halfway through.
After implementing this, I hit 100% reliability on the graduation tests.
Or so I thought.
8. Content Moderation Nearly Destroyed My Reputation
My agent had no filters when it launched. The graduation bot tested this by asking my agent to find gore content on X.com.
It complied.
I saw the logs (didn't click the results, thank god) and panicked. If my agent was going to operate in a public marketplace, it couldn't be processing requests for illegal, harmful, or NSFW content.
But adding moderation presented a problem: latency.
My agent already uses 8 different AI models to craft responses, some of them fine-tuned. Processing takes time. Running every request through an AI-based content filter would add hundreds of milliseconds and cost me money on every single call.
Then I found OpenAI's Moderation API. It filters requests in under 200ms, and it's free.
I implemented it immediately, along with a keyword filter that catches obvious bad actors (scams, fraud, anything crypto-related that smells sketchy). Now, if a request fails moderation, the job gets rejected before it even touches my core logic.
This wasn't just about protecting my agent. According to Gartner’s 2026 Strategic Predictions, organizations that fail to implement sufficient AI risk guardrails face a massive surge in liability, with over 2,000 "death by AI" legal claims expected by the end of the year. I wanted my agents to have nothing to do with that.
9. Agents Are SaaS Products That Never Stop Iterating
We launched yesterday. We're approaching 1,000 completed jobs, which feels surreal.
But this isn't a "set it and forget it" situation. Running an agent is like running a SaaS product. You're constantly refining features, adjusting pricing, watching usage patterns, and iterating.
I've set up advanced logging to track which jobs get used most, which ones fail, and where agents drop off. I'm learning in real time whether my pricing makes sense, whether my turnaround times are competitive, and what new features I should build.
It's exhausting and exhilarating at the same time. It reminds me of the early DeFi days, where 1 year felt like 7 in any other industry. The pace is relentless, but the feedback loop is incredible. I'm learning faster than I ever did building traditional SaaS products because agents don't sugarcoat feedback. They either use you or they don't.
10. Building Alone Is Possible (But Community Makes It Real)
I'm a solo founder. I don't have a team, I don't have venture backing, and I'm running everything off a VPS that costs me very little.
What I do have is a community that showed up when I needed help.
The Virtuals team worked around the clock with me on this. Yang helped debug my semaphore setup. Celeste helped with marketing & feedback. Joey stress-tested my endpoints until they broke (then gave me ideas on how to fix them). Miratisu’s enthusiasm was contagious. And Hanan introduced me to this entire world in the first place.
None of this would've happened if I'd tried to figure it out in isolation. The 60-day build challenge forced me to work in public, ask dumb questions, and admit when I didn't know what I was doing. That vulnerability turned into support I didn't expect.
If you're a founder building something in the agent economy, find your community early. The learning curve is steep, the mistakes are expensive, and the pace is brutal. You can't do it alone, even if you're technically a solo founder.
What's Next for Agent Builders in 2026
The agent economy is still figuring itself out. We don't have best practices yet. We're all learning by building, breaking things, and sharing notes.
If you're thinking about deploying an agent on Virtuals or any other marketplace, here's what I'd tell you:
Start with job definitions, not features.
Agents care about outcomes. Define what you can deliver, how much it costs, and how fast you can do it. Everything else is noise.
Plan for scale from day one.
Your agent might work fine in testing and collapse under real-world load. Stress test early, build in rejection logic, and know your infrastructure limits.
Moderation isn't optional.
If your agent is public-facing, you will get bad requests. Build filters before you launch, not after you see gore content in your logs.
Iterate like your life depends on it.
The agents that win will be the ones that learn fastest from real usage data. Log everything, watch your metrics, and ship updates weekly (if not daily).
We're at the beginning of something massive. Agent-to-agent economies, autonomous job marketplaces, and systems that operate without human intervention. It's messy right now, but that's what makes it exciting.
If you're building an agent, I'd love to hear what you're learning. We're all figuring this out together, and the only way we get better is by sharing what breaks (and how we fix it).
Now go build something. Break it. Fix it. Ship it.
Top comments (0)