An Agent Is Not an Employee

An agent does not join the company.

It does not accept legal responsibility. It does not understand a role through social context. It does not know when a request from a senior person conflicts with policy unless the system represents that conflict.

An agent is software.

It can receive an identity, use tools, retrieve context, spend money, create records, and propose or perform actions. Those capabilities can make it operationally important. They do not make it an employee.

The employee metaphor is attractive because it gives people a familiar way to discuss agentic systems. It is unsafe because it substitutes a story for an authority model.

BAMS treats agents as distinct software identities with bounded permissions, lifecycle state, budgets, evidence, and escalation paths.

BAMS agent identities and lifecycle state. All displayed data is simulated.

Why the Employee Metaphor Fails

The metaphor creates five problems.

It hides the real permission set

"Finance agent" sounds understandable. It does not tell an operator which accounts, files, tools, transaction types, model routes, or budget the identity may use.

Software needs enforceable scope.

It suggests judgment that may not exist

People rely on professional norms, experience, and hesitation. An agent executes within the context, instructions, tools, and controls it receives.

If the system expects the agent to infer an unwritten boundary, the boundary has not been implemented.

It blurs accountability

A human owner remains accountable for deploying the workflow and granting authority. Describing the agent as a digital employee can imply that responsibility has moved to the software.

It has not.

It encourages broad roles

Organizations do not usually give a new service account access to every tool used by a department. The employee story can lead teams to do exactly that with an agent.

It makes decommissioning sound social

An agent lifecycle is an operational process: provision, activate, pause, resume, restrict, rotate credentials, revoke access, retain required evidence, and decommission.

These are system controls, not personnel management.

The Software Identity Model

A useful agent definition is specific enough to test.

For each agent, record:

• a unique identity
• a bounded purpose
• an accountable human owner
• permitted projects and data classes
• permitted tools and actions
• model routes and data constraints
• budget and quota
• approval thresholds
• stop and escalation conditions
• memory read and write scope
• logging and evidence requirements
• lifecycle state and decommission procedure

This creates an authority envelope.

The agent can operate inside the envelope. The system must stop, reject, or escalate work that crosses it.

The envelope should be narrower than the set of tasks the model can technically perform. Capability and authority are different properties.

Distinct Identities Matter

Using one shared service identity for a fleet makes operations convenient and evidence weak.

When every action has the same technical actor, operators cannot reliably answer which agent accessed a source, used a tool, exceeded a budget, or created an output.

Distinct identities support:

1. Least-privilege access.
2. Per-agent budgets and route limits.
3. Clear audit attribution.
4. Targeted pause and revocation.
5. Separation between ordinary and sensitive workloads.
6. Safer experimentation with new capabilities.
7. Decommissioning without affecting the complete fleet.

The BAMS reference implementation represents a fleet of distinct agents with named roles, tiers, state, load, and lifecycle controls. Its provisioning path can connect an agent identity to access controls, credentials, memory, workspace, inference, and operating configuration.

Sensitive roles can be isolated and masked in operator views. That design reflects another principle: visibility itself can require a permission boundary.

Lifecycle Is Governance

An agent should not move from idea to production through a single enable switch.

A governed lifecycle can include:

Provision

Create the identity, owner, purpose, workspace, access policy, model policy, budget, and evidence requirements.

Validate

Test permitted tasks, denied access, approval boundaries, failure paths, budget behaviour, and stop controls.

Activate

Allow the identity to operate inside the approved workflow and scope.

Observe

Review work state, cost, exceptions, approval behaviour, and evidence quality.

Restrict or pause

Reduce authority or stop activity when the workflow, provider, connector, or risk condition changes.

Recover

Restore service through a documented procedure without losing the state required to understand in-flight work.

Decommission

Revoke tools and credentials, stop scheduled work, retain required evidence, reassign owned work, and remove memory access.

BAMS includes pause, resume, restart, and decommission operations in its agent lifecycle. The presence of a control is only the first step. Each client workflow still needs a policy for who may use it and what happens to open work.

Approval Is an Authority Boundary

Approval should not be treated as an admission that the agent failed.

It is a designed boundary between software recommendation and organizational authority.

An agent can prepare a supplier analysis. A procurement owner approves the decision. An agent can draft a customer message. A named human approves external communication. An agent can identify a budget exception. An authorized owner decides whether to accept it.

The approval request needs enough context to make the decision without replaying the complete agent run. It should identify the work, proposed action, evidence, risk, policy, and consequence of approval or rejection.

BAMS represents approval queues and decision context as operator surfaces. It also includes governance and audit activity around control actions.

The target is not to place a human click in front of every operation. It is to put human authority at the points where the organization requires it.

Budgets and Tools Are Permissions

Permissions are often discussed as read and write access. Agents introduce additional forms of authority.

A browser tool can expose external data. A communication tool can represent the organization. A finance connector can create monetary impact. A model route can send context across a boundary. A high quota can create financial exposure.

Tool access, route access, and budget are permissions.

The agent definition should state not only what the agent can see, but what it can cause.

