AI Workflows & Automation

Exact prompt

Assess the workflow below and define a bounded AI-assisted design. Begin with the real process and risks rather than assuming automation is the goal.

Current workflow and problem evidence:
{{workflow_context}}

Users, affected people, and decisions:
{{stakeholder_context}}

Data, systems, and constraints:
{{system_constraints}}

Instructions:
1. Map triggers, inputs, decisions, handoffs, exceptions, outputs, owners, and current failure demand.
2. Identify tasks suited to summarization, classification, drafting, retrieval, transformation, or recommendation, and tasks that should remain human-owned.
3. Exclude or escalate decisions involving rights, safety, employment, credit, health, legal status, identity, or other consequential outcomes unless qualified governance explicitly permits assistance.
4. Minimize input data and define consent, access, retention, redaction, residency, and deletion requirements.
5. Design human review points with sufficient context, meaningful choice, correction, and clear accountability.
6. Keep messages, purchases, deployments, record changes, and other external actions disabled until a human previews and authorizes the exact action.
7. Define quality, harm, latency, cost, fallback, audit, and rollback criteria before implementation.

Return the process map, assist-versus-own matrix, data boundary, approval model, risk register, and phased pilot. Do not claim feasibility without the missing technical and organizational evidence.

Replace before use

Workflow and evidence{{workflow_context}}

The actual steps, owners, delays, errors, volumes, exceptions, and evidence of the problem.

Users and affected people{{stakeholder_context}}

Operators, decision owners, customers, subjects of decisions, power dynamics, and redress needs.

Data and system constraints{{system_constraints}}

Data classification, integrations, permissions, policies, quality, latency, cost, audit, and recovery boundaries.

Exact prompt

Design a meaningful human approval gate for the AI-proposed action below. The reviewer must be able to understand, change, reject, and safely recover from the action.

Proposed action and workflow stage:
{{action_context}}

Evidence and generated output:
{{evidence_context}}

Authority, risk, and system constraints:
{{approval_constraints}}

Instructions:
1. Define the exact action, target, scope, timing, side effects, reversibility, and responsible owner.
2. Show the source inputs, material transformations, confidence or uncertainty, validation results, and unresolved contradictions needed for judgment.
3. Present a human-readable preview of the final message, command, transaction, or record change before approval.
4. Require reauthorization when target, scope, content, price, permission, or execution time changes.
5. Separate approve, edit, reject, defer, and escalate choices; avoid defaults, timers, bundled consent, or manipulative urgency.
6. Verify reviewer identity, least privilege, separation of duties, audit record, idempotency, duplicate protection, and expiry.
7. Define execution feedback, monitoring, cancellation, rollback, notification, and post-action review.

Return the approval-state model, required evidence, interface copy, authorization rules, audit fields, and failure paths. Do not let a missing reviewer, timeout, ambiguous target, or tool error become implicit approval.

Replace before use

Action context{{action_context}}

The proposed external action, initiator, target, scope, workflow stage, side effects, and reversibility.

Evidence and output{{evidence_context}}

Source inputs, generated result, validation, uncertainty, contradictions, and proposed final payload.

Approval constraints{{approval_constraints}}

Risk level, reviewer authority, policy, permissions, timing, audit, notification, and recovery requirements.

Exact prompt

Create an evaluation plan for the AI-assisted workflow below. Tie acceptance to the real task, affected people, and failure costs rather than a single aggregate score.

Workflow and intended assistance:
{{workflow_context}}

Known risks and failure examples:
{{risk_context}}

Available cases, reviewers, and constraints:
{{evaluation_resources}}

Instructions:
1. Define the unit of work, required output properties, prohibited behavior, abstention conditions, and downstream decision or action.
2. Build a representative case set across normal, boundary, ambiguous, adversarial, multilingual, accessibility, privacy, stale-information, and tool-failure conditions where relevant.
3. Preserve a clearly separated holdout set and document source, consent, redaction, representativeness, and known coverage gaps.
4. Create an explicit rubric for correctness, grounding, completeness, calibration, harmful content, privacy, usefulness, and action safety.
5. Combine deterministic checks, reference comparisons, expert judgment, and affected-user review where each is appropriate.
6. Define slice-level thresholds, release-blocking severe-failure criteria, reviewer disagreement handling, and other release-blocking cases before seeing results.
7. Add shadow operation, human override, monitoring, drift review, rollback, and incident response for production.

Return the evaluation matrix, case plan, rubric, review process, acceptance gate, and monitoring design. Do not invent scores or claim the workflow is safe from an unrun evaluation.

Replace before use

Workflow context{{workflow_context}}

The task, users, inputs, outputs, model and tool roles, downstream decisions, and intended boundaries.

Risks and failure examples{{risk_context}}

Known harms, near misses, bad outputs, sensitive groups, abuse paths, and costly failure modes.

Evaluation resources{{evaluation_resources}}

Authorized cases, subject experts, affected-user input, tools, time, privacy rules, and budget.

Exact prompt

Red-team the proposed agent workflow using the supplied design. Produce defensive test cases and mitigations; do not perform real external actions or expose sensitive data.

Workflow architecture and tools:
{{architecture_context}}

Data, permissions, and trust boundaries:
{{trust_context}}

Policies and unacceptable outcomes:
{{policy_context}}

Instructions:
1. Map actors, components, data stores, tool calls, credentials, approval points, external systems, and trust-boundary crossings.
2. Identify prompt injection, poisoned retrieval, data exfiltration, excessive agency, confused deputy, permission escalation, cross-tenant leakage, unsafe code, and social-engineering paths where relevant.
3. Trace accidental chains involving retries, stale state, partial success, duplicate actions, race conditions, tool errors, ambiguous targets, and missing confirmations.
4. Examine whether untrusted content can influence system instructions, tool arguments, logs, notifications, or later workflow stages.
5. Create synthetic test cases with expected safe behavior, including refusal, isolation, escalation, and fail-closed results.
6. Recommend least privilege, allowlists, schema validation, sandboxing, data minimization, content provenance, approval, rate limits, monitoring, and kill switches.
7. Prioritize mitigations by plausible harm, exploitability, detectability, and recovery difficulty, with an owner and verification method.

Return the threat model, attack and accident trees, defensive tests, prioritized controls, residual risks, and launch blockers. Use placeholders only; do not probe live systems, send messages, execute commands, or alter records.

Replace before use

Workflow architecture{{architecture_context}}

Components, prompts, retrieval, tools, models, orchestration, state, external systems, and failure handling.

Data and trust boundaries{{trust_context}}

Input sources, data classifications, tenants, identities, credentials, permissions, network boundaries, and approvals.

Policies and unacceptable outcomes{{policy_context}}

Authorized scope, security requirements, prohibited actions, harm scenarios, audit, incident, and recovery rules.