---
title: 7 practical context engineering techniques you can use right now
canonical: "https://agenticup.dev/posts/7-practical-context-engineering-techniques/"
pubDate: "2026-07-06T00:00:00.000Z"
description: The papers talk about context engineering as a harness problem. But the highest-impact techniques are things you can do in the chat right now. No infrastructure changes needed.
tags: [ai-agents, context-engineering, prompt-engineering, agent-harness]
---

**TL;DR:** The papers define context engineering as a harness problem. Build a runtime that routes, budgets, and compresses context. But the highest-impact techniques are things you can do in the chat right now. Seven techniques, each costing under 100 tokens, each saving thousands. No infrastructure needed.

> **Key takeaways:**
> - The 4 pillars of context engineering (write, select, compress, isolate) are not just harness concerns. You apply them through how you structure your prompts and sessions.
> - Selection is the highest-impact pillar because it prevents data from ever entering the context window. Tokens that never arrive cost nothing.
> - The single most effective technique: provide a file tree and recent git log before asking the model to debug something. 50 tokens in, 2000+ tokens saved.
> - Manual summarization between sessions is a working compression pass. No harness needed. Just a 100-word bookmark.
> - Explicit turn budgets change how the model paces itself. State "15 turns for this task" upfront and the model allocates its attention differently.

The first time I shipped an agent without any context management, it burned 47 tool calls and $12 on a task that was impossible from the start.

I did not blame the agent. It was doing exactly what I told it to do: try until it succeeds. What I had not done was tell it what information to look at first, how deep to go, or when to stop exploring. The agent was not the problem. The context was.

Here is what I learned. Context engineering is often presented as a harness problem. Something you solve by building a runtime that routes tool outputs to buckets, enforces token budgets, and runs compression passes. That infrastructure matters, and teams building production agent systems should invest in it.

But the highest-impact context engineering techniques are things you can do in the chat right now, with no infrastructure changes. They cost under 100 tokens each. They save thousands.

## How the four pillars apply at the chat level

