Known issues,and where they stand.

All four were found in one run: the 12-hour shop shift of 28 October 2026. They are the places where the agent got a graded question wrong. None has been traced to a kill; across 31 kills, no finished action ran again.

• Running counts drift in a long run

  Open. An agent that carries a running number, such as stock, through the reports it writes at each rebuild.

• A refund already paid gets paid again

  Open. An agent that pays something a customer was promised once, when a later event looks the same.

• A promised refund went unpaid

  Open. Seen once: a promised refund held about 8 hours before its triggering delivery was never paid. Four other promises held about 7 to 11 hours were paid.

• An old price is quoted after it changed

  Open. Seen twice: a price quoted after it had changed 6 and 9 hours earlier. 2 of the 5 price questions asked 6 or more hours after a change were wrong.

Open · found in the run of 28 October 2026 · Issue #1

The CEO in the shift asked for the current stock of one of three products 28 times. The agent gave the exact count 5 times. The other 23 answers were off, by between 5 and 200 units.

We have not confirmed why. A likely cause is the report the model writes each time the engine rebuilds its prompt, which can lose a running figure.

What to do now. Keep any number that has to be exact in your own system and give the agent a tool that reads it. We have not rerun the shift that way with a model, so we can't tell you yet how it scores.

What we have. A change to how the report is asked to treat running numbers is written and switched off. We haven't measured it, so we don't claim it helps.

Open · found in the run of 28 October 2026 · Issue #2

Seven orders were refunded more than once, 11 extra payments in all. Order O1039 was paid four times. No refund call ran twice; each payment was a separate call.

The engine's protection against repeats works per call: it stops a call that already finished from running again after a crash. A fresh call to pay the same refund is a new call, so nothing stopped it. The agent's own end-of-shift summary said it had paid each refund once. That was wrong.

What to do now. Make your refund tool refuse a second payment for the same order. That check belongs on your side whatever we ship.

What we have. A tool can now declare a key for the real-world operation, such as refund:{order_id}, and the engine refuses a second call with that key in the same reply or any later one. It is off for any tool that doesn't declare one, and the TypeScript client (0.1.6) doesn't send the setting yet, so you can't use it from there today. It stops the agent from deciding to repeat the operation. It does not make your app's side exactly once.

Open · found in the run of 28 October 2026 · Issue #3

The shop had promised a refund on order O1052 until a delivery arrived. The delivery of S08 that the promise waited for came 635 events later, about 8 hours into the promise, and the agent paid nothing. It was one of 14 questions in the far band. We haven't traced why it was missed.

What to do now. If an unpaid promise costs you money, check promised actions against your own records at the end of a shift.

Open · found in the run of 28 October 2026 · Issue #4

Twice the agent quoted a price that had since changed. Both times it gave 2250 when the price had moved to 2050, after 487 and 691 events. This looks like the same fault as the running counts, where the reports put an older price back. We have not traced these two answers to a specific report.

What to do now. Same as for counts: let the agent read prices from your system when the answer has to be current.

These are written elsewhere on the site. They sit here too so nobody has to hunt for them.

• A tool call cut off before its result was saved is requested again, because we can't know whether it ran; a tool declared once is not resent, and its outcome is recorded as unknown. After a kill, a finished call is not repeated. See the crash write-up.
• A worker that is frozen rather than killed repeated a refund in 2 of 22 runs, and in 3 of 22 in a rerun. See the crash test.

An entry stays open until a rerun shows it gone. Then it becomes fixed, with the date and a link to that rerun. If a fix doesn't hold, the entry reopens.

The numbers come from the run's graded events. The graded events behind these tables are in long-run-grades.csv; the kill and action rows are in long-run-kills.csv and long-run-actions.csv.

Each entry has an issue in our public tracker, which holds issues only and no engine code. To report something new, open an issue there, write to hi@getargentic.com or find us on Discord.