Context engineering for AI agents

Prompt engineering asks how to phrase the request. Context engineering asks a harder question. What should the agent be able to see when it starts, and where does that come from on every run, not just the demo run? Teams that run coding agents daily converge on the same answer. The prompt matters less than the material behind it, and assembling that material by hand is the part that doesn't scale.

We build Modem, which sells a context layer for agents, so we have an obvious stake here. The practice stands on its own, and most of it you can do without us.

What context engineering is

An agent's output is bounded by its input. Ask Claude Code "fix the export bug customers keep hitting" and its answer depends entirely on whether it can see which customers, which export, which error, and what was already tried. Context engineering is the discipline of making sure that material is available, current, and appropriately sized. In practice it covers three decisions.

What to include. The relevant slice, not everything. A merged summary of the bug with the affected accounts beats forty raw Slack messages.

How it gets there. Pasted into the prompt by a person, retrieved from files in the repo, or pulled live by the agent through a tool call. Each has a different staleness profile.

What persists. Session context evaporates when the run ends. Anything the agent should know next week has to live somewhere durable that the next session can reach.

The context window is not memory

The context window feels like memory while a session is open, which is why teams keep treating it as one. It fails the role in two ways. It is finite, so a long session starts dropping the early material exactly when the accumulated understanding was getting useful. And it is private to the run, so the Cursor session that diagnosed a bug yesterday shares nothing with the Claude Code session fixing it today.

The fix is boring and structural. Keep durable facts outside the agent, in a store built for them, and let each session pull what it needs. That's the same conclusion the agent memory literature reaches, and it's why the interesting question moved from "how big is the window" to "what feeds it."

Curate, don't cram

Bigger windows made cramming possible, not effective. Published tool-use benchmarks show selection accuracy degrading as you pile servers and documents into context, and anyone who has watched an agent burn its window re-reading a pasted thread dump has seen the mechanism firsthand. The window an agent spends holding raw input is a window it can't spend on the work.

Curation means the agent receives conclusions with the evidence attached, not the raw feed. "Twelve customers hit the 25k export timeout, eight on the enterprise plan, quotes attached" is a few hundred tokens. The Discord threads, Zendesk tickets, and call transcripts behind it are tens of thousands. The agent needs the first form, with the option to drill into the second.

Customer context is the hard part

Code context is largely solved. The repo is right there, greppable, and every coding agent ships with file search. Customer context is the opposite case. It lives in Slack, Discord, support tickets, and sales calls, in fragments that duplicate and contradict each other, and it goes stale weekly. Nobody greps a Gong call.

This is where hand-curation dies. Somebody has to merge the duplicates, link the reporters to their accounts, and keep the summary current as new reports arrive, per topic, forever. That's the job Modem automates. It reads the connected channels continuously and maintains a customer context graph linking topics, people, and companies, with the original quotes attached, so the curated form exists before any agent asks.

Wiring it up

Three connection paths, in order of how often teams use them.

MCP. Register the Modem server once and every session can query the graph. In Claude Code that's one command. claude mcp add --transport http modem https://mcp.modem.dev/mcp. Cursor, Devin, and any MCP-compatible agent register the same endpoint through their own flow. The search_modem tool answers a question directly against the workspace, and the agent-run tools proxy to the same Modem agent the team uses in Slack.

CLI. For scripts and CI, the @modem-dev/cli package on npm wraps the public API. The binary is modem.

A note in the repo. A line in your CLAUDE.md or agent instructions ("customer feedback lives in Modem, query it over MCP before guessing what users want") turns the connection into a habit instead of something a person has to remember to invoke.

The honest caveat is that a context layer only knows what you connect. If half the feedback arrives through a channel Modem never sees, the graph undercounts it, curated or not. Start with the two or three channels where most of your customer signal lands, and check the integrations list covers them before you build the workflow.