Before the techniques, the framework. The context engineering literature (from the [ACE paper at ICLR 2026](https://arxiv.org/abs/2510.04618), [Vishnyakova's formalization](https://arxiv.org/abs/2603.09619), and [Anthropic's engineering guide](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)) converges on four pillars. Here is what they mean when you are sitting in a chat session with an AI agent, not building a harness.

**Write** is how you structure your system prompt. Tagged sections, clear boundaries, explicit token budgets per section. You write the instructions once, the model organizes its mental model around your structure.

**Select** is what you tell the model to read and in what order. This is the highest-impact pillar because it prevents data from ever entering the context window. Tokens that never arrive cost nothing, consume no attention budget, and cannot cause lost-in-the-middle degradation.

**Compress** is dropping old context and replacing it with a summary. The model cannot delete tokens from its own context. But you can. Every time you paste a 100-word bookmark instead of continuing a 50-turn thread, you have run a compression pass.

**Isolate** is keeping separate concerns in separate sessions. Debugging auth and designing a landing page should not share a context window. New session per concern. File-level gates for cross-references.

The seven techniques below are organized by pillar. Each one includes a concrete example, an explanation of why it works, and the token economics.

## Technique 1: The three-line debug preamble (Select)

**Here is how it works:** Before you ask the model to debug anything, paste three lines.

```
Error: <paste the error message>
Relevant file: <path to the file>
Recent commits:
<git log --oneline -5 -- <path>>
```

**Why it works:** Without these three lines, the model has to guess. It reads the file tree to find the relevant file. It reads the file to understand its structure. It may read outdated code that was rewritten yesterday. Each guess costs a tool call and fills the context window with noise. With the preamble, the model starts with the exact error, the exact file, and the recent change history. It makes its first tool call on the right target, not a wrong one.

**The catch:** The preamble only works if you provide accurate information. A wrong file path or a misleading error message sends the model in the wrong direction faster than providing nothing at all. Verify your inputs before you paste them.

**Token cost:** 50 tokens. **Token saved:** 2000+ tokens of wrong-file exploration. **Leverage:** 40x.

## Technique 2: The first 30 lines rule (Select)

**Here is how it works:** Every time you ask the model to read a file, add this to your instruction.

"Read the first 30 lines of `<file>`. Stop. Tell me if this is the right file. I will confirm before you read more."

The model reads a snippet, reports back, you confirm or redirect. This single constraint stops the model from reading 400-line files when the bug is in a different file entirely.

**Why it works:** Models are eager to be helpful. When you say "fix the bug in auth.ts," the model reads the entire file because it wants to understand the full context before making a change. But most bugs localize to a specific function, and reading the whole file first is wasteful. The 30-line constraint forces the model to verify it is in the right place before committing to deeper exploration.

**The catch:** Some files need wider context. If the bug involves cross-file state or a multi-function flow, 30 lines may not be enough. Use this technique for initial exploration, not for deep debugging.

**Token cost:** 10 tokens. **Token saved:** 1000+ tokens of unnecessary file reads. **Leverage:** 100x.

## Technique 3: The grep redirect (Select)

**Here is how it works:** When the model says "let me read this file," redirect it to search instead.

Instead of "Read auth.ts," say "Search auth.ts for `token` and `expir`. Only read the lines around matches."

The model uses grep instead of reading end-to-end. It gets the specific lines that match the pattern instead of the entire file.

**Why it works:** Models default to reading entire files because that is the obvious tool call. But most debugging tasks only need a few specific lines. The function that handles token expiry, the import that brings in the authentication middleware. Grepping narrows the search space before the model commits to reading. The model still has the option to read more if the matches are not sufficient, but it starts with signal, not noise.

**The catch:** Grep depends on having good search terms. If you do not know what to search for, let the model read the first 30 lines first, then grep for symbols it finds there.

**Token cost:** 20 tokens. **Token saved:** 2000+ tokens of full-file reads. **Leverage:** 100x.

## Technique 4: The session bookmark (Compress)

**Here is how it works:** Before you end a session or switch tasks, write a structured bookmark.

```
BOOKMARK
State: <what is done, what is pending>
Key decisions: <3-5 bullet points>
Open questions: <any>
Next action: <single concrete step>
```

Start your next session by pasting the bookmark as the first message. The model picks up exactly where you left off.

**Why it works:** A 50-turn debugging session accumulates context that is detailed but increasingly irrelevant. The first 40 turns established the problem, explored wrong paths, and converged on a fix. The next session does not need the exploration. It needs the conclusion and the next step. The bookmark is a compression pass. It drops 3000+ tokens of raw exploration history and keeps 150 tokens of structured state.

**The catch:** Bookmarks work across sessions but not within them. If you paste a bookmark mid-session, the model treats it as new information alongside the existing context, doubling instead of compressing. Use bookmarks at session boundaries.

**Token cost:** 150 tokens. **Token saved:** 3000+ tokens of stale exploration history. **Leverage:** 20x.

## Technique 5: The three strikes close (Isolate + Compress)

**Here is how it works:** When a task is going in circles, type this.

```
Three attempts. No progress. Close this loop.
Summary of what we tried:
1. <attempt 1 failed because>
2. <attempt 2 failed because>
3. <attempt 3 failed because>
Blocked by: <reason>
Suggested next: <one concrete path>
```

This is a stopping policy in practice. It prevents the session from burning 30 more turns retrying approach 1 with slightly different wording.

**Why it works:** The CONVOLVE paper on Agentic Abstention shows that agents struggle to stop when a task is not working. They generate plausible next steps like "let me try a different approach," "let me check the documentation". Those keep the loop running. Humans do the same thing with AI agents. The three strikes rule adds an explicit stopping criterion. After the third failed attempt, the session closes the loop instead of spiraling. The insight from CONVOLVE applies here: stopping is a separate policy from task execution, and it needs to be explicit.

**The catch:** Three strikes is a heuristic, not a rule. Some problems genuinely need four or five attempts. Use your judgment. The purpose is to prevent infinite loops, not to enforce rigidity.

**Token cost:** 100 tokens. **Token saved:** 5000+ tokens of futile retries. **Leverage:** 50x.

## Technique 6: The explicit budget declaration (Write + Compress)

**Here is how it works:** At the start of a complex task, tell the model how many turns it has.

```
This session has a budget of 15 turns. After turn 15, we stop and assess.
Turn 1-5: Investigate.
Turn 6-10: Implement fix.
Turn 11-15: Test and verify.
```

**Why it works:** The ACE paper demonstrates that agents with explicit context budgets make better decisions about what to keep and what to drop. The same principle applies at the session level. When the model knows it has 15 turns total, it paces itself. It does not spend 10 turns exploring irrelevant tangents because it knows it has 5 turns left to ship. The budget changes behavior on both sides. You structure the task more carefully, and the model executes more efficiently.

**The catch:** Rigid budgets break on genuinely complex tasks. A task that needs 30 turns should get a 30-turn budget, not a squeezed 15-turn budget. Set the budget based on the task, not on a fixed number.

**Token cost:** 50 tokens. **Token saved:** 1000+ tokens of scope-creep exploration. **Leverage:** 20x.

## Technique 7: The artifact handoff (Write + Isolate)

**Here is how it works:** For multi-file changes or multi-step plans, write the plan to a file instead of keeping it in the chat.

"Write the implementation plan to `<path>`. I will read it in the next session."

The file persists across sessions. The chat does not. When you start a new session, the plan is one `read_file` call away instead of 50 turns of scrolling.

**Why it works:** Chat history is ephemeral and expensive. Every turn adds to the context window, and the model's attention budget degrades with length. A file is persistent, cheap, and structured. Writing the plan to a file also forces you to be precise. The model needs to produce something that makes sense without the surrounding conversation context. This clarity benefits both the model and the human.

**The catch:** File paths and formats need to be consistent across sessions. If you write to a random path each time, the file becomes noise instead of signal. Use a convention like `.hermes/plans/<task-name>.md` or similar.

**Token cost:** One write call. **Token saved:** 5000+ tokens of re-explaining across sessions. **Leverage:** effectively infinite for cross-session work.

## The cheat sheet

|| Technique | Pillar | Tokens spent | Tokens saved | Impact ratio |
|---:|---:|---:|---:|---:|---:|
|  1 | Three-line debug preamble | Select | 50 | 2000+ | 40x |
|  2 | First 30 lines rule | Select | 10 | 1000+ | 100x |
|  3 | Grep redirect | Select | 20 | 2000+ | 100x |
|  4 | Session bookmark | Compress | 150 | 3000+ | 20x |
|  5 | Three strikes close | Isolate + Compress | 100 | 5000+ | 50x |
|  6 | Explicit budget declaration | Write + Compress | 50 | 1000+ | 20x |
|  7 | Artifact handoff | Write + Isolate | file write | 5000+ | effectively infinite |

The throughline across all seven: stop the model from exploring before you know what it needs to find. Selection is the only compression that costs zero tokens, because the data never enters context in the first place.

## Why these techniques matter more than they look

The context engineering papers describe what a harness should do. The ACE framework treats context as an evolving playbook with three specialized roles. Vishnyakova formalizes five quality criteria. Relevance, sufficiency, isolation, economy, provenance. These are important frameworks. They are also infrastructure work that takes weeks to build and deploy.

The seven techniques above are what you can do in the chat while you wait for that infrastructure. You are the router. You are the budget enforcer. You are the compression pass. The model follows because you structured the interaction, not because the runtime handles it.

The habit that beats everything else: after every 5-10 turns, type "summarize what we have done and what is next in under 100 words." Read it. Then paste it back as the opening of your next prompt. That is write (you structured the summary), select (you chose what to keep), compress (you dropped 2000+ tokens), and isolate (you closed the previous loop). All four pillars in one habit. No harness required.

## FAQ

> **What is context engineering?**
> Context engineering is the discipline of designing, curating, and maintaining the set of tokens passed to an LLM at inference time. It covers system prompts, tool outputs, retrieved data, message history, and agent notes. Everything that fills the context window.
>
> **How is context engineering different from prompt engineering?**
> Prompt engineering optimizes the wording of a single query. Context engineering designs the entire informational environment in which an agent makes decisions. Including tool outputs, memory, policies, and prior-step history.
>
> **What is the cheapest context engineering technique?**
> Providing a file tree and recent git history before asking the model to debug something. It costs under 100 tokens and prevents thousands of tokens of wrong-file exploration.
>
> **Can I compress context without a custom harness?**
> Yes. The simplest technique is manual summarization: after every 5-10 turns, ask the model to summarize what happened, then paste the summary as the opening of your next prompt. This drops 2000+ tokens of raw history in exchange for 100 tokens of structured summary.
>
> **What is selection in context engineering?**
> Selection is deciding what information enters the context window before the model acts on it. The most effective selection technique is specifying a narrow search path in your instructions. "Read the first 30 lines," "grep for the symbol," "check git log first." Instead of letting the model explore freely.

## Related Posts

- [How to write project instructions that AI agents actually follow](/posts/write-project-instructions-ai-agents-follow/). Agents form a plan from training data before reading your instructions. The fix: invalidate the wrong path, not describe the right one.
- [Your agent needs policy gates, not just prompts](/posts/ai-agent-policy-gates/). Why policy-based guardrails outperform prompt instructions for controlling agent behavior.
- [The 15 jobs of an agent harness](/posts/agent-harness-15-jobs/). What an agent harness needs to handle. Including context management and stopping conditions.
- [Bigger Agents Are Worse at Knowing When to Stop](/posts/agentic-abstention-bigger-agents-worse-at-stopping/). The CONVOLVE paper on agentic abstention and why stopping is a separate policy from task execution.

---

<div class="callout"><p><strong>Agent mode:</strong> Context engineering is what you do before the model acts. Structure your instructions with file trees, git history, and turn budgets. The model follows the constraints you set. Set them before it starts exploring.</p></div>

This article was published on Agentic Up (https://agenticup.dev): practical guides for developers and founders building with AI agents. Reach me at hello@agenticup.dev
