There Are Only Two Types of Work Now: 0 to 1 and N to N+1

Most of the talk about AI at work treats it as one big bucket called "automation." Either a task gets automated or it doesn't.

I think that's the wrong way to see it. Going forward, almost all work falls into two types:

1. 0 to 1: making something that doesn't exist yet.
2. N to N+1: making something that already exists a little better.

Each type gets a very different setup. Humans stay deeply involved in the first, working with a team of agents. The second gets handed to a separate fleet of agents that runs on its own.

If you're a founder or run a small team, sorting your work into these two buckets tells you where to spend your own hours and where to stop spending them.

0 to 1: you plus a team of agents

0 to 1 is the first version of anything. A new product. A new offer. A new market. A blog post that didn't exist this morning.

This work is full of judgment calls with no clear right answer:

• What are we building, and for whom?
• What does "good" look like before there's any data?
• Which of ten directions is worth a month of our time?

Agents are great helpers here. They research, draft, prototype, and pressure-test ideas faster than any team I've worked with. But there's no metric to aim at yet, so someone has to bring the taste and make the call. That someone is still you.

The new part is that you're not doing 0 to 1 alone or with a big team anymore. You're doing it with a team of agents, each handling a piece. I broke down the agents I use day to day in My Updated Agentic Stack for Life and Business.

N to N+1: a fleet of agents that ships on its own

N to N+1 is everything after the first version: iterative improvement. Rankings go up a few spots. A bug gets fixed. A confusing screen gets clearer.

This work has three things 0 to 1 doesn't:

• A clear metric. Rankings, error rate, ticket volume, conversion.
• A live data source. Something already measures that metric every day.
• A repeatable playbook. The fix for most problems looks a lot like the fix for the last one.

That's exactly what an agent needs to work without you. Give it the data, the playbook, and permission to act, and it can run the loop over and over: find the gap, make the change, check the result.

Example 1: improving SEO rankings

SEO is mostly N to N+1 work. Once the site exists, the job is a long list of small improvements.

An SEO agent fleet looks like this:

1. Connect the data. Tools like Ahrefs, DataForSEO, and Google Search Console show what you rank for, what you almost rank for, and which pages are losing ground.
2. Give it predefined skills. Written playbooks for the common fixes: rewrite a weak title and meta description, refresh a page that's slipping, add internal links, fill a content gap a competitor ranks for.
3. Let it run. The agent spots a page sitting at position 11, applies the right skill, ships the change, and checks back in a few weeks.

No one has to remember to do an SEO pass. The pass is always happening.

Example 2: product improvements

Your product already tells you what's wrong with it. Most teams just can't keep up with the signal.

• Errors: an agent watches Sentry (or whatever you use for error tracking). When a new issue shows up, it traces it to the code, writes a fix, and ships it.
• User feedback: an agent sits on top of a feedback board like Canny or support tickets in Intercom. It spots the requests that keep coming up and ships the fix or the small feature.

The backlog of "we should really fix that" stops piling up, because something is working it down every day.

How to set up your first N to N+1 loop

You don't need a fleet on day one. Start with one loop this week:

1. Pick one metric you already track. Search Console clicks, open Sentry issues, or the top support ticket type.
2. Connect the agent to that data. Most of these tools have an API or an integration. No data, no loop.
3. Write the skill. Spell out how you'd fix the most common problem, step by step. This is where most of the setup time goes, and it's worth it.
4. Start with review. Have the agent open a pull request or a draft change you approve. Once it's right most of the time, let it ship the low-risk changes on its own.
5. Measure the metric, not the activity. A hundred changes that don't move the number aren't progress.

"Won't it break things?"

It can. That's why guardrails come before autonomy:

• Keep changes small so they're easy to review and easy to undo.
• Require tests to pass before anything ships.
• Grant autonomy by risk. A meta description rewrite can ship alone long before a change to checkout does.

The honest reality check: the loop isn't free. Expect to spend real time writing and tuning skills, and expect the first few weeks to need close review. The payoff is that once a loop works, it keeps working without asking for your attention.

Where your time goes now

This split changes the job. You spend less time grinding out the next small improvement, and more time on the two things agents can't do for you yet:

• The 0 to 1 calls: what to build next and why.
• Designing the loops: choosing the metrics, writing the skills, and setting the guardrails for the agents that handle N to N+1.

The teams that win won't be the ones with the most people. They'll be the ones whose existing products get a little better every day on their own, while the humans keep building what's next.