100% Output. 25% Workforce - The Autonomous Workforce: When AI Stops Assisting and Starts Doing - Part 4

Companies can use AI to help employees do their jobs.

I think that's the wrong ambition.

We have AI writing emails, summarizing meetings, generating reports and helping engineers write code. Employees are getting faster at individual tasks and companies are celebrating the productivity gains.

But look at what happens when the AI finishes its work.

Someone still has to review the output, copy it somewhere, update a ticket, notify another department and make sure the next step happens.

The AI helped. The employee is still responsible for moving everything forward.

Now multiply that across hundreds of employees and thousands of tasks.

You have a company where everyone works faster but the business still depends on the same number of people to operate.

In Part 3, I argued that we need to stop hiring people to move information between systems. But connecting those systems is only the foundation.

The next question is much bigger.

What happens when AI doesn't just provide information but actually takes responsibility for executing the work?

That's where the autonomous workforce begins.

Your AI assistant is not an employee

Let's look at a hypothetical customer support operation.

A customer reports an issue. An AI assistant analyzes the ticket, searches the knowledge base and suggests a response.

A support employee reads the suggestion, checks whether it's correct and sends it to the customer.

Maybe the AI saved that employee 10 minutes.

That's useful, but the business still needs someone to process every ticket.

Now imagine something different.

A customer reports that a feature isn't working.

An AI agent receives the request, identifies the customer, investigates the configuration, checks the relevant logs and determines what's wrong.

If the problem is a supported configuration issue, it applies the correction within its approved permissions.

It then verifies the result, updates the ticket and communicates the resolution to the customer.

Nobody had to manually investigate the issue. Nobody had to move information between systems or coordinate the next step.

The problem was resolved.

If the agent discovers a software defect, it can collect the evidence, identify the affected components and prepare the work for engineering. For a well-understood low-risk defect, an approved engineering workflow might even be able to implement and validate the correction.

For an unusual or high-risk change, a human takes responsibility for the decision.

The difference between these two approaches is enormous.

In the first, AI makes an employee more productive.

In the second, AI removes the need for an employee to execute that particular piece of work.

That distinction is what matters if we're serious about operating with 25% of today's workforce.

Stop measuring how much AI helps people

One of the biggest problems with how companies measure AI adoption is that we're still looking at employee productivity.

How many developers use AI? How many hours did we save? How many prompts were executed? How much faster can someone write a document?

Those numbers tell us almost nothing about whether the company can operate differently.

For illustration, imagine two companies processing 10,000 customer support requests every month.

The first company has 50 support employees using AI assistants. They investigate requests faster, draft responses faster and summarize tickets faster.

The second company has built autonomous workflows that can safely resolve 8,000 of those requests without routine human intervention.

The remaining 2,000 require people because the problem is unusual, the system lacks sufficient information or the consequences of a mistake are too significant.

Which company has fundamentally changed its operating model?

The second.

But even that 80% autonomous resolution rate doesn't tell us how many employees the company needs.

If those remaining 2,000 cases are complex and require hours of investigation, the human workload could still be substantial.

If the automated resolutions generate frequent customer complaints, the company may simply have moved the work somewhere else.

So measure what actually matters.

How many requests were completed without human involvement? How long did they take? What percentage were resolved correctly? How often did someone have to reopen the case? How much human work was required to maintain the system?

Most importantly, did the customer get the result they needed?

The number of AI interactions doesn't matter nearly as much as the amount of work the company no longer needs people to perform.

The next employee you hire might not be human

Think about how companies respond when demand increases.

Customer support is overwhelmed. We hire more support representatives.

Engineering has too many requests. We hire more engineers.

Finance can't process everything. We hire another analyst.

The assumption is that additional work requires additional people.

But what if the first question was whether the work could be performed by an autonomous system?

For illustration, let's say your support organization processes 5,000 requests per month and expects demand to double.

The traditional response is to estimate how many additional people are required.

In an AI-native company, I would start by examining which requests are repetitive, which require judgment and which can be resolved through well-defined actions.

If 60% of requests are standard configuration problems, access issues or questions that can be answered from reliable information, why should doubling the volume automatically require doubling the workforce?

Build the capability to resolve those requests.

Make it available to every customer who needs it.

Improve it as new cases appear.

The company might still need more people for the difficult cases. But the relationship between business growth and employee growth has changed.

That's what makes this approach powerful.

A human employee has a limited amount of time. An automated workflow can handle many requests concurrently, subject to the capacity of its systems, operational limits and cost.

You still pay for computing resources, models, infrastructure and maintenance. You still need people to improve the process and manage exceptions.

But you are no longer assuming that every additional unit of work requires another unit of human effort.

