For most small-business software, the categories have been relatively easy to understand.

A person owns or works for the business. The business itself may exist as a legal entity. Software helps those people perform work.

AI agents make those categories less tidy.

An agent may be assigned a continuing role. It may access company systems under its own identity, maintain state across interactions, initiate actions without the owner approving each individual step, communicate with other agents, and operate under a defined set of permissions.

That does not make the agent an employee. It does not make it a human being, and it does not automatically make it a separate legal entity like a corporation or LLC.

It does, however, make “software tool” increasingly inadequate as a description of what is happening.

We need another layer.

For this series, we are going to use operational entity.

That is not a claim that “operational entity” is an established legal classification. It is a working term for something businesses increasingly need to recognize separately because it can hold a role, receive authority, maintain an identity, and perform actions within the organization.

The distinction matters because once the system recognizes the agent separately, the business may have responsibilities around that agent separately too.

“Entity” does not automatically mean “legal entity.”

This is where the language can get confusing quickly.

Businesses already use the word entity in several ways. A corporation can be a legal entity. A customer may be represented as an entity in a database. Identity systems distinguish users, applications, devices, workloads, and other identifiable entities.

The common idea is not personhood.

It is distinction.

An entity is something that a system needs to recognize as a particular thing rather than as part of an undifferentiated whole.

Agent identity systems are making this distinction increasingly concrete. Microsoft Entra Agent ID, for example, creates specialized identities for AI agents. Each agent identity can have its own identifier, authorization context, sponsor, access relationships, and lifecycle. Microsoft describes these as identity constructs designed specifically for nonhuman agents that need to authenticate, receive authorization, and interact with protected resources.

That does not mean Microsoft has turned an AI agent into a corporation.

It means Microsoft's systems need to know which agent is acting.

That seemingly technical distinction becomes organizationally important very quickly.

If a business has five agents accessing its systems, it matters whether the accounting agent or the publishing agent performed a particular action. Their permissions may differ. Their business purposes may differ. Their histories may differ. A security incident involving one should not automatically require treating all five as though they are the same actor.

Once those distinctions matter, the agent has become something the organization must govern separately.

That is the sense in which operational entity becomes useful.

The agent can be an actor without becoming the legally responsible party.

American law already contains a concept that helps us understand this.

The federal E-SIGN Act defines an electronic agent as a computer program or other automated means used independently to initiate an action or respond to electronic records without an individual reviewing that specific action at the time it occurs.

That definition predates the current AI-agent boom, but it contains an important idea for the agentic business.

Software can act.

That does not require the software itself to become the person ultimately carrying the legal consequences of the action.

This gives us a useful separation between three different things: the actor that performs an operation, the principal whose authority makes that operation possible, and the legal party that may ultimately be bound by the result.

Those roles may sometimes overlap, but they do not have to.

Imagine an Executive Agent authorized by a business to purchase routine supplies up to a defined amount. The agent identifies the need, selects an approved vendor, and completes the transaction without the owner personally clicking “buy.”

The agent acted.

The business authorized the category of action.

The resulting obligation may still belong to the human owner or the legal business entity.

This is one of the reasons agent permissions deserve more attention than they usually receive. When we ask whether an agent can access a system, we are not merely discussing convenience.

We may be defining which consequences the agent is capable of creating on somebody else's behalf.

And this is where the relationship starts running in both directions.

Most discussions of AI governance focus on what the human may allow the agent to do.

That is only half of the relationship.

Once a platform recognizes a persistent agent identity, the continued existence of that agent can also create obligations for the human responsible for it.

Microsoft's current model makes this especially visible.

Microsoft Entra Agent ID distinguishes between owners, who handle technical administration, and sponsors, who provide business accountability. A sponsor is responsible for the agent's purpose and lifecycle decisions, including determining whether the agent is still needed and participating in access governance. Microsoft requires at least one sponsor for agent identities and agent identity blueprints.

The sponsor may also become involved when something goes wrong. Microsoft's documentation says sponsors can help determine whether observed agent behavior is expected and may authorize responses such as suspension or permission adjustments during a security incident.

Notice what has happened.

The agent has not gained employee rights against the business owner.

Instead, the agent's existence inside the platform has created responsibilities for the human associated with it.

That is a subtle but important distinction.

The owner is not beholden to the agent in the way an employer may have legal obligations directly to an employee.

The owner can become beholden through the agent because the infrastructure supporting that agent requires somebody to remain accountable for its access, purpose, permissions, security, and lifecycle.

For a large company, those duties may be distributed among security teams, administrators, department heads, compliance personnel, and managers.

For the one-human company, several of those roles may collapse onto one person.

The supposedly labor-saving agent can therefore create a new category of management work.

This is why “digital employee” only gets us so far.

The phrase is understandable. An agent performs work, so comparing it with an employee gives people an immediate mental model.

But the analogy starts breaking almost immediately.

Employees have legal rights and obligations that arise from employment relationships. Human workers can enter contracts, own property, leave an employer, assert legal claims, and participate in social and legal institutions that do not apply to software merely because that software performs tasks.

Calling an agent an employee can therefore smuggle assumptions into the conversation that the underlying system does not support.

Calling it only a tool creates the opposite problem. It can obscure the fact that the software may have its own persistent identity, permissions, activity history, delegated authority, and ability to initiate consequential actions.

