Working code, clear diagrams, and the parts of a system that only show up in production.
Most tool-calling failures are not model failures. Four things break in practice, and three are handled by one schema repair pass plus a single retry.
if (!parsed.success) {
const repaired = await repairArgs(call)
return dispatch(repaired)
}One repair pass. One retry. Then a hard failure you can inspect.
New notes and rewrites, newest first.
A complete retrieval path using Postgres, pgvector, hybrid search, and a reranker, including the measurements that changed the final query.
A loop, a tool table, and a stopping rule. Read the thirty lines that make it an agent; everything after that is product design.
Every token you spend on retrieved text is a token you cannot spend on instructions. Here is how I split it, and what happened when I got the ratio wrong.
The test run stopped teaching us anything. Recorded calls, explicit retries, and one useful failure report made the harness dependable again.
The first scaling change was not another node. It was a bounded queue that exposed backpressure before requests reached the expensive work.
A workflow with known states needs an API and a queue. Giving it an agent loop adds cost and failure modes without adding useful judgment.
The visible latency looked cheap. The connection lifetime, retries, and abandoned requests made the operating cost tell a different story.
Each topic starts with one useful article, then goes deeper.
Every claim here comes with the code, the trace, or the measurement behind it. When I get something wrong, the correction stays on the page.
The exact repositories behind the articles, with a clear place to start.
A small tool-calling loop with schema repair, one retry, traceable failures, and an eval suite built from recorded calls.
lib/agent/tool-loop.tsStart at line 14