PulseFlow Tecnologia
← Insights
·7 min read·technical-guide·context-engineering·ai-agents·caching
PulseFlow Tecnologia

How to build a context engineering workflow for agents

Designing an agent's context isn't about choosing what fits in the prompt - it's about systematically deciding what goes in, when it goes in, and what comes out. This guide draws on two real sources: the technical details Manus published about how it builds context in production, and OpenAI's harness engineering experiment, which documented what happens when an agent's context is poorly designed at scale.

Step 1: map everything that currently enters the context

Before optimizing anything, literally list everything that makes up the agent's prompt today: system prompt, conversation history, tool call results, attached files, project documentation. OpenAI's experiment shows why this mapping matters: the team discovered that architecture decisions discussed on Slack never showed up in the agent's context - they were as invisible to the agent as they'd be to a new hire on day one. Mapping existing sources is the only way to find that kind of gap before it turns into rework.

Step 2: classify by criticality and stability

Every context source answers two questions: is it critical for the task? and how often does it change? Manus uses exactly this distinction in practice: the prompt prefix (instructions, available tools) needs to be stable, because "even a single-token difference invalidates the cache" for everything that follows. Precise timestamps, for instance, are a classic classification mistake - they look harmless, but change on every call and break reuse of everything downstream.

Step 3: separate fixed context from dynamic context

Explicitly define what's fixed (architecture, conventions, available tools) and what's dynamic (current task state, result of the last action). Fixed goes in the stable prefix; dynamic gets appended, without touching what's already been processed.

Step 4: define how the agent retrieves information on demand

Instead of trying to keep everything inside the context window, define that the agent reads and writes files as external memory - the technique Manus calls "externalized structured memory." This avoids performance degradation in very long contexts and works around any window's size limit.

Step 5: define the compression strategy

When information needs to be summarized to fit, keep references (URLs, file paths) instead of raw content, so you can restore the original data later without losing it for good.

Step 6: prioritize conflicting sources

When two context sources disagree (outdated documentation versus a recent tool result), decide in advance which one wins. Without that rule, the agent decides inconsistently across runs.

Step 7: measure the cost of every context decision

The cost isn't abstract: with Claude Sonnet, a cached token costs $0.30 per million versus $3 without caching - 10x more expensive. Every context decision that breaks the cache (adding a tool dynamically, for instance, instead of masking it) carries that real cost.

Step 8: log the decisions, not just the result

Document why one source went into fixed context and another into dynamic - that becomes the basis for revisiting the decision later, instead of rediscovering the reason from scratch.

Step 9: build regression tests for context

Just like code, context design breaks silently when someone adds a new source without thinking about the impact on cache or compression. Regression tests catch that before production.

Step 10: review periodically

An agent's context isn't a one-time architecture decision - it shifts as the task shifts. Periodic reviews catch context that's become redundant, sources that stopped being updated, or patterns too repetitive, which Manus describes as a cause of "drift, over-generalization, or hallucination."

Sources