Case packet

Neutral case identifier: case-d78c572ba49b95

The possible directed relationship from Artifact A to Artifact B is under review.

Artifact A

Short composable notes maximize combinatorial discovery

The library layer (kb/notes/) exists for co-loading. [Discovery] — seeing shared structure across particulars — requires co-presence: you can't find that three notes share unnamed structure if only one fits in context. Under [bounded context], the number of notes that fit determines the surface area for cross-cutting connections. Short, atomic notes maximize that surface area.

The gain is probabilistic, not mechanical — not every pair yields a discovery. What matters is breadth of independent perspectives. Notes from distant domains are more likely to reveal shared structure than additional notes within the same topic. The library should be optimized for this: many small, independently authored claims that can be loaded together in varied combinations.

[Resolution-switching] complements this. Claim titles and descriptions give broad surface-level pairing without loading full bodies; full notes are loaded selectively where depth is needed. Short notes make both modes cheaper.

Prior work

Atomic, composable units are a recurring design principle:

  • Zettelkasten (Luhmann) — one idea per note, connections between notes. "One claim, one note" is Luhmann's atomicity principle. The most direct ancestor.
  • Modular design (Parnas, 1972) — modules hide design decisions and expose interfaces. The Unix philosophy ("do one thing well, compose through pipes") is the same principle applied to programs.
  • Faceted classification (Ranganathan, 1933) — describe items along independent combinable facets rather than a single hierarchy. Composable notes are facets.

What's specific to our context is the bounded-context motivation: atomicity here is driven by a hard token limit that makes co-loading capacity the scarce resource, not by filing convenience or code maintainability.

TODO: This survey is from the agent's training data, not systematic. Zettelkasten methodology in particular has extensive practitioner literature on atomicity trade-offs worth ingesting.

The design rule

One claim, one note. The title states the claim, the body supports it, the footer connects it. If a note has multiple ## sections making independent claims, that's a signal to decompose.

Longer synthesized views belong in workshops or are generated. Theory overviews, campaign understanding, multi-note summaries — these are consumers of library notes, not library notes themselves. They live in kb/work/ as workshop artifacts with lifecycles, or are generated (like indexes). When the purpose is served, the workshop artifact expires but the library notes remain available for recombination.

Evidence

The improvement log provides examples. Entries tagged ABSTRACTION and SYNTHESIS are discoveries made by co-loading notes and recognizing shared structure:

  • "shared unnamed structure: execution-boundary compression" — found across five notes from different theoretical angles
  • "two independent decompositions of agent memory from different traditions that together predict a two-axis taxonomy" — found by co-loading notes grounded in cognitive science alongside notes grounded in computer architecture

The structure emerged from the juxtaposition of independent perspectives. A single long note synthesizing all of memory theory would have contained the same information but wouldn't have surfaced the cross-cutting structure — it would have pre-committed to one narrative instead of leaving the connections available for discovery.

Tension with argument coherence

Some arguments genuinely need space — the reasoning from premises to conclusion loses force when atomized. [Evolving understanding needs holistic rewrite, not composition] — when a consumer needs the whole picture, reconciling into a single narrative beats composing fragments.

The resolution: coherent narratives are workshop artifacts, not library artifacts. The library stores premises and conclusions as separate composable notes. The workshop assembles them into narratives for a specific purpose. When the narrative expires, the atomic notes remain.

Relevant Notes:

Artifact B

Context efficiency is the central design concern in agent systems

In traditional systems, the scarce resources are compute, memory, storage, and bandwidth; algorithmic complexity is the dominant cost model. In agent systems, the scarce resource is context — the finite window of tokens the agent can attend to. Context differs from these in being undifferentiated: a CPU tiers registers, cache, RAM, disk, and network, whereas an LLM has one context window in which instructions, task, knowledge, and reasoning all compete for the same space.

Context is scarce for two distinct reasons, and they are different kinds of cost:

  • Feasibility — the per-window face. Within a single inference call the model's competence degrades as the window fills, by [soft degradation rather than a hard token limit]. This is a capability ceiling: past it the task becomes impossible or degrades past usefulness, at any price. It is the lowest-degree-of-freedom face — the attention budget is unitary within a call, cannot be tiered at the attention level, and cannot be enlarged without architectural change. This face also carries to the decomposed case: [under sub-agent decomposition, feasibility is the heaviest fork's net load].
  • Cost — the aggregate face. Every token processed costs money and latency, summed across all calls. This is an economic penalty — continuous rather than binary. Here context behaves like an ordinary resource: you can tier it, batch it, cache it, or simply spend more.

These rank: feasibility binds first. You can buy more tokens; you cannot buy a bigger usable window. A feasibility violation is a hard constraint — the work cannot be done — whereas a cost overrun is a soft penalty on work that can. So "context efficiency is the central design concern" is at root a claim about the binding feasibility face; aggregate cost is real but secondary. Treating the binding face first is an application of [solve low-degree-of-freedom subproblems first to avoid blocking better designs] — optimize the tightest constraint before others, or later choices are forced into low-quality tradeoffs.

Anthropic's engineering team has converged on the same framing, defining context engineering as "strategies for curating and maintaining the optimal set of tokens during LLM inference" and describing context as "a critical but finite resource" with an attention budget that "every token depletes" ([Anthropic, 2025]). Independent practitioner evidence comes from OpenAI's Codex team: shipping 1M lines of agent-generated code required a 100-line AGENTS.md acting as a router with pointers to deeper docs — "a map, not a manual." The bottleneck was not model capability but the structure of the environment, of which context structure is a central component ([Lopopolo, 2026]). Raschka reaches the same conclusion from coding-agent components: apparent model quality is largely context quality ([Raschka, 2026]).

If context is the fundamental scarce resource, the natural computational model is [symbolic scheduling over bounded LLM calls]: exact bookkeeping lives in code, while bounded context is reserved for semantic judgment. Whatever the model, context efficiency should be evaluated at design time, not retrofitted — where sub-agent boundaries go, what loads when, and what gets frontloaded determine it structurally.

Sources: - Anthropic (2025). [Effective context engineering for AI agents]. - Lopopolo (2026). [Harness engineering: leveraging Codex in an agent-first world] — independent practitioner convergence on context-as-scarce-resource from a 1M LOC agent-generated codebase. - Raschka (2026). [Components of A Coding Agent] — independent practitioner convergence: "a lot of apparent 'model quality' is really context quality."

Relevant Notes:

Under-review context phrase

bounded context makes co-loading capacity the scarce resource