Agent engineering isn't boring—the hard part has moved to deleting memory and not being annoying

Harrison Chase wrote on X that many content engineering challenges already have standard solutions, so some people say agent engineering is solved—or even boring. He admits that's partly true, but agent evolution will bring new, interesting problems. The original tweet and article are here: Harrison Chase's tweet, the article he mentioned.

The comments fill in that statement, and they are more concrete than the main post.

Sub-agents get only the what; the parent agent knows the why

A commenter, dimash, says most context engineering is just fixing things you broke yourself. The parent agent knows why; the sub-agent only gets what to do, then confidently solves the wrong problem. That description stings. When you split a task off to a sub-agent, you often leave the reasoning process, failure records, and constraints at the parent layer. The sub-layer sees a task description, lacks the context, yet delivers in a fully confident tone. It doesn't think it's wrong; it just doesn't know.

The hard part of memory is deletion, not storage

A commenter, ilmAI, says his agent reads a markdown wiki and does not connect to a memory plugin. Agents are good at adding pages and rarely go back to fix old ones, but they keep reading those old pages. Another commenter, Don Santo, says how agents store information is basically solved, but knowing what to throw away is still open. He adds that a good employee is defined by what does not make it into their file. That sentence is more useful than many architecture diagrams. Saving is addition; deleting is judgment. Addition has standard components; judgment does not.

There is no standard answer for long-task compaction

A commenter, Rohan, says that in long agent runs, deciding what survives compaction still has no standard answer, and every team ends up writing its own rules. Ordinary readers can understand compaction as compressing history midway through a long task and leaving only part of it for the model. What you keep and what you discard directly changes the mistakes the agent makes later.

Coordination and interruption are both boundaries

A commenter, Moriarty, describes a concrete scenario: two Claude accounts and two Codex accounts running on one Mac, and to keep them from entering the same file, you rely on a shared log plus a voluntary lock. The word 'voluntary' already explains the problem. Nick Woodhead also says that when making proactive suggestions, ignored suggestions should expire and not be recorded as the user skipping them. Otherwise the memory layer learns that the user hates things they never saw. Brian Cheong sums the problem up in one sentence: an always-on agent has to decide what to remember, what to ignore, and what to escalate. Reliability comes more from these boundaries than from another smarter loop.

Tom Daniel mentions another gap: automatic multi-agent team formation. Mainstream users will not assemble teams themselves; teams have to form on their own as the interaction unfolds. That judgment is worth looking at from the product side.

Luis Junior's reply is colder: when agent engineering becomes a recipe, the winner is the bakery owner, not the engineer. Each new model will swallow a batch of today's hard problems. That's true. Standard solutions will keep increasing. But being annoying, going stale, conflicting, and who to escalate to—these definitions live in the product, not in model parameters.

So agent engineering isn't boring. It has just shifted from building frameworks to managing a colleague who confidently makes mistakes. The hard problems haven't disappeared; they've moved to deleting memory, dividing tasks, fighting over files, and bothering people less.