The goal isn't to stop hiring people. It's to stop making hiring the default solution to every increase in workload.

An agent needs more than a prompt

This is where a lot of AI initiatives will fail.

Someone builds an agent, gives it access to a few tools and tells it to solve a problem.

It works beautifully in a demonstration.

Then you put it into production.

The agent makes the wrong assumption about a customer. It uses outdated information. A tool call fails halfway through the process. It repeats an operation that already succeeded. It makes a change without understanding the consequences.

Suddenly, the company needs people constantly supervising it.

You haven't created an autonomous workforce. You've created another system that requires manual attention.

Real autonomy requires an operating environment designed around execution, permissions, verification and recovery.

I think of this as the agent harness.

The model provides reasoning and chooses the next appropriate action. The harness controls what the agent can access, what actions it can perform and how its work is tracked.

A production agent needs access to reliable information, but not unrestricted access to everything.

It needs tools that perform specific operations with clear limits.

It needs a durable record of what it has done so it can recover from interruptions.

It needs to understand when a task is complete and when the result hasn't been verified.

It needs an escalation path when it cannot safely continue.

And every meaningful action needs to be traceable.

This isn't just a technology concern.

It's an organizational concern.

The company needs to decide who owns the agent's responsibilities, who approves its permissions, who monitors its performance and who is accountable when something goes wrong.

If nobody owns those decisions, putting the agent into production is not automation. It's introducing unmanaged risk.

Give agents authority, not unlimited freedom

For an autonomous workforce to be effective, agents need to do more than make recommendations.

They need permission to act.

But that doesn't mean every agent should be able to do everything.

Think about a human employee.

A support representative might be authorized to correct a standard configuration issue. They probably aren't authorized to change a customer's contract or issue an unlimited refund.

An engineer might be able to deploy an approved low-risk change. They shouldn't automatically be able to bypass every security control.

The same principle applies to agents.

An agent should have a defined responsibility and the authority required to fulfill it.

A support agent may be allowed to update approved settings after confirming customer identity and entitlement.

An engineering agent may be allowed to create a branch, implement a change, run tests and submit a pull request.

A finance agent may reconcile transactions but require approval before initiating a significant payment.

The permission shouldn't depend on the model deciding that an action seems reasonable.

It should be enforced by the system performing the action.

This is also why human approval should be based on risk rather than applied indiscriminately.

If a human must approve every routine operation, you haven't fundamentally reduced the human workload.

If an agent can make any change without controls, you may reduce workload temporarily and create much larger problems later.

The objective is to define which actions can be completed autonomously, under what conditions and when human judgment is required.

Human involvement should be intentional, not a mandatory step in every workflow.

One person should be able to manage an entire operation

Today we often organize work around the number of people required to execute it.

A support manager leads support representatives. An engineering manager leads engineers. An operations manager coordinates people completing operational tasks.

Now imagine that much of the routine execution is performed by autonomous agents.

What does the human workforce do?

They become responsible for the outcomes those systems deliver.

A support operations owner might oversee automated investigation and resolution across thousands of requests.

Rather than manually distributing tickets, they examine which cases fail, why customers reopen issues and where the autonomous workflow needs improvement.

An engineering lead might oversee multiple development agents working on different changes.

Instead of assigning every small task to a developer, they focus on architecture, important technical decisions, complex implementation problems and the quality of what reaches production.

An operations specialist might manage workflows that handle account configuration, billing preparation and routine data validation.

Their attention goes to exceptions, failures and improvements.

This changes what we expect from employees.

We need people who understand the business outcome, can work with AI systems and have enough technical understanding to recognize when something is wrong.

It also changes management.

If one person can oversee many autonomous workflows, do we still need the same layers of supervisors coordinating individual tasks?

In some organizations, probably not.

But there is an important limit.

One human overseeing twenty agents is not automatically more productive than one human overseeing five.

If those twenty agents constantly require decisions, produce unreliable results or compete for the same limited resources, the human becomes the bottleneck.

The measure isn't the number of agents someone supervises.

It's the amount of verified work those systems complete and how much human attention they require.

A manager of autonomous systems needs to understand the systems well enough to improve them. Simply watching dashboards and forwarding exceptions creates another coordination layer.

Stop building agents that only create more tickets

Let's return to the software engineering example.

A customer reports a defect.

A support agent investigates and creates a detailed engineering ticket.

An engineering agent analyzes the repository, identifies the likely cause and proposes a change.

Another agent writes tests.

A review process checks the change. The approved delivery workflow releases it and verifies the result.

That sounds like a fully automated process.

But look at where it might still break down.

Does product need to approve the priority? Does engineering need to confirm the expected behavior? Can the proposed change affect other customers? Who decides whether it's safe to release?

