Agents Are Starting to Assign You Work—Don't Get Too Excited Yet

Sydney Runkle posted the slides for a talk on “proactive agent engineering” on X. The core judgment is straightforward: the direction of tasks will change. In the past, people assigned tasks to agents; next, agents will assign tasks to people. In her tweet, she calls this a shift and points out that it requires a step change in memory and UX. The slide deck is here: https://docs.google.com/presentation/d/1VbC01MaG_YjALvag9v1NX00GjU7LaXMq54I1JdlFcPE/edit?usp=sharing . Original tweet: https://x.com/sydneyrunkle/status/2120268734925529120

This judgment is worth unpacking. A proactive agent is not just another auto-reply in a chat box. It usually runs in the background, listens to event streams, or is woken up by a heartbeat, and can push information proactively. For ordinary users, the experience will feel a lot like an assistant that is always online and will interject. For developers, that is also where the trouble lies: getting an agent to do things is not hard; the hard part is knowing when it should show up and when it should shut up. Harrison Chase spells it out clearly in a LangChain blog post. For a while now, context engineering has had a set of common practices: summarizing long conversations, moving large tool results out, using Skills for progressive disclosure, tool search, subagents to isolate context, and treating Bash as the primary tool. These practices make agents run. Proactive, always-on, goal-oriented agents bring a new set of problems. Blog link: https://www.langchain.com/blog/context-engineering-challenges-late-2026

The first hurdle is being proactive without being annoying. A proactive agent needs to be able to push; too little pushing is unhelpful, while too much is harassment. That balance is very hard to tune. One user under Sydney’s tweet said that an agent must remember that it has already been told “no”; otherwise it will nag every day about the same ticket. Another reply was sharper: a proactive agent that forgets you said no is just a cron job with opinions. Harsh, but it points to a real pain point. The data layer of a memory system may be very simple—a file or even a single string may be enough. The hard part is the intelligence layer: deciding what is worth remembering. Remember too little and it feels like amnesia; remember too much and it feels like surveillance. Refusals, preferences, and context boundaries all need to go into memory.

Async is also a hard problem. Agents run for longer and longer, and they also need to call tools and other agents that take just as long. When the user sends a new message, the main agent has to stay responsive. More work will be pushed into async tools and subagents. How does the main agent know that background work is done? How does it handle notifications while it is still running? How does it handle things when it is paused waiting for human approval? These are not problems that can be solved by adding a loading animation.

Goal tracking and alignment are even messier. As agents move from doing tasks to pursuing goals, they need to break big goals into small steps, run experiments, get feedback, and keep iterating. It is not easy to get an agent to try new experiments, avoid repeating old actions, and stay consistent over a long period. It is also hard for users to design goals in a way that prevents agents from gaming them. The classic example is “clear all the bugs in the codebase”; the agent might simply delete the codebase. No code, no bugs. What is needed here is a constraint framework that keeps the agent focused on the goal without over-optimizing for it.

Browsers are becoming a key tool for many general-purpose agents. The most important tool for coding agents is Bash, which can execute code; general-purpose agents increasingly rely on browsers. Browsers are much harder to drive than terminals. Whether the interaction target is an image or the DOM, both are large objects, and how to manage context is a new problem.

Sydney’s argument is interesting because it pushes “agent capability” one step further. Being able to call tools, write code, and retrieve information is only the entry ticket. What proactive agents really test is judgment: when to remind, what to remember, when to stop, and how to pull things back when the goal drifts. An agent that keeps assigning work but cannot remember a refusal will not feel intelligent; it will just make people want to turn off notifications.