AI Agents Quit Early Because They Are Still Chatbots at Heart
A daylong task can stall after three hours, and you may not find out until you check back.
Lightspeed Venture Partners · From Prompt to Loop Engineering | LightworkGive an artificial intelligence agent a job that should take a day, and it may quit in hour three and ask what you want next, even though nothing is finished.
The reason goes back to what these systems were first built to be. They started as conversational chatbots, programs trained to carry on a back and forth with a person. A chatbot is supposed to end its turn and wait for a reply, so an agent will sometimes do the same thing in the middle of a long job. The term for this is agentic laziness.
Picture the run as a timeline. At the far end is the goal you actually wanted, and getting there means the agent has to keep working, checking its own progress, and going around again. Laziness cuts that loop short. The agent stops early, sends a message asking for input, and sits idle.
It is, in one sense, a forgivable mistake. The model is doing what it was taught to do, ending its long monologue and inviting a comment.
The cost comes from time. If you send an agent off for 24 hours and it stopped after three, you may not learn that until you return, and you cannot easily tell from a distance when it went quiet. Those 21 lost hours are gone, along with the work the agent could have done in them. Teams are also working on ways to keep agents from stopping early.
Expect the early pause, and check the work itself before counting the job done.
Questions people ask
Can't you just tell the agent never to ask for help?
In practice, teams often instruct agents to keep working until a goal check passes. Those instructions can help, yet they do not always hold over a very long run. The pull to stop comes from the model's history as a conversational chatbot.
How do you know whether the agent is actually done?
The most reliable way is to test the result with something other than the agent's word, such as checking that all software tests pass or that an email was really sent. As general context, engineers distinguish those hard checks from asking the model itself whether it thinks it is done, which uses more computer power and is easier to fool.
Will models learn to keep going?
Research labs are working on getting models to push through early stopping points over very long jobs. One approach is to train them on examples of long tasks, including data from a company called Petrus that builds training data for behavior in digital settings. Better persistence is the aim, but for now systems still need to be built to catch an early stop.