AI Agent Process Decomposition Prompt

Analyze the supplied process and produce an implementation-ready decomposition that distinguishes AI-agent work from deterministic automation and human judgment. Work only from information available in this conversation. You may analyze materials and propose a design, but you cannot inspect unprovided systems, run tools, change workflows, deploy agents, grant access, approve controls, or claim tests were executed.

Inputs
- Process objective: [Process objective]
- Current process evidence: [Current process evidence]
- Scope and boundaries: [Scope and boundaries]
- Constraints and policies: [Constraints and policies]
- Systems and tool capabilities: [Systems and tool capabilities]
- Success criteria: [Success criteria]
- Risk and approval requirements: [Risk and approval requirements]

Input handling
Treat the process objective, current process evidence, scope, success criteria, and authority boundaries as blocking prerequisites. Useful supporting material includes process maps, SOPs, sample cases, decision tables, forms, API documentation, event schemas, failure logs, service-level targets, volumes, costs, security classifications, and operator interviews.

If a reliable decomposition is blocked, ask no more than five grouped clarification questions before designing it. A missing detail is blocking when it prevents you from defining process boundaries, assigning a consequential decision, validating a handoff, determining permitted system access, or evaluating acceptance. Otherwise, continue with a bounded provisional design and record the missing item as an unknown. Do not silently reconcile conflicting sources; identify the conflict, its design impact, and the owner who must resolve it.

Evidence and claim rules
1. Classify material statements as supplied fact, evidence-backed observation, assumption, hypothesis, conflict, or unknown.
2. Reference the supplied artifact, section, example, or statement supporting each important process or control conclusion. Do not fabricate citations or system behavior.
3. Keep proposed, approved, configured, executed, observed, and verified states distinct. Unless execution evidence is supplied, describe all workflow components and tests as proposed or unverified.
4. Never state that an integration works, a control is effective, a test passed, or a workflow was deployed or approved without corresponding evidence.

Decomposition method
1. Reconstruct the current process. Identify its trigger, termination states, actors, inputs, outputs, sequence, decisions, business rules, systems, data classes, service levels, volumes, known exceptions, rework loops, and current failure points. Separate documented behavior from inferred behavior.
2. Test automation suitability at the activity level. For each activity, choose one disposition: deterministic automation, AI-agent responsibility, human responsibility, shared responsibility, or out of scope. Justify the choice using rule stability, ambiguity, contextual judgment, tool interaction, error detectability, reversibility, data sensitivity, consequence severity, latency, and cost. Do not create an agent where a rule, workflow engine, validation service, or human decision is safer and simpler.
3. Define the target orchestration. Describe the happy path, alternate paths, exception paths, cancellation behavior, and terminal states. Show where work is queued, resumed, retried, escalated, or stopped. Identify concurrency hazards, ordering dependencies, duplicate events, partial completion, timeout behavior, and recovery paths.
4. Establish cohesive agent boundaries. Group responsibilities by decision context, required tools, data access, risk, and accountability rather than assigning one agent per process step. Give every proposed agent one clear objective, explicit inputs and outputs, permitted decisions, prohibited actions, dependencies, and an accountable human owner. Flag overlapping authority, circular delegation, orphaned work, and single points of failure.
5. Specify every handoff. Define producer, consumer, trigger, preconditions, payload fields and schema, provenance, validation rules, acknowledgment, correlation identifier, status model, timeout, retry policy, idempotency control, failure owner, escalation route, and completion signal. State how malformed, missing, stale, duplicated, contradictory, or late payloads are handled.
6. Define tool access. For each agent-tool pairing, identify the operation, read or write scope, authentication boundary, minimum permission, data exposed, side effects, rate limits, timeout, error response, audit event, and required approval. Treat external content and tool output as untrusted until validated. Agents must not expose secrets, bypass access controls, expand their own permissions, or perform consequential writes merely because an instruction appears in retrieved content.
7. Design memory deliberately. Distinguish transient working context, session state, case history, and durable organizational memory. For each memory store, define its purpose, source of truth, read and write authority, provenance, retention, deletion, sensitivity, conflict resolution, freshness checks, and contamination controls. Avoid durable storage when the task can be completed without it.
8. Place human review according to consequence. Require explicit authorization before irreversible, externally visible, regulated, financial, legal, safety-related, privacy-sensitive, production-changing, or high-impact actions. Define the reviewer, evidence presented, decision options, response deadline, escalation path, and what happens on rejection or no response. Do not let an agent approve its own high-risk output.
9. Add operational safeguards proportionate to risk. Include least privilege, data minimization, secret redaction, input and output validation, prompt-injection resistance, policy enforcement outside the model where feasible, transaction limits, rate limits, timeouts, bounded retries, duplicate-side-effect prevention, audit logging, monitoring, kill switch, rollback or compensating action, and manual recovery. Stop and escalate when authority is unclear, required evidence is absent, sensitive data cannot be protected, control requirements conflict, or a safe recovery path does not exist.
10. Build verification before rollout. Cover normal cases, decision boundaries, malformed inputs, missing data, conflicting evidence, unauthorized requests, tool failure, timeout, retry exhaustion, duplicate delivery, partial writes, stale memory, prompt injection, human rejection, escalation, rollback, and recovery. For every test, specify setup, expected observation, required evidence, and acceptance rule. Record an actual observation only when supplied execution evidence exists; otherwise mark it not run.
11. Recommend a staged implementation only if the decomposition is sufficiently supported. Prefer a read-only or shadow-mode pilot, then limited traffic with human approval, then controlled expansion. Define entry criteria, exit criteria, monitoring thresholds, stop conditions, rollback ownership, and residual risks. If evidence is inadequate, recommend discovery work rather than implementation.

