Find a new capability in the latest model.

What the AI will do

• Search your projects, conversations and previous attempts for ambitious work worth trying.
• Investigate the chosen model’s capabilities and how others have used it, then carry out the challenge you choose.
• Check the actual result, diagnose failures and save the project as a repeatable capability test.

What you can provide

• Access to relevant projects, emails, chats or earlier attempts; a rough concern or your own challenge also works.
• Access to the frontier model you want to try; the AI will inspect what is actually available.

Where you'll take part

• Accept or reject suggested challenges, or propose your own.
• Agree what success means, try the actual output and decide whether a revised attempt is worth making.

What you'll get

A completed project or a documented attempt with specific failure evidence, useful partial work and a saved challenge ready for a future model.

Activity context

Keep a few projects that AI cannot quite manage yet. The messy analysis, ambitious tool or complicated piece of work that defeated the last model can become a revealing test for the next one.

Let AI explore your projects and concerns, suggest ambitious challenges and help you try one. Failure is useful here too—especially when you can see what failed and preserve the attempt for another day.

For the user

You do not need to invent the perfect benchmark. The AI can look for something you actually care about, propose a few ambitious options and guide the attempt you choose. It will investigate whether a failure reflects the model, missing access or the way the task was set up.

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

Help me discover what a frontier model can do by attempting an ambitious project that matters to me. Look for work that was previously difficult or unsuccessful, propose useful challenges, guide my choice and carry out the selected attempt. A well-understood failure can be a valuable result. Preserve the project so a later model can try it under comparable conditions.

Explore my projects and previous attempts

Inspect and try available connections. Search current and unfinished project files, emails, chats including WhatsApp where accessible, meeting transcripts, calendar-linked work, saved AI conversations where permitted, issue logs, prototypes and records of earlier attempts. Look for something I wanted to make, understand or achieve that repeatedly stalled, required too much manual correction, exceeded an earlier model's capabilities or remains a substantial concern.

Use project names, people, dates and distinctive problem descriptions to follow the actual work. Read enough of a failed attempt to identify its intended result, inputs, output, errors and my corrections. Distinguish a documented model failure from an unfinished project, a missing tool, a changed goal or a task nobody actually tried. Keep real user or audience needs grounded in correspondence and work examples.

Maintain a compact coverage record and work in bounded project or source groups if the history is large. Use separate investigators only where they provide useful breadth, with explicit sources, questions and returned evidence. Without agents, use successive passes and preserve remaining coverage. Do not ask me to reconstruct everything the available record can show.

If access is missing, investigate supported connections or exports and ask for the specific missing file or example. A concern I describe in a sentence is enough to begin; label what is based on my account. Do not mistake inaccessible chat history for an absence of previous attempts.

Find the model and research promising ways to use it

Establish which frontier model I want to try and what model and version this environment actually exposes. Inspect available tools, context and file limits, execution capabilities and any relevant account restrictions. Use current official release notes, documentation, model or system cards and primary evaluation material to identify changes that might matter for these projects. Date the findings and distinguish announced capabilities from features actually available here. Do not guess a hidden model version.

Also search reviews, worked examples and analysis of that model to see how others obtained useful results and whether a different setup might suit the challenge. Treat these as leads and practitioners' reports, not controlled proof. For technical capability claims, verify against official documentation, original evaluations or a direct reproducible test. Read what the example actually did; do not infer success from a title or promotional demo.

Separate a capability new to me from a capability shown to improve over an older model. Different interfaces, tools, prompts or permissions may explain an improvement. Do not invent a universal best way to prompt the model or require a fashionable technique unsupported by this task.

Propose ambitious options and let me choose

Suggest a few concrete challenges grounded in my actual projects or concerns. Each should say what we would try, why I might care, what made it difficult before or why it is ambitious now, what inputs are available, and what an inspectable result would look like. Include uncertainty about whether this model can finish it. Do not quietly replace the interesting challenge with an easy demonstration.

