Becoming an AI Power User

1.8The Expanding Edge

They engineer the context AI works from, drawing on everything they already know

Developing

You decide what the assistant has to work with

Ask an assistant for a project update without saying which project or what changed this week, and you get an update that could describe any project. An assistant works from what reaches it: your request, the files and records it can read, earlier messages in the conversation, and any preferences you have saved. That collection is its context, and is the work of deciding what goes into it, gathering it, and keeping it current. The pieces most likely to be missing are the ones you know best: the project's history, what the reader expects, the constraint everyone on your team takes for granted.

A colleague closes those gaps by talking with you. You explain the task, they ask about the part you skipped, and you catch a wrong assumption before it shapes the work. An assistant can ask questions and look things up through connected tools, and it can also carry on with a guess you never intended. So build the shared understanding on purpose: have the assistant list what it is missing, pull the sources you point it to, and interview you about choices you have not explained.

Some context stays the same from one request to the next: who you write for, what you are trying to achieve, recurring limits, examples you like. Those parts can live in a reusable context package. The facts of the moment still come from current records. A saved tone preference can shape an email to a client, and the new date in that email has to come from this week's project notes.

Relevant source passages connect to a task beneath transparent goal and constraint layers, while unknowns remain visible. — is curation: the useful pieces become a reusable context package the model can work with.

A good AI request carries the news and the decision you need

Start with a request most people have typed at some point: "Write a project update email." The assistant has to invent the project, the reader, and the news. Compare it with this one: "Write to Priya, our client. The event invitations will be ready Friday instead of Wednesday because the final venue details arrived late. Ask whether a Friday send still gives guests enough notice. Keep it short and do not blame the venue."

Now the assistant can write something Priya can act on: "Priya, the invitations will be ready Friday rather than Wednesday because we received the final venue details later than expected. Does a Friday send still give guests enough notice?" The second request states the facts that affect the reader and the decision you need from Priya, and those same details become your checklist for the draft: the right day, the reason, the question, and no blame.

Those details can come from anywhere the assistant can read. If the dates live in your project notes, point it there and ask it to raise open questions before it drafts. What you cannot count on is the assistant asking on its own. In two studies of how language models handle gaps in a conversation, the models asked for clarification and followed up less than people did, and misunderstandings early in a conversation were associated with breakdowns later.

Details that feel obvious to you are easy to leave out of an AI request

Knowing something makes it hard to imagine not knowing it. In their 1989 experiments (opens in a new tab), Colin Camerer, George Loewenstein, and Martin Weber found that better-informed participants struggled to set aside their private information when predicting the judgments of less-informed people. They called this the curse of knowledge. Before you send a request, ask what feels obvious only because you already know the project.

Your assistant may not know the project's history, your team's shorthand, or the limits your colleagues never mention. Read the request as a capable newcomer would and ask what they would need before starting. Or have the assistant list the assumptions it would have to make, and fill in the ones that would change the answer.

Before sending an AI request, check what the answer depends on

A general explanation, such as how compound interest works, needs almost nothing from you. A recommendation about your own project needs its constraints and records. Knowing which kind of request you are making takes a short pause. In Microsoft and LinkedIn's 2024 survey, respondents classified as power users were more likely than others to say they often pause to ask whether AI could help with a task. The pause here adds a second question: what does the answer depend on, and does the assistant have it?

When you pause, the table below lists places to look. Use only the elements that change the answer. Some tasks need nothing beyond the source and a question, and others also need an audience, limits, or an example.

Element	What it covers	What you might say
Role	A perspective or responsibility for this task	"Review this event plan for scheduling conflicts"
Audience	Who will read or use the result	"This is for the client who decides when the invitations go out"
Goal	What the result should accomplish	"Explain that the invitations moved to Friday and ask whether that still gives guests enough notice"
Constraints	Limits on format, length, tone, or scope	"Under 500 words, short paragraphs, no jargon"
Examples	What good looks like, or what to avoid	"Here is an earlier email whose tone I liked: [paste example]"
Source material	Documents, notes, data, or earlier work to draw on	"Here is the meeting transcript from Tuesday: [paste transcript]"

