Tagged agents
8 pieces
- · 10 min read
Accept The Work, Not The Claim: An Agent's Own Status Is Not Evidence
A headless agent run that hits a rate limit can exit with a success status and a zero exit code, having written nothing at all. Every reliability feature that reads the agent's own account of what happened, retry, recovery, the status pane, then repeats that false claim instead of catching it. The only fix is an independent check between running and accepting.
- · 10 min read
Six Drills That Break An Agent: Accept Milestones By Breaking Them, Not By Demonstration
A demonstration shows an agent pipeline working on the path its author chose. A drill breaks it on purpose and records what the system does. Six drills cover most of what goes wrong: killing the worker mid-run, hitting the output token cap, resuming and watching the budget, cancelling a run that does not heartbeat, rate-limiting mid-run, and changing the workspace through the shell behind the tool's back.
- · 7 min read
Read-Only Is Not a Safety Boundary: It Protects Your Data From the Agent, Not Your Users From It
Giving an agent a read-only database role stops it writing. It does nothing about what it can see, because Postgres owner roles and the pg_read_all_data role bypass row-level security by default. If your product's promise is that one party cannot see another party's identity until they release it, that promise has to be enforced in the database, and read-only does not enforce it.
- · 10 min read
You Cannot Cancel What Does Not Heartbeat: Cooperative Cancellation And The Button That Does Nothing
In at least one widely used workflow engine, cancellation is delivered only to work that heartbeats. Wrap a command-line process that never reports in, and the cancel control returns successfully, the orchestrator marks the task cancelled, and the process keeps running and keeps spending. Cancellation is cooperative almost everywhere, which means it is a protocol the work has to participate in, and a timeout is the only non-cooperative backstop.
- · 10 min read
Checkpoints Do Not See What The Shell Did: Partial State Capture Is Worse Than None
A tool that snapshots its own view of a workspace cannot capture changes made outside that view, such as a file moved or generated by a shell command. Restoring the checkpoint reverts the tool's edits and leaves the shell's edits in place, producing a state that never existed at any point in the run. That is worse than no checkpointing, because a known-dirty workspace gets rebuilt while a confidently restored one gets built on.
- · 10 min read
What Should Never Be An Agent: Use The Benchmark Gap As Your Decision Criterion
Published benchmarks of agents on realistic computer-use tasks report completion rates in the low tens of per cent, while humans on the same tasks sit near ceiling. That gap is not a reason to avoid agents. It is the input to a decision procedure: a low success rate is fine when checking the answer is cheaper than producing it, and unacceptable when the action is irreversible or verification costs more than doing the work yourself.
- · 7 min read
Two Postgres Queues, Opposite Failures, Same Drill: Know Which Way Yours Breaks
Kill a worker mid-job and the two most common database-backed job queues behave in opposite ways. One re-runs the job after a fixed interval whether the worker is alive or dead, which duplicates work on a slow task. The other holds a dead worker's job for hours, which stalls it. Neither default is wrong, and inheriting one without knowing which you have is how a queue becomes an outage.
- · 6 min read
Your Budget Cap Resets on Resume, Which Is Exactly When the Cost Arrives
A spend limit on an automated run is a control only if it accumulates across the whole task. On at least one widely used agent runner the cap applies per invocation, so resuming or continuing a task starts the budget again. Cost controls therefore stop working at the precise moment a task goes back for more work, which is when the spend happens. The fix is to track cost outside the tool, against the task rather than the invocation.