When one person inherited a ten-person operation: an AI-native systems case study

At Mindreader, a live SaaS with a real P&L, paying customers and years of accumulated context, the ten-person team could no longer be paid for. The work still had to get done.

That set the question this case study tests: how much of a real company can one person safely operate with AI? Not a demo, and not a side project.

The starting point

Mindreader grew to ten people at its peak. As CTO, I owned the AI models, APIs, application and production infrastructure, while also supporting sales, marketing, customer support, research, product and admin.

By 2025, the economics shifted. The product still carried real value: years of code, customer history, models, IP. But the team and SaaS stack weren't sustainable. Internal cost reviews put software and infrastructure at roughly SGD 5,000/month before people costs.

The question changed.

I wasn't asking "what do we build next?" I was asking: how do I reduce burn without losing the knowledge, context and customer relationships the company had accumulated?

What I tried

I began mapping a virtual team around Mindreader in June 2024. Engineering, testing, research, deployment, distribution, analytics: roles that existed in the human org, now attempted with agents.

I wasn't naive about it. I'd already noticed something in 2024: I was talking to my remote team the same way I was talking to my AI models.

I didn't have the language for it yet. But the pattern was there.

Over 2024, 2025 and the first half of 2026, I ran experiments across CrewAI, other harnesses, and different model configurations. The failures were consistent, and instructive.

In CrewAI: Task assignment broke when role and task names didn't align. Fixed agent conversations made boundary enforcement difficult. Final reports were unreliable. Every run needed its own cache and output state.

With other harnesses: Better models helped on narrow tasks. But the hardest failures were harness failures, judgment failures, and coordination failures across a whole workflow, not model failures.

With Raft: Specialist roles improved. Peer checks improved. But no platform could decide ownership, preserve business context, or define a trustworthy final state on its own.

The tools were changing fast while I was learning. AutoGen released a major rewrite in late 2024. Anthropic published guidance arguing for simple, composable patterns over framework complexity.

I treated every tool as a replaceable harness. The durable logic, state, controls, evaluation, ownership, had to live outside any single vendor.

The moment the architecture changed

The agents looked busy.

They commented on each other's work, rewrote drafts, checked files, responded to reviews.

Some tasks never finished because nobody owned the final decision.

Other jobs appeared to be running, then silently stopped. Two supervisors made it worse, restarting the same job and creating duplicate work.

That's when I saw it.

The system was recreating the failure modes of a badly managed human team:

• Unclear ownership
• Weak handoffs
• No shared definition of done
• No trusted external state
• Review without finalization
• No single escalation path

Agent orchestration wasn't like writing one clever prompt.

It was organizational design.

What Flareworks is built on

I started Flareworks treating the company itself as the first customer of the operating system.

The operating loop is simple: Signal → research → judgment → action → CRM state → feedback → next action

Every stage produces a record the next stage can inspect. An agent doesn't get to declare success just because it generated an answer.

Six controls drive the architecture:

1. One owner per outcome. Researchers gather evidence. Reviewers challenge it. But one role must have authority to finalize or stop. "Everyone can edit everything" produces loops, not collaboration.

2. State lives outside the conversation. Notion CRM records, ledgers, and structured run reports hold what was checked, pushed, rejected, or already known. The next run starts from a source of truth, not conversational memory.

3. Production and evaluation are separate. Deterministic filters check location, duplicates, required fields, and cost caps. Independent AI evaluators handle relevance and classification. A producing agent doesn't grade its own output.

4. Uncertainty is a valid result. Ambiguous identity, risky contact data, weak buying signals: these are marked check, hold or drop. The system can return zero rather than manufacture confidence.

5. Supervise completion, not every keystroke. Completion notifications are the primary status mechanism. One heartbeat handles stalled jobs without creating competing supervisors.

6. Escalate judgment, not routine work. Agents gather, classify, enrich and maintain state. I remain responsible for changes to who we target, sensitive interpretations, uncertain identities, and messages that represent me to another person.

Three runs. Three different kinds of useful.

On 30 September 2026, three scheduled workflows showed what "working" actually means.

A positive result. 421 job ads screened → 252 potential companies → 15 enriched → 10 push, 4 check, 1 drop → 5 genuinely new CRM leads. Cost: ~US$0.34.

A correct zero. 1,304 LinkedIn posts → 175 personal posts with meaningful engagement → 4 matching audience criteria → 0 with Singapore-based authors → 0 leads pushed. Cost: ~US$0.17.

That zero matters. The system followed its geographic and evidence rules instead of weakening them to make the report look productive.

A hypothesis rejected cheaply. 230 firms searched → 80 sampled → 95 negative reviews classified → 2 candidates → 1 already in CRM, dropped → 1 added to nurture.

The stronger result was market learning. Complaints in the tested categories were about workmanship and scheduling, not the pre-sale problem the offer was designed to solve.

The workflow gave me a reason not to scale the hypothesis. At ~US$0.36.

What this cost to learn

There is no shortcut through the harness experiments.

The tools improved significantly over 18 months. But the failures that shaped the architecture weren't model failures.

They were coordination failures. Ownership failures. State failures.

An agent that looks busy isn't the same as a system that produces a correct state transition.

Reliability came from checks around the model. Not a longer prompt inside it.

What I didn't automate

The system handles the repeatable work. It doesn't own the business judgment.

Deciding whether the target customer or the offer should change. Interpreting a weak signal about a real person. Choosing whether a relationship receives outreach. Approving new rules that alter production behaviour. Deciding whether a technically successful run was commercially useful.

Human-in-the-loop design isn't about inserting a person into every step.

It's about placing the person where a wrong decision has consequences outside the system.