01
Understand
Establish the goal, gather permitted context and check what is missing. Source quality matters before a decision is made.
Approach
Earn autonomy. Step by step.
Useful intelligence is more than an answer. It is a controlled loop from understanding the work to verifying what actually happened.
Why do we separate AI decisions from software execution? Because a good answer is not yet a reusable way to get the work done.
The Problem with AI at Work
The working loop
Four steps. No blind handoffs.
02
Reason
Compare options against policies and constraints. Surface the evidence, assumptions and uncertainty behind the proposed next step.
03
Execute
Use narrowly scoped tools and permissions. Request approval before consequential actions and stop when authority or context is insufficient.
04
Verify
Check the resulting system state against the intended outcome. Record exceptions, escalate failures and distinguish an attempted action from a completed one.
From intent to evidence
Start small enough to learn. Design well enough to grow.
-
Discover
Map one workflow with its owner. Identify the baseline, data boundaries, recurring exceptions and decisions that must remain human.
Output: a bounded opportunity and explicit acceptance criteria.
-
Pilot
Test representative cases in a controlled environment. Compare quality, elapsed time, exception handling and review effort with the baseline.
Output: evidence for a go, revise or stop decision—not a demo mistaken for readiness.
-
Scale
Expand only after the pilot meets agreed criteria. Add monitoring, named support owners, change review and recovery procedures before widening access.
Output: an operating workflow with ongoing evaluation, not an unattended experiment.
Delivery artifacts
Define what will be handed over.
These artifacts describe the intended delivery approach. Scope, responsibilities and acceptance criteria are agreed for each engagement.
Workflow blueprint
Make the current process and proposed change inspectable before implementation.
- Named process and system owners, approvals and escalation paths.
- Representative cases and a documented baseline.
- Acceptance criteria, exclusions and go, revise or stop conditions.
Tested capability
Evaluate a bounded implementation against agreed cases, including failure paths.
- Versioned interface contracts and repeatable test cases.
- Least-privilege identities with explicit read and write permissions.
- Idempotent actions, tested retries and partial-failure handling.
Operating handover
Document how the workflow is supervised, changed and recovered, with responsibilities agreed before rollout.
- A runbook with support owners and escalation routes.
- Monitoring for failed actions, review queues and source changes.
- Recovery procedures, rollback limits and manual fallback.
Human authority by design
Approval is part of the system. Not an afterthought.
Agree in advance which actions may run automatically, which need review and which are out of scope. Approval should show the proposed change, its evidence and its likely impact.
Give people a practical way to pause, reject and take over. Plan for duplicate requests, unavailable systems and partial completion, with recovery or compensating actions where appropriate.
Outline a responsible first pilot