This is why BAMS connects agent lifecycle to tools, access control, credentials, memory, inference, and budgets. The operating question is the combined authority envelope, not an isolated role label.

The FDE's Responsibility

During a BAMS deployment, the Forward Deployed Engineer helps the client turn a workflow role into an enforceable software identity.

The FDE should not invent authority on behalf of the organization. The accountable client owner defines the permitted work, data, tools, approvals, budgets, and exception path.

The FDE implements and tests that definition, documents it, and transfers the procedure for changing it.

The handover should include:

• the agent registry and human owners
• purpose and prohibited-action statements
• access and tool matrix
• model and data-route policy
• budget and quota settings
• approval thresholds
• lifecycle runbooks
• denied-access and stop-control test results
• decommission checklist

The client operator should be able to pause, restrict, and decommission an identity without relying on BlackUnicorn.

Current Product Boundary

BAMS has a working agent fleet and lifecycle model in its internal reference implementation. It includes distinct identities, roles, tiers, controls, and integration with access, memory, credentials, workspace, and inference configuration.

We are packaging this architecture as a commercial beta appliance for client-controlled deployment. Customer-safe workspace isolation and repeatable module boundaries remain productization work.

The current controls provide evidence of the operating model. A client deployment still requires a workflow-specific authority design and acceptance tests.

The Better Question

Do not ask whether an agent can perform the work of an employee.

Ask:

"Which software identity may perform which bounded action, on which data, through which tool, under which budget, with which approval, and under whose accountability?"

That question is longer because the operating problem is real.

An agent is not an employee.

It is a software identity with bounded authority. When that boundary is explicit, the organization can use the capability without pretending the software carries human judgment or responsibility.

A Minimum Agent Record

The authority model becomes easier to review when each field has an owner and a test.

Purpose

Describe one bounded responsibility in workflow language. Avoid departmental scope. "Prepare a risk summary for new supplier agreements" is testable. "Support procurement" is not.

The purpose should also state the prohibited outcome. The supplier-review identity may not sign, send, amend, or approve an agreement.

Human owner

Name the person or function accountable for the identity's production use. This owner approves material changes to purpose, data, tools, routes, and approval boundaries.

Technical administration can be delegated. Accountability for the workflow should not disappear into the platform team.

Data scope

List the sources and classifications the identity may read or write. Define denied classes and test them. A positive source list is clearer than broad access followed by prompt instructions.

Tool scope

List each tool and the permitted actions within it. Read access to a repository is different from write access. Drafting a message is different from sending one. Creating a proposed record is different from committing it.

Model scope

Define which model routes may serve the work and which data constraints apply. The identity should not gain a broader data boundary because a fallback route activates.

Resource scope

Set budget, quota, concurrency, schedule, and time limits appropriate to the workflow. These limits bound both financial impact and operational blast radius.

Decision scope

Name the conditions that require human approval, the evidence supplied to the approver, and the state that follows approval or rejection.

Evidence scope

Define which request, source, route, tool action, approval, result, and exception records must remain. The identity record should point to the evidence required to review its work.

Review Authority as a Graph

An agent rarely acts through one permission. It combines access across memory, tools, models, projects, and credentials.

The effective authority is therefore the combination of edges:

• identity to project
• identity to data source
• identity to memory namespace
• identity to model route
• identity to tool and action
• identity to credential
• identity to budget
• action to approval owner

Each individual edge may look reasonable while their combination creates an unintended path.

An agent that can read confidential supplier data, use an external model route, and send external messages has a larger boundary than any one permission shows. The review must examine what the identity can cause across the complete path.

BAMS brings these concerns into a shared operating model. The client acceptance process still needs to test combined paths, including denied actions, external routes, and credential revocation.

Revalidation Matters

Authority changes when the workflow changes.

A new connector, model route, data source, tool action, or scheduled trigger can enlarge the envelope. The identity should return to validation when a material edge changes.

Revalidation does not require rebuilding the agent. It requires rerunning the tests affected by the change and recording the result.

This is another reason to avoid the employee metaphor. A software identity does not absorb new responsibility through conversation. Its authority changes when the system changes.

An Example Authority Envelope

Consider an agent that prepares supplier-risk reviews.

It may read agreements from one approved repository and retrieve the current procurement policy. It may use a permitted model route for the document classification. It may write a draft risk note to the BAMS project and create an approval request for legal.

It may not read employee records, use a general browser, send external messages, edit the source agreement, approve the supplier, or select an unapproved model fallback. Its daily model budget and concurrent work are bounded. A denied source, uncertain document version, or high-risk clause moves the case to a named human owner.

This definition is more useful than calling it a procurement specialist.

The team can test every part. Submit an approved document. Submit a restricted document. Remove the model route. Reject the legal approval. Exceed the budget. Pause the identity. Revoke the repository credential. Inspect the evidence.

The result tells the organization whether authority is enforced across the path.

That is the standard BAMS deployments should use: not whether the agent appears competent, but whether its complete authority envelope behaves as the organization approved.

<!-- Editorial evidence: E06 in series/bams-no-strings-attached/EVIDENCE-LEDGER.md -->