You can create ten specialized agents and still reproduce every handoff from the old company.

The agents just become participants in the same organizational structure.

That's not what we're trying to accomplish.

For an established class of low-risk defects, the company should define the expected behavior and the conditions under which a correction can proceed.

The workflow should use those rules to investigate, implement, test and validate the change.

For a genuinely new product decision, it should bring the question to an accountable person with enough context to decide.

That person should not have to restart the investigation from the beginning.

And once the decision is made, the process should continue without requiring another employee to manually coordinate each remaining step.

If your AI agents spend most of their time handing work to other agents and waiting for humans, you've rebuilt your old company in software.

The objective is to complete outcomes, not create an impressive network of agents.

Autonomy has to be earned

I wouldn't start by allowing an agent to make unrestricted changes across production systems.

I would start with one category of work where the expected result can be clearly defined and verified.

Let the agent investigate.

Initially, have it propose an action while a person completes or approves the operation. Compare the proposal with the actual outcome and examine failures.

Once the evidence supports it, allow the agent to execute a narrow set of approved actions.

Monitor whether it completes them correctly, whether they need to be reversed and whether customers experience problems.

Expand the scope as reliability improves.

Some operations may eventually run without routine approval. Others may always require a person because of their financial, legal, security or operational consequences.

That isn't a failure of autonomy.

The failure would be making a person approve thousands of predictable actions simply because nobody designed a way to distinguish ordinary cases from exceptional ones.

An autonomous workforce must also be able to stop.

When information is missing, tools behave unexpectedly or the situation falls outside the agent's authority, it should escalate rather than invent a solution.

The escalation should include the evidence, actions already taken, unresolved questions and the decision required.

That's how you keep people focused on work that actually needs them.

The economics change when work completes without people

For illustration, let's say you have 100 employees today.

Your objective is to explore whether you could eventually deliver the same outcomes with 25.

You cannot accomplish that by simply asking every employee to use AI more often.

You need to identify entire categories of work that can be completed reliably without routine human execution.

Start with customer support.

Then examine onboarding, reporting, internal operations and software delivery.

For each category, measure the total workload before and after automation.

In this illustrative example, if a process previously required 500 hours of human work per month and now requires 50 hours including exceptions and maintenance, you've reduced that workload by 90%.

That does not automatically translate into a 90% reduction in staffing. The remaining work may require different skills, continuous coverage or specialized knowledge.

But it is evidence that the operating model has changed.

Now consider what happens when several workflows produce similar improvements.

The company can serve more customers without proportional hiring. Employees can spend more time on product improvements, complex problems and customer relationships.

Eventually, the company may be able to operate with materially fewer people because it genuinely requires less routine human labor.

The financial case must include the full cost of automation. Models, infrastructure, maintenance, oversight and mistakes all matter.

And you must protect the quality of the outcome.

A support operation that appears cheaper because customers stopped reporting unresolved problems is not a successful transformation.

An engineering organization that produces more code but increases outages is not more productive.

The only productivity gain that matters is the one that survives when you measure the complete business outcome.

The biggest change is who performs the work

The traditional company assumes that people perform work and software supports them.

The AI-native company challenges that assumption.

For work that can be performed reliably within defined rules, software and autonomous agents should be considered the default executors.

People remain responsible for judgment, direction, accountability, relationships and the situations that automation cannot safely handle.

That doesn't make humans less important.

It changes where their effort is required.

The real transformation begins when you stop building AI around every employee's existing job and start designing the job around what the autonomous system cannot do.

That will require difficult decisions.

Some roles will change substantially. Some activities will no longer justify dedicated positions. New responsibilities will emerge around designing, maintaining and supervising automated operations.

Companies will need to handle those changes transparently and responsibly.

But preserving every existing task and reporting relationship cannot be the starting requirement if the goal is to fundamentally redesign the business.

The 25% company will not be built with copilots

Copilots can make individuals more productive.

Autonomous systems can change how much human labor the business requires.

Both have value, but they solve different problems.

If your ambition is a 10% productivity improvement, giving employees better tools might be enough.

If your ambition is to deliver 100% of the output with 25% of the workforce, you have to challenge who or what performs the work in the first place.

That means moving beyond AI that drafts, summarizes and recommends.

It means building systems that investigate, decide within approved boundaries, execute, verify and recover.

And it means giving people responsibility for results rather than making them manually supervise every step.

The next time someone shows you an impressive AI assistant, ask a simple question:

"What work can we now complete without a person having to touch it?"

If the answer is none, you may have built a useful tool.

But you haven't built an autonomous workforce.

And you are probably still operating the same company.