And Other Duties as Assigned

Most of us have seen the line at the bottom of a job description.

And other duties as assigned.

It is how someone hired to run reports ends up onboarding interns, ordering lunch, and fixing the printer.

The phrase gives managers room to adapt. It also gives organizations room to avoid deciding where a role ends.

People can question those boundaries. They do not always do it. Plenty of employees absorb responsibilities that were never properly assigned, supported, or reviewed.

Automation creates another way for that to happen. A new connection, permission, or instruction can expand its responsibilities without prompting anyone to reconsider the whole job.

The organization calls it a small enhancement.

It may be a substantial delegation of authority.

Whether you use an AI agent, an automated approval, or a workflow that updates records, the leadership question is the same. What is it authorized to do today, and who approved that authority?

The bot that kept getting promoted

Consider a hypothetical AI agent built to read incoming service requests and route them to the right team.

Its purpose is clear. It has an owner. Its access is limited to the intake queue.

Then the requests start.

• Month twoSince it already reads the requests, could it draft replies? It gets access to email.
• Month fourCould it update customer records? It gets permission to change the database.
• Month sixCould it approve refunds under $200? It gets authority over money.

Each change solves an immediate problem. Each looks reasonable in isolation.

Each one is treated as a ticket, not a decision.

By month six, the agent hired to sort the mail is preparing customer communications, changing records, and approving refunds. Nobody has assessed whether its controls or supervision are adequate for the expanded role.

The consequences now reach beyond a misrouted request. An incorrect record can affect a later decision. A refund can release money without the intended review. If the next enhancement allows replies to be sent automatically, the agent can make commitments on the organization’s behalf.

The automation may be working exactly as configured.

The organization has lost track of what it authorized.

A technical change can be a management decision

Connecting an agent to email is a technical task. Deciding whether it may send messages on the organization’s behalf is a management decision.

The same distinction applies to changing records, approving payments, or closing cases.

When those decisions disappear inside configuration work, technical capability can become business authority by default.

OWASP identifies a related risk in LLM-based applications as Excessive Agency, driven by excessive functionality, permissions, or autonomy. Its guidance includes limiting access, requiring human approval for high-impact actions, and enforcing authorization in connected systems rather than relying on the language model to decide what is allowed.

That last point matters.

A written instruction to “never approve refunds over $200” is not equivalent to a system control that prevents it.

Review the whole role

Approval rests on assumptions about the work, its consequences, and the controls around it. Routing a request and approving a refund require different judgments and supervision. Approval for one does not establish readiness for the other.

Before expanding an automation’s role, answer five questions.

1. 01
   What new work are we authorizing? Define the duty and its limits.
2. 02
   What access does that work require? Grant only what is needed.
3. 03
   What may it decide independently? Specify what requires approval or escalation.
4. 04
   How will we detect and contain mistakes? Establish monitoring, intervention, and recovery.
5. 05
   Who is accountable for the expanded role? Name the person authorized to approve it and responsible for its performance.

Consider the combined responsibilities. Permission to read a request, change a record, and issue a refund creates a different level of exposure when one agent holds all three.

Every addition may look sensible. The cumulative authority still deserves scrutiny.

Review should also extend beyond new duties. Changes in ownership, policies, models, or the underlying process can make earlier assumptions unreliable. Periodic checks help catch changes nobody recognized as significant at the time.

Flexibility still needs an owner

The fair objection is that AI agents are valuable because they can handle varied work. A lengthy approval process for every adjustment would undermine that value.

Agreed.

Define a useful operating boundary in advance. Specify the tasks an agent may perform, the systems it may use, the decisions it may make, and the conditions that require human involvement.

Teams can improve performance within that boundary. Crossing it requires a deliberate decision, proportionate to the consequences.

The review should fit the exposure. What matters is that someone considers the expanded role before the organization starts relying on it.

End the job description with a period

Ask the owner of an automation to show you its current responsibilities, permissions, approval requirements, and escalation rules.

Then compare that record with what the system can actually do.

Any difference is a reliability gap. Someone should own closing it.

A defined role can change. When it does, someone with the authority to approve the change must also accept responsibility for its consequences.

A bot’s job description should end with a period, not “and other duties as assigned.”