A responsible-autonomy workshop for one real workflow

“How autonomous should our agent be?” sounds strategic but is too abstract to answer. Autonomy belongs to a workflow: which action, for which user, on which resource, under which condition, with what consequence and recovery path.

A responsible-autonomy workshop turns one real workflow into a bounded decision. Its output is not an AI maturity score. It is an authority map, control design, evidence backlog and named owner for the next gate.

Prepare a workflow, not a slide deck

Choose a workflow with a real owner and a plausible decision in the next planning horizon. Gather the current process, roles, policies, systems, exception paths, incident history and a small sample of representative cases. Do not start from a vendor demonstration.

Write a neutral question: should an agent be allowed to propose, execute or coordinate defined steps in this workflow? State constraints already known, including data location, regulated decisions, customer commitments and systems that cannot be changed.

The NIST AI RMF Core maps risk in context before measurement and management. Preparation should give participants enough context to discuss consequences rather than debate AI in general.

Map the work and decision points

Walk through the current workflow from trigger to completion. Identify information gathered, judgements made, system changes, approvals, handoffs and recovery steps. Mark where work is deterministic, where discretion matters and where delays or errors create cost.

For each step, ask whether the proposed system would read, recommend, draft, decide, act or coordinate. These verbs expose authority more clearly than labels such as copilot or autonomous agent.

Capture the result in a workflow table:

Step	Current owner	Proposed agent role	State changed	Exception path
Interpret request	Service team	Classify and propose	None	Human review
Check eligibility	Policy owner/system	Retrieve and compare	None	Escalate conflict
Apply change	Authorised operator	Execute after confirmation	Customer record	Reconcile/rollback

Classify authority by consequence

Discuss consequence for each proposed action: who could be affected, scale, reversibility, time to detect and available remedy. Avoid one autonomy level for the whole product. An agent may act freely on low-impact internal formatting while requiring confirmation for an external commitment.

Use four practical modes:

• observe and summarise;
• propose for review;
• act within explicit limits;
• act and escalate defined exceptions.

These are design options, not a universal standard. The right mode is the lowest authority that still creates useful workflow value. The GAO accountability framework connects governance, data, performance and monitoring; the workshop should do the same for each chosen mode.

Design human control as part of the workflow

“Human in the loop” is not a control description. Name who reviews, what evidence they see, what action they can take, how much time they have and what happens when they do nothing. Check whether workload and incentives make meaningful review plausible.

Different points need different mechanisms: confirmation before a high-impact action, exception review for ambiguous cases, sampled quality review, or emergency intervention after an operating signal. The NIST human-AI interaction appendix treats human roles, configurations and oversight as part of risk management rather than a generic safeguard.

Test whether a handoff preserves context, trace and authority. If the person must reconstruct the case or lacks permission to correct it, the handoff shifts burden without restoring control.

Define evidence before selecting the technology

For each proposed authority, state what must be true and how it will be evaluated. Include outcome correctness, tool and policy behaviour, recovery, handoff, cost and latency. Identify routine, boundary, fault and adversarial cases.

Write release criteria in decision language. For example: the agent may update a record only for authenticated users, after explicit confirmation, with no cross-account action in the evaluation set and a tested reconciliation path for partial failure. Thresholds must reflect consequence; they are not workshop decoration.

List evidence gaps and owners. Some questions may require legal, privacy, security or domain analysis outside the room. The workshop should expose those dependencies, not improvise professional conclusions.

Stress the operating and recovery model

Ask how the organisation will identify the agent, restrict credentials, observe actions, detect drift, suspend one capability and recover external state. Include model, tool, retrieval and provider changes that can invalidate evidence.

The NCSC secure AI development guidance spans design through secure operation and maintenance. Use that lifecycle to prevent the workshop from ending at a pilot prototype.

Define post-release obligations: monitoring questions, incident triggers, reevaluation events, user feedback and accountable review cadence. A proposed workflow without an operator is not ready for higher authority.

Leave with a decision artefact

Close by recording the workflow scope, proposed authority per action, human controls, evidence required, open specialist questions, exclusions, owner and next gate. Note disagreement rather than forcing artificial consensus.

The possible outcomes are proceed to design/evaluation, narrow the authority, use conventional automation, conduct more discovery or stop. All are useful. Responsible autonomy is not maximum delegation with safeguards added later; it is an explicit allocation of action and accountability that the organisation can evidence and revise.

Facilitate disagreement as evidence

The most valuable workshop moments often occur when participants disagree about what the workflow actually permits. A policy owner may believe approval is mandatory while operators routinely use an exception; engineering may treat a downstream API as reversible while the business knows it triggers an external commitment. Capture these contradictions instead of resolving them through the loudest voice.

Use scenario cards to make differences concrete. Present a routine case, a high-value case, a user with reduced permissions, conflicting source data, a tool timeout after partial execution and a request that falls just outside policy. For each, ask the group to choose the permitted agent action, required evidence and recovery owner. Variation in answers becomes a requirements backlog.

Keep four parking areas visible: policy clarification, technical experiment, specialist review and operating change. This prevents legal or security questions from being guessed in the room and stops technical uncertainty from being mislabeled as policy. Each parked item needs an owner and a decision date.

Close with a pre-mortem: assume the chosen design caused a material incident six months later. What combination of authority, data, interface and organisational behaviour made it possible? Then check whether the evidence plan exercises that combination.

The facilitator should not sell the agent or force a maturity narrative. A good session may conclude that standardised automation or a clearer human process is the responsible design. The quality of the workshop is measured by the clarity of its decision artefact and follow-through, not by how much autonomy it approves.

Within two working days, circulate the artefact for factual correction, not wholesale renegotiation. Mark unresolved decisions explicitly and schedule the next gate. Teams lose confidence when a workshop produces attractive canvases but no authoritative record.

Measure follow-through through evidence: policy questions closed, cases assembled, controls prototyped and owners accepting decisions. Do not claim impact from attendance or satisfaction alone. If the workflow changes before evaluation, reconvene only the affected decisions rather than repeating the whole workshop. This keeps the method lightweight while preserving traceability.

The workshop should make one workflow easier to govern, not make the organisation feel more advanced. Its durable output is a bounded authority choice that can be tested, challenged and revised.