# AI Agents Are Just Distributed Systems Now Salman Munaf, TikTok | AI Engineer World's Fair 2026 | 19:48 Source: https://www.youtube.com/watch?v=hD9-V56FNRI Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks. Page: https://aietalks.com/talks/ai-agents-are-just-distributed-systems-now Published: 2026-08-29 Tags: guardrails, observability, reliability, tool-use ## TL;DR - Once an agent can call tools and change external state, it has the failure modes of a distributed system. - A timeout means the result is unknown, so retries need idempotency keys, request IDs, status lookups, and limits. - Teams should bound agent actions with scoped credentials, approval parameters, circuit breakers, budgets, traces, and recovery paths. ## Summary Salman Munaf argues that tool-using agents should be designed as distributed systems. A text-only model could produce a bad answer, but an agent can call an API, update a database, send an email, or issue a refund. That creates network failures, stale state, duplicate requests, partial completion, retry storms, and unsafe permissions. Munaf describes the agent as a probabilistic coordinator surrounded by deterministic controls. Those controls include idempotent tools, request and status tracking, exponential backoff, turn and spend limits, circuit breakers, scoped credentials, parameter-bound approvals, and compensating actions. He also treats agent context and memory as state or cache data, with provenance and invalidation. Better models may reduce mistakes, but they cannot remove network failures or stale information. The design question is what the system allows the agent to do when it is wrong, and whether teams can observe and recover from that action. ## Key ideas ### Tool use moves the system boundary beyond the model [00:01](https://www.youtube.com/watch?v=hD9-V56FNRI&t=1s) Munaf contrasts early language models, which took text in and returned text, with agents that run loops, call tools, contact external services, and change state. The important boundary is no longer the model itself. Engineers must account for the systems the agent talks to, the state it reads or changes, the credentials it holds, and the actions it can perform. He uses incidents involving a Replicate AI agent deleting a production database and an Air Canada chatbot giving an incorrect refund to show why this matters. Backups, scoped authority, and authoritative policy retrieval could have reduced the damage in those examples. ### An agent is a probabilistic coordinator surrounded by deterministic controls [03:25](https://www.youtube.com/watch?v=hD9-V56FNRI&t=205s) Traditional services can coordinate multi-step workflows through a decision tree designed in advance. An AI agent can choose different actions and take different paths, so its coordination is probabilistic. Munaf says those actions need deterministic controls around them. A typical loop plans, acts, observes results, persists information, and decides what to do next. Each part crosses a system boundary. The agent may receive partial results, persist incorrect data, choose an unsafe next action, or start a retry storm. Persisting each action and its context gives the system enough information to identify where it failed and attempt an undo or recovery operation. ### A timeout leaves the outcome unknown [07:16](https://www.youtube.com/watch?v=hD9-V56FNRI&t=436s) A remote call can time out even when the server completed the operation. Munaf gives the example of a refund tool: the request times out, and the agent has to determine whether the customer was refunded. Treating the timeout as failure and immediately retrying can create a duplicate refund. The same pattern applies when a database writes successfully but another error causes the client to receive an error response. A system needs request IDs, idempotency keys, and a status lookup for the previous request. These controls let a repeated call check what happened before causing another side effect. ### Retries need backoff, budgets, and compensation [08:32](https://www.youtube.com/watch?v=hD9-V56FNRI&t=512s) Munaf says an agent's first response to failure is often a retry, which makes idempotency a requirement for tools that change state. Uncontrolled retries can become a retry storm and cause cascading failures in external APIs. He recommends exponential backoff, maximum turns, limits on parallel calls, and a spend budget. These controls limit how far an agent can fan out or how long it can keep trying. Side-effecting operations also need compensation operations. If a multi-step workflow completes some actions and then fails, the system needs a defined way to undo or correct the actions that already happened. ### Context that can change an action is state [10:18](https://www.youtube.com/watch?v=hD9-V56FNRI&t=618s) Munaf argues that teams often treat agent context as harmless context even when it can influence an action. In that case it is state. It can become stale, conflict with authoritative data, or corrupt later decisions. He separates short-term memory, such as the execution thread, from long-term memory, such as project files, system prompts, databases, and cache data. The system must decide which source wins when these sources disagree. He recommends treating memory as a cache, with provenance attached and invalidation available. When the source of truth changes, related agent memory should be invalidated so later actions do not use old information. ### Multi-step actions need recovery across system boundaries [12:17](https://www.youtube.com/watch?v=hD9-V56FNRI&t=737s) An agent can complete its first actions and then fail later in the workflow. Munaf gives an example in which it updates an internal ticket, emails a customer, and then fails to update the CRM. Recovery cannot be designed only for one service because the transaction crossed several systems. Each step needs an explicit transaction and a defined compensation operation. If the agent sends an incorrect email, the recovery might be an apology or correcting email. The same reasoning applies to other irreversible or unsafe operations. Teams need to decide in advance what the agent should do after partial completion. ### Permissions and approvals must describe the specific action [14:36](https://www.youtube.com/watch?v=hD9-V56FNRI&t=876s) Munaf warns against giving an agent every permission attached to a database or tool. Credentials should be scoped, with separate read and write access and an allow list for callable tools. A model that appears harmless can cause harm when it has unsafe operations available. Human approval also needs precise bounds. Approval should identify the action, parameters, actor, timestamp, and expiration. Approval for a 30 dollar refund must not become approval for a later 300 dollar refund. The approval has to bind to the particular request that was reviewed. ### Observability must reconstruct the agent's decision [16:23](https://www.youtube.com/watch?v=hD9-V56FNRI&t=983s) Logs alone do not give teams enough information to understand an agent failure. Munaf says engineers need to reconstruct which model ran, which prompt it received, which tools it called, the requests and responses, the errors, the retrieved context, the writes it made, and the approvals it received. This record connects the agent's action to the information available at the time. He closes by saying that better models can improve the chance of correct operations, but they cannot remove network failures, stale data, or adversarial input. Tool contracts, idempotency, source-of-truth rules, retry policies, permissions, traces, and recovery paths bound what happens when the model is wrong. ## Notable quotes - "The architectural boundary now has moved way beyond an LLM model." (02:33) - "The timeout does not actually mean that there a failure had occurred. It means unknown." (08:06) - "When that context can influence an action, it's a state." (10:18) - "Logs are not enough." (16:24) - "We should also ask what the system lets it do when it is wrong." (19:20) ## Tools & references mentioned - Replicate - Air Canada ## Who should watch - You are building an agent that can issue refunds, modify records, send messages, or call other systems, and you need to reason about duplicate or partial operations. - Your agent retries after errors and you do not yet have idempotency, status checks, backoff, or limits on turns, spend, and parallel calls. - You are deciding how to handle agent memory, human approvals, credentials, tracing, and recovery when the model takes an unsafe action. ## Editor's note From the pack [Agents in production: reliability, evals and cost](https://aietalks.com/packs/agents-in-production): Munaf's question is what the system lets the agent do when it is wrong, and whether you can see enough to recover. Navan lists replay and debugging as unsolved problems. We built Kitaru for that gap. It records agent runs so you can replay one that failed and find the step where it went wrong, instead of guessing from the logs. Written by the AIE Talks editors (the Kitaru team), not by the speaker.