Start with the outcome and the source material it depends on. To pull the deadlines out of a contract, the assistant needs the contract and a clear idea of which dates count. A client email may also need the audience and the tone. A role sets a perspective, and that is all it does: telling the assistant it is a contracts lawyer supplies neither a lawyer's training nor the facts of your contract.

Some context doubles as a checklist. "Under 500 words, short paragraphs, no jargon" tells you what to look for in the draft. The project notes do a different job: they back up its facts. Reviewing the email to Priya takes both, because a draft can meet every style limit and still give the wrong day.

Feedback on a resume needs the resume and the job

Bare prompt: "Give me feedback on my resume." With no resume attached, the assistant can only offer general advice or ask to see it.

Your material: Say the job posting asks for someone to "coordinate projects across teams and report progress clearly." Two of your resume bullets read "Managed stakeholders" and "Organized weekly planning meetings for a six-person team; recorded owners and deadlines."

Prompt with context: "Use these two resume bullets and the quoted job requirement. Which bullet gives stronger evidence for this role? Explain why, suggest a revision grounded in what I provided, and ask before adding an achievement or metric."

A grounded answer: "The planning-meetings bullet is stronger because it names your responsibility, the team, and what you recorded. 'Managed stakeholders' leaves all of that unclear. What did you coordinate, and what evidence of the result can you support?"

You now have something to revise, and the assistant has not invented a launch, a dashboard, or a percentage you never earned. Its question about missing evidence is useful feedback in its own right.

Give the assistant enough to do the task, and keep the rest out of reach

Give the assistant what the task needs and a clear boundary around what it may read. For the email to Priya, that could be the project notes, her last message, and one earlier email whose tone you liked. Ask it what else it would need. That is minimum sufficient context: enough information to do the job, with gaps raised as they come up.

Access should fit the task too. Suppose the transcript of your last client call also covers the client's finances. For an update about invitations, share the passage about the dates, or point the assistant to the project record that holds them. For a coding task, name the project files it may use and keep passwords and keys out of its reach. A file sitting in the same folder is no reason to include it.

When extra context makes an answer worse, find out what changed. Irrelevant material, contradictions, stale facts, sheer length, and the order of information can each pull a result off course. State priorities outright, group related material, cut what does not help, and test the rearranged version on the same input, since no single order suits every task. Anthropic's context-engineering guidance (opens in a new tab) makes the same case for curation: sufficient, relevant information across instructions, sources, conversation history, and tool results.

An AI planner needs to know school pickup is fixed and a writing block can move

W. Ross Ashby's law of requisite variety (opens in a new tab) offers a lens from cybernetics: a regulator can keep outcomes on target only if it has a distinct response for each disturbance that matters. On a calendar, school pickup and your preferred writing block are both just blocks of time. When a meeting request lands on one of them, the right response depends on which one it is, and only your context can tell the assistant that pickup cannot move. Your context has to preserve every distinction that calls for a different decision. Ashby's law says nothing about prompt length. Use it to ask which differences the assistant must be able to act on.

Suppose you want a daily planner that protects school pickup and suggests a writing block before 10 a.m. Say which one is fixed and which one can bend, or have the assistant interview you before it schedules anything. Then check its plan against those two conditions. If it treats pickup as movable, the plan fails however tidy the rest of it looks.

Once you have confirmed a preference, save it with its scope. A context block for the planner can hold the standing rules: pickup is fixed, and writing goes before 10 a.m. when the day allows. Each day's events still come from the calendar. Put the block where the assistant loads it, check that it does, and update it when a commitment changes. With the rules saved, a request as short as "Plan tomorrow" can work, because the rest of what the assistant needs is already available.

Build an AI context package for the task you do most

Pick a task you repeat that keeps needing the same background. Have the assistant gather the material and interview you about any gap that would change the answer. Keep standing instructions apart from facts that need refreshing on each run. When a result misses, compare it with the package and its sources: was a distinction absent, stale, contradicted, or ignored? Fix the part the evidence points to, then try the change on another case.

