Give the agent the right context

IDEA 1

Context is a working set

Context is the information supplied to a model for its next response: instructions, relevant messages, tool descriptions, and selected observations. It is different from all the information an application stores. A note saved yesterday is not automatically in the next model call; the program must retrieve and include it.

Our lab replaces a model's token budget with a simple character allowance. This is an authored counting rule, not a tokenizer or an API bill. It lets you see a tradeoff clearly: keep the task's required facts first, and never silently omit one merely to make the pack look complete.

Stored is not supplied

1. Stored records. The app may have more information than one response needs.
2. Selection. Choose records the next step requires.
3. Working context. Only selected text fits into this pack.

Follow this authored example, then test the idea in the lab.

Read the example

const size = record.text.length;
const fits = used + size <= input.maxChars;

JavaScript string length is this exercise's character-cost convention. Real token accounting requires the actual model's tokenizer or reported usage.

Think it through: The app stored a note, but did not send it to the model. Can the model rely on it in that response?

IDEA 2

Retrieve when needed

Instead of putting every record into every request, a program can keep references and read the necessary records at the moment they matter. This makes information selection an explicit operation. It also creates a responsibility: a failed or missing read must be reported instead of replaced with a guess.

In this exercise requiredIds is an ordered list of source IDs that the task needs. Read each unique ID once. Add the record if the remaining allowance can hold it; otherwise put its ID in missing. Preserve that order, so an optional-looking but required constraint is not silently traded for unrelated background text.

Load a required fact

1. Reference. The task asks for the access rule.
2. Read. Load the real text for that ID from the fixture.
3. Account. Include it or explicitly mark it missing.

Follow this authored example, then test the idea in the lab.

Read the example

for (const id of input.requiredIds) {
  const record = tools.read(id);
  // Account for this required record.
}

The reference is lightweight. The read operation supplies the evidence and makes missing records visible.

Think it through: A required record does not exist. Which output is useful?

IDEA 3

Summarize carefully and check what was lost

A summary is another representation of evidence. It can reduce length while losing a crucial exception. If 'visitors need permission' becomes 'visitors welcome', the shorter text is not an equivalent replacement. A useful summary check asks which task requirements remain supported, not merely whether the sentence reads well.

Reflexion explores another kind of context: notes generated from feedback on earlier attempts. Those notes are supplied on a later trial; this does not update the model's weights. A useful note identifies a failure and a check to try next. Its explanation may still be wrong, so compare the next attempt with evidence.

For example, a club helper that omitted an access rule could retain: check every required source ID before calling the pack complete. Our lab tests that completeness rule with code; it does not generate reflections or verify summaries automatically. Keep the original source available for checking.

Shorter can lose a rule

1. Original. A condition changes what actions are allowed.
2. Bad summary. A short phrase drops the requirement.
3. Check. Required evidence must remain available or be marked missing.

Follow this authored example, then test the idea in the lab.

Read the example

return { ids, missing, used,
  complete: missing.length === 0 };

A completeness flag should be derived from missing evidence, not from whether the pack contains some text.

Think it through: A short summary drops a permission condition. Has it successfully compressed the task context?

Put it into practice

Read each distinct required record once, include it when it fits, and list any missing evidence.

1. Read the selected case and predict its expected result.
2. Run the starter once. Use the failed check and tool trace to locate the missing rule.
3. Insert the explained snippet at the TODO, then run the case again.
4. Test all three cases. Change the experiment input and explain whether the same rule still works.

Your next experiment: Increase maxChars from 7 to 8. Which exact evidence becomes available? Explain why this does not measure real model tokens.

Good context preserves the information the task needs and makes omissions visible.

Key terms

Context

The working information supplied for a particular model response.

Compaction

Replacing a longer history with a shorter representation while trying to preserve needed information.

Persistent memory

Information stored outside a current model call and deliberately retrieved later.

Sources and scope

Original Stemtiq teaching, reviewed 2026-09-14. The named researchers and organizations do not endorse this course. Classroom cases are authored exercises, not published findings.