Invite me to accept or reject any option, modify one or supply my own. Ask one focused question if the choice needs clarification and wait before committing to a project. For my own challenge, investigate the relevant context and help make the desired result concrete instead of forcing it into your shortlist.

Agree the project scope, success criteria, representative inputs, permissible actions and a sensible effort boundary suited to my interest. If the project is too large for one run, propose a meaningful complete slice that preserves what makes it difficult and let me decide. Failure is allowed; silent scope reduction is not success.

Save the starting point and make the attempt

Retain the agreed brief, authorized input snapshot or stable source references, model identity where known, date, settings and tools that materially affect the task, and any prior attempt that will serve as a comparison. Preserve earlier outputs separately so they are not overwritten. Keep future comparison inputs free of your previous solution unless the agreed test intentionally studies improvement from an existing artifact.

Create a practical execution sequence and do the work. For a research question, investigate sources and deliver the supported analysis. For a tool, build the actual behavior and exercise it. For a complex production task, create the artifact and inspect whether its intended user can use it. Let this project's requirements determine the method; an impressive-looking mockup is not a substitute for promised working behavior.

Use agents for bounded research, implementation or review when they could expand what gets done. Give each its goal, actual sources, precise output and completion checks; sequence dependencies, track coverage and integrate their results. Use waves or explicit fresh-session handoffs when capacity is limited. Keep closely coupled reasoning with a lead and be honest when role passes share context. Do not count the number of agents as evidence of capability.

Keep me involved in consequential choices and useful trial feedback, while carrying routine work and correction yourself. Operate within the project's agreed authority. Publication, contacting people or other external commitments require authorization appropriate to the action; this capability exercise does not grant them automatically.

Check success and investigate failure

Evaluate the actual output against the agreed criteria and representative inputs. Cite evidence, recalculate important numbers, run the relevant behavior or inspect the produced artifact as appropriate. Use a separate reviewer with the actual result, brief and source evidence, without the builder's account of why it should pass. When human judgment is essential, ask me to try the result or judge the specific dimension; do not make me perform all the verification.

For each material failure, identify the observable symptom and plausible cause: reasoning or source error, goal drift, context loss, inaccessible data, unavailable tool, integration defect or unclear specification. These are hypotheses to investigate. Do not blame the model when access was never available, and do not conceal a poor result behind the claim that the prompt was wrong.

Use targeted research into model documentation, original worked examples and relevant analyses to identify a justified change in setup. Propose a revised attempt when it could teach us something, explain what changes and preserve the original result. Try agreed corrections within the effort boundary and recheck affected criteria. Avoid an endless series of retries; when the boundary is reached, show what further work would test and let me choose whether to continue.

If an older model is accessible and a comparison is useful, run equivalent inputs and criteria without feeding it the new model's answer. Keep tool and resource differences visible. If the older attempt is missing or incomparable, report what this run demonstrated without claiming a measured improvement.

Deliver the result and a challenge worth keeping

Give me the actual artifact or useful partial work first. State clearly what succeeded, what failed and what remains untested, with concrete evidence and the practical consequence for using it. A failure can finish this capability test without finishing the underlying project; keep those outcomes distinct.

Save a compact challenge packet: purpose, inputs or authorized references, success criteria, exact starting brief, tool conditions, attempts and changes, result evidence, identified limitations and a self-contained instruction for a future model to try again. Make it easy to reopen the project without requiring me to remember its history. Do not store credentials or unnecessary private records in the packet.

Summarize whether the result demonstrates a useful new capability, a better performance under changed conditions, or a still-unsolved challenge. Include what a different setup might improve and which explanation remains uncertain. Stop after the agreed attempt and usable handoff. Do not claim future monitoring or automatic reruns unless they are separately requested and actually arranged.

Done when

You have tried an ambitious challenge, checked what the model actually accomplished, and saved the result and failure evidence so a later model can try again.

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.