Before You Build an AI Agent, Decide What It Is Allowed to Do.

Most AI-agent projects define a task.

Fewer define the agent's authority.

That difference matters.

“Handle customer requests” could mean summarizing an email for a service representative. It could mean recommending a response. It could mean updating an account, issuing a credit, or sending a binding commitment directly to the customer.

Those are not variations of the same design. They are different allocations of decision-making power.

Before an organization gives an agent tools, memory, or access to business systems, it should decide what the agent is—and is not—allowed to do.

Start with the action, not the label

Terms such as assistant, copilot, automation, and agent are used inconsistently. A reassuring label can disguise the amount of authority a system has been given.

Instead of debating what to call it, examine the actions it can take.

An AI-enabled workflow may allow a system to:

• **Support:** retrieve, summarize, organize, or draft information for a person.
• **Recommend:** propose a decision or next step while a person retains approval.
• **Prepare:** complete most of an action but require a person to release it.
• **Initiate:** act within predefined conditions, limits, and review requirements.
• **Execute:** complete an action without case-by-case human approval.   

The further the system moves from support toward execution, the more carefully the business must define permissions, limits, evidence, exception handling, and accountability.

“Human in the loop” is not specific enough

Many organizations say a person will remain in the loop. That phrase sounds responsible, but it does not explain what the person is expected to do.

Are they reviewing every output or only flagged cases? Do they have enough context to challenge the recommendation? Are they approving substance or merely clicking a button? Can they reverse the action? What happens when they disagree with the agent? How quickly must they respond?

Human review only works when the review point has a clear purpose, an accountable owner, sufficient information, and actual authority to intervene.

Otherwise, the human can become a ceremonial checkpoint in an automated process.

Boundaries should be operational

An instruction that says “do not make risky decisions” is not an operating boundary.

Useful boundaries are connected to the workflow. They may limit:

• the records an agent can access;
• the systems it can update;
• the dollar value or business impact of an action;
• the types of customers, employees, or cases it may handle;
• the confidence or evidence required to proceed;
• the circumstances that require human review; and
• the actions the agent must never perform.  

The goal is not to predict every possible situation. It is to make the agent's operating space clear enough that exceptions become visible instead of silently absorbed.

Permission should match consequence

Organizations routinely give software access based on a person's role. AI agents need the same discipline—often more.

An agent that can search a knowledge base does not need permission to edit customer accounts. An agent that prepares a payment exception does not automatically need authority to release funds. An agent that routes an HR request should not infer that it may make an employment decision.

More access may make a demonstration look impressive. It can also make a mistake harder to contain.

The right design is rarely “give the agent everything it may need.”

It is “give the workflow the least access required for the approved purpose.”

Authority can change over time

An agent does not need to begin with its maximum possible autonomy.

A team can start with recommendations, observe performance, collect real exceptions, improve the workflow, and expand authority only when the evidence supports it. It can also reduce authority when conditions change.

This is not a lack of ambition. It is responsible operational design.

Trust should be earned through performance, not assumed from a successful demo.

The business decision comes first

Agent authority is not merely a technical setting. It is a business decision about who—or what—may act on behalf of the organization.

That decision belongs to the people accountable for the workflow, the customer or employee experience, the data, the risk, and the outcome. Technology can implement the boundary. It should not invent it.

Before you ask what tools an agent needs, decide what authority the business is prepared to grant.