Give new hires your company’s collective memory.

What the AI will do

• Reconstruct the history, decisions and practical customs a new colleague needs, using relevant company records.
• Build a source-linked guide and a way to ask questions, then create the learning experience you choose: daily messages, a course, a podcast, a video or an interactive webapp.

What you can provide

• A new hire’s role or one team to start with. Existing onboarding material, project names or a rough account of what newcomers struggle to understand are enough to begin.

Where you'll take part

• Clarify uncertain history and help distinguish a real team custom from an AI inference.
• Choose the learning format and, for daily delivery, the recipient, channel and schedule. Review the result and authorize any messages before they are sent.

What you'll get

A tested introduction to the company’s memory in the chosen format, with sources and a queryable reference. If access limits the work, the result states which history is covered and which production or delivery action remains.

Activity context

Every company has the official introduction—and the things someone finally explains over coffee. Why that project has a strange name. How a decision really gets made. Which old experiment everyone is still reacting to. Give a new colleague a way into both.

For the user

Start with one role or team. The AI searches the records you can use, reconstructs the story and checks the customs it thinks it sees. You help settle the uncertain parts and choose how the newcomer should encounter it: a useful message each morning, a course, something to listen to or watch, or a small interactive guide.

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

Give a new hire access to the company’s collective memory, starting with one role or team. Reconstruct useful history and evidenced unwritten customs, build a source-linked reference they can question, and produce the learning format we choose. Keep the substantive gathering, writing, production and checking with you.

1. Establish whose first weeks we are helping

Use any supplied role, team, start date and project names. Search accessible hiring and welcome correspondence, calendar invitations, role descriptions, onboarding documents and relevant team messages for the newcomer’s responsibilities, initial meetings, first assignments and expressed questions. Use evidence of their background and needs to choose depth and vocabulary; do not infer their knowledge or personality from a job title.

Check actual access to relevant email, chats and WhatsApp where available, meeting transcripts, project archives, decision documents, team calendars and current process records. Try useful searches before asking me to gather a packet. Inspect available export or connection options if access fails, then ask only for the material or user action needed. Start from permitted sources a newcomer can actually receive. A manager’s ability to read something does not establish the newcomer’s access.

Briefly state the role, intended first-weeks use and available record. Ask one necessary question at a time where the scope is unresolved, and wait on choices that determine the next phase. If records are missing, offer a narrower guide from accessible sources. An interview-based reconstruction is possible but weaker and incomplete; do not describe it as the company’s comprehensive memory.

2. Reconstruct the useful history

Search for earlier onboarding questions and the replies that resolved them; project origins, renamed initiatives and abandoned experiments; strategy and product decisions; customer commitments; escalation and handoff practices; and disagreements that changed what the team now does. Follow references back to original discussions where possible. Locate later amendments rather than treating the latest mention as a new decision.

For a substantial corpus, give research agents bounded assignments by project, period or question. Each receives exact source boundaries, the newcomer’s evidenced needs and a brief to return findings with links, dates, supporting passages, uncertainties and unexamined material. Keep a coverage record and reconcile conflicting accounts after the independent passes. Use waves, bounded passes or fresh-session handoffs when capacity is limited.

Build a working memory in which each item has:

• The question a newcomer is likely to ask.
• The current answer and why it matters in their work.
• The relevant story: what happened, who held the relevant roles and what changed.
• Source references with dates, including any later decision that superseded an earlier one.
• What is unresolved, disputed or missing, and the appropriate role to ask next.

Choose stories that explain present choices; do not bury the newcomer in every document you found. Distinguish official decisions, someone’s recollection, interpretations and unresolved disagreements.

3. Find the unwritten rules without inventing a culture

Look in actual meeting transcripts, scheduling habits, handoff messages, feedback to earlier newcomers and repeated responses to requests. Seek useful patterns: whether a proposal normally circulates before the meeting, what information a leader expects in an escalation, how colleagues signal a tentative idea, or which decisions need consultation across teams. These are examples to investigate, not customs to assume this company has.

For each proposed custom, retain examples, dates, team scope and counterexamples. Distinguish an explicit instruction from a repeated observed practice and from a tentative inference. One person’s habit is not automatically a company rule. Where evidence conflicts, describe the variation rather than manufacture consensus.

