A lot of content engineering challenges have pretty standard solutions, which has lead to some engineers saying agent engineering is solved/boring
True to some extent, but there are a bunch of (fun) new ones emerging as agents evolve! https://x.com/i/article/2116547440857718784
New context engineering challenges in late 2026
It feels like everyone is converging on the same agent architecture: an LLM, running in a loop, calling tools, running in a sandbox. Claude Code - perhaps the first high profile manifestation of this - came out over a year and a half ago. Deep Agents, our agent harness, launched over a year ago. This pattern has been building for a while.
There’s nothing bad with that convergence per se, but it has led to a sentiment among some AI engineers that I’ve talked to recently that “all the hard problems are solved” or “there’s no new AI engineering problems to solve”.
When people express this sentiment, I think they are largely talking about the context engineering practices we do to make agents work. And to some extent they are right - there are a lot of standard-ish context engineering solutions we’ve all arrived at:
- Summarizing long threads when it gets to be too much for the context window
- Offloading large tool call results
- Skills for progressive disclosure
- Tool search to deal with a lot of tools
- Subagents for context isolation
- Bash as a primary tool
The good news (for context engineering aficionados like myself) is that I think we’re seeing a step function change in agent capabilities, or at least how they are being used. Specifically, over the past few months every agent builder I’ve chatted with has been thinking about proactive, always on, goal-oriented agents. The core of this agent shares a lot of similarities with coding agents, but there are a set of new challenges as well. I highlight a few below. We (at LangChain, and in the industry) don’t necessarily have solutions (or at least, general solutions) for these, so thinking about these has been the most fun I’ve had in a while!
How to be proactive without being annoying: These proactive agents run in the background and either listen to event feeds or are woken up with heartbeats. On one hand, they need to be able to push things to the user - that creates a sense of helping. On the other hand, if you push too many notifications to the user, you risk overwhelming them. Calibrating this to be a delightful experience (not too much, not too little) is still a hard context engineering challenge!
Memory: memory for agents has been something we’ve talked with builders about for a while. Memory systems end up having two parts: the underlying data structure and an intelligence layer (agent) around the data. The data structures are often pretty simple (files, a single string). The hardest part of the intelligence layer is figuring out what to remember. Similar to proactiveness, it’s easy to mess up on either extreme (remembering nothing at all, or remembering way too granular of details). Since this intelligence layer that decides what to remember is often a (simple) agent itself, the context engineering around what to remember and when is still an open problem.
Async: These agents are getting longer and longer running, and interacting with other systems (tools, other agents) that themselves are longer and longer running. However, you almost always want to make sure the main agent interacting with the user is responsive to new messages. These combine to lead to an architecture where more work is getting done in asynchronous tools and subagents. This presents a set of new context engineering challenges: how do you notify the main agent when that work is done? How do you handle situations where the main agent is still running, vs when it has finished? What if it's paused waiting for human approval?
Goal Tracking: Agents are moving from doing tasks to working towards goals. Agents like Hone are a great example of this. How do you design agents that can break down goals into smaller steps, run experiments, get feedback, and continue to iterate towards a larger goal. It’s challenging to get agents to try out new experiments in pursuit of a goal (and not just repeat things). It’s challenging to get agents to think about broad goals and not just small tasks. It’s challenging to keep them consistent over long time horizons.
Alignment: Related to the above. Goal design is hard by itself. It will be very hard for users to design goals that agents can not cheat. If agents blindly try to optimize a goal - they may accomplish it, but they may cheat in ways that we cannot anticipate. For example: the classic example of “get rid of all bugs in codebase” → deletes codebase entirely (no code = no bugs). How do you design a harness to keep agents not only focused on goals, but not overly optimize for those goals.
Browser Use: For coding agents, the most important tool was a bash tool that could run and execute code. For a lot of these more general purpose agents, the browser is becoming that tool. A browser is a lot more complicated to drive than a terminal! Do you interact with images or with the DOM? Both are large objects - how do you manage context around that? Those are just some of the questions that pop up.
A few months ago I would have maybe agreed that there weren’t that many open questions in context engineering. But with these always on, proactive agents we are seeing a whole new set of challenges arise! What a time to be alive.