Loading today’s stories
Product1 distinct publisher3 min readPublished
An agent that plans five steps and executes three is worth no more than one with no tools at all. That puts the parsed tool call ahead of plan quality in the list of things worth logging.
The Product Desk · Product desk
Compiled by The Product DeskSomething wrong?How this is made
Follow any of these and your For You feed starts watching them — no settings page required.
build
Fabricated SQLite CVEs cleared NVD, CISA ADP and Red Hat before anyone ran the code1 distinct publisher
build
One bookkeeping row turns an empty scrape into a billable event1 distinct publisher
build
One instruction to delete the sample data surfaced three invisible defects in an hour1 distinct publisher
security
Akrites switches on in September with 20-odd members and a one-to-10 engineer donation band1 distinct publisher
One model labels its call payload arguments; another uses parameters for the same concept [5]. A parser expecting the first does not necessarily choke on the second, according to Red Hat: it can pass along an empty or wrong set of values, the tool runs anyway, and the agent books the step as a success and plans the next one on top of it [9].
The rest of Red Hat's failure list has the same shape. A parser tuned for one model's tag style misses a call from a model that uses no tags at all, so the call never fires and the plan loses a step without saying so [8]. A parser built to expect one call per response can grab the first call in a multicall response and drop the others, so an agent that asked for three things gets one back [10]. And when a model interleaves chain-of-thought text with the call itself [7], a parser drawing that line in the wrong place can lift arguments out of the reasoning text and send those instead [11].
It's tempting to treat agent reliability as a reasoning problem and go shopping for a better planner. Red Hat's list describes something narrower: a text-parsing problem that manufactures confident plans on top of steps that never happened.
The five-and-three line is a rhetorical yardstick, and the format examples in the post are illustrative snippets rather than measured failure rates from deployments [16]. The exponent is still worth working by hand, because each step's output becomes the next step's input [4]. A five-step chain where every step parses and executes correctly 99 times in 100 finishes clean on 95.1% of runs (0.99^5 = 0.951). At 95% per step it finishes clean 77.4% of the time (0.95^5 = 0.774), which is about one run in four ending up somewhere wrong [15]. Per-step numbers that read respectably on a dashboard compound into a chain failure rate too high to trust in production.
The 2x2 worth drawing over your own tool inventory has one axis for whether a malformed call raises an error or returns something plausible, and another for whether the tool only reads or actually writes something, such as filing the ticket or issuing the refund. Silent-and-writes is the quadrant that earns instrumentation first, which in practice means logging the raw model output beside the parsed call for every model in rotation, and putting the assertions on the parsed call rather than on the final answer. Loud-and-reads can wait, because it announces itself. The person who needs this is whoever answers for the agent's output on Friday, and the run they will be asked about is the one whose logs looked clean while a step silently failed underneath.
Ranked by verification strength, evidence, and original report placement.
Red Hat's engineering blog argues that most attention in agentic AI goes to the model's reasoning capability, while far less goes to the last step, actually executing the action the model decided on.
Red Hat calls the execution step the last mile and says it is taken for granted despite being the step that frequently causes agentic systems to quietly break in production.
Red Hat writes that an agent that plans 5 steps and can only reliably execute 3 of them is as useful as one that has no access to any tools at all.
In an agentic chain, each step's output feeds the next step's input.
Red Hat shows the same get_weather call emitted three ways by different models: XML-style tags wrapping a JSON payload, plain JSON using the field name parameters where another shape uses arguments, and a special token followed by a function-call-style string.
A parser has to know ahead of time which tool-call shape a given model is going to produce.
Distinct publishers with included, body-backed reporting in this cluster.
1 article · September 2, 2026
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Mechanism shown, magnitude absent
Red Hat shows its work where it can: three real tool-call shapes set beside each other, and four failure modes described precisely enough that an engineer can reproduce each one against their own parser in an afternoon. What never appears is a number — no failure rate, no incident, no before-and-after from a running deployment. Credit for the mechanism, none for how often it actually bites.
A bug class has no install base
There is nothing to count. No product ships in this reporting, no team is named as having hit these failures, no engine is tested against the checklist Red Hat closes with. What is described is a category of defect, and a category of defect has no users, downloads or deployments to measure.
Confident framing, no field numbers
The sharpest line — five steps planned, three executed, worth no more than no tools at all — is an assertion Red Hat leaves undefended, and it is doing a lot of rhetorical work. Worth naming, too, that the only arithmetic anywhere in this coverage is ours, run on per-step reliability rates nobody has measured. The overstatement stays modest because the failure modes themselves are mundane, specific and easy to falsify.
The vendor writes the spec it sells against
The post ends exactly where you would guess: a five-point list of what 'every serving engine' must handle, published by a company that sells serving. None of the five points is wrong, and none is disinterested — the problem statement and the product requirements are the same document. Red Hat at least declines to name a product, which is more restraint than the genre usually shows.
Internally consistent, externally unchecked
One publisher, self-consistent, and unusually easy for a reader to check against their own stack — that last part is the only reason this sits near the middle rather than lower. Absent a second account or a single measurement from production, we can vouch for how these failures work and not for how common they are.