Build a reusable context package for your most common task

The assistant gathers the sources, checks, and confirmed preferences for a task you repeat, then plans a comparison with your usual request.

Copy the promptUse the copy button above the box.
Paste it in Claude or CodexMake sure your active project is enabled.
Answer the questionsGive clear answers so it understands what you want made.
Test it to see if it worksTry the output and refine until it does what you need.

Problem: A task I often do with AI depends on context I keep re-explaining or that the assistant does not have. Intent: I want a reusable context package for it and a plan to compare it with my usual request. Start with the task and any material already available here. Ask for what is missing: what the task should accomplish, my usual request, the records and examples it draws on, and who the result is for. Ask me to paste the material or tell you where to read it. Use short, focused questions to clarify preferences or limits I have not explained, and use my answers before you continue. 1. Gather the context from those sources. Mark each item as a fact from a source, a preference I stated, or an open question. Do not invent examples, facts, or personal preferences. 2. Draft a package with what this task needs: purpose, audience, constraints, examples, where to find sources, and a useful perspective if one helps. Follow the priorities I have stated. If two needs conflict and the priority is unclear, ask me to decide. 3. Separate standing instructions and preferences from facts that change. For each changing fact, name the source, the date or scope to use, and what to report if the source cannot be read. 4. Plan a comparison between my usual request and a request that uses the package. Keep the task and essential sources the same, list what changed, and say which difference in the output we will compare. If several details changed together, do not credit an improvement to any one of them. 5. Explain how a future session would load the package in the tool I use, and how I could check that it used the right information. Ask which tool I use if that is unclear. Flag material that is irrelevant, stale, contradictory, or outside the task's source scope. Show the proposed package, the open questions, and the comparison plan. Ask me to confirm the facts, preferences, and scope before saving a reusable version. Do not run the task or save anything in this exercise.

References

3 sources

1
Grounding Gaps in Language Model Generations View source
Omar Shaikh, Kristina Gligorić, Ashna Khetan, Matthias Gerstgrasser, Diyi Yang, Dan Jurafsky · 2024 · NAACL 2024; preprint first posted November 15, 2023
The tested model interactions showed less conversational grounding than human dialogue. The preference-training data the authors examined, the examples of preferred responses used to tune models, also reduced the grounding acts models generated, such as clarifying questions and acknowledgments.
These findings are a reason to check whether the assumptions behind a request have been settled. Asking the assistant to list its questions, or to interview you, brings those assumptions out; test whether the answers improve the result.
The results concern particular models, training setups, and datasets. They do not establish how every current model behaves, and they do not mean you must assemble all context by hand.
2
Navigating Rifts in Human-LLM Grounding: Study and Benchmark View source
Omar Shaikh, Hussein Mozannar, Gagan Bansal, Adam Fourney, Eric Horvitz · 2025 · ACL 2025
In the human–AI dialogue datasets studied, users made more clarification and follow-up requests than the assistants did. Human–human assistant dialogues supplied a comparison. Early grounding failures were associated with later breakdowns in the interaction.
When a request leaves an important decision open, check whether the assistant settles it with you before going ahead. One good clarifying question can save a draft built on the wrong assumption.
The datasets differ in tasks and participant roles, and the findings concern the models studied. They do not show how every current assistant behaves, or that asking more questions always improves an interaction.
3
2024 Work Trend Index View source
Microsoft, LinkedIn · 2024 · May 8, 2024
Respondents classified as power users were 49% more likely to report frequently pausing to ask whether AI could help, and 68% more likely to report frequent experimentation, compared with other respondents.
The survey describes habits to try as experiments in your own work. It does not establish that a pause itself improves output or that it measures expertise.
The power-user category was based partly on how often people used AI and how much time they reported saving. These self-reported associations are a snapshot from one point in time, not a causal study of how skill develops or a universal maturity ladder.