Skip to content
Growth Method
Go back

Context Engineering for AI Agents: Why Less Beats More

Stuart Brameld

Stuart Brameld

Founder
Table of contents

We’ve written before about context engineering: the practice of building persistent knowledge, playbooks, and live tool connections so your AI stops starting from scratch. The lesson there was simple. Give the AI more of the right context and the output gets better.

So here’s an uncomfortable follow-up: for AI agents working unattended, the rule flips. The best agent systems deliberately give each run as little context as possible.

Both are true. Knowing which rule applies where is fast becoming the real skill.

More context makes agents worse

When you chat with an AI, you are the filter. You notice when it drifts, you correct it, you paste in what’s missing. An agent running overnight has no filter. Whatever is in its context window is its entire world, and that world degrades as it grows.

This isn’t a hunch. Anthropic’s own engineering guidance is blunt about it:

As the number of tokens in the context window increases, the model’s ability to accurately recall information from that context decreases.

There’s a cost problem stacked on top of the quality problem. An agent re-reads its entire conversation on every single step. If a long-running task carries weeks of accumulated history, you pay for that history again and again, and most of it is irrelevant to the step at hand. A task that should cost pennies quietly costs pounds, and the agent reasons less clearly for the privilege.

The fix the industry has converged on is not better summarising or cleverer prompts. It’s structural: break long-running work into stages, give each stage a fresh, focused context, and pass what matters between stages through a shared record rather than a shared transcript.

The pattern is everywhere once you see it

This is how serious software has modelled multi-stage work for years, well before AI agents existed.

GitHub Actions runs your deployment pipeline as separate jobs, each with its own log and its own pass-or-fail status. Jobs hand work to each other through saved artifacts, never by reading each other’s logs. The pipeline page that shows you one continuous run is a view assembled on top.

Stripe records everything that happens in your account as discrete, immutable events. The activity feed you scroll is assembled from those records at display time. Zapier logs every automation run step by step, with the exact data in and data out of each step, stitched into one inspectable story.

The AI world landed in the same place. Anthropic’s multi-agent research system, the architecture behind Claude’s research feature, runs subagents in their own separate context windows and has them return condensed findings, precisely because one ever-growing transcript would be slower, dearer, and less accurate. Agent frameworks like LangGraph pass structured state between steps rather than raw chat history.

Separate records per stage. State passed through structured artifacts. One timeline view on top. Nobody who runs multi-stage work at scale chooses the ever-growing log.

What this means for a marketing campaign

Think about what an autonomous agent actually does across a campaign’s life. It researches your data and drafts an idea. Later it writes the plan. Later still it launches, working in your connected tools. Weeks after that, it pulls the results and writes up what happened.

Those are four different jobs, weeks apart, needing four different slices of context. The analysis run does not reason better for having every search result the research run skimmed in June. It needs the campaign itself: the hypothesis, the plan, the baseline numbers. Everything else is expensive noise.

So the campaign record, not the chat transcript, should carry the story forward. Each stage reads the campaign fresh, does its job, and writes its findings back. That’s the agent-world equivalent of the persistent knowledge base from our first article: durable, structured context that compounds, instead of a transcript that just gets longer.

This is exactly how custom agents in Growth Method work. Every phase of a campaign runs in its own conversation: one for creation, one for planning, one for launch, one for analysis. Open any of them and the campaign’s earlier conversations appear above it, read only, so the whole campaign still reads as one story. The campaign page lists every run with its date, its query count, and the data sources it touched.

The audit dividend

Here’s the part that matters most if you’re the one accountable for what an autonomous agent does: small per-stage records don’t just make agents cheaper and sharper. They make them auditable.

When every stage keeps its own record, every question you’d want to ask has a specific answer. What did the launch run actually do? Which data sources did the analysis consult, and how many queries did it make? Did a person approve that change, or did the agent act alone? Which stage failed, and which stages succeeded? One long shared log blurs all of this together. Discrete records answer it per stage, the way a pipeline tells you exactly which job broke.

One principle does the heavy lifting: the record must come from what the system observed as the agent worked, never from the agent describing its own work. An agent that grades its own homework will occasionally grade it generously. In Growth Method, the ran-autonomously markers, the query counts, and the consulted data sources are all derived from what actually executed. And where a count can’t be known precisely, we show no number rather than a wrong one.

Questions to ask any agent platform

If you’re evaluating agentic tools, this gives you a short, revealing checklist:

  1. Does each run keep its own record, or does everything append to one growing log?
  2. Is the history you see assembled from records, or is it the storage itself? Views can improve; storage mistakes are forever.
  3. Are the audit markers observed or self-reported? Ask the vendor directly how they know an action ran autonomously.
  4. Can you see which data sources each stage touched, and what it did in your connected tools?
  5. When a run fails, can you tell which stage failed without reading a full transcript?

A platform that can’t answer these is asking you to trust the agent’s own account of its work. That’s not a trust model. It’s a hope model.

The bottom line

Context engineering has two halves. Build deep, durable context your AI can draw on: your positioning, your playbooks, your live data. Then ration it ruthlessly per run, so each unit of work carries only what it needs and leaves behind a clean, observable record.

The onboarding analogy from our first article still holds, with one addition. A well-briefed new team member gets proper onboarding, clear processes, and the right tools. What they don’t get is the entire company history read aloud before every task. You brief them on the task at hand, they do the work, and the work leaves a paper trail.

That’s what good agents look like too.

Growth Method is the GrowthOS built for marketing teams focused on pipeline — not projects. Get started with a 30-minute call.

We are on-track to deliver a 43% increase in inbound leads this year. There is no doubt the adoption of Growth Method is the primary driver behind these results.

Laura Perrott, Colt Technology Services

Further reading


Back to top ↑