Process-to-Assistant Brief Loop

By Juan Beltrán, Industrial B2B AI Transformation Executive.

How do we turn this process into a realistic AI assistant brief? Use this when someone says 'AI should automate this' and you need a grounded assistant brief that states scope, inputs, outputs, risks, and human review. Process-to-Assistant Brief Loop Decision to make: How do we turn this process into a realistic AI assistant brief? Decision owner: AI product owner or process owner. Working-session setup: - Timebox: 45 min working session - People in the room: Process owner, frontline representative, delivery owner, and affected manager. - Preparation: Working prep: bring representative evidence, constraints, and a named owner. Context: [Paste your notes, excerpts, draft, meeting transcript, CRM fields, proposal text, public research, or examples here.] Context I should provide: - Workflow notes - Current documents - User roles - Decisions made - Data sensitivity - Exceptions - Desired business outcome Safety boundary: - Use only information I provide in this conversation. - Do not infer personal, confidential, regulated, pricing, customer, employee, or supplier facts. - If the material belongs in an approved enterprise environment, tell me before analyzing it. Instructions: Act as an AI assistant product brief writer. Turn the workflow notes below into a realistic assistant brief. Define task scope, users, inputs, outputs, boundaries, human review, escalation rules, and a first practical test. Run the session in this order: 0. Inspect the context. If a missing fact could materially change the recommendation, ask no more than five focused questions and wait. If I ask you to continue, mark each missing fact as unknown. 1. Define the assistant job: Name the specific task the assistant should help with, not the whole process. 2. Map inputs and outputs: List the context users provide and the artifact the assistant returns. 3. Set boundaries: Define what the assistant must not decide, access, store, or claim. 4. Add human review: Specify who reviews the output, when escalation is required, and what cannot be automated. 5. Design the first test: Create a small test using representative examples and clear success criteria. Evidence rules: - Separate supplied facts, interpretations, assumptions, and unknowns. - Reference the exact note, excerpt, metric, or example supporting every material claim. - Show the strongest credible counterargument to the recommendation. - Do not invent customer facts, benchmarks, financial numbers, policy approvals, or system access. - Do not turn missing evidence into a confident recommendation. - Keep the answer useful for AI Product Owner. Output contract: An assistant brief with task scope, input checklist, output spec, guardrails, escalation rules, and first test. Return: 1. BLUF: the decision, recommendation, or draft in plain language. 2. Evidence table: claim, supplied evidence, confidence, and gap. 3. Assumption ledger: what is assumed and how to verify it. 4. Counterargument: the strongest reason the recommendation may be wrong. 5. Decision record: decision status, accountable owner, next action, and due date or trigger. 6. Evidence still needed: only the gaps that could change the decision. 7. Stop condition: state when the work is complete and when it must pause. Evidence checklist: - Task - User - Input - Output - Sensitive data - Guardrail - Human review - First test Human operating ritual: - Start with one task, not a platform dream. - Require examples before build decisions. - Keep escalation rules explicit. Do not use this loop when: Do not use it when nobody in the room owns the workflow or can change the operating conditions. Stopping condition: Stop when the assistant brief is narrow enough to test with examples this week.

Canonical URL: https://juanbeltran.ch/operating-loops/process-to-assistant-brief-loop