Agentic AI needs an authority model
Before an agent can act for the organisation, leaders must define what it may decide, what it may change, and when a person must intervene.
Giving an AI agent access to business tools is a delegation decision. An agent that can examine information has a different mandate from one that can change an order, communicate a commitment, or move money. The organisation should define those distinctions before it connects the tools. A vague instruction to be helpful is an inadequate description of authority.
Anthropic distinguishes predefined workflows from agents that direct their own process and tool use. That flexibility makes the boundary of action especially important. A capable system may discover a path its designers did not anticipate. The enterprise still needs to decide which actions on that path are authorised. (Anthropic source)
Separate preparation from commitment
Consider an illustrative procurement assistant responding to a late supplier delivery. It could retrieve the order, compare permitted alternatives, and prepare an explanation for the buyer. Those activities support a decision. Changing the supplier, accepting a higher price, or sending a revised contractual commitment crosses a different boundary.
I would describe the mandate in four levels: inspect information, recommend an option, prepare an action, and execute an authorised action. These are proposed design categories, not a universal industry standard. Their purpose is to make the difference visible to business owners and system designers. A use case can occupy more than one level, provided the transitions are controlled.
The control should operate in the connected system as well as in the agent’s instructions. Access should be limited to the records and operations required for the task. An action outside the mandate should fail safely or require an authorised person. A convincing explanation from the model does not expand its permission.
Design the exception before the happy path
The procurement example needs rules for incomplete information, conflicting supplier records, and a change that exceeds the approved commercial limit. It also needs a response when the tool reports an ambiguous outcome. Retrying an uncertain action can create a second order or duplicate a communication if the surrounding system does not prevent it.
A human checkpoint should present the proposed action, the evidence supporting it, the uncertainty, and the expected consequence. Sending a reviewer a long activity log is a poor substitute for a decision brief. Review capacity also matters: an approval queue that nobody can service can turn a sensible control into an operational blockage.
The business owner should know who receives exceptions, how urgently they must respond, and what work continues while the agent waits. The technical owner should know how to suspend the agent, preserve its activity record, and reconcile actions already completed. These responsibilities should be exercised before the service becomes routine.
Expand autonomy through evidence
My preference is to begin with a narrow decision and limited permissions. Test ordinary cases alongside missing data, contradictory instructions, unavailable tools, and attempts to push the agent outside its task. Judge the complete workflow, including human review and recovery, rather than the plausibility of a single response.
An organisation can then consider additional authority when evidence supports it. The case for expansion should identify the remaining failure modes and the effect of a mistake. Some decisions will continue to justify human approval even when the agent performs well. The consequence and reversibility of an action matter alongside its average accuracy.
Agentic AI becomes a useful enterprise capability when delegated authority is understandable to the people accountable for its effects. The essential leadership question is what the organisation is prepared to let this system do on its behalf.
Developed from my EA 878 capstone on the Cognitive Enterprise Architecture Framework (CEAF); coursework on architectural alignment in project management plans. These recommendations extend the coursework; examples are illustrative and do not report an employer assessment or measured results.