Picture one agent working through a day's tasks for a small business: refunds to issue, suppliers to chase, a report due at five. Early on it knows exactly where everything stands. Hours later it reopens a refund it finished, forgets a supplier it was waiting on, and tells you the report is done when it isn't.
This is the version of the long-run problem that matters most for real work, because one agent is holding many tasks at once. This post goes through the reasons it loses track of what is done, pending and blocked, what you can do about each, the one underneath, and the small part an engine can fix. It is about one agent tracking many tasks, not a framework of many agents.
Every cause, and what to do about it
1. The status board is prose the model rewrites. "Refund for O1039 is done, supplier call is waiting" lives as text, and every update is a model re-stating it. A recent paper, How Strongly Should Task State Influence an LLM Agent?, compares ways of putting task state in front of an agent. It reports that showing the agent accurate task state does not reliably improve its behavior, and that an unverified ledger the agent writes itself beat an accurate checklist shown to it, except on one task where acting depended on recognizing a cue. State in text is unreliable in more than one direction, so don't assume that printing the right status into the prompt is enough.
2. A finished task gets reopened. The record that it finished was dropped or summarized away, so the agent does it again. The post on repeated actions goes through the causes.
3. A blocked task has nothing to wake it. An agent acts when something runs it. A task that is waiting on a reply, a delivery or a person has no event of its own, so the agent moves on and the task sits. If the due time passes while the agent is idle, nothing happens at all.
4. Many tasks share one long context. The tasks interleave, and the detail about one task sits among the details of the others. Lost in the Middle found that accuracy drops when the relevant information is in the middle of a long input. Chroma's context rot report tested 18 models and found that performance degraded as input length increased across its experiments.
5. Two tasks touch the same thing. A refund and a replacement for the same order, or two supplier chases about one delivery, can each be correct alone and wrong together. The agent only notices if the link between them is written down somewhere it reads.
6. "Done" is a claim the model makes about itself. The agent says the report is done. Nothing checks it against what happened. The same paper looks at a gate that refuses actions that violate the task state, and finds it helps when failures are frequent and can be decided from state, and hurts when the gate's own judgment is wrong. So check what can be checked mechanically, such as whether the refund call returned success, and leave judgment calls to a person.
What you can do without us
- Keep the task list in a table in code. Each task has an id, a status, an owner, what it is waiting on and a due time.
- Change a status from a tool result, in code, not from the model's sentence. "Done" means the call succeeded.
- Run a clock yourself. When a task's due time passes, wake the agent with that task in front of it.
- Put anything that touches the same object under one key, so a second action on that object is refused or flagged.
- For anything risky, ask a person before the agent acts, and record the answer.
Causes 2, 3, 5 and 6 shrink with these. Causes 1 and 4 shrink because the model reads a short, code-built status board instead of keeping one.
The cause underneath
A status board is state, and in a plain loop the state is kept in the model's own words in a context that keeps changing. Each of the causes above is a different way for that copy to go wrong. A larger window or a better prompt doesn't change who is keeping the book.
What an engine can fix
That is the part we build. In the Argentic engine every step is recorded, and each prompt is rebuilt from that record, so what already happened comes from code. A plan can carry a due date, the engine keeps it, and it is shown to the agent the next time you wake it. Nothing wakes an agent by itself. With scheduling turned on, you poll the engine for plans whose time has passed and wake each agent yourself, so the clock is yours. It doesn't cover causes 5 and 6 for you. Linking tasks to the same object and verifying a result are still your tools' job.
What we have and haven't measured
We have not run an orchestration benchmark. Our long-run test is a single agent working through a 900-event shop shift, and it says nothing yet about an agent juggling dozens of live tasks. In our own tests the engine has also missed acting on a plan at its due time on some runs. We are working on that and are not publishing a rate yet.
The number we can offer is about state kept in code instead of prose. On the shop shift, on Claude Haiku 5.5 and the hosted engine (release 0.51.0), running stock counts were right in 22 of 28 questions with the engine keeping the counts and 4 of 28 with the model writing them. One run per setup, on a scenario we generated, and six answers were still wrong. The post on running counts has the rest.