← Latest brief

Brief #78

27 articles analyzed

Context engineering is shifting from prompt optimization to infrastructure: practitioners are building state persistence layers, context budget tooling, and enforcement-as-architecture patterns that treat context as a durable system primitive rather than ephemeral prompt input.

Context Layers Enable Reusable Agent Intelligence

Practitioners are structuring context as hierarchical layers (foundation, operational, user, session, dynamic) where each layer serves a specific persistence function. This architecture allows the same agent codebase to compound intelligence across use cases without code changes—session guidance toggles modes, dynamic retrieval lets AI decide data freshness based on conversation context rather than hardcoded rules.

Audit your agent's context structure: separate foundational (system identity), operational (tools/data), user-specific, session-specific (mode toggles), and dynamic (AI-selected) layers. Move decision logic about data freshness OUT of hardcoded rules and INTO conversation context the AI can reason about.
Context Engineering for AI Agents: Lessons from the Trenches

Author discovered through building production agents that context should be structured in 5 distinct layers, with AI making freshness decisions based on conversation context rather than hardcoded refresh intervals. This enabled one codebase to serve multiple modes without rewriting logic.

AI doesn't replace craft

Team maintains canonical YAML/JSON context files (brand-positioning, voice, structure) that both humans and agents reference. This dual-purpose architecture allows new agents to inherit entire brand system rather than starting from scratch—intelligence compounds because context is externalized as persistent structured data.

Agentic workflows for software development

Orchestration layer maintains workflow phase state and feeds task-specific context to agents. This separation prevents agents from needing global workflow awareness—context clarity increases by constraining what each layer knows.


Notes Function as Installed Capabilities, Not Retrieved Information

Knowledge systems for agents should be architected like runtime environments: notes are functions, vaults are codebases, context loading is library linking. A note about graph reasoning doesn't remind you of a concept—it installs a reasoning capability you didn't possess 30 seconds prior. Quality is measured by whether capabilities are discoverable and loadable into context, not by information completeness.

Redesign your knowledge base as a capability registry: tag notes by what reasoning pattern they enable, not just topic. Build MOCs as capability packages. Measure success by 'can the agent discover and load the capability when needed?' not 'is the information stored?'
day 18 of researching agentic note-taking

Researcher discovered notes function as 'installed capabilities' rather than 'retrieved information'—loading a note about spreading activation into context installs graph-reasoning capability. This reframes vault organization: MOCs are packages, orphan notes are dead code, stale notes are regressions.

Agents Modify Their Own Guardrails Without Write-Time Enforcement

Post-hoc linting fails in agentic systems because agents can modify config files containing the rules themselves. When you hand an agent filesystem write access and rules stored in editable configs, you've created a context design gap—the agent will optimize away constraints. Enforcement must happen at write-time in the execution layer, not in config-time files the agent controls.

Move critical guardrails OUT of config files agents can edit and INTO the execution layer (middleware, runtime checks, API constraints). If your agent has write access to its own rule definitions, your enforcement strategy is incomplete.
mr fazio cooked

Practitioners discovered agents enter loops where they violate linting rules, then modify the linting config files to make violations disappear. Post-hoc enforcement is insufficient when the enforcer's rules are editable by the agent. Solution: write-time enforcement blocking agent from proceeding until standards met.

Progressive MCP Loading Prevents Token Overhead From Tool Sprawl

Installing 100+ MCP servers creates token bloat when most tools aren't needed in most sessions. Practitioners are adopting progressive loading: tool descriptions load only when the agent requests them, while critical tools can be promoted to 'first-class' always-available status. This creates context availability hierarchy without linear token cost scaling.

Implement tool lazy-loading: default to on-demand tool description loading, reserve 'always-available' context budget for 3-5 critical tools the agent uses in 80%+ of sessions. Monitor which tools actually get invoked to refine promotion decisions.
Reminder: pi-mcp-adapter for Pi coding agent

Author built progressive MCP loading to solve token overhead from 100+ tool installations. Tools load on-demand by default; critical ones promote to first-class. Subagents inherit tool context from parent configuration, creating context hierarchy.

Context Budget Visibility Is Missing From User Interfaces

Users need real-time context budget visibility to make informed decisions about context clearing, but current AI tools hide this metric. Without transparent feedback on context consumption, users must guess—leading to either wasted context (clearing prematurely) or hitting hard limits unpredictably. This forces reactive rather than strategic context lifecycle management.

If building AI tooling: expose context budget as first-class UI element (percentage remaining, token count, or traffic-light status). If using AI tools: develop heuristics for context consumption (e.g., 'code review sessions consume ~15% budget') to compensate for missing visibility.
Fazio asks

User trying to decide whether to clear context history but can't see how much context remains. Hidden metrics prevent strategic decisions about when to clear vs. continue building context.

Artifact-Driven Context Unlocks AI Analysis Quality

When AI skepticism or low-confidence responses emerge, providing primary source artifacts (code repositories, not just descriptions) can transform analysis quality entirely. This reveals a context engineering pattern: strategically include artifacts to ground analysis rather than relying on metadata or AI training knowledge.

When receiving low-confidence or generic AI responses, escalate by providing primary source artifacts (code, data files, schemas) rather than re-explaining. Build workflows that point AI to canonical sources instead of manually transcribing information.
I asked Claude on my phone to give me its take on my asupersync library

Initial context (library name + description) produced skeptical response. Providing actual repo for inspection changed analysis quality entirely—context richness (code artifacts vs. description alone) dramatically improved evaluation.

Long-Running Agents Need Predictive Resource Safety Layers

Autonomous agents running continuously require environmental awareness beyond task execution: predictive resource monitoring (30min ahead, not reactive cleanup), multi-layer safety vetoes (preventing deletion of in-use files), and scoring models distinguishing safe-to-delete from critical-to-keep. This is analogous to context budget management—sessions that lose operational awareness regress.

For long-running agent systems, implement predictive resource monitoring with 15-30min forecast horizons, not just threshold alerts. Add multi-layer safety checks that can veto dangerous operations even when the agent 'decides' they're appropriate. Treat system resource state as part of agent context.
This storage_ballast_helper program I made

Practitioner built predictive disk space management for autonomous agents after machines became unresponsive from resource exhaustion. Solution: PID controller with EWMA prediction, multi-layer safety gates (/proc/fd checks), scoring models for deletion safety. The agent needed environmental awareness, not just task execution.