Can You Fire an Agent You Don't Fully Own?

For ordinary software, ending the relationship is usually easy to understand.

Cancel the subscription. Delete the account. Uninstall the application. Revoke the API key.

The consequences may be inconvenient, but the conceptual boundary is clear: the software stops being available to you.

AI agents complicate that picture because an agent can become part of the way the business operates rather than merely one of the applications the business uses.

An Executive Agent may coordinate specialist agents, carry operational context, hold access to company systems, initiate workflows, communicate externally, and act as the recognizable operational interface between the business and other digital systems.

Once that happens, asking whether you can “fire” the agent is really asking several different questions.

Can you stop the software from running?

Can you disable its identity?

Can you revoke its authority?

Can you stop the agents and processes that derived authority from it?

Can you undo what it already did?

Can you preserve the business functions that depended on it?

And, eventually, can you replace the agent without losing part of the company with it?

Those are not the same operation.

The first problem is that “off” has several meanings.

Microsoft's current Agent ID infrastructure gives us a useful example.

An owner or sponsor can disable an individual agent identity. Doing so prevents that identity from receiving authentication tokens and blocks its access to protected resources. Administrators can also disable an entire agent blueprint, which blocks existing agent identities created from that blueprint and prevents them from authenticating. At the broadest level, an organization can block agent authentication across the tenant.

That is a meaningful form of control.

It also illustrates why revocation needs precision.

Disabling an identity prevents future authenticated access through that identity. It does not necessarily mean that every process previously initiated by the agent vanishes.

Imagine your Executive Agent has already scheduled tomorrow's newsletter, initiated a payment through another service, instructed a commerce agent to reorder inventory, opened a support workflow, and delegated research to three subordinate agents.

At 4:00 p.m., you disable the Executive Agent.

What exactly stopped?

The Executive Agent may no longer be able to authenticate.

The newsletter may still be sitting in a scheduler.

The payment may already be in a banking queue.

The inventory order may already have reached the vendor.

The specialist agents may have their own identities and credentials.

The customer-service workflow may now be operating inside another platform.

You stopped an identity.

You did not necessarily stop everything that identity caused.

That distinction becomes one of the most important pieces of agent governance.

Revocation of authority is not the same as reversal of consequences.

Businesses already understand this principle when humans are involved.

If a purchasing manager loses purchasing authority at noon, contracts legitimately executed at 11:30 do not ordinarily evaporate because the person's authority ended thirty minutes later.

Agents introduce the same temporal problem at machine speed.

A business owner may revoke an agent's authority now, but some of the consequences created while that authority was valid may remain.

A purchase may need to be cancelled through the vendor.

A publication may need to be removed from another platform.

A credential given to a subordinate agent may need to be revoked separately.

A message already delivered cannot simply be “unsent” from the recipient's memory or systems.

A transaction that settled may require another transaction to reverse it.

The useful distinction is therefore:

revocation controls what the agent may do next; remediation deals with what already happened.

Those should not be treated as interchangeable.

For the one-human company, this matters because the owner may assume that one emergency switch gives her control over the entire agent network.

That is only true if the system was designed so authority actually collapses when that switch is used.

Delegated authority creates a revocation problem of its own.

In the previous article, we looked at the possibility that an Executive Agent may delegate work to specialist agents.

That creates an obvious question when authority is revoked.

If the Executive Agent's authority disappears, what happens to authority it already delegated?

Ideally, the business should be able to trace the delegation chain and determine which permissions depend on which upstream authorization.

If the owner granted the Executive Agent authority to coordinate a campaign, and the Executive Agent granted a specialist agent permission to purchase advertising for that campaign, revoking the campaign authority should have a predictable effect on the advertising agent.

But systems do not automatically behave this way merely because the logic makes sense to a human.

The specialist agent may have received its own credentials.

It may be operating on another platform.

Its authorization may have been granted for a fixed period.

It may have already delegated another task.

That means revocation eventually needs to become transitive.

The system needs to know not only that a particular agent's authority has ended, but whether other authority was derived from it and therefore should end as well.

This is part of why NIST's current agent-identity work focuses on identification, authorization, auditing, and the risks created when agents operate across multiple tools, data sources, and applications. Once authority can move across systems, revocation is no longer a single-account setting.

The business may need an authority map before it needs more agents.

That sounds less exciting than deploying another autonomous workflow, but it may matter more.

A one-human company with an Executive Agent should eventually be able to answer questions such as:

Which agents currently exist?

Which of them have persistent identities?

Which systems can each access?

Which credentials are attached to them?

Which permissions came directly from the human owner?

Which permissions were delegated by another agent?

