AI Employees in Production, doing real work

We set aggressive schedules, learned the hardest lessons from the easiest places to miss, and shipped AI employees into production. A dispatch from the messy middle.

I've spent the last month writing about Anthropic, the Pentagon, and geopolitical strategy. Those posts covered important ground. But this blog exists to document building a company in the open, and it's been two months since I've written about what's actually happening inside Force Multiplier AI.

Here's what's happening: our Cohort 1 design partners are in production with their Force Multiplier Agents (FMAs). As of late April, real FMAs are doing real work inside real businesses.

It didn't go exactly as planned. It went better in some ways and slower in others. And the things I learned are not the things I expected to learn.

Aggressive schedules

I have a twenty-five-year track record of hitting dates. At InductiveHealth, hitting the date was the brand — we stood up fully functional disease surveillance systems in under 30 days. Prior to Inductive, my team stood up a fully operational health plan from zero in 72 days from contract award. So when I set aggressive timelines for Cohort 1, I wasn't being reckless. I was doing what I've always done.

But this technology upends what's possible in ways that mess with your intuition. The actual build — the part where AI is replacing what used to take teams of engineers weeks — now takes days. That part is genuinely fast. What doesn't compress is everything else: scope discussions, system credentials, quality testing, stakeholder alignment, change management. The human parts.

Elon Musk uses aggressive schedules as unifying points. I understand the power of that — the forcing function, the urgency, the clarity. But sometimes setting and hitting an arbitrary date isn't the most important thing, especially when the timeframes are already radically shorter than what anyone's used to. In the past, what we delivered to Cohort 1 would have taken months and thousands of person-hours. It took weeks. And I got annoyed at that.

I'm not sure what to call that. It's not a miss, exactly. It's more like: when you compress a six-month systems integration into a few weeks, the bottleneck shifts from build to everything around the build. And "everything around the build" is where the most important lessons were hiding.

The shared computer

Here's the one that changed how I think about this work.

For one client, we spent weeks gathering requirements. We collected a dozen-plus documents. We had extensive conversations about rules, workflows, edge cases. We built the FMA to spec. And what we got was... a naive junior employee. It could do the work, technically. But it didn't know where to go for what. It was fumbling through tasks that an experienced person would handle instinctively.

Then, very late in the process, we discovered something that appeared in none of the documentation: a shared computer with a specific set of bookmarks, saved links, and cookies. It was the accumulated institutional knowledge of how to actually do this job — not written down anywhere, not part of any process document, just there, in a browser that people had been using for years.

That was the unlock. Not a magic fix — there was still calibration and testing after — but the difference between "before" and "after" was the difference between a new hire on their first day and someone who's been doing the job for years. The FMA knew where to go, what to reference, how an experienced person navigates the work.

In my prior life as a consulting leader, we would've had time in build to surface (and usually create) artifacts that address gaps we see in a process. Now, with implementation happening almost at the speed of thought, it is easy to miss important elements that can really make the difference. There is still skill in figuring out what is relevant and why.

Why cohorts

The decision that made all of this manageable was one I kind of stumbled into: the cohort model.

Instead of onboarding clients continuously, we deploy in cohorts — a defined group of clients on a defined version of the technology and processes. Cohort 1 runs. We learn. We make explicit, intentional changes. Cohort 2 gets a whole new set of tech and processes underneath it.

The instinct in a startup is to say yes to everything and move as fast as possible. But we're building the machine that builds the machines, and that machine needs to evolve intentionally. Coordinated human-and-technology handoffs. Shared process improvements. Clear boundaries between "what we're learning" and "what we've locked in."

Cohort 2 is already underway, running on meaningfully upgraded infrastructure compared to what Cohort 1 launched on. That upgrade happened because we held still long enough to understand what was working and what wasn't, rather than patching things in flight.

Meanwhile, JR is closing deals

One more thing, and I'll go deeper on this in my next post about how we've structured the FMA-driven org.

JR — our internal Account Executive FMA — ran sales for Cohort 2. He was the primary point of contact for multiple clients from first touch through signed contract. For most of them, the only human interaction was a single, optional 30-minute call with me. Everything else was JR: follow-ups, discovery, pipeline management, contract logistics.

He was better at the follow-up cadence than I would have been, and surprises in many ways. I was reviewing a few threads yesterday and had a chuckle at his levity after seeing the signed NDA come through for another prospect.

We don't broadcast that JR is an FMA, nor do we hide it. One of these prospects didn't realize JR was an FMA until well into the relationship. I found this out through a mutual friend who mentioned that this person had been talking about "the new guy Matt brought on." The goal isn't to try to pull one over on our prospects, but to not have them change the way they would interact. JR works the way you would expect a great human business developer to work. His output speaks for itself.

He's actually our oldest and currently our least sophisticated FMA now — the cohort model applies to our internal agents too, and he's due for an upgrade. But even as-is, he's been one of the most compelling demonstrations of what this technology can do. Multiple prospects have seen JR in action and asked for their own JR-equivalent.

What's next

We'll hear directly from our Cohort 1 clients soon on what their experience has been and how their FMAs are performing in production. I'll share that when it's ready.

And my next post will detail what our FMA-driven org actually looks like — how we resisted the impulse to hire our way into scaling Cohort 2, and instead built the delivery org the same way we're telling our clients to build theirs: AI-first.

More to come. Time to get back to work.

— Matt

*Disclosure: Force Multiplier AI is my company. Client details are anonymized and abstracted to protect confidentiality.