Predict the next request before it arrives.
The onslaught of requests can sound like noise: leadership wants a number, another department needs an update, a partner asks the same question again. There may be a rhythm underneath. Find it, learn what signals the next request, and get the answer there before anybody has to ask.
Try it now
Copy the prompt into your AI tool of choice, then answer its questions as they come.
Paste it into any AI chat to start. For most people, this is all you need.
Everything on this page in one paste: the prompt plus the full plan, every step and what to check. Use it for longer moves, to plan ahead, to share with a colleague, or if your AI can't open links.
How it goes
What the AI will do
- Finds patterns in the requests reaching you: who asks, how often, what triggers them and how much warning is available.
- Builds an early warning system that prepares answers and, with your agreed permission, sends suitable answers before the request arrives.
What to have ready
- A role, team or stream of requests you want to get ahead of.
- Access to relevant messages, transcripts, calendars and answer sources, or usable exports.
Where you come in
- Confirm which patterns matter and what a useful advance answer looks like.
- Agree on recipients, sending rules and exceptions; review the tested system before activation.
What you'll get
A tested request-prediction and response system, with evidence for its warnings and a record of what it prepared or sent. If a required connection is blocked, you receive the tested analysis and response components, with ongoing monitoring or sending clearly marked as unfinished.
You're done when
The system watches the agreed signals, records useful advance warnings, prepares sourced answers and runs the authorized delivery path. Its record distinguishes a tested connection, an actual advance answer and a prediction whose outcome is still pending.
These are general instructions, not a description of this user's particular AI system, tools, access, or circumstances. Adapt the method to the user's goal and the capabilities you can actually use, while preserving the activity's essential sequence, review points, and intended result. ### Start with the activity and the user's context Read the complete activity and guide the user through it. Use the activity prompt yourself; the user does not need to paste it again. Keep the responsibilities of the user, the AI, and any colleague clear. Begin with what the user has already supplied. Establish the intended result and resolve missing context through focused questions when needed. Work within the activity's stated scope, permissions, required confirmations, and stopping points, including any deliberate order for introducing information. Make progress with the available information and reasonable, clearly identified assumptions where the activity allows them. ### Check the capabilities needed for this work Inspect relevant available tools, connectors, and data. Use small, relevant, non-destructive checks to establish whether necessary access or a capability actually works. Naming a product does not establish access to it. Let this activity determine what needs checking; do not impose a universal preliminary questionnaire or a full system audit. When useful access is missing: - Explain what you cannot reach and how that material would help. - Investigate practical setup, connection, export, or other access alternatives before asking the user to gather material or troubleshoot. - If progress depends on access, request only the specific user action or permission needed to enable it or provide the material another way. Continue useful independent work while awaiting the response. - Offer to walk the user through an export or upload. Welcome files, links, copied text, rough notes, or an interview as supported by your system and the activity, and use the best available route. If the missing access is optional, continue with what is available. ### Ask focused questions and respect the answers Ask questions only when necessary to complete the work well or satisfy the activity's required review points. Build on answers already supplied. Ask one question at a time, or a small group of closely related questions. Wait on work that depends on the answer, and continue useful work that does not. Explain unfamiliar language with examples where helpful. Confirm answers or decisions you supply on the user's behalf before treating them as the user's final answers or decisions. This does not require separate approval of every sourced finding; follow the activity's specific review requirements. ### Keep evidence and independent contributions distinct Distinguish evidence, inference, and missing information. Check your work against the source material. Use independent agents when your system actually supports delegation and independent investigation or review would improve the work: - Give each agent a bounded brief and the context appropriate to its role. - Keep discovery independent until synthesis where the activity requires it. Preserve any requirement for the user or colleagues to contribute before seeing other explanations. - Follow the activity's stated fallback and any required confirmation when independent agents or fresh contexts are unavailable. Preserve reviewer isolation where required; describe shared-context or sequential passes accurately. ### Produce, check, and revise the result Do the substantive investigation and production. Carry the activity through to the most complete, usable result within its scope, rather than ending with a plan or handing the main work back to the user. When missing information does not prevent useful work, proceed with clearly identified assumptions where the activity permits them. Check the result against the activity's completion criteria. At each substantive delivery, state what is complete and any material unfinished work, assumptions, helpful missing information, and remaining uncertainty. Explain how these affect what the user can use, and help the user revise the result. Preserve the activity's stopping point. Do not turn a rehearsal, investigation, or test-design activity into execution that the user has not authorized. Build an early warning system for requests I receive from leadership, teammates, other departments and outside stakeholders. Learn the patterns from actual history, predict likely requests and their timing, and prepare and send useful answers before the request arrives wherever I authorize that behavior. ### Reconstruct the requests and their triggers Use the role, people or examples I supply to identify search terms. Inspect and try available access to email, chats and other messages, including WhatsApp where accessible, meeting transcripts, calendars, project boards and recurring reports. Search for explicit requests and their surrounding conversations, earlier signals, answers and follow-up. Look for recurring reviews, deadlines, launches, metric changes and other events that might precede a request. Build a sourced case record: requester and role, requested information or work, request date, answer date, frequency, related event, possible trigger, warning time and what the requester actually used or questioned. Link repeated mentions of the same request instead of counting them as new demand. Recover recipients' needs, preferred detail and useful format from their actual correspondence and prior responses; label inferred preferences and trigger explanations. Keep a coverage record of channels, time periods, cases and gaps. For a large history, divide bounded periods or request families among agents with source links and the same case fields; reconcile their results and check cross-channel duplicates. Without agents, use successive manageable passes. Investigate connection or export options before asking me to supply missing material. Recollection may suggest patterns but cannot establish unseen frequency or timing; make that limitation explicit. ### Find signals that give us useful warning Group requests by purpose and requester. For each promising pattern, show the history behind it, observed frequency, likely triggering event, expected arrival window and preparation time. Separate a recurring schedule from a prediction based on changing conditions. Look for counterexamples: triggers with no request, requests with no recognized trigger and changes that may have made an old pattern obsolete. Use upcoming calendar events, project milestones, leadership meetings and current messages to identify the next plausible windows. Ask me to resolve only gaps that affect usefulness or action. Confirm the request families to cover and the benefit we want: earlier preparation, fewer interruptions, faster stakeholder decisions or another concrete result. Test candidate rules on a later portion of history that was not used to invent them. Replay what was visible before each request; exclude later replies, edits or outcome knowledge. Record correct warnings, missed requests, false alarms and usable lead time. Compare with simply predicting the usual recurring request at its usual interval. With too little dated history, label the rule provisional and use an observation period to measure it before granting it unattended sending authority. ### Design the warning and answer loop For each selected pattern, specify the watched signal, likely requester, timing window, evidence shown in the warning, required answer sources, readiness checks and conditions that suppress a response. Retrieve current information from the documents, systems or people identified in earlier successful answers. Build the actual answer or requested artifact, adapted to the recipient's documented needs, and check material claims against dated sources. Agree with me on alert destinations and cadence, and on standing permission for advance sending. Make that permission concrete: named recipients or defined groups, request families, channels, allowed content, source-freshness requirements and exceptions requiring review. This should support actual send-before-request behavior when authorized. Do not turn every authorized recurring answer back into a draft awaiting approval. Conversely, a predicted need alone is not permission to contact somebody. Include a check for whether the request has already arrived, someone else has already answered, the relevant event has been cancelled, or the information changed after preparation. If the request arrived, handle it as an ordinary response under the agreed rules and do not count it as advance delivery. ### Build and test the running system Inspect the existing automation environment and current official documentation for its message, data and scheduling connections. Implement persistent monitoring through supported events or scheduled checks, a durable prediction record, answer generation, review where required and the authorized send action. Configure the agreed cadence so it continues after this chat. Record each signal, prediction, preparation, decision, sending attempt and actual delivery result; use stable request or event identities so retries do not send duplicates. Replay representative cases without contacting historical recipients. Exercise a correct signal, false alarm, missing answer source, already-answered request, cancelled event, rejected send and repeated automation run. Have a separate reviewer inspect predictions and answers against the original records without your rationale where possible. Repair failures and recheck them. Show me the working loop and its proposed live rules. Activate it once authorized. Verify an end-to-end live case using an eligible real signal or a clearly labeled test addressed to an agreed test recipient. Check the actual destination or delivery evidence; a generated answer or queued action is not evidence of delivery. A test does not establish that a real request was anticipated. ### Learn whether it gets ahead of real demand Deliver the active configuration, upcoming prediction view, first run record and instructions to change or pause it. At the agreed review cadence, compare predictions with incoming requests, measure lead time and false alarms, and review whether advance answers were useful. Track “answer sent before request” separately from “predicted request later observed”; an effective advance answer may mean the recipient never needs to ask. Show what has actually happened, what is awaiting a future trigger and what remains uncertain. If missing access blocks monitoring or sending, deliver the functioning analysis and response components, prepared integration work and exact remaining action. Call that partial completion; do not call saved drafts an operating send-before-request system. These instructions were written in September 2026 using the frontier models available at the time. You may now have better tools or models, or restrictions that make some tasks harder. Your AI should adapt to the tools and access you actually have and find the best available way to help. Everything here is a starting suggestion for you and your AI, not a proven best practice for every setup. Feel free to rewrite any of it to better meet your needs.
View full AI instructions
Predict the next request before it arrives.
What the AI will do
- Finds patterns in the requests reaching you: who asks, how often, what triggers them and how much warning is available.
- Builds an early warning system that prepares answers and, with your agreed permission, sends suitable answers before the request arrives.
What you can provide
- A role, team or stream of requests you want to get ahead of.
- Access to relevant messages, transcripts, calendars and answer sources, or usable exports.
Where you'll take part
- Confirm which patterns matter and what a useful advance answer looks like.
- Agree on recipients, sending rules and exceptions; review the tested system before activation.
What you'll get
A tested request-prediction and response system, with evidence for its warnings and a record of what it prepared or sent. If a required connection is blocked, you receive the tested analysis and response components, with ongoing monitoring or sending clearly marked as unfinished.
Activity context
The onslaught of requests can sound like noise: leadership wants a number, another department needs an update, a partner asks the same question again. There may be a rhythm underneath. Find it, learn what signals the next request, and get the answer there before anybody has to ask.
For the user
Name the stream of requests you want to get ahead of; a rough description is enough. The AI will investigate the history and build the early warning and response loop. You will choose useful cases and authorize exactly when it can send an answer on your behalf.
Guidance for the AI
These are general instructions, not a description of this user's particular AI system, tools, access, or circumstances. Adapt the method to the user's goal and the capabilities you can actually use, while preserving the activity's essential sequence, review points, and intended result.
Start with the activity and the user's context
Read the complete activity and guide the user through it. Use the activity prompt yourself; the user does not need to paste it again. Keep the responsibilities of the user, the AI, and any colleague clear.
Begin with what the user has already supplied. Establish the intended result and resolve missing context through focused questions when needed. Work within the activity's stated scope, permissions, required confirmations, and stopping points, including any deliberate order for introducing information. Make progress with the available information and reasonable, clearly identified assumptions where the activity allows them.
Check the capabilities needed for this work
Inspect relevant available tools, connectors, and data. Use small, relevant, non-destructive checks to establish whether necessary access or a capability actually works. Naming a product does not establish access to it. Let this activity determine what needs checking; do not impose a universal preliminary questionnaire or a full system audit.
When useful access is missing:
- Explain what you cannot reach and how that material would help.
- Investigate practical setup, connection, export, or other access alternatives before asking the user to gather material or troubleshoot.
- If progress depends on access, request only the specific user action or permission needed to enable it or provide the material another way. Continue useful independent work while awaiting the response.
- Offer to walk the user through an export or upload. Welcome files, links, copied text, rough notes, or an interview as supported by your system and the activity, and use the best available route. If the missing access is optional, continue with what is available.
Ask focused questions and respect the answers
Ask questions only when necessary to complete the work well or satisfy the activity's required review points. Build on answers already supplied. Ask one question at a time, or a small group of closely related questions. Wait on work that depends on the answer, and continue useful work that does not. Explain unfamiliar language with examples where helpful.
Confirm answers or decisions you supply on the user's behalf before treating them as the user's final answers or decisions. This does not require separate approval of every sourced finding; follow the activity's specific review requirements.
Keep evidence and independent contributions distinct
Distinguish evidence, inference, and missing information. Check your work against the source material.
Use independent agents when your system actually supports delegation and independent investigation or review would improve the work:
- Give each agent a bounded brief and the context appropriate to its role.
- Keep discovery independent until synthesis where the activity requires it. Preserve any requirement for the user or colleagues to contribute before seeing other explanations.
- Follow the activity's stated fallback and any required confirmation when independent agents or fresh contexts are unavailable. Preserve reviewer isolation where required; describe shared-context or sequential passes accurately.
Produce, check, and revise the result
Do the substantive investigation and production. Carry the activity through to the most complete, usable result within its scope, rather than ending with a plan or handing the main work back to the user. When missing information does not prevent useful work, proceed with clearly identified assumptions where the activity permits them.
Check the result against the activity's completion criteria. At each substantive delivery, state what is complete and any material unfinished work, assumptions, helpful missing information, and remaining uncertainty. Explain how these affect what the user can use, and help the user revise the result.
Preserve the activity's stopping point. Do not turn a rehearsal, investigation, or test-design activity into execution that the user has not authorized.
Your AI prompt
Build an early warning system for requests I receive from leadership, teammates, other departments and outside stakeholders. Learn the patterns from actual history, predict likely requests and their timing, and prepare and send useful answers before the request arrives wherever I authorize that behavior.
Reconstruct the requests and their triggers
Use the role, people or examples I supply to identify search terms. Inspect and try available access to email, chats and other messages, including WhatsApp where accessible, meeting transcripts, calendars, project boards and recurring reports. Search for explicit requests and their surrounding conversations, earlier signals, answers and follow-up. Look for recurring reviews, deadlines, launches, metric changes and other events that might precede a request.
Build a sourced case record: requester and role, requested information or work, request date, answer date, frequency, related event, possible trigger, warning time and what the requester actually used or questioned. Link repeated mentions of the same request instead of counting them as new demand. Recover recipients' needs, preferred detail and useful format from their actual correspondence and prior responses; label inferred preferences and trigger explanations.
Keep a coverage record of channels, time periods, cases and gaps. For a large history, divide bounded periods or request families among agents with source links and the same case fields; reconcile their results and check cross-channel duplicates. Without agents, use successive manageable passes. Investigate connection or export options before asking me to supply missing material. Recollection may suggest patterns but cannot establish unseen frequency or timing; make that limitation explicit.
Find signals that give us useful warning
Group requests by purpose and requester. For each promising pattern, show the history behind it, observed frequency, likely triggering event, expected arrival window and preparation time. Separate a recurring schedule from a prediction based on changing conditions. Look for counterexamples: triggers with no request, requests with no recognized trigger and changes that may have made an old pattern obsolete.
Use upcoming calendar events, project milestones, leadership meetings and current messages to identify the next plausible windows. Ask me to resolve only gaps that affect usefulness or action. Confirm the request families to cover and the benefit we want: earlier preparation, fewer interruptions, faster stakeholder decisions or another concrete result.
Test candidate rules on a later portion of history that was not used to invent them. Replay what was visible before each request; exclude later replies, edits or outcome knowledge. Record correct warnings, missed requests, false alarms and usable lead time. Compare with simply predicting the usual recurring request at its usual interval. With too little dated history, label the rule provisional and use an observation period to measure it before granting it unattended sending authority.
Design the warning and answer loop
For each selected pattern, specify the watched signal, likely requester, timing window, evidence shown in the warning, required answer sources, readiness checks and conditions that suppress a response. Retrieve current information from the documents, systems or people identified in earlier successful answers. Build the actual answer or requested artifact, adapted to the recipient's documented needs, and check material claims against dated sources.
Agree with me on alert destinations and cadence, and on standing permission for advance sending. Make that permission concrete: named recipients or defined groups, request families, channels, allowed content, source-freshness requirements and exceptions requiring review. This should support actual send-before-request behavior when authorized. Do not turn every authorized recurring answer back into a draft awaiting approval. Conversely, a predicted need alone is not permission to contact somebody.
Include a check for whether the request has already arrived, someone else has already answered, the relevant event has been cancelled, or the information changed after preparation. If the request arrived, handle it as an ordinary response under the agreed rules and do not count it as advance delivery.
Build and test the running system
Inspect the existing automation environment and current official documentation for its message, data and scheduling connections. Implement persistent monitoring through supported events or scheduled checks, a durable prediction record, answer generation, review where required and the authorized send action. Configure the agreed cadence so it continues after this chat. Record each signal, prediction, preparation, decision, sending attempt and actual delivery result; use stable request or event identities so retries do not send duplicates.
Replay representative cases without contacting historical recipients. Exercise a correct signal, false alarm, missing answer source, already-answered request, cancelled event, rejected send and repeated automation run. Have a separate reviewer inspect predictions and answers against the original records without your rationale where possible. Repair failures and recheck them.
Show me the working loop and its proposed live rules. Activate it once authorized. Verify an end-to-end live case using an eligible real signal or a clearly labeled test addressed to an agreed test recipient. Check the actual destination or delivery evidence; a generated answer or queued action is not evidence of delivery. A test does not establish that a real request was anticipated.
Learn whether it gets ahead of real demand
Deliver the active configuration, upcoming prediction view, first run record and instructions to change or pause it. At the agreed review cadence, compare predictions with incoming requests, measure lead time and false alarms, and review whether advance answers were useful. Track “answer sent before request” separately from “predicted request later observed”; an effective advance answer may mean the recipient never needs to ask.
Show what has actually happened, what is awaiting a future trigger and what remains uncertain. If missing access blocks monitoring or sending, deliver the functioning analysis and response components, prepared integration work and exact remaining action. Call that partial completion; do not call saved drafts an operating send-before-request system.
Done when
The system watches the agreed signals, records useful advance warnings, prepares sourced answers and runs the authorized delivery path. Its record distinguishes a tested connection, an actual advance answer and a prediction whose outcome is still pending.
These instructions were written in September 2026 using the frontier models available at the time. You may now have better tools or models, or restrictions that make some tasks harder. Your AI should adapt to the tools and access you actually have and find the best available way to help. Everything here is a starting suggestion for you and your AI, not a proven best practice for every setup. Feel free to rewrite any of it to better meet your needs.
These instructions were written in September 2026 using the frontier models available at the time. You may now have better tools or models, or restrictions that make some tasks harder. Your AI should adapt to the tools and access you actually have and find the best available way to help. Everything here is a starting suggestion for you and your AI, not a proven best practice for every setup. Feel free to rewrite any of it to better meet your needs.