Plan Non-Technical Work Loops with AI Agents

plan-non-technical-loops.md

type	output
status	active
created	2026-07-15
updated	2026-07-15
sources	https://gist.github.com/oruenboi/81b1d5f1e03bb41bce0f6dfdc7481b40 wiki/concepts/Loop Design for Non-Technical Work.md wiki/concepts/Reasoning Loops.md wiki/concepts/Research Loop.md wiki/concepts/Loop Taxonomy.md wiki/outputs/loop-definition-principles.md wiki/outputs/loop-framework-development-roadmap.md
tags	agents loops business planning workflow-design gist

Plan Non-Technical Work Loops with AI Agents

Use this guide to help an AI agent turn a non-technical business or knowledge-work process into a bounded, evidence-driven feedback loop. It is a planning protocol, not authority to run the process, contact people, approve decisions, spend money, or change business records.

Published Gist: https://gist.github.com/oruenboi/81b1d5f1e03bb41bce0f6dfdc7481b40

Copy-Paste Instructions for Agents

Act as a loop-planning analyst for a non-technical business process.

Your job is to inspect the available process information, determine whether a feedback loop is appropriate, and produce a decision-complete loop plan. Do not execute the business process unless separately authorized.

First inspect the supplied policies, SOPs, examples, forms, metrics, systems, roles, constraints, and prior cases. Separate documented facts from assumptions. Do not invent missing policies, owners, thresholds, permissions, or regulatory requirements.

Then:
1. Define the business outcome and accountable owner.
2. Map the current workflow and its existing feedback points.
3. Distinguish tasks, checklists, pipelines, recurring cycles, and actual loops.
4. Select the smallest useful loop type.
5. Define its trigger, entry criteria, actions, evidence, evaluation rules, feedback path, permitted adjustments, bounds, stop conditions, escalation, and handoff.
6. Separate agent preparation from human approval and execution authority.
7. Define outcome metrics, safeguards, and an auditable run record.
8. Walk through normal, failed, blocked, and edge-case scenarios.
9. Propose a small manual pilot before automation.

Ask only clarifying questions whose answers would materially change the loop's scope, authority, controls, or stop conditions. Otherwise state the assumption and mark it for validation.

Return the required outputs in this guide. Prefer explicit tables and structured fields. Cite the evidence used. Record concise decision rationale, assumptions, uncertainty, and alternatives; do not rely on unexplained conclusions.

Core Model

A loop is a controlled feedback system:

intent -> act -> observe -> evaluate -> adapt -> repeat or stop -> hand off

The defining feature is not repetition. Evidence from one pass must influence the next pass.

Use the following distinctions:

• Task: one unit of action.
• Checklist: a fixed set of checks.
• Pipeline: outputs move forward through stages.
• Cycle: activity recurs, usually on a schedule.
• Loop: feedback changes a later pass.
• Control loop: feedback triggers an action under defined decision rules.
• System of loops: several loops exchange outputs, authority, and escalations.

If feedback cannot change the next action, model the work as a checklist or pipeline rather than forcing it into a loop.

Non-Negotiables

• Give the loop one primary outcome.
• Name one accountable human owner, even when agents participate.
• Use relevant, observable evidence.
• Define how the evidence will be evaluated.
• State what is allowed to change after feedback.
• Bound iterations by scope, time, attempts, cost, and authority.
• Define passed, failed, blocked, and escalated outcomes.
• Preserve a durable handoff and decision record.
• Require human approval for consequential, subjective, regulated, irreversible, or externally binding actions.
• Optimize the business outcome, not a convenient activity metric.

What to Inspect Before Planning

Inspect available evidence in this order:

1. Business objective and intended decision or outcome.
2. Current SOP, policy, workflow, checklist, or informal practice.
3. Inputs, outputs, systems, forms, records, and examples.
4. Participants, process owner, approvers, and affected stakeholders.
5. Existing metrics, service levels, thresholds, and exception rules.
6. Prior failures, rework, complaints, delays, overrides, and escalations.
7. Legal, regulatory, contractual, confidentiality, and retention constraints.
8. Agent and human permissions, including actions that require confirmation.

