Loading today’s stories
Build1 distinct publisher3 min readPublished
The New Stack's harness argument doubles as an estimating memo, because the schemas, idempotency keys, permission checks and readable traces it lists are the parts that decide whether a demo survives a reworded question.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Follow any of these and your For You feed starts watching them — no settings page required.
build
Airlock's per-case proxy enforces what a tool's readOnlyHint only claims1 distinct publisher
invest
Google's bank agent can read FactSet. The licence, not the model, decides how much.1 distinct publisher
build
Rate limit your MCP servers, because a retrying agent turns one error into a billing incident1 distinct publisher
product
A 2x LLM bill is not a bug report: token spend is an observability problem1 distinct publisher
Read the four jobs the article assigns to the harness as a work breakdown: tool contracts that limit what a wrong call can do, permissions enforced outside the model even when an instruction attempts to bypass them, context paths and trace records the team can actually inspect, and tests built from the failures users will find first [5]. None of the four is model work. They are changes to an API surface, an authorization layer, a log pipeline and a fixture set.
The worked example shows the same ratio inside one tool. A single sentence of description faces the model [10]. Around it sit three input fields, two output fields, five error states and one timeout, which is eleven declarations the server enforces rather than suggests [14]. The description only helps the model pick the tool; it does nothing to protect the API from invalid input or unsafe requests, because an agent tool is an API for a caller that can make incorrect choices [13].
The heaviest of those eleven are the idempotency key and the error split. The key is there because an agent that hits a timeout will often just try again, and the article's phrasing is exact: that should not mean charge them twice [11]. The split between retryable and terminal codes is there because the model reads whatever the tool returns and acts on it, so ERR_422 teaches it nothing while APPROVAL_REQUIRED plus a sentence about annual plan changes needing human sign-off tells it what to do next [12]. Error strings are prompt text. An error taxonomy is not where anyone wants to spend week three, and it is where week nine goes anyway.
The estimating error has a tell in the requirement itself. The New Stack contrasts a support agent that drafts a reply from a knowledge base with one that reads an account record, retrieves the policy for that account and routes an exception to a review queue, and says the second needs more than a better prompt [7]. Anything written in the second form is systems work, because the model does not arrive knowing whether a record is current or whether an action needs approval unless the surrounding system supplies those rules [6].
The demo conditions in the piece are a clear question, up to date documents and a handful of tools behaving exactly as expected [1]. That is also a description of a clean stack, and it is the transfer condition for the cheap estimate. For a model-integration budget to hold, the tools you need already publish input and output schemas with timeouts and defined error states [9], the write paths already implement idempotency [11], authorization already keys off the acting user rather than the service account, and traces are already inspectable by the people who get paged [5]. Where one of those is missing, the agent project is what pays to add it.
The capability boundary is the cheapest illustration. An agent that can read an invoice but cannot change it [2] reads to a user as a broken feature and to an engineer as a grant nobody requested, and which reading wins is settled by the harness, since the model supplies reasoning and not boundaries [15].
Ranked by verification strength, evidence, and original report placement.
The article's central claim, stated twice as a pull quote: the model is one part of the service, and the agent harness is the rest, being the scaffolding the application builds around the model.
A production agent needs a wrapper around the model so the system can decide what data the agent sees, which actions it can take, and what happens when a required fact is missing.
The article says proving an agent is ready for real work is the harness's job, via tool contracts that limit what a wrong call can do, permissions enforced outside the model even when an instruction attempts to bypass them, context paths and trace records the team can actually inspect, and tests built from the failures users will find first.
A language model can reason about whatever an application sends it but does not arrive with an understanding of your business systems, and cannot know whether a record is current or whether an action needs approval unless the surrounding system gives it those rules.
The article contrasts two support agents: one drafts a reply from a knowledge base, the other reads an account record, retrieves the policy for that account and sends an exception to a review queue, and it says the second needs more than a better prompt.
The article's recommendation is to give each tool a specific job with input and output schemas, a timeout, and defined error states.
Distinct publishers with included, body-backed reporting in this cluster.
1 article · August 30, 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.
One voice, one checkable artefact
Everything here rests on a single New Stack post, and exactly one part of it can be checked by a reader: the update_billing_plan contract, eleven enforced elements wrapped around one sentence of description. The claims that make the piece feel important — most agent projects are harder than their demos, many failures live in the model-to-system seams — carry no incident data, no survey and no second reporter. Our copy also breaks off mid-sentence in the permissions section, so the prompt-injection argument is announced rather than made.
No deployments named
Nobody's agent appears by name. There is no company running this harness, no before-and-after failure rate, not even a dated anonymous war story; the billing tool is an illustration, not a system in production. The only nod to the wider ecosystem is half a sentence saying MCP may handle some schema plumbing. There is nothing here to count.
Restrained prose, one example carrying a broad claim
The piece is unusually disciplined about its own reach: it puts no figure on how much of an agent project the harness is, and hedges even the idempotency claim to 'can help prevent'. What tips it slightly to the overstated side is scope — a general verdict on where agent projects fail, drawn from one billing tool and no field data, with the words 'most' and 'many' doing work no measurement supports.
No stake visible
We cannot see who gains if this advice is followed. The text carries no author affiliation, no disclosure, no product and no call to buy anything; the nearest thing to a commercial hook is a passing MCP reference that hands responsibility back to the reader. Assigning a motive from the publisher's name alone would be manufacturing one.
Mechanics checkable, frame not
Confidence splits by claim type. The engineering is self-checking — split retryable from terminal errors, verify account_id server-side, gate a write behind confirmation and a permission check, make the retry idempotent; you can read the contract and judge it yourself. The empirical frame wrapped around it cannot be tested from what we have, there is no second publisher to test it against, and the piece stops before its permissions argument finishes.