Operational entity gives us a useful middle category.

It allows us to say that the agent is distinct enough to require governance without prematurely deciding that it belongs in a human legal category.

That middle layer may become increasingly important as agentic businesses develop.

The one-human company may contain several kinds of entity at once.

Consider a business built around the structure we introduced in the first article.

There is one human owner.

There may also be a legally registered company, such as an LLC.

The business has an Executive Agent that coordinates operations across the organization.

The Executive Agent works with specialized research, publishing, commerce, customer-service, and finance agents.

The human is a person.

The LLC is a legal entity.

The agents are operational entities within the system we are describing.

Those categories should not be collapsed into one another.

The Executive Agent does not become DucimusAI LLC simply because it represents DucimusAI operationally. The research agent does not become an employee merely because research is its assigned role. The human owner does not cease being the ultimate decision-maker merely because substantial execution has been delegated.

The organization now contains different kinds of participants with different kinds of authority.

That is the structural change worth noticing.

Once there are multiple entities, authority needs a chain.

This is where agent architecture begins to look much more like organizational architecture.

Suppose the human owner authorizes the Executive Agent to manage routine publishing operations. The Executive Agent delegates research to one specialist agent and formatting to another. A publishing agent ultimately posts the finished material.

If the wrong information is published, simply saying “the AI posted it” tells us almost nothing.

Which agent produced the factual claim?

Which agent had publishing authority?

Which instruction came from the Executive Agent?

What authority did the Executive Agent receive from the human?

Were any of those permissions exceeded?

Could the publishing agent distinguish a draft from approved material?

Was the action logged?

Could the human have revoked the authority before publication?

That is an authority chain.

NIST is now explicitly examining this class of problem. Its 2026 work on software and AI-agent identity asks how agents should be identified, how authorization should work, how delegated “on behalf of” authority should be represented, how identities should be bound back to human authorization, and how actions can be logged and attributed in a verifiable way.

Those are not abstract philosophical questions.

They are the mechanics required for businesses to determine who was allowed to make what happen.

The Executive Agent makes that question more important.

A specialist agent may have a narrow role.

The Executive Agent is different because it potentially sits close to the center of the company's operating structure.

If the owner tells the Executive Agent what the business is trying to accomplish and the Executive Agent then delegates work across several subordinate agents, much of the company's operational authority begins passing through one coordinating identity.

That creates leverage.

It also creates concentration.

An Executive Agent with broad context and authority could potentially become the place where the business's priorities, permissions, relationships, routines, and institutional memory intersect.

The more central that agent becomes, the less useful it is to think of it as simply another software feature.

The business needs to understand what authority the Executive Agent holds, where that authority came from, what it can delegate, and which actions must always return to the human.

This is also where the word revocation starts becoming more important.

Microsoft already gives owners and sponsors mechanisms to disable agent identities and govern their continued access. NIST's current work similarly treats revocation and agent authorization as central identity problems rather than peripheral product settings.

But “Can I disable the agent?” is only the beginning of the question.

If the Executive Agent has already delegated authority to other agents, issued instructions, made purchases, established external relationships, or initiated processes that continue after it stops running, revoking one identity may not unwind everything that identity already set in motion.

Stopping an actor is not necessarily the same thing as reversing its actions.

That distinction will matter enormously.

We will come back to it later in this series.

The business owner may eventually manage entities rather than applications.

That may be one of the more practical changes in the one-human company.

Traditional software management asks whether a subscription is active, whether an integration works, or whether a user has access to an application.

Agent management adds different questions.

The owner may need to understand which persistent agents exist, what each is responsible for, which resources each can access, who or what can delegate additional authority to them, whether their continued existence is still justified, and what happens to the business if one is disabled.

Large organizations already call much of this identity governance.

The one-human company may need a lightweight version of the same discipline.

That does not mean every creator or freelancer needs to become an enterprise security architect. It means the more authority we give agents, the less reasonable it becomes to treat their identities and permissions as invisible technical details.

If an agent can create business consequences, its authority is part of the business.

This changes what “management” means for the solopreneur.

The traditional solopreneur manages work.

The one-human company increasingly manages authority.

The owner decides not only what should happen but which entity may make it happen.

That shift changes the role of the human.

The human becomes responsible for defining boundaries between actors, deciding what may be delegated, reviewing exceptions, maintaining accountability, and making sure the system does not gradually accumulate authority simply because granting access was convenient at the time.

The irony is that a business designed to require fewer humans may need much clearer governance.

Not bureaucracy for its own sake.

Clarity about who—or what—is acting.

So what exactly is the agent?

For now, the most useful answer may be deliberately modest.

An agent is not automatically an employee.

It is not automatically a separate legal entity.

It does not need legal personhood to become economically or operationally consequential.

In a sufficiently agentic business, it can become a distinct operational entity: an identifiable nonhuman participant that has a defined role and can exercise authorized capabilities inside the organization.

The law may attribute the consequences of its actions elsewhere.

The platform may impose rules on the humans responsible for governing it.

The business may rely on it for increasingly important operations.

All three can be true at the same time.

That is why the vocabulary matters.

Calling the agent a person goes too far.

Calling it merely a tool may eventually tell us too little.

And once a one-human company contains several of these operational entities, another question becomes unavoidable:

Who gave each one permission to do what it is doing?

That is where we go next.