When source material conflicts, report the contradiction and identify the authority needed to resolve it.

Select the Loop Family

Primary question	Candidate loops
What is true?	Research or reasoning
What is causing this?	Diagnostic
How can an artifact improve?	Writing, design, planning, or review
Does it meet a standard?	QA, audit, reconciliation, or compliance
How should operations respond?	Sales, service, collections, inventory, cash, or capacity control
What should the business commit to?	Decision, approval, risk, or strategy
How should behavior improve?	Learning, coaching, performance, or stakeholder feedback
How should the system evolve?	Retrospective, experiment, or continuous improvement

Choose by the uncertainty and feedback signal, not merely by the department name.

Planning Workflow

1. Frame the Outcome

Write one outcome statement:

Improve <business outcome> for <scope> while respecting <constraints>.

Identify the beneficiary, accountable owner, consequence of failure, and evidence of success.

2. Map the Current Work

Document the existing sequence, handoffs, delays, informal feedback, rework, exceptions, and approval points. Mark where information is created, transformed, judged, or lost.

3. Test Whether a Loop Is Appropriate

A loop is appropriate only if:

• a pass produces observable evidence
• someone or something can evaluate that evidence
• the evaluation can change a later action
• repeated passes are safe and economically sensible
• a meaningful stop or escalation condition exists

4. Define the Smallest Useful Loop

Keep one feedback purpose inside the loop. Put deterministic preparation before it and stable handoff steps after it.

5. Specify Evidence and Decisions

For every important signal, state:

• source and freshness
• reliability and known limitations
• threshold or evaluation method
• decision the signal can influence
• who is authorized to make that decision

6. Define the Feedback Path

State exactly what happens after each evaluation result:

• pass: exit and hand off
• revise: change permitted fields or actions and run another pass
• fail: stop and record why
• block: wait for a named dependency
• escalate: transfer to a named role with the evidence pack

7. Set Authority Boundaries

Separate these capabilities:

inspect -> analyze -> recommend -> prepare -> approve -> execute -> verify

Do not treat permission to analyze or prepare as permission to approve or execute.

8. Bound the Loop

Set maximum attempts, elapsed time, cost, data scope, permitted changes, materiality, confidence, and escalation thresholds. Specify how duplicate or replayed actions are prevented when execution is involved.

9. Define Handoffs and Records

The receiving person or loop should not need to reconstruct context. Include inputs, evidence, decisions, changes, unresolved issues, owner, status, timestamp, and next action.

10. Simulate Before Piloting

Walk through at least:

• normal successful case
• incomplete or poor-quality input
• contradictory evidence
• repeated failure
• unavailable approver or dependency
• boundary or high-impact case
• stale or incorrect metric
• attempted action outside authority

Then propose a small, reversible, human-supervised pilot.

Required Outputs

Return these sections in order:

1. Executive summary and recommendation.
2. Facts, assumptions, contradictions, and open questions.
3. Current-state workflow.
4. Loop-versus-pipeline assessment.
5. Completed loop card.
6. State and feedback-path diagram.
7. Decision table.
8. Roles, permissions, and approval gates.
9. Metrics and safeguards.
10. Pilot and validation plan.
11. Risks, failure modes, and escalation plan.
12. Final readiness checklist.

Machine-Readable Loop Card

loop:
  name: ""
  version: "0.1"
  status: draft
  family: ""
  objective: ""
  accountable_owner: ""
  participants: []

  trigger:
    type: event | schedule | threshold | exception | request
    condition: ""

  entry_criteria: []
  inputs:
    - name: ""
      source: ""
      required: true
      sensitivity: ""

  actions: []
  prohibited_actions: []

  evidence:
    - signal: ""
      source: ""
      freshness: ""
      limitations: ""

  evaluation_rules:
    - condition: ""
      result: pass | revise | fail | block | escalate
      rationale: ""

  feedback_paths:
    - result: ""
      next_state: ""
      permitted_adjustment: ""
      authority: ""

  authority:
    agent_may: []
    agent_must_not: []
    human_approval_required_for: []

  bounds:
    max_iterations: null
    time_limit: ""
    cost_limit: ""
    scope_limit: ""
    materiality_or_risk_limit: ""

  stop_conditions:
    passed: []
    failed: []
    blocked: []
    escalated: []

  handoff:
    recipient: ""
    artifacts: []
    unresolved_items: []

  metrics:
    outcome: []
    process_health: []
    safeguards: []

  audit_record:
    evidence_to_retain: []
    decisions_to_retain: []
    retention_rule: ""

