Hey y’all — time for a flashback.

It’s 2018. Pre-COVID. Pre-LLMs being everywhere.

A big debate in software engineering was whether you should build your product as a monolith or a swarm of microservices.

The former offered simplicity whereas the latter gave specific jobs to specific services.

I can’t help but notice the same exact debate has broken out around agentic systems, especially in the wake of Grok Bot’s release.

Some people are arguing in favor of building teams of agents, each with names, areas of ownership, etc under an orchestration layer.

Others are just full-sending one company brain to manage everything.

So this week I’m breaking down this tradeoff (because I’ve lived it) and explaining why the best approach differs based on where your company is at.

Quick TLDR (skip if you know the difference and history):

A monolith is when you build an application as a single, unified, shared codebase. A microservice architecture breaks the application into small, independent services that communicate through APIs.

Netflix, for example, famously runs a massive cloud-native architecture split into over a thousand independent microservices on AWS.

Amazon does as well.

As the obsession with FAANG and hype around cloud-native services grew during the 2010’s, everyone else was left trying to imitate what those companies were doing differently.

Traditionally, companies had built their codebases mostly as monoliths. But, suddenly, it seemed like everyone felt the pressure about why they weren’t using microservices.

Microservices do have significant benefits:

Seemed great if you were bogged down trying to spin up new parts of your biz due to legacy code, or had seen issues where small bugs had taken down your whole system.

It got kind of crazy.

Small startups would split simple applications into dozens of services simply because large companies did it and they assumed they would scale at some point.

They were planning for success without considering that first they need to actually get there.

It became obvious that most of these teams had traded simple codebases for insane complexity and operational overhead.

Even Amazon Video published a post-mortem about moving back to a monolith.

These days it’s understood that it doesn’t make sense to be dogmatic about it.

It’s usually better to start with a monolith that lets you operate quickly and then pay the tech debt costs later, when you have the capital and stability, to consider splitting some parts out into microservices to handle scale.

Now we’re seeing tons of folks on X and LinkedIn talk about how you need a team of agents (aka “AI teammates”) to each run a unique job within your startup.

But… do you?

Back in March I set up a team of agents and what I found relatively quickly was:

Among other concerns.

Basically it was a huge headache that wasn’t reducing costs (since we needed more human hours to manage the system + higher token costs due to the orchestration layer) or allowing us the time to pursue growth.

So these days I have a single monolithic agentic system. Goodbye named agents, scoped to specific “roles“ on the team.

Instead, hello to a single company brain that has all my context, a ton of skills to know when to pull and do what with it, and easily accessible to anyone on our team.

It’s been a huge improvement to everything from shipping velocity to system accuracy / memory.

Most importantly, it’s actually been useful to the degree that I’ve been able to reduce $425K in annual expenses, and is now starting to build out new growth channels for us.

Now, I do think that as I grow the business to (hopefully) $10M ARR and beyond, it will likely make sense to set up some specific things as their own agents / services.

But, IMO, the vast majority of startups don’t yet need to worry about building AI teammates yet.

And anyone selling you the idea that everyone needs them on social media is either being naive or (at worst) dishonest, because they know it’ll drive clicks right now.

Instead, spend the time you get back on growing your business.

It’s just the same argument playing out again in a new arena.

You need to actually be hyperscaling before spending your limited and valuable time worrying about solving hyperscale problems.

Curious what y’all think. Shoot me a reply if you’ve had similar (or opposing) thoughts!

Advertise in my newsletter to get in front of 60,000+ founders.

Founders: treat yourself for once.

A few of our partners are offering $$$ for taking a quick call with them (that’s it).

Honestly, block off a couple hours, knock them all out, and walk away with some cash to get off the ramen diet for the weekend.