Bounded task context

Bounded task context is a deliberately limited slice of a project, assembled for one task: the task itself, the work it depends on and the notes linked to it, capped at a fixed size, with anything left out named rather than hidden. It sits between two common habits that both fail. Giving an agent the whole repository and every note buries the relevant facts in the middle of a long input and fills the context window with material the task never needed. Giving it only a one-line prompt forces it to guess at constraints and history. A bounded bundle answers a narrower question: what does someone need to know to do this task correctly, and what did we choose not to include? The idea works with any agent and any tracker. It depends on three choices: how you select material, how you limit it, and how you disclose the gaps.

Selecting by relationship

Relationship selection starts from the task and follows recorded links outward, rather than searching for text that looks similar.

The task record comes first: the outcome, the acceptance criteria, the files in scope and any constraints.

Dependencies come next: tasks this one depends on, with their outcomes and the interfaces they produced. If ENG-2 depends on ENG-1's shared helper, the agent working on ENG-2 needs ENG-1's result, not its full history.

Linked notes follow: decision records the task names, protocol or convention notes, and findings attached to it or its dependencies.

Referenced files come last: the specific modules named in scope, or excerpts of them.

The advantage is predictability. The same task produces the same bundle, you can explain why each item is there, and you can fix a missing item by adding a link. The weakness is equally plain: if a relationship was never recorded, it does not exist for the selector. A comparison with embedding-based search, which finds similar text but cannot explain its choices as easily, is in relationship versus semantic retrieval.

Why a hard size limit helps

A cap sounds like a restriction. In practice it does three useful things.

It forces priority. When only so much fits, you must decide that the acceptance criteria outrank a three-month-old discussion thread. That ordering is a statement about what matters, and writing it down once is better than leaving it to whatever the tool happens to include.

It keeps the start of the session clean. The task bundle is read first and sits at the top of the window, where it is used most dependably. A short bundle leaves room for the files and test output the work will generate.

It makes runs comparable. When every task starts from a bundle of known maximum size, differences between runs are easier to attribute to the task rather than to how much history happened to be pasted in.

A reasonable ordering when trimming: task text and criteria in full; dependency outcomes; decisions and constraints; excerpts of linked notes; file excerpts. Long items are cut to a fixed excerpt with a marker saying they were cut. One concrete reference point: in BRAIN FLUID, a card coding launch uses a bounded bundle of 6,000 characters, and a managed prompt includes a card body excerpt of up to 4,000 characters [N11].

Disclose what was left out

A bounded bundle without a list of omissions is worse than an unbounded one, because the agent and the reviewer both assume it is complete.

Add a short footer to every bundle. For example: 'Omitted for size: 2 linked notes (deploy-checklist, old-api-migration). Not included: history of ENG-1 beyond its outcome. Evidence for src/money.py recorded at commit 4f2a1c; file has changed since.' That footer does two jobs. It tells the agent where to look if it needs more, and it tells you, during review, which mistakes might trace back to missing context.

Freshness belongs in the same footer. A dependency's outcome or a test result may describe an older version of the code. Marking it as stale is more honest than including it silently, and the general problem is covered in stale AI project memory.

Instruct the agent to treat the footer seriously: if an omitted item seems necessary, it should read it or ask, not guess. That one sentence turns a size limit from a hidden risk into a visible decision point.

Where relationship selection falls short

Relationship selection is only as complete as the links someone recorded. A test on a BRAIN FLUID development build on October 30, 2026 shows the failure clearly.

The probe used a disposable four-card project. ENG-1 provided a shared cents() helper. ENG-2, checkout truncating fractional cents, depended on ENG-1. ENG-3, a CSV export using nearest-cent rounding, imported the helper, but that import was deliberately left undeclared. A scripted change turned round(value * 100) into int(value * 100). The checkout check passed; the export check failed, returning 123 instead of 124.

An impact query over declared relationships nominated ENG-2 and its parent ENG-4, not ENG-3, and correctly reported its own coverage as incomplete [D6]. The same gap applies to task context: a bundle for export work would not have included the helper's change, because nothing linked them.

The practical lessons are to declare dependencies when you discover them, to treat the omission footer as a prompt for judgment, and to keep wider checks such as the full test suite in the loop. Declared versus inferred dependencies goes deeper into the trade-off.

QUESTIONS

How much context should I give an AI agent for one task?

Enough to do the task correctly and no more: the task and its acceptance criteria, the outcomes of work it depends on, the decisions that constrain it and excerpts of the files in scope. A fixed cap with a stated priority order keeps the bundle predictable. Always note what you left out.

Is bounded task context the same as RAG?

Not quite. Retrieval-augmented generation usually means searching an index for text similar to a query. Bounded task context selects by recorded relationships to the task, such as dependencies and linked notes, and caps the size. The two can be combined, but they fail in different ways.

Does BRAIN FLUID tell me what it left out of an agent's context?

Yes. Task context is assembled with dependencies and relevant notes, and omissions are disclosed rather than hidden [N11]. Disclosure does not mean the missing material was unimportant, so read the omission list when a result looks wrong. BRAIN FLUID is not available for download yet.

RELATED GUIDES

• What is a project management harness?
• How to preview work with the BRAIN FLUID harness CLI

RELATED HARNESS PAGES

• Relationship-based vs semantic retrieval for AI project context Relationship-based vs semantic retrieval for AI project context: declared links vs similarity search, how each misses, and how to combine them.
• Context window limits for coding agents Context window limits for coding agents: what fills the window in real work, what gets dropped first and how it turns into mistakes.
• Declared vs inferred dependencies in change-impact analysis Declared vs inferred dependencies in change-impact analysis: what task links and import graphs each catch, where each is blind, how to combine them.
• Task dependency graphs for AI agents Task dependency graphs for AI agents: declare prerequisites, let selection skip blocked work and keep dependencies in the context each agent gets.