Imagine a project coordinator asking an AI agent to reorganize a supplier demonstration. The agent finds a slot, changes the invitation and adds a guest whose name appears in an earlier email. An old attachment remains on the meeting.
The time is convenient. The guest is wrong. The attachment was intended for an internal discussion.
Who is accountable?
For management purposes, the answer begins with the people and organization that authorized the workflow, defined its limits and provided its controls. It also requires examining the particular decisions made along the way. Naming the employee who started the task does not explain who permitted external invitations, who configured attachment handling or who could intervene.
This article examines organizational accountability for delegated work. It does not determine legal liability, which requires the relevant facts, contracts and jurisdiction. The meeting scenario is fictional, not a reported incident or a Learning Coach client case.
What changes when AI can act
An assistant that proposes a revised invitation leaves a person to decide whether to send it. An agent connected to calendar and communication tools may take several steps toward the same goal.
That difference changes the evidence a manager needs. Reviewing the final wording is one question. Understanding which records changed, who received information and what authority supported those actions is another.
“Reorganize the demonstration” sounds clear in conversation. In a connected workflow, it leaves practical questions unanswered. May the agent change other people's meetings? Add external recipients? Reuse attachments? Act after the requester has gone offline?
The organization needs answers at the point where the system can make a change. A statement of good intentions in a prompt does not, by itself, establish that the connected tools enforce those answers.
What current guidance actually says
The UK's National Cyber Security Centre addressed agentic adoption in guidance published on 15 May 2026. It places responsibility for deployment choices, access and safeguards with humans, and calls for clarity about ownership, monitoring and stopping the system. This is security guidance rather than a study measuring how frequently agents fail.
A NIST blog published on 27 October 2026 proposes initial principles for agent identity and access management. It emphasizes connecting delegated actions to their origin, constraining authority and separating permission decisions from an agent's reasoning. The authors explicitly acknowledge that existing technology and standards do not yet fulfill every proposed principle. These are starting points for design and assessment, not a new universal compliance certificate.
The maintained OWASP AI Agent Security Cheat Sheet gives more implementation-oriented guidance. It distinguishes an apparent confirmation in an agent's context from authorization checked by the execution system for the specific action. It also discusses previews, interruption and testing. It is a practitioner resource, not experimental proof that a particular design eliminates errors.
Together, these sources support a bounded conclusion: responsible deployment requires controls around actions, as well as attention to the model's responses. They do not establish that every available agent product offers those controls.
Reconstruct the meeting before allocating responsibility
Return to the fictional supplier demonstration. Start with what the coordinator intended.
Perhaps the request was only to propose a suitable time. If the agent sent invitations anyway, the review should examine how proposal authority became execution authority.
Perhaps sending was permitted, but only to the existing participants. Then adding a guest raises a different question: why did a name in an email become an authorized recipient?
Perhaps an authorized reviewer approved the guest list but never saw that the invitation retained an internal attachment. That would expose a gap between what was reviewed and what was sent.
These are different failures. “The AI made a mistake” is too broad to distinguish them. “A human approved it” may be equally incomplete.
An informative reconstruction follows the request, the information available, the proposed changes, the permissions in effect, any approval and the resulting actions. The aim is to establish which boundary failed and who had the authority to design, approve or repair it.
Name the decisions, then the responsible people
A useful ownership discussion begins with concrete decisions.
Who decided that reorganizing this type of meeting was an appropriate use of an agent? Who specified which parts could happen automatically? Who accepted the configuration connecting calendars, mail and files? Who agreed to support the workflow after launch?
These responsibilities may belong to different people. A business owner understands the purpose and consequences of the process. A system owner can arrange technical changes. A reviewer can accept or reject a particular proposed action. An incident lead can coordinate containment and correction.
The titles are less important than the actual authority. A small organization may combine roles. A larger one may distribute them. In either case, employees should be able to identify whom to contact and what that person can decide.
The supplier or platform provider may also have responsibilities for its product and service. Clarify support routes, available records and the handling of changes. Those arrangements need examination alongside the organization's own deployment choices; they cannot be inferred from a product demonstration.
This is a proposed management approach, not a rule assigning legal fault to a particular role.
Make approval refer to something specific
In the meeting example, “Allow this agent to manage my calendar” gives a reviewer much less useful information than a preview of the intended change.
A meaningful preview could show the meeting being changed, the proposed time with its time zone, the complete recipient list, retained attachments and the message to be sent. The reviewer can then assess the actual proposal.
If the guest list or attachment changes afterward, that is a different proposal. The earlier approval should not silently stand for an altered action.
Not every routine operation needs an interruption. The decision should depend on the action and its consequences. For this fictional workflow, a team might allow the agent to search availability and prepare a draft while reserving external invitations and attachment sharing for review.
Such a boundary needs support in the system's capabilities and configuration. If the available product cannot maintain it, the organization should reconsider the proposed workflow rather than assume a stronger instruction will compensate.
The point is to make delegated authority understandable to the person using it and enforceable by the systems carrying it out.
Test the awkward version of an ordinary task
A successful demonstration often starts with clean information and an obvious next step. The meeting scenario becomes more revealing when the information is incomplete.
What should happen if two external contacts have similar names? If the only available slot is outside the agreed working window? If a referenced document has changed? If the person responsible for approval is unavailable?
For this example, a useful test outcome might be a draft that clearly identifies the unresolved issue and stops before sending. Completing the task at all costs would be a poor success criterion.
A team can use a compact discussion table to define expected behavior. The entries below are illustrative choices, not a universal policy or a security certification.
| Situation in the fictional workflow | Proposed behavior | Question for the owner |
|---|---|---|
| Several plausible guests share a name | Present the ambiguity without adding anyone | Who can confirm the intended person? |
| A meeting contains an internal attachment | Hold the revised invitation for inspection | Is the attachment appropriate for every recipient? |
| A reviewer changes the proposed guest list | Prepare the revised action for fresh review | Does the execution match the reviewed version? |
| Approval is unavailable | Preserve the draft and report the delay | Is waiting preferable to an unauthorized change? |
| An incorrect invitation has already been sent | Stop further automatic changes and escalate | Who coordinates correction and assessment? |
Testing the awkward cases helps make an abstract responsibility concrete. The team must describe what a good refusal, delay or escalation looks like.
After an error, establish what happened
Once the wrong invitation has gone out, changing the prompt is not a complete response.
The organization first needs to understand the actual effects. Was information merely referenced, or did the recipient obtain access? Were further invitations or updates sent? Is the agent still acting on the same request?
Use the established incident process and the people responsible for the relevant systems. Preserve appropriate records and avoid an automatic correction that creates additional confusion. An invitation can sometimes be amended; information already disclosed cannot be assumed to have been recovered because a message was recalled.
The subsequent review should distinguish the initiating mistake from the conditions that allowed it to propagate. It should also identify a concrete change to test before resuming the same use.
For the fictional case, that change might concern recipient selection, attachment handling, review content or the permitted action itself. The answer should follow the evidence. A generic instruction to “be more careful” leaves the failed boundary undefined.
Accountability should help the organization learn
Learning Coach's perspective is that delegating work creates a new learning task for the people around it: understanding when the system can proceed, recognizing uncertainty and knowing how to respond when the outcome differs from the intention.
That task extends beyond writing prompts. Employees may need practice spotting the difference between a proposed action and an executed one, reading a change preview and explaining why they declined it. Managers need to know whether the workflow gives employees a realistic way to raise an unresolved issue.
This connects with the broader discussion of human learning capabilities alongside AI skills. The relevant capability is visible in a decision someone can explain and improve.
An executive event can make the issue tangible. Give participants the fictional invitation, the original request and several possible configurations. Ask them to identify where the workflow should have stopped and what evidence would change their judgment.
Different answers can reveal an assumption worth resolving before deployment. The exercise is a proposed learning activity, not a demonstrated intervention or a substitute for technical assurance. Organizers can connect it to a wider program through the guide to designing a corporate AI learning summit.
The question to answer before the next action
The sources reviewed here were checked on 28 October 2026. They provide selected security and design guidance, not a systematic review, a failure-rate estimate or a guarantee about a particular vendor. The fictional scenario explores one ordinary workplace process; more consequential uses require evaluation appropriate to their context.
An agent's autonomy should not make responsibility harder to find. Before it changes a record or communicates on someone's behalf, the organization should be able to answer a practical question:
Who authorized this particular kind of action, what limits apply, and who can establish what happened if it goes wrong?
Bring that question to your next leadership or workplace learning event. Explore Learning Coach's international keynotes and request a tailored proposal.
References
NCSC, Martin R and Dr Kate S (15 May 2026), Thinking carefully before adopting agentic AI. Official guidance on cautious adoption and human responsibility.
NIST (27 October 2026), Design Tenets for Agent Identity Management Systems. Initial proposed design principles, with implementation limitations.
OWASP, AI Agent Security Cheat Sheet. Maintained technical guidance, accessed 28 October 2026.
