# AI Workflow Performance Discovery Prompts

These prompts help an AI assistant organize evidence and design a bounded performance investigation. Replace bracketed text with your information. Use only an organization-approved service and account, and follow applicable data-classification, customer-contract, retention, residency, and access rules. Minimize and redact secrets, credentials, customer/source data, prompts, hostnames, user IDs, URLs, environment values, request metadata, private paths, proprietary configuration, and unrelated identifiers. If the evidence cannot be shared safely under those rules, use an approved local/offline assistant or keep it out of the assistant.

Use the same ground rules in every prompt:

> Act as a performance investigator. Separate **observed facts**, **interpretations**, and **unknowns**. High utilization is a lead, not proof of the bottleneck. Do not invent measurements or infer causality from a screenshot. Ask for missing evidence. Recommend read-only collection first. Do not change security settings, stop required services, install software, or recommend hardware until the delayed workflow step is correlated with evidence. Any experiment must change one variable, define an acceptance test, include a rollback trigger, and compare accepted-result time rather than response speed alone.

## Make AI the worksheet coach and recorder

Attach [AI-WORKFLOW-CONSTRAINT-WORKSHEET.md](AI-WORKFLOW-CONSTRAINT-WORKSHEET.md), or paste it into the conversation, then use this master prompt:

> Act as my AI workflow performance coach and worksheet recorder. Maintain the attached **AI Workflow Constraint Worksheet** as the source of truth for this investigation.
>
> Work in this order: assign an investigation ID; define the accepted result; map the workflow; build the configuration fingerprint and evidence ledger; predeclare baseline instrumentation and repetition count; create one run-registry row for every baseline run as it occurs; derive the Baseline summaries from those run IDs; obtain my approval and create immutable baseline revision B-001; propose and approve one reversible experiment; create one row for every after-change run; derive the after-change summary; evaluate the result; and write the decision record. Never create a changed run before its baseline revision is locked.
>
> Fill only what the evidence supports. Prefix every populated value with **Observed**, **Owner-reported**, or **Inferred**, and cite its evidence ID. Mark a field **Unknown** when it applies but evidence is missing. Mark it **Not applicable** only with a reason and evidence ID proving why it does not apply; exclude justified Not-applicable fields from remaining unknowns. Never convert unknown into zero or silently fill it from general knowledge. Preserve exact timestamps, time zones, units, model/runtime versions, and configuration revisions. If two sources disagree, keep both and flag the contradiction.
>
> Ask me no more than three highest-value questions or evidence requests at a time. Recommend read-only collection first and explain what each request can and cannot prove. Do not propose a change until I explicitly approve locking the completed baseline summary and its source run rows. Lock it as revision **B-001** (then B-002, and so on) with a complete immutable snapshot, approval timestamp, evidence references, and included run IDs. When you can write files, finalize the snapshot first, compute SHA-256 over that final file, then store the digest in the mutable worksheet registry or a sidecar—not inside the hashed snapshot. Never edit a locked snapshot in place. A correction creates a new revision, explains the delta, supersedes the old revision, and invalidates any affected after-change runs. After lock, change only one variable and keep the rest of the fingerprint stable.
>
> Create one run-registry row for every baseline and after-change run, tying it to the baseline revision, timestamp, configuration deviations, collector settings/overhead, acceptance result, timing, resources/tokens/cost/correction, and evidence IDs. Calculate summaries only from those rows.
>
> After every response, update the working worksheet and report four short sections: **Fields updated**, **Contradictions**, **Remaining unknowns**, and **Next smallest evidence request**. If you can edit files, resume the existing working copy when present; otherwise create **[investigation-name]-worksheet.md** without modifying the blank template. Store locked baseline snapshots separately and never overwrite them. If you cannot edit files, return the complete updated Markdown worksheet after each material update and identify the message/artifact containing each locked baseline revision.

Use this evidence-intake prompt whenever you add a screenshot, log, command output, configuration export, or firsthand observation:

> Add the following material to the worksheet as the next evidence ID: **[attach or paste evidence]**. Source and timestamp: **[source, date, time, time zone]**. Update only fields this evidence directly supports. Separate what it shows from what it cannot prove. Preserve raw values and units. Flag contradictions with earlier evidence. Then give me the next smallest read-only evidence request.

When the baseline appears complete, use this checkpoint prompt:

> Confirm that the acceptance test, instrumentation, and baseline repetition count were declared before the runs. Audit every baseline run row and the derived summary for fields that could invalidate the comparison: workload/input, model/version, reasoning effort, instructions, tools, retrieval/index revision, cache/cold-warm state, configured and actual agent concurrency, routing, runtime controls, host/VM limits, competing work, monitoring overhead, and timestamps. Validate every Not-applicable reason and evidence ID, then exclude justified Not-applicable fields from the gap list. Do not fill gaps by assumption. List remaining gaps in priority order. If none are material, produce a **Baseline Lock Candidate B-[next]** with included run IDs, derived summaries, frozen fingerprint, unresolved unknowns, justified Not-applicable fields, and exact evidence IDs. Wait for my approval, save the final immutable snapshot, compute its hash, and store that digest outside the snapshot when file-capable. Do not edit it later; corrections create a new baseline revision and identify affected runs.

