You Built a Digital Workforce. Now Try Firing One.

Silicon Valley wants you to build a digital workforce.

Nobody is talking much about the first performance review.

If companies deploy agents in the numbers now being proposed — across finance, procurement, customer service, research and operations — some of those agents will eventually have to go.

Not through some dramatic failure. For much more ordinary reasons.

Some agents will simply not be good enough at the job. Others will begin operating beyond the role management thought it had given them. Some will become compromised or no longer trustworthy. And some will continue to work perfectly well but cease to make sense because the business, economics or regulation has changed around them.

Eventually somebody in authority will say something entirely familiar:

We need to fire this agent.

That is when an organisation may discover that it knows far more about putting agents into the business than taking them out.

There are four ways you get there

The first is performance failure.

One bad answer is not a dismissal. It is a reason to investigate, correct, change a model or tighten supervision. But repeated failure becomes something different. At some point the organisation stops asking how to improve the agent and starts asking why it is still performing the role.

The second is loss of control.

Perhaps its role has gradually widened. Sometimes because people gave it more authority. But not necessarily. An agent may itself begin using the tools, discretion and delegation already available to it in ways nobody explicitly designed. What began as drafting becomes action; one task becomes a chain of tasks; one system becomes activity across several. No one necessarily made a conscious decision that the role should become what it has become.

At some point narrowing a permission or adding another approval step may no longer answer the real concern. The organisation has lost confidence in the agent itself.

The third is integrity or security.

An agent may be compromised. A dependency may no longer be trusted. Its behaviour may become anomalous. There may be uncertainty about what data it has used, which tools it has reached, or whether its operating context has been manipulated. The question is no longer simply which authority to remove. The organisation no longer trusts the actor exercising it.

And the fourth requires no failure at all: the business no longer wants the agent.

The process may have changed. Another system may replace it. The economics may disappoint. Regulation may move. The agent may still be doing exactly what it was designed to do.

It has simply become redundant.

Four different routes. One conclusion: this agent should no longer be part of the business.

That is not the same as reducing its authority

If you reduce what an agent may approve, remove one of its tools, require human sign-off, or move it from execution back to recommendation, you have not fired it. You have changed its job.

If you hit a kill switch while investigating an incident, you may not have fired it either. You may have suspended it.

Firing is different.

The organisation has decided that the agent itself must cease to be an operating actor. Its role is not being trimmed. Its authority is not merely being narrowed. It is leaving.

That distinction matters more with an agent than with any software that came before it. An application is something you use. An agent is something to which you delegate authority: to read, to decide, to act, to schedule future work and to hand tasks to other systems. Trimming its role changes the terms of that delegation. Firing withdraws it altogether, and the withdrawal is complete only when the organisation knows everywhere that authority was exercised.

We understand that distinction with people. An employee can be coached. Responsibilities can be reduced. Someone can be suspended while an allegation is investigated. But eventually there is a different decision: the employment relationship itself is over.

If the technology industry wants us to think in terms of a digital workforce, it inherits the other half of the analogy. Workforces do not merely get hired. They also get managed out.

The human comparison stops here

We know roughly what it means for a person to leave because companies have spent decades building the machinery of departure.

Access is revoked. Open work is identified. Responsibilities are transferred. Delegated authorities are cancelled. The person leaves, while the organisation continues.

There is a boundary between the departing employee and the organisation that employed them.

With an agent, that boundary may be much harder to find.

The agent may have created recurring workflows that no longer require it to run. It may have scheduled future actions, altered the state of another system, delegated work to another agent, or caused another system to treat its output as trusted input.

And the dependency can run in the opposite direction.

Another part of the business may have quietly become dependent on a feed, decision or action the agent was producing, without anyone ever formally recording the dependency. Then the agent is removed — and that part of the business simply stops working.

Nobody intended to create a single point of failure. Nobody even knew one had been created. The dependency becomes visible only when the thing it depended upon disappears.

The work can survive the worker

Imagine removing a procurement employee.

You would not expect contracts they negotiated last month to disappear. Purchase orders they approved still exist. Work they handed to colleagues continues. That is normal because those consequences are visible, and the organisation broadly understands how they relate to the person who left.

Now replace the employee with an agent.

A process it initiated may be running somewhere else. An instruction may already have passed to another agent. A scheduled action may execute tomorrow. A downstream system may continue responding to a status the agent changed three weeks ago. People may continue working on the assumption that the agent is still performing a background check that, from this morning, nobody performs at all.

The problem is that the organisation may not know which of those things will happen.

It can therefore succeed technically — credentials dead, identity unable to authenticate — while failing operationally because it has not identified everything that should have stopped with the agent, everything that should continue without it, and everything that must be transferred elsewhere.

That is not a kill-switch problem.

It is an offboarding problem for autonomous software.

The uncomfortable question is not “is it off?”

What work was still open? What had already been delegated? What recurring processes had been created? Which systems had come to depend on the agent's outputs? Which humans had changed their behaviour because they believed the agent was doing something for them? What should be terminated, what should be transferred, and what should deliberately continue?

And who is able to certify that the distinction has been made?

Nobody can certify it from an inventory. An inventory lists the agents. The question needs an authority map: what each agent is permitted to do, what it has initiated, where it can delegate, what it has scheduled to run later, and what has come to depend on it. Kill switches and rollback, set out in the February risk assessment, act on the agent. The map shows where its authority has already travelled. Without it, an organisation can know exactly which agent it has switched off and still not know what it has stopped.

Deployment usually has an owner, a business case, a vendor, an implementation plan and a launch date.

What does agent removal have?

In many organisations today, probably a button.

The industry has designed the front door

Almost all the language around enterprise agents points in one direction.

Build them. Deploy them. Give them tools. Connect them. Let them collaborate. Let them take on more work. Create the digital workforce.

The direction of travel is inward.

That is understandable. Vendors are paid for adoption, not departure.

Boards do not have that luxury.

A board that permits autonomous actors into the operating environment has to consider the whole lifecycle, including departure.

Not because boards should expect armies of rogue agents.

Because removing agents will eventually become ordinary management.

At scale, some will be excellent. Some mediocre. Some obsolete. Some compromised. Some simply wrong for the role they were given. The ability to remove them cleanly will become as fundamental as the ability to deploy them.

And the worst time to discover what agent removal involves is the morning somebody urgently needs one gone.

The next board question

Boards have already begun asking where AI is being used. The better ones are beginning to ask what authority those systems have been given, how that authority changes, and what the business is becoming dependent upon.

There is now another question.

Not theoretical. Not technical. Not about some imagined future in which artificial intelligence has become uncontrollable.

A straightforward management question for any company serious about creating a digital workforce:

If we decided tomorrow that one of our agents had to leave the business completely, could we actually remove it — and could we prove that everything which should have stopped with it had stopped, while everything that should have continued still worked?

If the answer is a discussion about disabling an account, the question has not yet been answered.

The AI industry has become very good at showing us how agents enter an organisation.