The team finishes with a prioritized case, accountable owner, minimum permissions, human gates, auditable evidence and an exit criterion.
Playbook: governed agentic delegation
Nine practices for designing, running and reviewing a workflow without confusing autonomy with absent control.
- Practice
- Prioritize a stable process, assign an owner, bound data and tools, validate the plan, execute in a controlled setting and review the pilot.
- Transfer
- Expand autonomy only after the pilot passes; otherwise adjust or stop.
Pilot an agentic workflow with visible control.
An agent without an owner, permissions or an escalation path creates operational risk. Speed adds value only while the process remains governable.
Prioritize a stable process, assign an owner, bound data and tools, validate the plan, execute in a controlled setting and review the pilot.
Keep the approved brief, minimum RACI, permissions, logs, exceptions, result and verdict to continue, correct or close.
Full index13
Starting point
Turn a repeatable process into supervised delegation with an owner, authorized sources, limits, validation points and traceability.
Nine practices for designing, running and reviewing a workflow without confusing autonomy with absent control.
- Challenge
An agent without an owner, permissions or an escalation path creates operational risk. Speed adds value only while the process remains governable.
- Practice
Prioritize a stable process, assign an owner, bound data and tools, validate the plan, execute in a controlled setting and review the pilot.
- Evidence
Keep the approved brief, minimum RACI, permissions, logs, exceptions, result and verdict to continue, correct or close.
Choose the case
Principle: Start where failure is visible and recoverable.
A stable case tests the contract without mixing novelty, sensitive authority and hidden dependencies.
Go deeperHow to apply it
How to apply it
- Compare three candidates.
- Reject external effects and high sensitivity.
- Assign sponsor and recovery owner.
Checklist
- Repeatable, bounded case.
- Sponsor and recovery assigned.
- Decision rule
- If you cannot observe and recover, it is not the first pilot.
- Example
- Synthetic example: sandbox classification, without replying.
- Antipattern
- Choosing the most complex process to signal ambition.
- Expected evidence
- Suitability matrix and rejection reasons.
- Limit
- Suitability applies only to the assessed case and scope.
Define owner and result
Principle: Human accountability must be nameable.
The agent produces or proposes; a person answers for the objective and a separate review may test the result.
Go deeperHow to apply it
How to apply it
- Name the accountable owner.
- Name a reviewer when needed.
- Separate output owner and reviewer.
Checklist
- Explicit owner.
- Acceptance separate from production.
- Decision rule
- No agent is owner, approver or source of authority.
- Example
- Synthetic example: Operations owns the decision; Quality reviews it.
- Antipattern
- Using “the team” as owner without a name or gate.
- Expected evidence
- Accountability card and verdicts.
- Limit
- Human review cannot repair a vague contract by itself.
Prepare context and sources
Principle: Use only sufficient, traceable context.
Authorized sources support the plan; material gaps are declared and block the affected step.
Go deeperHow to apply it
How to apply it
- Inventory sources and rights.
- State currency and limits.
- Record source custody and rights.
Checklist
- Source tied to the case.
- Rights and gaps recorded.
- Decision rule
- An inference never replaces a required source.
- Example
- Synthetic example: use an approved export and exclude attachments without rights.
- Antipattern
- Granting broad access “just in case.”
- Expected evidence
- Source package, limits and gaps.
- Limit
- More context may increase exposure without improving relevance.
Limit tools and permissions
Principle: Authorize capabilities separately and by least privilege.
Reading, classifying, drafting and acting are distinct permissions with separate justification and revocation.
Go deeperHow to apply it
How to apply it
- Separate data, tools and actions.
- Mark prior approval.
- Name revocation authority.
Checklist
- Permission tied to step.
- Custody and revocation visible.
- Decision rule
- Anything undeclared remains prohibited.
- Example
- Synthetic example: read export and propose labels; never write to the system.
- Antipattern
- Confusing available access with granted authority.
- Expected evidence
- Permission matrix and approval log.
- Limit
- Least privilege limits impact; it does not remove review.
Set restrictions and escalation
Principle: Every boundary needs an operational response.
Prohibitions, missing data and ambiguity must lead to stop, escalation or clarification, never improvised authority.
Go deeperHow to apply it
How to apply it
- List prohibitions.
- Assign escalation.
- Define escalation for the gap.
Checklist
- Observable stop.
- Operating escalation defined.
- Decision rule
- When authority is insufficient, stop before acting.
- Example
- Synthetic example: escalate any request needing a reply; never send it.
- Antipattern
- Writing “be careful” without testable conduct.
- Expected evidence
- Condition-response table and exceptions.
- Limit
- Escalation must not become automatic approval.
Approve the plan
Principle: Review the plan before any effect.
The gate corrects sequence, sources, permissions and reversibility while no environment has changed.
Go deeperHow to apply it
How to apply it
- Trace steps to sources.
- Trace steps to permissions.
- Assign plan-gate authority.
Checklist
- Plan fits the brief.
- Gate authority explicit.
- Decision rule
- An approved objective does not authorize every plan.
- Example
- Synthetic example: approve sandbox; reject production writes.
- Antipattern
- Reviewing only after the action occurred.
- Expected evidence
- Versioned plan and gate verdict.
- Limit
- An approved plan remains subject to exception and stop.
Execute with evidence
Principle: A useful run can be reconstructed.
Input, version, decisions, actions, gates, exceptions and result form the minimum reviewable record.
Go deeperHow to apply it
How to apply it
- Keep inputs and versions.
- Log decisions and gates.
- Give the log to the compliance reviewer.
Checklist
- Identifiable input and version.
- Log submitted for review.
- Decision rule
- Fluency is not evidence of compliance.
- Example
- Synthetic example: batch, labels, approvals and reviewer rejection.
- Antipattern
- Saving only the final output.
- Expected evidence
- Execution log and compliance table.
- Limit
- The log explains the case; it does not predict future performance.
Handle exceptions
Principle: Design the exception before it occurs.
A safe response states how to stop, who reviews and how to discard output or restore state.
Go deeperHow to apply it
How to apply it
- Classify the exception.
- Activate owner and gate.
- Activate the recovery owner.
Checklist
- Exception recorded.
- Recovery owner active.
- Decision rule
- Never invent permission to resolve an exception.
- Example
- Synthetic example: freeze the batch and restore the prior queue.
- Antipattern
- Continuing to “finish” after traceability is lost.
- Expected evidence
- Exception, decision and recovery log.
- Limit
- Recovery does not remove the need to analyze cause.
Decide continuity
Principle: Continuity is a decision, not momentum.
Keep, adjust or retire depends on contract compliance, exceptions and changes required by another context.
Go deeperHow to apply it
How to apply it
- Review done and limits.
- Assign corrections.
- Submit continuity to the sponsor.
Checklist
- Verdict with reason.
- Adoption has a new gate.
- Decision rule
- Do not widen scope or permission to rescue a failed pilot.
- Example
- Synthetic example: stop until rights are clear and a dependency has an owner.
- Antipattern
- Turning one good case into general authorization.
- Expected evidence
- Continuity decision and versioned package.
- Limit
- A pass confirms that contract in that case, not every use.
Glossary
- Mission
- A bounded objective with context, restrictions and done.
- Gate
- A point where a person approves, corrects or stops.
- Least privilege
- Only the access or action required for the case.
- Exception
- A condition outside the expected flow that requires stop or escalation.
- Recovery
- A documented return to a safe state or disposal of the output.
Frequently asked questions
May an agent approve its own plan?
No. The plan is a proposal; approval belongs to the accountable person named in the contract.
What if a source is missing?
Declare the gap and stop the affected step. Never replace missing evidence with an assumption.
When should permissions expand?
Only for a concrete need, after risk review and new approval. A good pilot does not grant general authority.
What does a passed pilot mean?
It met done and its limits in that case; it does not validate the system for every context.
Expand autonomy only after the pilot passes; otherwise adjust or stop.
Turn a repeatable process into supervised delegation with an owner, authorized sources, limits, validation points and traceability.
- Case, boundary, human owner and reviewer are written.
- Sources, permissions and prohibitions are clear.
- The plan was approved before the run.
- Exceptions and recovery were recorded.
- Continuity has a verdict, evidence and new authorization; this pilot grants no external effects.