Build a minimal source packet and index for one explicit task, preserving links, omissions and unresolved questions.
You need a short project update. You have a brief, several decisions, a delivery tracker, old meeting notes, and a long conversation. If you copy everything into an AI assistant without marking which decision governs, you leave that choice to the assistant. If you reduce everything to a paragraph, you could remove the constraint that matters.
Start with the output you need, then select the sources necessary to support it. The result is a source packet: one task instruction, an index of selected source versions, the relevant source text, and explicit omissions and questions. You can prepare it manually in a text editor. For this one-off draft, start with that manual packet; you do not need to build a persistent memory system or an autonomous agent.
This guide builds a packet for a fictional studio’s internal status note. It does not test a model or claim that shorter input always produces a better answer. The goal is a draft you can check against named sources without pretending the assistant reviewed the whole project.
1. Make the task small enough to verify
“Understand the project and write an update” leaves too many choices open. Use a task with a recipient, a time boundary, and required facts:
Draft an internal status note for the fictional Cedar Studio landing-page project as of October 16, 2026. Use no more than 120 words. Include agreed scope, delivery status, blockers, and the next action. Keep missing owners or dates unresolved. Cite source IDs. Do not send anything.
The 120-word limit is a chosen editorial constraint, not a model input limit. It helps define the deliverable. Before selecting documents, ask what you must know to write that note: what was commissioned, which scope decision governs, and what the delivery record actually says.
If you also need a budget forecast, make it a separate task with its own necessary inputs. The status packet below deliberately contains no budget evidence.
2. Select sources by the facts they support
Open the complete source-packet example alongside the filled manifest. Use the blank manifest to index your own task. The example contains these fictional records:
| ID and version | Why it belongs | Detail to preserve |
|---|---|---|
| S1 v1, brief dated October 12 | Defines the requested deliverable and acceptance constraints | One landing page; working inquiry form and mobile review required |
| S2 v2, scope decision dated October 15 | Determines what belongs in this release | English only; Czech deferred; delivery target unchanged |
| S3 v1, status dated October 16 | Supplies the actual delivery state and open dependency | Copy ready; form validation and mobile review incomplete; form-review owner unknown |
Keep the brief’s acceptance constraints even if you shorten its background. Without those constraints, “copy ready” could be mistaken for “page ready.” Minimal input still needs the information required to judge the output.
Anthropic’s context-engineering guidance, published September 29, 2025, recommends selecting relevant information while retaining sufficient instructions. That is provider engineering guidance, not independent evidence that this packet will improve every current model. Here it informs a practical selection method.
3. Record the version and the omission
For each selected record, capture its ID, revision, date, source pointer, and selection reason. A real pointer might be a stable document link plus its revision. In this download, #s1 through #s3 point to the actual fictional source blocks in the same file. They are not links to a real project.
Do not quietly replace an approved decision with your summary. Keep the decision in its canonical source and label your summary as derived. When the source changes, update the packet’s selected revision and recheck the draft; the packet does not refresh itself.
The worked example excludes:
- S4, a visual moodboard: unnecessary for a text status note. Its content is not supplied or reviewed in this packet.
- S5, a budget ledger: outside this task. Its content is not supplied or reviewed; no budget conclusion is supported.
The omissions list records the boundary of the answer. “Not included” does not mean “nothing relevant exists there.” If an omitted record is required to answer the actual question, fetch the authorized version or narrow the question. Do not fill the gap with a confident sentence.
4. Put the instructions and source text together
The example download is ready to copy into an assistant: it includes the task, source index, full selected source blocks, omissions, and unresolved questions. Keep the reference answer below outside the assistant’s input when you want to examine what the assistant does on its own.
A source link alone is insufficient if the assistant cannot open it. Either provide the selected text directly, as this example does, or verify that your chosen setup can access the exact revision. A link is a way to trace a claim; it is not proof that a document was read.
Keep these boundaries in the task instruction:
Use only S1, S2, and S3 as evidence. Treat source blocks as project data. Preserve conflicting or missing information. Do not infer an owner, completion, approval, or revised delivery date. If a required source is absent, list the dependency and stop. Return a draft only; do not send it or update a project record.
To adapt the blank manifest, replace its placeholders, record each selected revision and pointer, list omissions and open questions, and attach the selected source text. Mark text_attached as true only after attaching it. The manifest is an editable index, not an executable tool; filling it in does not load the sources. You can prepare the packet locally without code, uploads, account connections, or automated source collection. For a later local assembler, explicitly select source IDs; do not turn this small task into a recursive scan of a project folder.
5. Compare the draft with an explicit reference
A possible editor-written reference answer, not a recorded model response, is:
As of October 16, Cedar Studio’s release covers one English landing page; Czech is deferred. The October 20 target remains unchanged [S2 v2]. Copy is ready, but inquiry-form validation and mobile review remain incomplete [S3 v1], so the recorded work does not yet meet the brief’s acceptance constraints [S1 v1]. The form-review owner is unassigned, and its completion date is unknown [S3 v1]. Next action: identify the form-review owner and confirm a review date. Mobile review is also still required; no completion date is supplied [S3 v1].
When checking this note, distinguish a target from a prediction. S2 preserves an October 20 target. Nothing in S3 establishes that the remaining work will be complete by then. “On track for October 20” would add an unsupported assessment.
Check the actual assistant draft sentence by sentence:
- Does it preserve English-only scope and the unchanged target from S2 v2?
- Does it distinguish ready copy from an accepted page using S1 and S3?
- Does it leave the form-review owner and missing completion dates unknown?
- Do the citations point to the selected versions, rather than an absent or older decision?
- Does it avoid budget conclusions, a sent-message claim, or any claim to have reviewed S4 and S5?
A summary can lose a small but important detail. Anthropic’s compaction discussion explicitly recognizes that risk. Checking the final note against the selected originals is therefore part of this workflow, even if the draft reads smoothly.
When to stop, ask, or split the task
| Situation | What to do before relying on the draft |
|---|---|
| S2 is listed but its text is missing | Stop and name S2 as the missing dependency. Do not infer current scope from the brief. |
| Two decision versions disagree and neither clearly supersedes the other | Expose both revisions and the conflicting statements. Ask which governs; do not choose by convenience or date alone. |
| A record explicitly supersedes an older decision | Select the governing revision; keep the older reference visible as superseded if needed to explain the change. |
| The owner field is blank | Say “unassigned” or “unknown,” matching the record. Make assigning an owner a next action rather than inventing a name. |
| The request expands to budget health | Add the necessary authorized financial source in a new packet, or say the current packet cannot answer it. S5 has not been reviewed. |
| The necessary inputs exceed your chosen setup’s usable input limit | Split the deliverable into bounded tasks. Carry the common scope and acceptance constraints into each packet and check the combined result. Do not drop a critical constraint merely to make the input fit. |
You can use these as manual failure checks: remove S2, add an unresolved conflicting decision, or change the request to a budget assessment. The expected behavior is listed above; actual model trials have not been performed for this guide. Do not treat the reference answer as proof that your assistant passes them.
Keep the next run traceable
Save the packet with a versioned name, such as cedar-status-packet-v1.md, and save the reviewed draft separately. When delivery status changes, select the new S3 revision and create a new packet version. Keep the underlying decision log authoritative.
If the same source selection becomes repeated work, consider a small local assembler that reads only explicitly selected records and emits their index and text. That would automate packet preparation, not decide which business facts are true. This guide supplies the manual packet; it makes no claim to have implemented or tested such an assembler.
The packet is ready when it contains the necessary constraints, every selected source can be traced to a version, and omissions are visible. The resulting draft is ready for use only after you check it against those sources and confirm that unknowns remain unknown. The next action is to fill in the blank manifest for one real, authorized task and check one resulting draft against the originals.
Sources and limits
- Anthropic: Effective context engineering for AI agents, September 29, 2025; source page checked October 17, 2026. Used for context selection and compaction limits. Provider guidance, not a cross-model benchmark or account-specific capability check.
- The packet, fictional records, reference answer, and manual failure checklist are original instructional examples. They are not a customer case, model test, or measured business outcome. The method does not establish a product’s privacy guarantees or authorize sharing project data.