Which agents can create additional agents?

Which permissions automatically expire?

Which require explicit revocation?

Which workflows continue if the original agent disappears?

And which actions are irreversible once performed?

If the business cannot answer those questions, then it may have more automation than governance.

That is not necessarily catastrophic.

It does mean the human may have less control over the organization than the interface suggests.

“Delete” is also not as simple as it sounds.

Microsoft's current agent-identity model again illustrates the distinction.

Agent identities can be disabled, deleted, restored, and in some cases permanently deleted. Microsoft uses soft deletion for agent identities, with deleted objects entering a recycle state before permanent deletion. Deleting an agent blueprint can also cascade through associated child agent identities and agent user accounts.

That is useful lifecycle management.

But notice how many things “delete the agent” might actually mean in a more complex business.

Delete the runtime?

Delete the platform account?

Delete the identity?

Delete the blueprint that created a family of agents?

Delete stored memory?

Delete credentials?

Delete logs?

Delete external copies of information the agent previously shared?

Delete relationships another system has associated with that identity?

These things may live in different places and belong to different providers.

Deleting the local agent may therefore remove the actor without erasing its footprint.

That footprint may matter.

For audit reasons, the business may actually need some of it to survive.

If an agent made decisions affecting customers or finances, deleting every record of its existence would be the opposite of good governance.

So even the right to delete needs to coexist with another requirement:

the ability to preserve an accountable history.

There is another wrinkle: the sponsor may not have absolute control.

When we imagine a one-human business owner, it is tempting to think that because she created the agent, she necessarily controls every aspect of its lifecycle.

Platform governance can complicate that.

Under Microsoft's current model, owners and sponsors do not have identical powers. Sponsors can disable or delete agents and change sponsorship relationships, but they cannot independently re-enable or restore certain identities after those actions. Owners or administrators may be required for recovery.

That makes sense inside enterprise identity management.

It also reveals something important for the one-human company.

The person economically responsible for an agent may not possess every technical power over that agent.

The platform may divide authority among roles.

Administrators may hold powers the business owner does not.

Recovery may depend on provider infrastructure.

Certain actions may be reversible only within a provider-defined window.

Some capabilities may exist only while the underlying platform account remains active.

This is where ownership language gets slippery.

You may say:

“That's my Executive Agent.”

But what exactly does my mean?

You may own the business purpose.

You may control the instructions.

You may own the data you placed into it, subject to applicable terms.

You may be the sponsor responsible for its conduct.

Yet the agent's technical identity may still be created, recognized, authenticated, suspended, restored, and ultimately constituted inside someone else's infrastructure.

That is not necessarily improper.

Cloud infrastructure works this way constantly.

It does mean we should distinguish economic ownership, operational control, and infrastructural control.

They are not always held by the same party.

This is where “rented organizational structure” becomes useful.

A company has always rented infrastructure.

It rents office space.

It leases equipment.

It uses cloud servers.

It pays payment processors.

It uses email providers.

None of that means the company ceases to be its own organization.

Agents introduce a different possibility because the rented infrastructure may begin carrying pieces of the organization's internal structure.

Your Executive Agent may become the thing that knows which agents exist, what each one does, how work moves between them, which permissions apply, which processes are active, what exceptions remain unresolved, and which outside entities recognize the company.

If that Executive Agent exists only inside Provider A, then Provider A may be hosting more than software.

It may be hosting part of the structure through which the business coordinates itself.

That is what we mean by rented organizational structure.

The concern is not that renting infrastructure is inherently bad.

The concern is knowing which parts of the organization are portable and which cease to function when the rental ends.

A business can survive losing a tool. Can it survive losing its Executive Agent?

That is the better continuity test.

Suppose your preferred image generator disappears tomorrow.

Annoying.

You find another one.

Suppose your Executive Agent disappears tomorrow.

Now ask what goes with it.

Does your company still know which workflows were active?

Can the specialist agents continue?

Does another system know which one should coordinate them?

Do external services still recognize the business?

Can the new Executive Agent inherit the previous agent's permissions?

Can it prove that it has authority to do so?

Can it access institutional memory?

Can you reconstruct the delegation structure?

Can you inspect what the old agent did immediately before disappearing?

Can pending transactions be identified?

If the answers are mostly no, then the business has created a structural dependency that is much deeper than ordinary software lock-in.

The business did not merely lose a tool.

It lost organizational continuity.

Platform failure makes this problem unavoidable.

Now remove voluntary choice from the scenario.

You did not decide to fire the agent.

The platform shuts down.

The product is discontinued.

The company is acquired and the agent service is sunset.

