Technology On the Net

Nested LLM agents burn time the way nested HTTP calls do: a supervisor waits on a worker, the worker waits on three tools, and one of those tools waits on a slow upstream. Without an end-to-end deadline, the outer request sits open until a client times out, your gateway retries, and you pay for work that will never be delivered. Image: mikemacmarketing / photo on flickr via Wikimedia Commons (CC BY 2.0) Image: John Morgan via Wikimedia Commons (CC BY 2.0) This guide shows how to propagate a single request deadline through agent steps and tool calls so every layer stops when the user-facing budget is gone—without aborting healthy work that still has time left. Why flat timeouts fail for agents A common first attempt is a fixed timeout on every tool: thirty seconds for search, ten for a database write, sixty for the whole agent. That looks tidy and still fails in production. Budget stacking : Five tools at thirty seconds each can run for two and a half minut...

Modern LLM APIs let a model request several tool calls in a single turn. Ask an agent "What's the weather in Tokyo, Paris, and Denver, and do I have meetings tomorrow?" and a capable model will often emit four tool calls at once instead of four round trips. Run those calls concurrently and the turn finishes in roughly the time of the slowest call rather than the sum of all of them. Run them carelessly and you get race conditions, duplicated side effects, blown rate limits, and conversations the provider rejects because a tool result went missing. Image: mikemacmarketing / photo on flickr via Wikimedia Commons (CC BY 2.0) Image: Savni via Wikimedia Commons ( CC BY-SA 4.0 ) This guide covers how parallel tool calling works at the API level, how to execute the calls safely, and the failure cases that bite teams once real traffic arrives. How parallel tool calls show up in the API The shape differs by provider, but the contract is the same: one assist...

The moment you split an LLM agent into a supervisor and several workers, a new class of bugs shows up. The supervisor passes too much context and the worker gets confused. The worker returns a paragraph of prose and the supervisor misreads it. One worker spawns its own helper, and now nobody knows who is responsible for the budget. This post covers a practical way to design the handoff between agents so each piece stays small, checkable, and bounded. Image: ProjectManhattan via Wikimedia Commons (CC BY-SA 3.0) Why handoffs are where multi-agent systems break A single agent has one context window and one loop. When you add workers, every boundary between agents becomes an interface, and most teams treat that interface as free-form text. That works in a demo and fails in production for three common reasons. Context bleed. The supervisor forwards its full conversation to the worker. The worker now sees instructions, user data, and earlier tool results that have nothing t...

Every agent that can call tools can also get stuck. It reads a file, gets an error, reads the same file again, gets the same error, and repeats until it hits a timeout or your spending cap. Nothing crashed, so your usual alerts stay quiet, but the run is useless and the bill is real. This post covers how to detect those loops early, how to cap them with budgets, and what the agent should do when it gets stopped. Image: BalticServers.com via Wikimedia Commons (CC BY-SA 3.0) Image: Christopher Bowns via Wikimedia Commons (CC BY-SA 2.0) What a runaway loop actually looks like Loops in production agents are rarely a literal infinite while True . They usually show up in a few recognizable shapes: Exact repeats: the same tool called with identical arguments several times in a row, usually because the result did not change anything the model can use. Oscillation: the agent alternates between two actions, such as editing a file and reverting it, or searching with...

A long-running LLM agent is a distributed system with a language model in the middle. It calls tools, waits on APIs, and sometimes runs for many minutes. Sooner or later the process hosting it will be redeployed, OOM-killed, or evicted. If your only copy of the agent's progress lives in process memory, every one of those events throws away the work and, worse, may repeat side effects when the run starts over. This post shows how to checkpoint agent state so a run can resume from the last good step instead of from zero. Agent workers are ordinary processes on ordinary machines, and those get restarted. Photo: Derrick Coetzee, Wikimedia Commons , CC0. What actually needs to survive a restart Before writing any code, list what a fresh worker would need in order to continue the run without guessing. For most agents that is a short list: The message history. The system prompt version, user input, assistant turns, and tool results so far. The pending step. Whether the agent ...

Long agent runs fail in a boring way: each tool returns a wall of JSON, the next model call stuffs that wall into the prompt, and you blow the context window or the dollar budget before the user gets an answer. Truncating and summarizing tool results is not a nice-to-have polish step. It is how you keep multi-step agents alive under a fixed token budget. Image: mikemacmarketing / photo on flickr via Wikimedia Commons (CC BY 2.0) Image: Carl Lender via Wikimedia Commons (CC BY 2.0) This guide covers a practical pattern for production stacks in October 2026: measure what tools return, truncate with structure in mind, summarize only when you must, and keep enough raw detail for debugging and retries. No invented benchmarks—just steps you can implement against your own gateway and logs. Why tool results dominate agent context Chat history and system prompts are usually predictable. Tool payloads are not. A search API can return fifty documents. A SQL tool can dump ...

The Model Context Protocol (MCP) has become the common way to plug tools and data into LLM agents. Instead of writing a custom integration for every agent framework, you build one MCP server and any MCP-capable client can discover and call its tools. That convenience cuts both ways: the moment your server is reachable, an agent you do not fully control can call it with arguments you did not anticipate, in loops you did not plan for. This guide covers the practical decisions that separate a demo MCP server from one you can safely put in front of real users: how to shape tools, how to handle authorization, how to keep outputs small, and how to observe what agents are actually doing. Technician working on a server rack at NERSC. Photo: Derrick Coetzee, CC0 ( Wikimedia Commons ) A quick refresher on what an MCP server exposes An MCP server speaks JSON-RPC 2.0 to a client (the agent host). It can expose three kinds of things: Tools : functions the model can decide to call, each...

Giving an LLM agent a "run code" tool is one of the fastest ways to make it useful. It can crunch a CSV, test a regex, plot a chart, or check its own math instead of guessing. It is also one of the fastest ways to get burned. The code the model writes is untrusted input, no matter how well-behaved the model usually is, because the model's instructions can come from a user, a retrieved document, or a web page that someone else controls. Image: mikemacmarketing / photo on flickr via Wikimedia Commons (CC BY 2.0) This guide walks through how to run agent-generated code safely in production: which isolation layer to pick, which limits to set, how to handle files and network access, and what to log. The goal is simple. A bad snippet should fail inside a disposable box and take nothing else with it. Start from the threat model, not the tool Before you pick a sandbox, write down what you are defending against. For most agent setups the realistic list looks like t...

Most LLM agents in production can do real things: send email, issue refunds, change records, merge code, or spend money through an API. Prompts and tool allowlists cut down on mistakes, but they can't guarantee the model won't pick the wrong recipient, the wrong amount, or the wrong customer. For a small set of actions, the practical answer is to have a person look before the action runs. Image: mikemacmarketing / photo on flickr via Wikimedia Commons (CC BY 2.0) The hard part isn't deciding that some actions need approval. It's building the gate so it's safe, auditable, and fast enough that people don't start rubber-stamping everything or switching it off. This guide covers how to design approval gates for agent tool calls: which actions to gate, how to pause and resume a run, what the reviewer should see, and how to keep the whole thing from turning into a bottleneck. Decide What Actually Needs a Human If you gate every tool call, reviewers drown...