Show me the small set of consequential or uncertain customs for confirmation, one focused question at a time as needed. If confirmation requires someone else, draft a concise request; do not send it without authorization. Keep unconfirmed interpretations visibly tentative or omit them from definitive guidance. Make the newcomer’s version useful and humane: explain how to navigate the work, without turning gossip or inferred motives into facts.

4. Choose how the newcomer will learn

Present creative, concrete possibilities based on the material and the newcomer’s actual work:

• A daily email or message: one useful story, practical custom or answer each day, with a source and a small question or action.
• A short course: sequenced lessons, real company examples, exercises and feedback tied to the first weeks’ responsibilities.
• A podcast: a listenable account of how the company got here, with chapters for the questions that recur.
• A video: a visual introduction to people’s roles, project history and how work moves through the team.
• An interactive webapp: explore a timeline, follow a project’s decisions, try a realistic situation and ask source-grounded questions.

Show a short sample using an actual finding, recommend a format when the evidence supports it, and let me choose. Ask about only the relevant duration, platform, language or accessibility needs. Do not silently choose a medium or produce all five. For daily messages, agree the recipient, channel, start date, timezone, cadence, duration and whether sending is automated. Stop before dependent production if these choices are unresolved.

5. Build the chosen experience and the question-answering reference

First create the concise source-linked guide, including current practice, useful history, a glossary, people’s roles and evidenced customs. Establish a queryable reference in an available approved tool: load the selected material, preserve citations and dates, and instruct it to acknowledge missing answers and conflicting versions. Test that an answer’s citation actually supports the claim. If a persistent assistant cannot be created, deliver the curated source pack and a complete reusable question-answering prompt for the supported environment, labeling that fallback clearly.

Then produce the chosen medium, rather than stopping at its outline:

• For daily delivery, write the entire agreed sequence, attach supporting links and prepare it in the actual messaging or scheduling system. Show the content and schedule for authorization before sending or activating automated delivery. After authorization, configure supported delivery and verify the saved schedule or test with an agreed recipient; do not claim future delivery from a written timetable. If access is absent, deliver the complete dated sequence and an importable schedule where supported, with the exact activation action remaining.
• For a course, create the lessons, exercises and answers or feedback, build the learner navigation in the chosen tool and test a complete lesson path.
• For a podcast, prepare the source brief and use an available audio-generation tool, check its claims and sound, then export playable audio. Inspect current official documentation before using product controls.
• For a video, create the source brief and generate or render the video with an available tool; inspect the resulting visuals, narration and captions.
• For a webapp, build the agreed browsing and learning interactions, connect question answering to the permitted sources where feasible, and run realistic questions and navigation tests. A static page must not pretend it has live AI answering. Provide a working local or approved private destination, and seek authorization before external deployment when needed.

Inspect and try production capabilities first. Prepare exact files and settings for any user-only action, wait for its result, and continue. If no production route works, agree a feasible alternative or deliver the prepared package while explicitly naming the unfinished medium. A script is not a podcast, a storyboard is not a video and a schedule file is not active delivery.

6. Test a newcomer’s experience

Give a fresh reviewer the actual guide, chosen artifact, role context and sources without your drafting rationale. Ask them to try realistic questions: why a current practice exists, who owns a decision, what changed after an old project, which custom is merely inferred, and a question the sources cannot answer. Check accuracy, source support, readability, useful uncertainty and whether the answer reflects the current decision. Have them inspect or play the actual medium; reviewing a script alone does not establish audio or video quality. Disclose shared-context review if a fresh reviewer is unavailable.

Verify access from the intended learner’s account where possible, including links, media and reference sources; ask for only the necessary user-only check otherwise. Do not broaden source permissions to make a test pass. Repair problems and retest the affected experience.

Deliver the guide, the usable learning experience and queryable reference or agreed fallback. Include the covered teams and dates, known gaps, actual delivery/access state, and a simple way for the owner to correct or update the material. Do not claim that a system maintains itself unless an update mechanism has been configured and tested.

Done when

The newcomer can use the chosen learning experience and follow or question its sources. The history covered, evidence behind customs, learner access and any remaining production or delivery step are clear.

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.