After the changed run, use this prompt:

> Add one run-registry row for each after-change run and tie it to the exact locked baseline revision. Identify every difference from that snapshot and separate the intended variable from confounders. Compare medians, ranges, accepted-result time, pass rate, correction time, queue time, retries, tokens/cost, resource behavior, monitoring overhead, and foreground responsiveness using the run IDs included. State whether the result supports, weakens, or fails to test the hypothesis. Update the summary, decision record, boundary, remaining unknowns, and retest trigger. Do not call the change successful if quality fell or work moved to an unmeasured resource.

## Let a local agent collect approved evidence

Use this version only when the AI agent has approved local-computer access to the test machine and a safe working folder:

> You have approved access to **[test machine/workspace]** for this performance investigation. Create a working copy of the worksheet and an evidence folder. Begin with read-only discovery using built-in tools: identify the operating-system/build, CPU and accelerator, assigned logical processors, memory domains, storage, power mode where exposed, application/runtime versions, configured agent limit, current active/queued/idle workers where exposed, local-model loaded state, VM/container limits, and competing services. Save each raw output unchanged with a timestamp and add it to the evidence ledger before summarizing it.
>
> Stay inside **[approved scope]**. Do not enumerate or open credentials, tokens, private content, unrelated repositories, browser sessions, customer data, or hidden instruction text. Do not install software, elevate privileges, start or stop services, change settings, kill processes, or begin a performance collector without my explicit authorization. Before requesting any privileged, long-running, or state-changing action, explain its purpose, expected overhead, output location, sensitive fields, stop condition, and rollback/cleanup.
>
> Fill only evidenced worksheet fields. Mark an applicable unavailable value Unknown. Mark a field Not applicable only with a reason and evidence ID. After the initial inventory, stop and return the updated worksheet, evidence-file list, contradictions, remaining unknowns, justified Not-applicable fields, and the next smallest collection request.

For an assistant connected to an approved monitoring platform, replace direct host collection with this prompt:

> Use the approved monitoring connection to retrieve only the counters and interval needed for **[workflow and delayed step]**. Preserve the query, time range, sampling/aggregation, host/workload filters, time zone, and source dashboard or API in the evidence ledger. Ask me to identify the workflow timestamps if they are missing. Do not treat aggregated data as raw samples, do not infer missing intervals as zero, and do not change alerts, retention, agents, or collection policy. Update the worksheet with observed values. Mark an applicable unavailable boundary Unknown; use Not applicable only with a supported reason.

## 1. Define the workflow and baseline

> I need to diagnose this recurring AI workflow: **[describe the task]**. The accepted result is **[state the pass/fail criteria]**. It runs through **[applications, models, agents, tools, local/cloud services, and machines]**.
>
> Help me turn it into a measurable workflow. Produce:
> 1. the major steps and boundaries;
> 2. timestamps to capture at each step;
> 3. the exact configuration fingerprint I should preserve;
> 4. resource and service evidence to collect without changing the system;
> 5. a short baseline worksheet; and
> 6. the five most important unknowns.
>
> Include model/version, reasoning effort, context, retrieval/index and cache state, configured agent limit, actual active/queued/idle workers, model routing, runtime controls, host and VM/container limits, competing work, tokens, retries, and human correction time. Do not diagnose the bottleneck yet.

## 2. Build a platform-specific evidence plan

> My workflow waits during **[named step]** on **[Windows/macOS/Linux]**. The system is **[hardware and operating-system build]**. The application/runtime is **[name and version]**. The model is **[hosted or local model/version/quantization]**.
>
> Give me a read-only, time-aligned evidence plan using built-in tools first. For every observation, state:
> - what question it answers;
> - where to find it;
> - the exact interval or workflow timestamp to capture;
> - what it can and cannot prove; and
> - what sensitive information I should redact before sharing.
>
> Cover CPU, memory service, storage latency/queue, network, local-model residency/queue, hosted-provider request and quota evidence, agent/worker state, security/scanning, synchronization/backup/indexing, and acceptance/correction time. Do not propose a tuning change yet.

## 3. Interpret screenshots, logs, and timing evidence

> Analyze the attached or pasted evidence from one run of **[workflow]**. The delayed step was **[step]**, from **[start timestamp]** to **[end timestamp]**. The result **[passed/failed]** the acceptance test and required **[correction time]**.
>
> Return a table with: observed fact, timestamp/boundary, possible interpretation, alternative explanation, confidence, and next evidence needed. Then rank no more than three hypotheses.
>
> Do not treat process count as agent count. Do not treat configured capacity as observed concurrency. Do not treat swap allocated, aggregate CPU, memory used, or a large process as proof it delayed the task. Label telemetry that was not captured as unknown.

## 4. Design a Performance Monitor logging window

