A Two-Minute Cap That Wasn't Supposed to Be There

July 19, 2026 · InfraScout Team

Assessment tools take a timeout. The AI sets it, the agent honors it, and the ceiling is an hour — enough for a package upgrade, a wide certificate scan, or a directory query across a large domain.

The chat loop was ignoring all of that and wrapping every tool call in a hard two-minute limit.

Why that was worse than slow

If a two-minute cap merely made long commands fail, it would be an annoyance. What actually happened is worse, because the command did not stop.

A package upgrade on a Linux host was reported to the AI as "timed out after 2m0s" while it carried on running perfectly well. The AI did what a reasonable operator would do with that information and retried — which started a second upgrade alongside the first. Two package managers contending for the same lock. Broken packages on the host.

We traced it against a real execution: a command with a five-minute timeout that ran for 247 seconds and completed successfully. The record shows it completed. The AI was told it had timed out, because the process waiting on the result gave up at the two-minute mark and never collected the output.

The failure mode is the one that makes a bug like this dangerous. Reporting failure when something succeeded does not just lose information — it invites a corrective action that causes real damage.

Three fixes

The wrapper honors the requested timeout. A tool call now runs for as long as the AI asked, up to the ceiling the tool allows, plus a short grace period. The wrapper is a genuine backstop now rather than the effective limit: the agent's own timeout fires first, and the routing layer classifies the result before the grace period runs out. Nothing reaches the wrapper's limit unless something upstream has already failed to report.

The connection is kept alive. A long call used to run into a different wall — the load balancer in front of InfraScout closes an idle connection after about four minutes, which would sever the live update stream mid-call even once the timeout was right. While a tool runs, the running-status message is now re-emitted periodically, so the connection is never idle long enough to be closed.

Terminal results are written even if you leave. A tool result is now persisted and published even when the request context is cancelled — you close the tab, the network drops, you navigate away. This is what was behind a specific and confusing pattern in the records: executions where the raw response had been preserved but the readable output was empty. The result had arrived and the write had been abandoned mid-flight.

While we were in there: tool results stream individually

When the AI fires several tools in one turn, every card used to show as running until the slowest one finished, and then all of them flipped to done together.

That was purely a timing artifact. The interface resolves each card on its own result arriving, so it was already capable of settling them one at a time — the results were simply all emitted after the whole batch had joined. They are now emitted the moment each individual call completes.

A fast inventory read next to a slow directory query settles immediately instead of looking stalled for a minute for no reason. This applies to every path that produces a result, including delegated Task Agent spawns, and there is a sweep at the end of a batch as a safety net so no card can be left spinning forever.

A better error when the AI guesses an argument

One more small thing from the same period, from reading a real conversation rather than a bug report.

InfraScout rejects unknown tool arguments rather than silently ignoring them, which is right — a mistyped filter should fail loudly rather than quietly running an unfiltered query. But the error named only the field that was wrong. A model that passed command to a PowerShell tool whose field is script was told unknown field "command" and had to guess again. In the conversation we were reading, it burned three consecutive calls on it.

The error now names the valid fields alongside the invalid one:

invalid arguments: json: unknown field "command";
valid fields for agent_exec_powershell: script, session_id, timeout_seconds

One turn instead of three. It applies to every tool.

And a larger result budget

The cap on how much of a tool result is passed back to the model went from 80,000 to 120,000 bytes. Eighty thousand was occasionally clipping output that mattered. The head-and-tail split that keeps the beginning and end of a long result is preserved at the same three-to-one ratio, so a command-line tool's trailing verdict still survives truncation.

Nothing to do

All of this is server-side. Long commands now run to completion and report what actually happened, tool cards settle as their tools finish, and an argument mistake costs one turn.

For what the timeout ceiling is per tool, see Agent Tools. Questions? info@infrascout.cloud.