Context Engineering & Tool Efficiency Standards

Status: Active standard (advisory + eval-backed; specific items are CI-enforced — see “Enforcement”). Owner: Enterprise Architect persona / dpf-platform:dpf-architecture-review. Rationale of record: docs/superpowers/specs/2026-06-20-context-engineering-tool-efficiency-design.md (research, current-state evaluation, and the full principle derivation). Live client facts: docs/architecture/agent-client-capability-parity.md (refreshed monthly — clients change weekly).

This is the canonical reference for how DPF spends context and tokens across its three model-facing surfaces — the MCP tool registry, Build Studio (CLI agents + native local LLM), and AI coworkers. Consult it when tuning prompts, adding or changing tools, sizing context, or reviewing a spec that touches any of these. It is the operational form of Anthropic’s context engineering: find the smallest set of high-signal tokens that maximize the likelihood of the desired outcome.

Why this is a first-order constraint here (not a nicety)

DPF is local-first by founder strategy: cloud frontier models are disabled by choice and the platform is tuned for budget / small-GPU deployments. The binding constraint is therefore the served local window of ~24,576 tokens (RECOMMENDED_BUILD_CONTEXT_TOKENS), not a 200K cloud window. Three consequences shape every rule below:

The three laws

  1. Context is a finite resource with diminishing returns. Recall degrades as tokens grow (“context rot”). Default to removing, not adding.
  2. Smallest high-signal set. Optimize signal-to-token ratio in every block: system prompt, tool definitions, examples, history, results.
  3. Tool-selection accuracy collapses past a threshold. Few, consolidated, unambiguous tools beat many; keep exposed sets under the local cliff.

The standards (P1–P13)

Each is a rule + how DPF applies it. Items marked [ENFORCED] have an automatic guard; [REVIEW] are checked at architecture review.

Enforcement (how subsequent changes stay conformant)

The criteria apply to future changes automatically, not by memory:

  1. Runtime cap (P6). clampToolResultForModel bounds the native loop’s model-facing tool messages to a window-proportional cap (~10% of the known window, floored at 4,000 chars); the MCP route (/api/mcp/v1) bounds payloads to MCP_ROUTE_TOOL_RESULT_CHAR_CAP and no longer double-dumps data into both text and structuredContent. Truncation always carries a notice so the model knows to paginate/filter.
  2. CI guard (P5). tool-description-hygiene.test.ts fails the build if any tool’s model-facing description carries Phase N / (BI-…) provenance or a leaked source path. (Input-schema property descriptions may still carry format examples like e.g. BI-E4A86393.)
  3. Shift-left precheck (P5/P6). packages/dpf-skill-pack/hooks/tool-economy-precheck.mjs fires (Claude/Codex/Grok) when mcp-tools.ts, the MCP route, the agentic loop, or the budget module is edited, re-asserting these criteria before CI.
  4. Review tie-in. docs/architecture/agent-standards-dpf-conformance.md carries a Context Economy control area so spec/architecture reviews check P1–P13.
  5. Attachment budget on every model path. The per-turn tool-attachment budget (apps/web/lib/actions/coworker-tool-budget.ts — window-fit + local selection-cliff cap, load_tools deferral) applies to interactive chat AND to every autonomous run: scheduled tasks, dispatcher child threads, and remote MCP task submission all budget through resolveAutonomousWorkTools (BI-CAP-F2D39F8F). A coworker whose grants expand past the cap keeps full authority; the long tail loads on demand.
  6. Admission follows authoritative evidence scope and identity. scripts/gate-worktree.mjs lets an exact, clean, up-to-date documentation tree complete doc-index, link, and repository-guard evidence before the scarce local-integration-ci lease. For runtime trees, the planner’s integration tree, evidence-plan digest, and toolchain fingerprint form the server-derived claim identity. The executor alone owns the lease; subscribers observe the canonical run, and only fresh identity-matched terminal evidence is reusable. The CI evidence planner is authoritative; any stale base, non-documentation path, workspace-required document, planner uncertainty, or evidence mismatch routes to exhaustive verification or fails closed.

How to apply (quick checklist when changing a model-facing surface)