If you want to run a multi-product business with a single founder, you can't have a strategy. You need an operating system.
We've been running ours for about two years. It's four specialized agents arranged in a loop, with a fifth — a self-learning core — sitting in the middle and grading the rest. This piece is the technical breakdown of how it actually works.
The four agents
Each agent owns one part of the company. They don't share state via shared memory; they share state via a small, well-defined contract — a structured "card" that gets passed between roles.
Find — the ideas agent
Job: decide what to build next.
Find reads the market: search trends from Google Search Console + Ahrefs + DataForSEO, competitor mentions on Reddit and Indie Hackers, GitHub trending repos in the spaces we care about. It assembles a spec — target keyword, audience, channel hypothesis, monetization model, expected unit economics — and grades it against the studio's portfolio. If the spec passes the gate, it goes to Build. If not, it goes back into the queue for refinement.
Find's most important constraint: it cannot validate something that already exists in the studio. Cannibalization between products is the most expensive mistake a studio can make, so Find scores every spec against existing products' keyword overlap and demographic overlap before it ever reaches Build.
Build — the dev agent
Job: turn a spec into a live product.
Build is the most LLM-heavy agent. It writes the frontend, the backend, the database schema, the payment integration, the SEO foundations — all of it. Tooling varies by stack (Next.js for web, Expo for mobile, FastAPI/Express for APIs), but the pattern is: spec → scaffolded codebase → integration tests → deployed-to-Vercel preview → smoke test → promoted to production.
Build also writes the first version of every content asset the product needs — copy, FAQ, schema markup, OG images. None of it stays static; the optimization agent rewrites it later. The point is to go live fast, with everything that needs to exist, even if v1 is rough.
Acquire — the traffic agent
Job: put money to work.
Acquire generates ad creative across formats — image, video, carousel, story — using a combination of LLM copywriting and image gen models. It launches across Meta, Google, TikTok. It kills underperformers within hours and scales winners within days.
The interesting part: Acquire isn't optimizing CPA in isolation. It's optimizing CPA against retention signals from the product itself. A campaign that delivers cheap signups but no second-day retention is killed even if Meta says it's converting well.
Acquire also runs our browser automation layer for any task that needs a real browser — checking competitor landing pages, running automated SEO audits, scraping public data for ad inputs. That layer matters because most "agent runs ad campaign" demos break the moment they hit Cloudflare or a checkout flow with anti-bot. Real cursor control + residential IPs + human-like input cadence is the difference between a demo and a production system.
Optimize — the analytics agent
Job: measure, A/B test, feed wins back.
Optimize tracks every funnel step. Wizard-started, demo-viewed, paywall-hit, checkout-completed, retained-day-7. It runs continuous A/B tests on pricing, copy, layout. When a variant beats control with statistical significance, it rolls out to that product and gets added to the studio's pattern library for other products to pick up.
A real example: a TunedForYou pricing test found that displaying "$1.28/day" outconverted "$9/week" by 25%. Optimize rolled that pattern into the pattern library; within a week, every product showing recurring pricing was using per-day display.
The self-learning core
The fifth piece is what makes the whole thing more than the sum of four agents.
The self-learning core runs every hour. It reads the full state of the studio — every metric, every audit log, every postmortem, every Telegram approval card, every recent commit. It asks itself: what's working, what isn't, what's drifting, what should the next move be?
Wins become defaults. If a brand-comparison page format ranks well for one product, the core promotes it into the spec library. If a Find specification turned out to be a flop after 30 days, the core retires that vector from future recommendations. If an Acquire campaign drift starts looking like a fraud pattern, the core flags it as an anomaly before the bill arrives.
Anything risky waits for a human tap.
The contract between agents
Agents talk via small structured "cards." A card is just a JSON object with a strict schema:
{
"from": "find",
"to": "build",
"type": "spec",
"product_name": "InkOn",
"primary_keyword": "ai tattoo preview",
"estimated_monthly_search_volume": 40000,
"competitor_landscape": [...],
"monetization": { "model": "freemium", "tiers": [...] },
"channels": ["aso", "ugc"],
"budget_cap_usd": 2000,
"go_no_go_metrics": [...]
}
The contract is enforced. If Find tries to hand Build a spec missing required fields, the validator rejects it and routes the card back to Find with the error. This is the difference between a swarm and a mess.
Same shape for Build → Acquire, Acquire → Optimize, Optimize → Find. Every handoff is structured, validated, replayable.
The infrastructure underneath
Three pieces of infrastructure make this work, and they're each substantial moats in their own right.
Browser automation
Every agent needs to do real work on the open web at some point. Competitor research, ad-network management, public-data collection, link-building outreach. We built our own browser automation layer — Human Browser — because the off-the-shelf options either get caught (datacenter IPs, headless fingerprints) or are too expensive at the scale we need to run experiments.
Human Browser uses residential IPs, human-like input timing, and real cursor control. It runs Playwright-compatible scripts but at a scale that wouldn't be possible if we had to babysit each one. We open-sourced it as a public skill — anyone running AI agents that need to use the web hits the same wall we did.
Hosted agent infrastructure
The agents themselves run as private containers. Each product's swarm has its own container; the studio's meta-loop runs on a shared container. We built Clawster — hosted OpenClaw agents in two minutes — initially as our own deployment tool, then made it available as a product because anyone running AI agents in production wants the same thing.
The observability + approval layer
Built in-house, will eventually be a product. It's the layer that:
- Audits every action every agent takes.
- Catches anomalies — stuck metrics, broken funnels, sudden drops.
- Surfaces high-blast-radius proposals as one-tap Telegram approval cards.
- Logs every postmortem and feeds it into the next iteration.
This is the layer that turns "AI in the loop" into "AI in production." Without it, agents drift. With it, they self-correct.
What the swarm is not
It's not a single LLM call. The system is dozens of cron-driven jobs, hundreds of small structured prompts, and a strict contract between roles. The LLM is a tool inside each agent; the agent is a role inside the swarm.
It's not autonomy without humans. The founder is in the loop on every meaningful decision via Telegram approval cards. Routine things autoplay. Anything that could move the company autoplays only after the operating policy says it's safe.
It's not done. The swarm gets better every week — usually because the self-learning core surfaces a gap and the founder fixes it. The next big upgrade we're working on is replacing the central LLM in the meta-loop with a smaller, more reliable router that can shard reasoning across cheaper models for parts that don't need depth.
When this model fits
It fits when you want to explore a space rather than build a singular thing. The swarm is optimized for portfolio learning, not deep-product breakthroughs. If you're building the next OS, this isn't your model. If you're shipping a portfolio of 5-10 focused products optimized for distribution, it's the only model that scales without a team.
Curious how the engine actually runs day-to-day? See /engine for the full breakdown. Or read how we run 7 AI products with no employees for the operations view.