Closed Loop Process And Human Oversight Design

Closed-Loop Process & Human Oversight Design

Purpose

Help you see the business as a collection of processes, some of which are "open loops" (executed, not learned from) and some of which could be "closed loops" (executed, measured, automatically adjusted on the next cycle). This skill provides the language and decision framework for which processes are worth designing as closed loops, and where the human needs to stay involved in decision-making — via a three-tier in-the-loop/on-the-loop/outside-the-loop model.

Based on

• The owner's AI-native Business Design workshop (the owner's own workshop), run 1–2 June 2026, Day 1 — Session 1 "AI as the operating system your company runs on": the open loop (Input → Execution → Output, no systematic feedback) vs. the closed loop (Input → Execution → Output → Feedback → Adjustment → back to Input); the core idea that "your company isn't one closed loop — it should be a set of closed loops," each run by agents and orchestrated together.
• The human-in-the-loop / human-on-the-loop / human-outside-the-loop three-way split on the level of human oversight in an AI process.
• Agent, orchestration, and tool/agent-registry concepts, as presented by the workshop.

Method

1. Choose a process to examine. E.g. order processing, customer support, content production, quality assurance, sales tracking.
2. Map the process as it currently stands. Is it an open loop — Input → Execution → Output with no systematic feedback that would change the next cycle — or does it already have a partial feedback mechanism? Most companies, and most parts of most companies, run as open loops: learned information leaks away each cycle instead of improving the next one.
3. Design the closed loop. Add Feedback and Adjustment stages: Input → Execution → Output → Feedback → Adjustment → (back to Input). A closed loop is self-regulating — it watches its own output and adjusts its behavior to keep hitting the target.
4. Give the loop a clear, measurable goal. A closed loop only works if it knows what it needs to achieve and can measure progress toward it.
5. Decide the human's position relative to the loop, from three options:
   • Human-in-the-loop — a human reviews/approves every step before it proceeds. Highest control, slowest, suited to high-stakes or still-untested processes.
   • Human-on-the-loop — the process runs independently, a human monitors and can intervene when needed. A good middle ground once the loop has proven reliable.
   • Human-outside-the-loop — the process runs fully automatically with no human in any individual case. Fastest and most scalable, suited only for a trusted loop where the cost of error is low.
6. Honestly assess whether the workflow is genuinely closed-loop shaped before you set out to automate it: does it have a clear goal, machine-readable inputs, well-defined tools an agent can use, and a measurable success signal? If the work is mostly quiet human judgment without these, document the process manually first rather than trying to automate it directly.
7. Once multiple loops have been designed: record a tool/agent registry — which agents/tools are in use, what each does, and how work is routed to the right place. Think about orchestration: how the separate loops coordinate into a bigger, coherent whole.

Gotchas

• Calling a process "closed loop" just because it has some occasional feedback is not the same as it having explicit Feedback and Adjustment stages that actually change the next cycle's behavior — step 2 notes most companies run as open loops where learned information leaks away each cycle, and it's easy to mistake ad hoc feedback for a real loop.
• Defaulting to human-outside-the-loop because it's fastest, without the loop having actually proven reliable, contradicts the method: that tier is suited only to a trusted loop where the cost of error is already known to be low, not to a newly designed one.
• Forcing a process into the closed-loop framework when it's mostly quiet human judgment without a clear goal, machine-readable inputs, well-defined tools, and a measurable success signal is exactly what step 6 warns against — document it manually first instead of automating it prematurely.
• This skill is the initial design choice, not the ongoing governance layer — once a loop is live with real usage data to calibrate against, the deeper model (confidence-score routing, override-rate diagnostics) lives in ../../../../human-ai-collaboration-design/skills/hitl-maturity-and-confidence-routing/SKILL.md, not here.
• The goal is removing the bottleneck of human judgment only where it isn't genuinely needed — treating "closed loop" as a mandate to automate everything and remove judgment entirely is the opposite of what the method intends.

What this skill does NOT do

• Does not recommend automating everything — the main message is the opposite: the goal is to remove the bottleneck of human judgment from the places where it isn't genuinely needed, not to remove judgment entirely from where it is needed.
• Does not assess a specific AI tool's technical feasibility — see ../ai-native-tool-stack-selection/SKILL.md and ../../../../ai-strategy-and-governance/skills/ai-use-case-feasibility-and-poc-scoping/SKILL.md.
• Does not replace a responsible-AI governance check for high-risk use cases — see ../../../../ai-strategy-and-governance/skills/responsible-ai-and-governance-check/SKILL.md and, if needed, separate EU AI Act regulatory expertise (not included in this skills pack).

Continue from here

• Preceding/related skill in this pack: ../ai-native-opportunity-scan/SKILL.md (the agentic-ness identification criterion that this skill deepens).
• Related skill in another pack: ../../../../ai-strategy-and-governance/skills/ai-opportunity-portfolio/SKILL.md (the "Degree of Agenticness" stage), ../../../../ai-strategy-and-governance/skills/responsible-ai-and-governance-check/SKILL.md
• Related skill in another pack: ../../../../business-design-frameworks/skills/value-chain-mapping/SKILL.md — a complementary way to structure the same business as a value chain rather than as processes.
• Once a loop is live and needs deeper operational governance, not just this initial design choice: ../../../../human-ai-collaboration-design/skills/hitl-maturity-and-confidence-routing/SKILL.md — a four-level maturity model with confidence-score routing, a named accountable calibration owner, and override-rate diagnostics. This skill's simple in/on/outside-the-loop model is still the right starting point for an early-stage design decision; the linked skill is the deeper layer for once the process has real usage data to calibrate against.
• The pack's shared guardrails: ../../CLAUDE.md

References

• ../../references/workshop-source.md — source information
• ../../CLAUDE.md — the pack's shared guardrails