A pricing change makes continued use impossible.

Your account is suspended.

A regional service disappears.

A regulatory change prevents the platform from providing the product in your jurisdiction.

The provider suffers a long-term outage.

Suddenly “Can I revoke my agent?” has an inverse question:

Can the platform revoke my agent from me?

Not in the sense that the provider owns your business.

In the practical sense that the provider may control the technical environment necessary for that agent identity to continue existing.

If your organization depends on that identity, then platform failure becomes business-continuity failure.

That is why the agentic company needs to think about exit before crisis.

Not because every provider is untrustworthy.

Because every dependency has a failure mode.

Interoperability helps, but it does not automatically solve continuity.

There is meaningful progress here.

The Agent2Agent Protocol, or A2A, reached version 1.0 in 2026 and is specifically designed to let agents built on different platforms and frameworks communicate across organizational and technology boundaries.

That is important.

It makes the ecosystem less dependent on every agent living inside one proprietary stack.

But communication interoperability is not automatically identity portability.

A new Executive Agent may be able to speak the same protocol as the old one.

That does not necessarily mean other agents will recognize it as the same entity.

It does not automatically transfer the old agent's history.

It does not automatically transfer permissions.

It does not automatically transfer reputation.

It does not automatically transfer delegated authority.

It does not necessarily preserve external trust relationships.

So interoperability answers:

Can these systems talk?

Portability asks a much harder question:

Can this business relationship survive when one of the systems changes?

We will deal with that distinction directly in the next article.

The real off-switch may belong above the agent.

This is where I think the architecture of the one-human company needs to evolve.

If the Executive Agent itself becomes the root of organizational authority, the business becomes fragile.

Everything below it may depend on the continued existence of that one agent identity.

A more durable structure would place the business's root authority above any individual agent.

Conceptually:

Legal business / business identity

authorizes

Executive Agent

which delegates to

specialist agents.

That way, replacing the Executive Agent does not require reinventing the business's identity.

The company remains the principal.

The agent remains an authorized representative.

That distinction may feel technical until the day the agent must be replaced.

Then it becomes the difference between:

“We hired a new Chief of Staff.”

and

“We accidentally founded a new company.”

The digital version should work much more like the first.

“Firing” an Executive Agent therefore needs a succession mechanism.

A mature process should eventually look less like deleting software and more like changing an important organizational role.

The outgoing Executive Agent should lose authority.

Derived authority should be reviewed or revoked.

Pending actions should be identified.

Credentials should be rotated where necessary.

Institutional memory that belongs to the business should remain accessible.

The successor should receive only the permissions that are intentionally transferred.

External systems should have a way to recognize that the new agent is now authorized to act for the same business.

Audit history should remain intact.

None of that requires pretending the agent is human.

It simply acknowledges that the role became important enough that its removal affects organizational continuity.

This is why the Chief-of-Staff analogy for the Executive Agent works better than the employee analogy.

A human Chief of Staff may leave without the company ceasing to exist.

The organization's authority survives the person occupying the role.

The digital structure should ideally work the same way.

And the business owner needs control over both sides of the relationship.

Earlier in this series, we asked how much authority an agent should receive.

Now we can add the other half.

A business owner needs to know both:

How do I authorize this entity to act?

and

How do I make that authority end?

Those two abilities belong together.

Authorization without meaningful revocation is not full control.

Revocation without continuity is not full control either.

If the only way to stop your Executive Agent is to destroy the accumulated memory, relationships, permissions, and operational structure that your company depends on, then technically you can fire it.

Economically, you may not be free to.

That is the deeper lock-in risk.

Not:

“Switching AI providers is annoying.”

But:

“Switching AI providers may require rebuilding part of the organization.”

That is a fundamentally different problem.

So can you fire an agent you don't fully own?

In many current systems, yes, you can disable or delete an agent identity you control or sponsor, subject to the roles and mechanisms the platform provides. Microsoft already gives organizations substantial control over disabling identities, restricting access, deleting agent structures, and governing their lifecycle.

But that is only the narrow technical answer.

The business answer depends on what the agent has become.

If it is a disposable task agent, firing it may be trivial.

If it is the Executive Agent holding the company's operational context, authority relationships, workflows, history, and connections to other entities, disabling it may be easy while replacing it is extraordinarily difficult.

That is why the most important question may not ultimately be:

Can I turn my agent off?

It may be:

Can I remove this agent without removing part of my company with it?

If the answer is no, then the business does not merely have an agent dependency.

It has an organizational dependency.

And that takes us directly to the next question:

If your Executive Agent has become part of the continuity of the business, can you actually take that identity somewhere else?