Before Your AI Agent Acts, Decide What It May Decide
Conceptual illustration
6 MINUTES READ
When does help become authority?
By Kåre Bjørn Jensen
“The possibility of getting some of that time back matters.
But so does the moment when assistance becomes a decision made on our behalf”
Who gave AI permission to decide?
In my teaching, I want people to see agent development as something they can begin on a manageable scale. That means taking data, permissions and testing seriously while keeping the first task small enough to understand.
There is a balance I want to preserve. People should have room to explore what an agent might help them do, without feeling they must understand every technical detail before beginning. They also deserve to understand what they are handing over.
An agent can offer something appealing: relief from work that consumes attention, repeats itself and leaves less time for the parts of a job that require care. Reading inquiries, finding information and preparing routine replies can take up a substantial part of a working day.
The possibility of getting some of that time back matters.
But so does the moment when assistance becomes a decision made on our behalf.
Imagine a small customer service team introducing an agent to help with incoming inquiries. The following is a hypothetical example, but the situation is easy to recognize.
A customer asks whether an order can arrive earlier. The agent finds the order, checks the available information and writes a friendly reply. It promises delivery by Friday.
The reply is clear. The tone is helpful. The customer is pleased.
Then a colleague sees the message.
Friday might be possible, but it has not been confirmed. Someone now needs to speak to fulfillment, find out what can be arranged and perhaps call the customer back.
For the customer, a promise has been made. For the colleague, the agent has created an obligation they did not choose.
The important question is no longer whether the agent wrote a good email. It is whether anyone had agreed that it could make that commitment.
What we are comfortable handing over
Delegation involves a particular kind of trust. We allow something to happen without personally controlling every step.
That can be welcome. It can also be uncomfortable, especially when the work carries our name or affects a relationship we have spent years building.
An experienced employee may be happy for an agent to find order details while wanting to approve anything sent to a long-standing customer. Another may welcome automatic routine replies but hesitate over complaints, where a small choice of words can affect whether someone feels heard.
These concerns deserve examination. They may reveal something important about the work: an unwritten agreement, an exception, a relationship or a consequence that the proposed automation has overlooked.
When introducing an agent, I think we should make room for a practical conversation:
What would you be relieved to stop doing yourself? What would you want to see before it happened? What would make you feel that a decision had been taken out of your hands?
The answers help define a mandate that people can understand and work with.
In our customer service example, the team might begin by allowing the agent to gather information and prepare replies. Commitments about delivery would remain with someone authorized to make them.
That arrangement gives the agent useful work while preserving a clear point at which a person takes responsibility.
It also gives the team somewhere manageable to begin.
Boundaries people can rely on
A mandate needs to survive contact with the actual system.
If the team agrees that the agent may prepare replies but may not send them, its tools should reflect that decision. Giving it unrestricted access to the mailbox and asking it to remember the boundary leaves too much resting on an instruction.
OWASP’s security guidance on excessive agency recommends limiting the functions and permissions available to an AI system and enforcing authorization where actions are carried out.
For the people using the system, that technical detail has a human consequence: they should be able to rely on the boundaries they were told existed.
If an employee believes every customer message will wait for approval, discovering that the agent can sometimes send one independently changes the relationship. It becomes harder to know what has happened and what still needs attention.
Approval also needs to mean something.
Picture a busy colleague receiving a notification: “Approve response?”
To make that decision, they need to see the proposed commitment and the information supporting it. They need to know whether Friday is a confirmed date or an inference. They must also have the authority to approve the change.
Otherwise, responsibility has been passed to them without the conditions needed to exercise it.
Responsibility has been passed to them without the conditions needed to exercise it.
The same applies when the agent encounters uncertainty.
Suppose an order update times out. The agent cannot tell whether the change succeeded. Someone needs to investigate before the task continues.
A useful handover would explain what was attempted, what was confirmed and what remains unclear. It would go to a named person or team who knows that responding is part of their work.
There is a considerable difference between receiving an unresolved problem with context and discovering one after a customer calls.
Learning what can be delegated
There is a reasonable concern here: if the agent constantly needs attention, will it save any work?
It may not. That is something to discover through a bounded trial, rather than assume away.
The first version might handle a narrow part of the task. The team can then examine where it helps, where it creates extra work and which decisions still require knowledge it does not have.
Anthropic’s engineering guidance recommends starting with simple solutions, adding complexity where it is needed, and using checkpoints and stopping conditions to maintain control. These are useful design principles from a model provider, rather than a guarantee of success in any particular workplace.
For me, their practical value is that they leave room to learn.
Perhaps the agent reliably communicates delivery dates that are already confirmed. Perhaps it struggles to recognize when a customer is asking for an exception. Perhaps the team discovers that its own records are less consistent than anyone realized.
Each finding can inform a specific change.
People need room to revise the arrangement too. A colleague who was initially hesitant may become comfortable delegating more after seeing the agent work. Someone who welcomed it may notice a problem that deserves a tighter boundary.
Both responses can contribute to a better system.
Introducing an agent is therefore also an opportunity to listen carefully to the people who understand the work. Their experience helps determine what the task really involves, which consequences matter and where responsibility should sit.
The customer waiting for Friday’s delivery will probably never see the instructions, permissions or approval process behind the email.
They will experience whether the organization keeps its word.
The colleague handling the inquiry will experience whether the agent made their work more manageable and whether they retained a meaningful say in the decisions for which they are responsible.
Those experiences belong in our definition of success.
Before handing a task to an agent, consider the people around it.
Whose attention might it free? Whose judgment will it still need? Who will have to put things right if it exceeds its mandate?
A useful place to begin is with one piece of work you would welcome help with and a conversation about what you are ready to entrust to something else.
About the author
Kåre Bjørn Jensen is a Danish independent educator and consultant and the owner of Intellia. With more than 20 years of teaching experience, he works with practical AI adoption, data tools and learning. His focus is on helping people make informed decisions about technology in their everyday work.
References and Research Foundations
1. Anthropic. (2024). Building effective agents.
Read the article
2. OWASP Gen AI Security Project. LLM06:2025 – Excessive Agency.
Read the guidance
