Build a queryable memory of every team decision.
In a fast-moving team, decisions can arrive so quickly that people forget the latest one, who made it and why. Build a shared memory that finds key choices in emails, chats, conversations with chatbots and meeting transcripts, keeps track of what each choice changes, and lets anyone with access ask what currently stands.
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
- Find decisions and their history in accessible email, human and chatbot conversations, transcripts and project records.
- Research the tools available in your organization, choose a suitable shared home and build the searchable decision memory.
- Set up and test automatic updates, sources, corrections, superseded decisions and access for the intended readers.
What to have ready
- A team or project to start with and access to its relevant records.
- The intended readers and any existing shared tools or approved place for the resource.
Where you come in
- Resolve important ambiguities about decisions and who had final authority.
- Agree the sharing and update arrangement, then try the resource on questions your team actually asks.
What you'll get
A tested, shareable decision memory that answers what was decided, what changed, who decided and why, with sources, open loops and visible update coverage. If access blocks automatic operation, you receive a clearly identified partial build and the exact remaining step.
You're done when
The intended team has a tested, shareable decision memory with traceable answers, decision history, corrections and visible source coverage, and the agreed automatic updating has been verified. Any blocked sharing or automation remains explicitly unfinished.
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 a queryable, shareable memory of my team's decisions. Help us answer what currently stands, who made the choice and why, even when decisions changed across email, human chat, chatbot conversations, meetings and documents. Automatically keep the resource current using the sources and tools we can actually access. ### Establish the team, sources and intended readers Use my starting context to find the team or project, its people and date range. Inspect and try the available connections. Search relevant email, chat including WhatsApp where accessible, conversations with chatbots, meeting transcripts, calendar invitations, project documents and existing decision logs. Look for explicit choices, their rationale, who took part, final authority, later amendments and unanswered follow-up work. Use invitations, project roles and correspondence to establish who was involved and who needs the resource; don't invent authority from a person's seniority. Inventory source systems, successful access, available history, pagination or export limits, source links and update capabilities. Check actual coverage of chatbot conversations separately from human chat. An accessible excerpt is not access to the whole conversation history. If a needed source is missing, investigate available setup or permitted export routes before asking me for the specific action only I can take. Welcome existing exports or rough material but preserve their dates and coverage limits. Propose a bounded starting team, corpus and historical period from what you find. Establish who should read, correct and administer the resource and how often new material needs to appear. Ask focused questions one at a time where the answers change the build, and carry forward choices I already supplied. ### Reconstruct decisions without turning discussion into agreement Extract candidate decisions with links to the exact source passages and enough surrounding context to interpret them. Distinguish proposals, options, recommendations, announcements, approved choices, tentative agreements and unresolved contradictions. A chatbot's suggested plan is not a team decision; look for a person's adoption of it. A later mention or file update is not proof that an earlier decision was superseded. For each decision, record: - A stable identifier and a concise account of what was decided, including scope and current status. - The earlier decisions it overturns or alters, including exactly which part changed and which part still stands. - Open loops created by the decision, with owners, due dates and completion evidence when the record supplies them; keep missing owners or dates unknown. - People involved and the final decider, with evidence for that distinction. - The recorded reason for the choice; label inferred rationale separately and leave absent rationale unknown. - Decision or event date, source-message date, effective date when different, source links, extraction time, version and relevant uncertainty. Retain the original evidence and history when a record is corrected. Connect related decisions and express partial supersession explicitly. Do not erase the old choice to make the latest view tidy. Queue ambiguous cases for focused human review; they can appear as unresolved records without becoming current policy. Ask me about consequential gaps after searching the accessible record. My clarification becomes a dated, attributed addition, not an invented original source. For a large history, divide extraction into bounded assignments by project, period or source, with explicit source references, record definitions, deliverables and coverage. Use agents where useful and available; reconcile duplicates, chronology and conflicts centrally. When capacity is limited, use successive passes or self-contained handoffs. Keep an auditable coverage record throughout. ### Choose a shared home that fits the actual environment Inspect the tools you can use to store structured records, query them, expose an interface, authenticate readers, run scheduled or event-driven updates and preserve backups. Research current official documentation for the plausible options in this environment. Date and link the supporting sources. Assess whether an existing company database or collaboration tool, a versioned JSON file with an interface, a web deployment or an intranet deployment best supports the intended readers, volume, updates and permissions. A JSON file can hold the data; explain and build how colleagues will actually search and share it. Recommend a concrete route in ordinary language, including where people will open it, how new records will arrive, who can see which material and how corrections work. Explain the practical difference only if another viable route presents a meaningful choice. Confirm any consequential unresolved sharing or deployment choice with me before depending on it. Build on an existing suitable tool when it meets the need. Don't end with a list of products or assume a product capability without checking it. ### Build the decision memory and automatic updates Create the data structure, import the reconstructed records and build a usable search or question interface. Support questions such as “What's our current launch decision?”, “Who changed the pricing plan and why?”, “Which earlier choices does that replace?” and “What work did this decision leave open?” Answers must identify the relevant current decision, cite the evidence, expose material ambiguity and let readers inspect the history. When the sources don't establish an answer, say what is missing. Implement an ingestion path for the agreed sources using the available authorized tools. Track source identifiers, change markers and last successful processing times so reruns do not duplicate decisions. Process new and edited source records, reconcile amendments and keep the review queue distinct from confirmed decisions. If a source is withdrawn or becomes inaccessible, visibly mark the affected coverage and apply the agreed retention and access behavior. Surface failed runs and stale sources rather than silently appearing up to date. Provide a simple correction flow: a reader can flag an error, supply evidence or ask the responsible person to clarify. Preserve the earlier version and record who corrected what and when. Apply the agreed decision authority to confirming changes. Ensure generated answers and shared records don't expose source information to readers who lack the agreed access; preserve needed evidence through an appropriately accessible citation or restricted view. Configure the agreed automatic schedule or source-change trigger, persistence and shared access. Carry out the building, integration and routine checks yourself. Ask me only for the necessary credentials, approval or action you cannot supply, after preparing the concrete work that action enables. If essential access or hosting is unavailable, preserve a usable local or export-based partial build and a precise continuation handoff; identify that automatic shared operation is still unfinished. ### Test the resource as the team will use it Use a small set of source-backed decisions to test the complete path: initial extraction, a later reversal, a partial amendment, an unresolved proposal, an ambiguous final decider and an open loop later closed. Compare stored fields and answers with the original passages. Verify that reprocessing the same source does not duplicate records and that a corrected record preserves history. Test a newly available or approved synthetic source item through the actual ingestion path and verify the visible result, last-run status and next automatic run or registered trigger. Identify synthetic test material and remove or isolate it from the team's real record. Confirm that the update mechanism persists beyond this chat; code or a suggested schedule alone is not operating automation. Exercise a failed or unavailable source and confirm the interface reports the gap. Test the shared route with the intended permission levels, including whether an unauthorized reader is excluded and whether readers receive only the decision material permitted for them. If you cannot verify another user's access directly, explain the exact remaining check and guide that person through the smallest necessary test; don't claim it has passed. Have me or an intended reader try real questions and a correction, then fix substantive problems. Where available, give a separate reviewer the working resource, source sample and expected questions without your account of the implementation. Have it challenge current-status answers, source support, supersession and access behavior. Otherwise perform a distinct checking pass. Resolve material errors and recheck the affected behavior. ### Hand over a memory people can rely on Deliver the shared link or agreed access route, concise instructions for asking questions and correcting records, and the person or role responsible for upkeep. Show what historical sources have actually been processed, current update coverage, last successful run, known ambiguities and excluded or inaccessible sources. Provide an export or backup and the configuration needed to continue maintaining the resource. Demonstrate a current decision with its rationale, final decider, predecessor and open loops. State what sharing and automatic ingestion were tested and any concrete unfinished behavior. Finish when the agreed shared memory works and its updates and corrections have been checked, or clearly identify the remaining blocker and partial deliverable. 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
Build a queryable memory of every team decision.
What the AI will do
- Find decisions and their history in accessible email, human and chatbot conversations, transcripts and project records.
- Research the tools available in your organization, choose a suitable shared home and build the searchable decision memory.
- Set up and test automatic updates, sources, corrections, superseded decisions and access for the intended readers.
What you can provide
- A team or project to start with and access to its relevant records.
- The intended readers and any existing shared tools or approved place for the resource.
Where you'll take part
- Resolve important ambiguities about decisions and who had final authority.
- Agree the sharing and update arrangement, then try the resource on questions your team actually asks.
What you'll get
A tested, shareable decision memory that answers what was decided, what changed, who decided and why, with sources, open loops and visible update coverage. If access blocks automatic operation, you receive a clearly identified partial build and the exact remaining step.
Activity context
In a fast-moving team, decisions can arrive so quickly that people forget the latest one, who made it and why. Build a shared memory that finds key choices in emails, chats, conversations with chatbots and meeting transcripts, keeps track of what each choice changes, and lets anyone with access ask what currently stands.
For the user
Name a team or project; rough context and existing records are enough to start. The AI will investigate the record and available tools, recommend a shared home, and build the resource. You'll settle unclear decisions, choose who can use it and try a few real questions. It will show which sources it covers and whether automatic updating is actually working.
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 a queryable, shareable memory of my team's decisions. Help us answer what currently stands, who made the choice and why, even when decisions changed across email, human chat, chatbot conversations, meetings and documents. Automatically keep the resource current using the sources and tools we can actually access.
Establish the team, sources and intended readers
Use my starting context to find the team or project, its people and date range. Inspect and try the available connections. Search relevant email, chat including WhatsApp where accessible, conversations with chatbots, meeting transcripts, calendar invitations, project documents and existing decision logs. Look for explicit choices, their rationale, who took part, final authority, later amendments and unanswered follow-up work. Use invitations, project roles and correspondence to establish who was involved and who needs the resource; don't invent authority from a person's seniority.
Inventory source systems, successful access, available history, pagination or export limits, source links and update capabilities. Check actual coverage of chatbot conversations separately from human chat. An accessible excerpt is not access to the whole conversation history. If a needed source is missing, investigate available setup or permitted export routes before asking me for the specific action only I can take. Welcome existing exports or rough material but preserve their dates and coverage limits.
Propose a bounded starting team, corpus and historical period from what you find. Establish who should read, correct and administer the resource and how often new material needs to appear. Ask focused questions one at a time where the answers change the build, and carry forward choices I already supplied.
Reconstruct decisions without turning discussion into agreement
Extract candidate decisions with links to the exact source passages and enough surrounding context to interpret them. Distinguish proposals, options, recommendations, announcements, approved choices, tentative agreements and unresolved contradictions. A chatbot's suggested plan is not a team decision; look for a person's adoption of it. A later mention or file update is not proof that an earlier decision was superseded.
For each decision, record:
- A stable identifier and a concise account of what was decided, including scope and current status.
- The earlier decisions it overturns or alters, including exactly which part changed and which part still stands.
- Open loops created by the decision, with owners, due dates and completion evidence when the record supplies them; keep missing owners or dates unknown.
- People involved and the final decider, with evidence for that distinction.
- The recorded reason for the choice; label inferred rationale separately and leave absent rationale unknown.
- Decision or event date, source-message date, effective date when different, source links, extraction time, version and relevant uncertainty.
Retain the original evidence and history when a record is corrected. Connect related decisions and express partial supersession explicitly. Do not erase the old choice to make the latest view tidy. Queue ambiguous cases for focused human review; they can appear as unresolved records without becoming current policy. Ask me about consequential gaps after searching the accessible record. My clarification becomes a dated, attributed addition, not an invented original source.
For a large history, divide extraction into bounded assignments by project, period or source, with explicit source references, record definitions, deliverables and coverage. Use agents where useful and available; reconcile duplicates, chronology and conflicts centrally. When capacity is limited, use successive passes or self-contained handoffs. Keep an auditable coverage record throughout.
Choose a shared home that fits the actual environment
Inspect the tools you can use to store structured records, query them, expose an interface, authenticate readers, run scheduled or event-driven updates and preserve backups. Research current official documentation for the plausible options in this environment. Date and link the supporting sources. Assess whether an existing company database or collaboration tool, a versioned JSON file with an interface, a web deployment or an intranet deployment best supports the intended readers, volume, updates and permissions. A JSON file can hold the data; explain and build how colleagues will actually search and share it.
Recommend a concrete route in ordinary language, including where people will open it, how new records will arrive, who can see which material and how corrections work. Explain the practical difference only if another viable route presents a meaningful choice. Confirm any consequential unresolved sharing or deployment choice with me before depending on it. Build on an existing suitable tool when it meets the need. Don't end with a list of products or assume a product capability without checking it.
Build the decision memory and automatic updates
Create the data structure, import the reconstructed records and build a usable search or question interface. Support questions such as “What's our current launch decision?”, “Who changed the pricing plan and why?”, “Which earlier choices does that replace?” and “What work did this decision leave open?” Answers must identify the relevant current decision, cite the evidence, expose material ambiguity and let readers inspect the history. When the sources don't establish an answer, say what is missing.
Implement an ingestion path for the agreed sources using the available authorized tools. Track source identifiers, change markers and last successful processing times so reruns do not duplicate decisions. Process new and edited source records, reconcile amendments and keep the review queue distinct from confirmed decisions. If a source is withdrawn or becomes inaccessible, visibly mark the affected coverage and apply the agreed retention and access behavior. Surface failed runs and stale sources rather than silently appearing up to date.
Provide a simple correction flow: a reader can flag an error, supply evidence or ask the responsible person to clarify. Preserve the earlier version and record who corrected what and when. Apply the agreed decision authority to confirming changes. Ensure generated answers and shared records don't expose source information to readers who lack the agreed access; preserve needed evidence through an appropriately accessible citation or restricted view.
Configure the agreed automatic schedule or source-change trigger, persistence and shared access. Carry out the building, integration and routine checks yourself. Ask me only for the necessary credentials, approval or action you cannot supply, after preparing the concrete work that action enables. If essential access or hosting is unavailable, preserve a usable local or export-based partial build and a precise continuation handoff; identify that automatic shared operation is still unfinished.
Test the resource as the team will use it
Use a small set of source-backed decisions to test the complete path: initial extraction, a later reversal, a partial amendment, an unresolved proposal, an ambiguous final decider and an open loop later closed. Compare stored fields and answers with the original passages. Verify that reprocessing the same source does not duplicate records and that a corrected record preserves history.
Test a newly available or approved synthetic source item through the actual ingestion path and verify the visible result, last-run status and next automatic run or registered trigger. Identify synthetic test material and remove or isolate it from the team's real record. Confirm that the update mechanism persists beyond this chat; code or a suggested schedule alone is not operating automation. Exercise a failed or unavailable source and confirm the interface reports the gap.
Test the shared route with the intended permission levels, including whether an unauthorized reader is excluded and whether readers receive only the decision material permitted for them. If you cannot verify another user's access directly, explain the exact remaining check and guide that person through the smallest necessary test; don't claim it has passed. Have me or an intended reader try real questions and a correction, then fix substantive problems.
Where available, give a separate reviewer the working resource, source sample and expected questions without your account of the implementation. Have it challenge current-status answers, source support, supersession and access behavior. Otherwise perform a distinct checking pass. Resolve material errors and recheck the affected behavior.
Hand over a memory people can rely on
Deliver the shared link or agreed access route, concise instructions for asking questions and correcting records, and the person or role responsible for upkeep. Show what historical sources have actually been processed, current update coverage, last successful run, known ambiguities and excluded or inaccessible sources. Provide an export or backup and the configuration needed to continue maintaining the resource.
Demonstrate a current decision with its rationale, final decider, predecessor and open loops. State what sharing and automatic ingestion were tested and any concrete unfinished behavior. Finish when the agreed shared memory works and its updates and corrections have been checked, or clearly identify the remaining blocker and partial deliverable.
Done when
The intended team has a tested, shareable decision memory with traceable answers, decision history, corrections and visible source coverage, and the agreed automatic updating has been verified. Any blocked sharing or automation remains explicitly unfinished.
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.