Context engineering needs a context engine

One of my highlights from last week was speaking at WeAreDevelopers about context engineering.

My argument was simple:

As LLMs get stronger at reasoning and tool calling, the bottleneck shifts from:

Can the model do this?

to:

Can we get the right context to the model at the right time?

Longer context windows help, but they do not remove the need for good context engineering.

Models can still struggle with problems like “lost in the middle”, where they do not use every part of the context window equally. More context also means more latency, more cost, and more work for the system.

So “just put everything in the prompt” is not a strategy.

The teams that get this right will treat context engineering as its own discipline:

• How do we help agents find the right context?
• How do we retrieve it from wherever it lives?
• How do we make context improve with usage?
• How do we keep it fast and cost-efficient?

My view is that context engineering needs a context engine: an abstraction layer between agents and the data they need to act.

That data might be structured data, unstructured data, APIs, state, history, memory, search, or caching. The agent should not need to know every place context lives before it can do useful work.

A lot of the talk focused on agent memory.

Not just chat history, but things like user preferences, goals, past actions, learned knowledge, and what worked.

The part I am still thinking about is this:

What if agents did not only learn from user interactions?

What if they learned from their own runs?

Most teams already collect agent traces, but those traces are often used mainly for human debugging when something breaks. I tried a small experiment with a browser agent for job search: extract learnings from prior traces, inject those learnings into future runs, and see what happens.

The result: about 28% cheaper, fewer steps, and around 30% faster.

Small experiment, but it points to a bigger question:

Are agent traces just debugging artifacts, or are they the raw material for the next layer of agent memory?

The hallway conversations after the talk were just as interesting. One person pointed me to Anthropic’s work on J-space and the Jacobian Lens, which explores ways of inspecting parts of a model’s internal workspace for reasoning that may not appear in the output.

Pair that with ideas like memory consolidation or “dreaming”, and it feels like we are still early in understanding how agents should learn, remember, forget, and improve over time.

My current takeaway:

The next big leap in agent reliability may not come only from bigger models.

It may come from better context systems around them.

For anyone exploring this space, Redis has a good starting point on Iris and the idea of a real-time context engine: Context is all you need.

What should agents be allowed to remember about users, tasks, and their own behavior?