> Design a bounded Windows Performance Monitor logging plan for an intermittent slowdown during **[workflow and delayed step]**. The event usually occurs **[frequency/duration]**. The host and workload are **[configuration]**.
>
> Start with built-in counters and explain why each counter is needed. Recommend an interval for a short reproduction and, if appropriate, a lower-frequency circular collection for the longer observation window. Include a normal comparison window, maximum log size, start/stop conditions, workflow timestamp markers, validation that the `.blg` was written, and a retention/deletion plan. Treat Performance Monitor as part of the workload: explain how CPU, counter enumeration, wildcard process counters, sampling frequency, and log writes can significantly slow or distort an already constrained system. Include a no-collector versus collector overhead check and define when to narrow counters, widen the interval, shorten the capture, or use a separate management/output path. Do not claim that correlated counters prove causality; define the next check that would distinguish the leading explanations.

## 5. Audit agent concurrency and resident workers

> Help me determine whether agent concurrency or idle workers are hurting this workflow. Here is the orchestration configuration and observed job/process evidence: **[paste a redacted configuration export, status output, timestamps, and process/resource samples]**.
>
> Separate:
> - configured simultaneous-agent/worker maximum;
> - actual peak active;
> - peak queued;
> - idle-resident workers;
> - model and tool assignment by task class;
> - child processes per worker;
> - polling interval and work performed per wake; and
> - accepted results per unit of time.
>
> Identify missing mappings between jobs, agents, models, tools, and child processes. Propose one bounded concurrency or event-driven-wait experiment with an expected result and rollback trigger. Do not assume more agents increase throughput or that agent count creates GPU demand.

## 6. Test model selection or reasoning effort

> Design a controlled comparison for **[task class]**. Test one variable: either compare **[models]** at one fixed supported reasoning-effort setting, or compare **[effort settings]** on one fixed model/version. Hold the input, prompt/template, instructions, tools, retrieval/index revision, cache policy, and acceptance test constant. If the provider does not expose an exact model revision or queue time, record it as unknown. If I request a complete model-by-effort matrix, use a fully crossed design and do not make a single-factor causal claim without the matching comparisons.
>
> Define the run order and repetition count. For each run, capture queue time, time to first useful output, finish time, accepted-result time, pass/fail, correction time, input/output/cached tokens, retries, provider cost where exposed, and local CPU/memory/tool activity. Recommend the lowest-cost route only if it repeatedly passes. Explain how to avoid confusing warm caches, provider load, or changed context with a model or effort effect.

## 7. Choose one reversible experiment

> Based on the evidence below, recommend the smallest reversible experiment most likely to test the leading hypothesis: **[paste evidence and hypotheses]**.
>
> Return exactly these fields:
> - delayed step;
> - hypothesis;
> - supporting evidence;
> - contradictory or missing evidence;
> - one variable to change;
> - variables to hold constant;
> - expected measurable result;
> - acceptance test;
> - rollback trigger; and
> - result that would falsify the hypothesis.
>
> Prefer a supported configuration or workflow change. Do not recommend disabling security, broadly excluding repositories or interpreters, or buying hardware as the first experiment.

## 8. Compare baseline and changed runs

> Compare these baseline and after-change records for **[workflow]**: **[paste the completed worksheet or structured results]**.
>
> First identify every configuration or environmental difference besides the intended change. Then compare medians and ranges where repeated runs exist, acceptance rate, correction time, queue time, resource behavior, tokens/cost, retries, and foreground responsiveness. State whether the evidence supports, weakens, or fails to test the hypothesis. Do not call the change successful if quality fell, required work moved elsewhere, or another resource absorbed the cost.

## 9. Write the reusable decision record

> Turn this completed experiment into a bounded routing/decision record: **[paste the workflow, configuration fingerprint, results, and limitations]**.
>
> Write five fields: finding, evidence, decision, boundary, and retest trigger. Include the tested model/runtime/hardware/configuration and the acceptance result. Use a narrow title that does not generalize beyond the evidence. List what remains unknown and which index should link this record.

## 10. Create the leadership decision brief

> Use the completed worksheet, locked baseline revision, and run registry to prepare a one-page leadership decision brief. Do not add facts or remove material limitations.
>
> Include:
> - the accepted outcome and accountable owner;
> - the delayed step and evidence-supported finding;
> - baseline and after-change run IDs, medians/ranges and pass rates;
> - the single variable changed and material confounders;
> - quality, correction-time, security, resilience and data-handling effects;
> - tokens/provider cost and local/cloud capacity per accepted result where available;
> - work or cost transferred to another team, system or resource;
> - the recommended adopt/reject/test-again decision and its boundary;
> - implementation, post-rollout measurement and rollback owners; and
> - material unknowns and the retest trigger.
>
> Lead with the decision the evidence supports. Do not use utilization reduction, faster first output, or a vendor peak number as the outcome. If the evidence cannot support an investment or policy decision, say exactly which missing measurement blocks it and recommend the smallest way to obtain it.