The Model May Not Be Your Bottleneck

You ask an AI assistant to write a launch plan. It suggests a landing page, a social campaign and a webinar. The answer is organized, but it could belong to almost any company.

Before trying another model, look at what you gave this one. Did it know who buys the product? Why the last trial failed? Which feature is ready to ship? What the team can afford to do this month?

If those facts were missing, changing models leaves the same information gap. The next answer may be better written while still recommending the wrong plan. Checking the brief is a useful first step because it separates a problem you can fix by supplying information from one that needs a different model or approach.

A concrete brief changes the task

Consider a small team launching inventory software. This is an illustrative example. Its buyers are operations managers, the team has two weeks to prepare, and a previous trial stalled because the customer thought implementation would take too much of their time.

"Write a launch plan" gives the assistant none of that. A more useful request would be:

We are preparing a launch for operations managers at regional distributors. Our previous trial stalled over the work the customer expected to do during setup. We have two weeks and one person available for the launch. Use the attached trial notes and current product facts to propose a plan focused on that concern. Identify any capability we would need to verify before promising it. Return the recommended activities, what each one needs and what we would measure.

This brief makes it possible to recommend a setup demonstration, a clear account of the customer's responsibilities or another response to the actual objection. It also makes the output easier to judge. A plan that ignores implementation effort or depends on a large marketing team has missed something explicit.

No special phrasing supplies the missing facts. You still have to provide the notes and product information mentioned in the request.

Separate instructions from source material

Instructions explain what you want the assistant to do. Source material gives it something to work from. Mixing the two into a long, undifferentiated message makes later review harder: you cannot easily tell whether a conclusion came from a customer, an old planning document or your request.

For the launch example, label the current product facts and the trial notes separately. Date them. If an older plan conflicts with the current one, say which is in force. Keep proposed features distinct from released features so the draft does not accidentally sell a promise as a capability.

OpenAI's prompting guidance describes including relevant material when a task depends on private information or a chosen set of sources. Retrieval-augmented generation, or RAG, automates part of this process by finding material to provide with the request. The original RAG paper reported improvements over its comparison model on the tasks evaluated. That supports the value of retrieval in those settings; it does not make every retrieved answer correct.

You can apply the principle manually by attaching the right document. The retrieval system becomes valuable when finding that document repeatedly is itself a burden.

An example can clarify what instructions leave vague

"Make it direct" means different things to different writers. A short example can show the level of detail you expect.

For the launch plan, show one activity written with its purpose, required material and measure of success. Tell the model which aspects of the example to follow, rather than asking it to imitate everything. It can then use the same level of specificity for the other activities.

Providing examples in the input is commonly called few-shot prompting. The GPT-3 research paper evaluated this approach across tasks, with both strengths and limitations. For your own work, the test is whether the example reduces the errors you were seeing.

A larger input can contain a worse brief

Suppose you attach every launch document the company has ever produced. Some mention abandoned features. Others target a customer segment you no longer serve. The assistant now has more material and several competing accounts of what you are doing.

A larger context window provides room for input, but room alone does not resolve those conflicts. In Lost in the Middle, researchers found that the models they tested often performed worse when relevant information appeared in the middle of a long input. The paper reports results for particular models and tasks, not a fixed limitation of every future model.

The practical implication is to test whether the system can use the evidence you give it. Ask it to identify the source for its recommendation. Check whether it found the current trial notes or relied on the old launch plan. Remove irrelevant duplicates, while keeping enough of each source to interpret it correctly.

Anthropic's context engineering guide treats selecting and maintaining this information as an ongoing task. An agent may retrieve a document, inspect it and fetch more material as its question becomes clearer. That requires a way to find the right source, not just somewhere to paste a larger one.

Some missing sources were never documents

The implementation concern in our example might have been raised during an office visit. If nobody recorded or noted it, it will be missing from both the launch brief and the assistant's search results.

This is the part of the context problem Draki addresses. Its app can record conversations on its own and uses OpenAI cloud transcription after your permission. The public app does not automatically separate or recognize speakers. The optional bracelet keeps capture close at hand during the day; you can turn recording on or off whenever you want.

Draki offers an optional custom MCP connection for AI assistants that support remote MCP. Availability depends on the assistant and your account settings. The read-only connection lets an assistant retrieve the text and context you authorize for sharing. It can bring the recorded objection into the launch discussion, with enough of the original passage for you to check what the buyer meant. The ChatGPT and Claude connection guide shows how that access works and what the external assistant receives.

The assistant still needs instructions about the launch, and you still need to evaluate its reasoning. What changes is that the customer's account is available to the task.

Review the failure before choosing the fix

When an answer disappoints, identify one thing it got wrong and trace the cause.

If the assistant proposed a feature that is still in development, check whether the product facts made its status clear. If it missed a concern that was plainly in the supplied notes, check whether it retrieved and read the right passage. If it understood both and still made a poor recommendation, more background may not help; you may need a different method, more capable model or human judgment.

For recurring work, keep a small set of representative requests and the requirements that make their answers acceptable. Use them when you change the brief, retrieval setup or model. Then you can see which change improved the result, rather than treating a fluent response as proof that the problem is solved.

Sources

• OpenAI, "Prompt engineering", API docs.
• Patrick Lewis, Ethan Perez, Aleksandra Piktus, Fabio Petroni, Vladimir Karpukhin, Naman Goyal, Heinrich Kuttler, Mike Lewis, Wen-tau Yih, Tim Rocktaschel, Sebastian Riedel and Douwe Kiela, "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks", NeurIPS, 2020.
• Nelson F. Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni and Percy Liang, "Lost in the Middle: How Language Models Use Long Contexts", Transactions of the Association for Computational Linguistics, 2024.
• Anthropic, "Context windows", Claude Platform Docs.
• Anthropic, "Effective context engineering for AI agents", Engineering at Anthropic, 2025.
• Tom B. Brown et al., "Language Models are Few-Shot Learners", NeurIPS, 2020.