Software factories and the agentic company

Apparently I have a software factory now. I’d heard the term before, but it took setting one up myself to understand it.

My current mobile development loop looks roughly like this:

Intent → Linear → Cursor Cloud → GitHub → CodeRabbit / agent review → next decision → repeat

I put what I want to build into Linear. Cursor works on it asynchronously. The code lands in GitHub, CodeRabbit reviews it, and another agent can look at what changed and help figure out what should happen next.

Each step leaves something the next one can work with. Review feedback becomes another task, and the loop continues. Increasingly, my part is deciding what’s worth building and whether the result is any good. A clean review doesn’t tell me whether I asked for the right thing.

Each team could have its own

Once you have this working for software, it’s easy to imagine each team having something similar. Marketing, support, sales. Each has work that moves through a fairly familiar set of steps.

Marketing could take a brief through research, writing, design, and review, then publish. Support could investigate a ticket, respond, and update the knowledge base. Sales could connect account research to outreach and CRM updates. Product could turn recurring feedback into work for engineering.

Teams would decide where they want to stay involved. Fixing a help article and changing how a company describes its product deserve different amounts of review.

I can imagine these factories developing a little at a time. A team gets one workflow running well, then connects another. Eventually, each function has its own tools, agents, and ways of checking the work.

That’s an agentic company I can picture. Then all of those teams have to stay in sync.

The feature shipped. The pricing page is wrong.

Imagine a company decides to make a paid feature available on its free plan.

A coding agent removes the restriction, the tests pass, review catches an edge case, and the update ships. The feature works for free users. The task is done.

Meanwhile, the pricing page still lists it as a reason to upgrade. The docs say you need a paid subscription. A support agent reads those docs and tells a free customer they’ll have to pay. A sales agent includes the feature in an upgrade pitch.

Each system can follow its instructions and still contribute to this mess. Engineering made the requested change. Support used the knowledge base. Sales used the approved materials. The customer gets a different answer depending on where they look.

Making the feature free also changed what other teams needed to know and say. Those updates weren’t part of the engineering task.

The dependencies run both ways. Support finds an issue that should affect product priorities. Sales makes a commitment that creates work for engineering. Each factory can do its job well while the company gets harder to keep in sync.

Someone usually remembers

Companies already deal with this. A lot of it works because someone remembers to tell someone else.

Someone gives Support a heads-up before a release. Someone notices an old claim in a sales deck. Some of this is written down; a lot comes from knowing the business and what tends to get missed.

A team can give its agents more tasks without adding anyone to think through what the results change elsewhere. We could get much faster at making changes while still relying on the same people to catch what follows from them.

More notifications would only get us so far. A merged pull request might mean nothing to someone in marketing. They need to know that a feature is now free and the pricing page needs an update. Then someone has to own that update and check that it happened.

Even when every team can see what the others are doing, there’s still work in understanding what it means for them.

That’s the part I keep coming back to. I can picture each team getting better at running its own factory. I have a harder time picturing how the company keeps up with everything they change.