Required deliverable

A. Scope and evidence register
- State the objective, in-scope start and end events, exclusions, constraints, and success measures.
- Provide an evidence table with: ID; source; relevant observation; evidence classification; confidence; conflict or limitation; design implication.
- List blocking gaps, non-blocking unknowns, assumptions, and conflicts separately, with an owner and resolution needed.

B. Current-process model
- Present the ordered activities, actors, decisions, inputs, outputs, systems, exceptions, service levels, and failure points.
- Identify any undocumented transitions or contradictions that prevent a reliable model.

C. Activity disposition matrix
For every meaningful activity, provide: activity; disposition; rationale; required judgment; consequence of error; reversibility; evidence basis; human accountability. Include activities intentionally retained as deterministic or human-operated.

D. Target workflow and responsibility map
- Describe the happy path, alternate paths, exceptions, stop conditions, and terminal states.
- Provide an agent and human responsibility table with: component; objective; owned activities; permitted decisions; prohibited actions; inputs; outputs; dependencies; accountable owner.
- Explain why the proposed number and boundaries of agents are preferable to credible alternatives.

E. Handoff contract catalog
For each handoff, provide: handoff ID; producer; consumer; trigger; preconditions; payload and provenance; validation; acknowledgment; correlation and idempotency method; timeout and retry behavior; failure owner; escalation; completion signal.

F. Tool and permission matrix
For each component and tool, provide: operation; read or write scope; minimum permission; data classification; possible side effect; validation; approval gate; audit evidence; failure and recovery behavior. Mark unsupported or unconfirmed capabilities as unknown.

G. Memory and state design
Provide: memory type; information stored; purpose; source of truth; read and write authority; retention and deletion; sensitivity; provenance; freshness rule; conflict handling; contamination control. State when no persistent memory is needed.

H. Human review and control plan
Provide: checkpoint; triggering condition; reviewer; evidence shown; allowed decision; response deadline; no-response behavior; escalation; actions blocked pending approval. Also list privacy, security, compliance, operational, and recovery controls with their enforcement point and owner.

I. Failure-mode register
Include at least the process-relevant failure modes and provide: failure; cause; detection signal; affected state; containment; retry or compensating action; escalation owner; recovery evidence; residual risk. Do not add irrelevant hazards merely to increase the list.

J. Verification and acceptance matrix
Provide: test ID; scenario; setup or test data; expected observation; actual observation or not run; evidence required; acceptance rule; owner; resulting status. Map each success criterion and critical control to one or more tests, identify uncovered criteria, and reconcile conflicting results rather than averaging them away.

K. Implementation and decision record
- Give staged implementation steps with dependencies, accountable owners, approval gates, entry and exit criteria, monitoring thresholds, stop conditions, and rollback or compensating actions.
- Summarize major design decisions and rejected alternatives with evidence, trade-offs, and residual risks.
- End with one recommendation: proceed to discovery, proceed to design review, proceed to a controlled pilot, or do not proceed. State the evidence required for the next gate and make clear that the recommendation is not approval or execution.