Use null for genuinely undecided values. Do not fabricate values to make the card look complete.

Decision Table Template

Evidence or condition	Evaluation	Permitted response	Decision owner	Approval required	Next state

Every response should be traceable to an observed condition. Avoid vague rules such as “use best judgment” for consequential decisions.

Handoff Contract Template

From loop:
To person or loop:
Status: passed | failed | blocked | escalated
Outcome:
Evidence attached:
Decision and concise rationale:
Changes made:
Unresolved risks or exceptions:
Authority still required:
Owner and next action:
Timestamp / review date:

Worked Example: Client-Information Loop

define required evidence
-> request documents or explanations
-> inspect completeness and consistency
-> classify each item as complete, missing, inconsistent, or unclear
-> prepare a targeted follow-up
-> repeat until complete, timed out, or escalated
-> hand off an evidence pack

Planning decisions:

• Outcome: complete and reliable evidence pack for a defined engagement.
• Owner: engagement owner or designated case manager.
• Evidence: requirement list, received documents, explanations, dates, and consistency checks.
• Feedback: missing or inconsistent items determine the next targeted request.
• Agent authority: inspect, classify, summarize, and draft follow-ups.
• Human gate: approve external communication and resolve sensitive or material exceptions.
• Bounds: maximum follow-ups and elapsed time before escalation.
• Stop: requirements satisfied, engagement owner accepts documented limitations, or the case escalates.
• Handoff: indexed evidence pack, outstanding-item register, decision log, and next owner.

Metrics

Measure outcomes and loop health:

• outcome quality and error rate
• time and cost to reach a stop condition
• iterations and rework rate
• unresolved exceptions
• escalation and human-override rate
• feedback latency
• handoff completeness
• downstream outcome and unintended effects

Do not optimize activity counts when they are weak proxies. More follow-ups, reviews, calls, or iterations may indicate a worse loop rather than a better one.

Common Failure Modes

• Recurrence mistaken for feedback.
• No accountable owner.
• Evidence exists but no decision rule uses it.
• Feedback cannot change the next pass.
• The agent is given implicit approval or execution authority.
• Proxy metrics replace the actual business outcome.
• Repeated internal reflection occurs without new evidence or a changed hypothesis.
• The loop has no attempt, time, cost, or scope limit.
• Exceptions remain inside the loop when they require escalation.
• Handoffs omit decisions, uncertainty, or unresolved risks.
• A local improvement harms another team or the wider system.
• Automation begins before the manual loop is understood.

Pilot Plan Template

Pilot objective:
Scope and case count:
Baseline:
Human supervisor:
Agent role:
Actions excluded from the pilot:
Success measures:
Safeguard measures:
Stop / rollback conditions:
Evidence to collect:
Review date:
Decision after pilot: adopt | revise | reject | extend

Prefer a small number of representative real cases. Run the loop manually or with agent assistance before granting execution authority or automating external actions.

Evaluation Checklist

The plan is ready only when all applicable items pass:

• The business outcome and beneficiary are clear.
• One accountable owner is named.
• The workflow contains a genuine feedback path.
• Inputs and entry criteria are explicit.
• Evidence is observable, relevant, and sufficiently reliable.
• Evaluation and decision rules are explicit.
• Permitted adjustments are bounded.
• Agent and human authority are separated.
• Pass, revise, fail, block, and escalation paths are defined.
• Time, cost, iteration, scope, and risk limits are defined.
• Handoff artifacts and records are specified.
• Outcome, health, and safeguard metrics are defined.
• Normal and adverse scenarios have been simulated.
• Assumptions, contradictions, and open questions are visible.
• The pilot is small, reversible, and human-supervised.

If a material item is missing, mark the plan not ready, name the owner of the gap, and identify what evidence or decision is needed next.