Talk by Salman Munaf (site reliability at TikTok) arguing that AI agents that call external services are fundamentally distributed systems problems, not model problems. Key points: a timeout means unknown rather than failure, so an agent's retry instinct requires idempotency keys, request identifiers, and status lookups to avoid duplicating actions like refunds. An agent is framed as a probabilistic coordinator, with determinism supplied by surrounding controls such as circuit breakers, spend and turn ceilings, compensating actions per step, and scoped credentials separating reads from writes. Context that can influence actions should be treated as staleable state (like a cache) requiring invalidation and provenance, and human approval must bind to a specific action, actor, and expiry. Includes timestamps only when present in the supplied record. # Channel Identity Observations — "AI Agents Are Just Distributed Systems Now — Salman Munaf, TikTok" ## Explicit Self-Description - The speaker self-identifies by name and affiliation via the video title: **Salman Munaf, TikTok** — indicating the talk is delivered by an engineering practitioner at TikTok. - The speaker frames the talk's purpose directly: *"I will be talking about AI agents are also distributed systems… it is important to incorporate distributed systems thinking and concepts when building AI agents."* - The speaker identifies his audience implicitly as builders: *"a lot of teams when building AI agents think of AI agent context as just…"* — addressing engineering teams designing agent systems. ## Claimed Scope - The talk claims to cover the **transition from chatbots to production agentic systems**, applying distributed systems concepts (idempotency, circuit breakers, compensation/sagas, scoped credentials, observability) to AI agent architecture. - Claim of relevance is anchored to real-world incidents: *"the Replit AI agent deleting a production database or Air Canada chatbot basically making an incorrect refund."* ## Intended Audience (Observable) - **Backend/platform/distributed-systems engineers** building AI agents in production — evidenced by technical vocabulary used without definition: *item potency keys, exponential back off, circuit breakers, max parallelism, source of truth, provenance*. - Practitioners concerned with **operational safety** — the talk's throughline is *"when building AI agents, we should also ask what the system lets it do when it is wrong."* ## Demonstrated Presentation Patterns - **Conference-talk format**: formal opening (*"Hello everyone. Good afternoon"*), structured progression through topics, and a closing summary (*"So I would like to end with the idea that…"*), ending with music — consistent with a recorded conference session. - **Framework-oriented teaching style**: repeatedly reframes AI-agent concepts in distributed-systems terms, e.g., *"I like to think about it as AI agents as basically having a probabilistic coordinator."* - **Prescriptive, checklist-like guidance**: dense recommendations — persist every step, define explicit transactions, *"human approval shouldn't be tied to a blanket approval. It should be tied to action, timestamp, actor and expiration."* - **Mental-model classifications offered**: e.g., classifying agent memory into *"short-term memory which is the chat thread"* and *"long-term memory… project files, system prompts, databases… the cache layer."* ## Notes on Evidence Limits - No curated metadata was supplied; all observations derive from title and transcript only. - No explicit channel-wide mission statement, subscriber appeals, or calls to action appear in the transcript; the material demonstrates a single technical talk rather than stating channel-level identity claims. # Delivery Observations — "AI Agents Are Just Distributed Systems Now" (Salman Munaf, TikTok) ## Tone & Overall Delivery Style - **Calm, instructional conference-talk tone.** The speaker addresses the audience directly at open and close: > "Hello everyone. Good good afternoon." - **Conversational and explanatory rather than performative.** Sentences are long, hedged with fillers, and structured around "what happened → why it matters → what to do." - **Consistent closing pattern:** the talk ends with a compact recap of recommendations followed by a single summarizing question: > "when building AI agents, we should also ask what the system lets it do when it is wrong." ## Filler and Disfluency Patterns (Very Frequent) - **"uh" is the dominant filler**, appearing throughout — often multiple times per sentence: > "Uh today uh I will be talking about AI agents are also distributed systems." - **Repeated word restarts** occur when self-correcting mid-sentence: > "the replicate AI agent deleting a production incident production database" > "those uh actions can have severe consequences uh ba uh if they are not confined" > "d some data store" / "a a wrong email to a customer" - This restart habit is stable across the entire talk, from the opening through the closing section. ## Recurring Phrases & Rhetorical Moves - **"It is important to…"** is the speaker's signature recommendation formula, used repeatedly: > "it is important to incorporate distributed systems thinking and concepts when building AI agents." > "it is important to have uh request ids, item potency keys" > "it is important to trace the model that was called" - **"So…" as a topic-transition marker**, opening many new sections: > "So let's uh go over the transition from chatbot to production system." > "So a the AI agent basically runs in a loop…" - **"For instance…"** repeatedly introduces concrete examples: > "So for instance if an agent calls refund customer uh tool call" > "So for instance, an agent can update an internal ticket uh send an email to a customer" - **Rhetorical questions to the audience** to dramatize failure ambiguity: > "that did the refund happen or not? What will the agent uh infer from that? Would it retry uh refunding to the customer?" ## Teaching Habits & Structure - **Incident-driven motivation first.** The talk opens with two real-world failure cases before any theory: > "the replicate AI agent deleting a… production database or Air Canada chatbot basically making an uh an incorrect refund." - **Contrast framing.** The core thesis is built by opposing old vs. new paradigms: > "they were deterministic in nature. But in the case of AI agent, the AI acts as a probabilistic coordinator." - **Enumeration habit.** Recommendations are delivered as bulleted-style lists in speech: > "There should be separate read and write permissions and there should be allow list for the tools that it can call." > "we should have set up max turns, max parallelism, max spend" - **Concrete-example anchoring.** Abstract concepts (idempotency, compensation, scoped approval) are each paired with a tangible scenario — the refund example recurs at least twice: > "if a user has given uh an approval to approve a $30 refund, it shouldn't turn into a subsequent approval for $300 refund." - **Memorable aphorisms / quotable framing**, e.g.: > "A harmless model can become dangerous when it can perform unsafe operations." > "when that context can influence an action, it's a state" > "the timeout does not actually mean that there a failure had occurred. It means unknown." ## Vocabulary & Register - **Distributed-systems terminology is used densely and consistently:** "idempotency keys" (rendered as "item potency" in the transcript), "circuit breakers," "exponential back off," "compensation operations," "cascading failures," "retry storms," "source of truth," "provenance." - **Audience assumed technical** — no definitional pauses for terms like CRM, rate limits, or tool calls. - **Repetition for emphasis** on key nouns: > "external external APIs, databases, cues" / "retry uh retry loop" ## Uncertainty Notes - **No curated metadata was supplied**, so delivery context beyond the transcript (slides, audience reaction, pacing) cannot be observed. - **Transcript is auto-generated** — apparent verbal stumbles (e.g., "item potency," "readr access," "system break uh circuit breakers") likely reflect transcription error rather than mispronunciation; these are flagged but not treated as confirmed delivery features. - Audience engagement (laughter, applause, Q&A) is not observable in this transcript, so the talk's reception cannot be assessed. # Position Record: "AI Agents Are Just Distributed Systems Now" — Salman Munaf, TikTok ## Central Thesis - AI agents are now effectively **distributed systems** because they interact with external systems and cause real-world side effects. - Therefore, **distributed systems thinking and concepts** must be incorporated when building AI agents. - The architectural boundary has "moved way beyond an LLM model." ## Motivating Evidence Cited - **Replit AI agent deleting a production database** — Munaf claims it could have been prevented with robust backups and scoped authority ("we shouldn't ideally allow AI agents to delete production databases"). - **Air Canada chatbot making an incorrect refund** — could have been prevented with **authoritative source-of-truth retrieval** rather than stale or incorrect policies. ## From Chatbot to Production System - Old model: **prompt in, text out**, no side effects, no interaction with other systems. - Agentic era: agents run agent loops, call external services and tools, and **perform state changes**. - Builders must recognize: which external systems the agent talks to, which states it interacts with, what credentials it holds, and what actions it can perform. ## Probabilistic Coordinator Framing - Munaf's stated mental model: AI agents have a **probabilistic coordinator**. - Traditional distributed-systems coordinators of multi-step workflows were **deterministic**; agent actions "can vary quite a lot" and are not a mapped-out decision tree. - Consequence: **deterministic controls** must confine agent actions, since unconfined actions can have severe consequences. ## Agent Loop Analysis Typical loop: **plan → act → observe → persist → decide**. Each step crosses a boundary: - **Planning**: interacts with data sources. - **Action**: calls external APIs, tools, databases. - **Observation**: may act on partial results; may persist incorrect data. - **Decision**: may take incorrect actions or trigger a **retry storm**. Recommendations: - **Persist every step** (actions and retrieved context) so failures are identifiable and reversible/undo operations are possible. - Define **explicit transactions** per step, including compensation for irreversible/unsafe operations (e.g., what to do after sending a wrong email to a customer). ## Tool Calls as Remote Calls - Tool calls are wrappers around external APIs, databases, queues, etc. - Standard distributed-systems failure modes apply: network delays, timeouts, duplicate requests, and **server-side success with client-reported error** (Munaf reports seeing instances where the database wrote data but an error was still returned). - Humans in the loop could previously correct such cases by checking the actual source of truth; agents need **guardrails** instead. - Example: an agent calls a `refund customer` tool, the request times out — "the timeout does not actually mean that a failure had occurred. It means **unknown**." The agent must not blindly retry. - Design requirements: **request IDs**, **idempotency keys**, and **status lookup** so duplicate requests cause no duplicate side effects. ## Retry and Failure Handling - Agents' first response to failure is to retry — so **idempotency must be baked in**. - Prevent **retry storms** / cascading failures via: - **Max turns**, **budget/spend limits**, **max parallel calls** (limit fan-out). - **Exponential backoff** to protect downstream dependencies. - **Compensation operations** for side-effecting operations. ## Context as State (Memory Model) - Claim: when context can influence an action, **it's not just context — it's state**, which can become stale, conflict with authoritative data, or corrupt future actions. - Two memory types: - **Short-term**: the thread/jet thread tied to a single execution. - **Long-term**: project files, system prompts, databases, cache layers. - Must decide the **source of truth** when sources conflict; treat memory as a **cache** that can be invalidated and has **provenance**. When the source of truth updates, invalidate agent memory/context. ## Distributed Transactions and Compensation - Multi-step actions can partially succeed (e.g., update internal ticket, email customer, then **fail to update CRM**) and cross system boundaries. - The whole transaction should be reversible; compensation operations must be defined (e.g., apology or correction email after an incorrect email). ## Circuit Breakers, Rate Limits, Budgets - **Circuit breakers** on external calls: prevent calling unhealthy downstream dependencies and prevent cascading failures when a dependency is unhealthy or saturated. - **Rate limits and budgets**: without them an agent can run up cost by endlessly retrying; set **max turns, max parallelism, max spend**. ## Permissions and Approval Hygiene - Common anti-pattern (per Munaf): granting agents all permissions/credentials up front (e.g., full read/write to entire tables). - Instead: **scoped credentials**, separate read/write permissions, and **allow lists** for callable tools. - Quote-level claim: "A harmless model can become dangerous when it can perform unsafe operations." - Human approvals must not be **blanket approvals**; they should be tied to **action, timestamp, actor, and expiration**. Example: approval of a $30 refund must not become approval for a $300 refund. ## Observability - **Logs alone are not enough**; teams must reconstruct what the agent reacted to and why it failed. - Required traces: model called, prompt, tool calls, requests/responses, errors, retrieved context, writes, and approvals. ## Closing Position - Munaf acknowledges: **model capability matters** — smarter models reduce mistakes and improve correctness. - But models **cannot eliminate network failures, stale data, or adversarial input**. - Architecture must answer: *can we bound, observe, and recover from agent actions?* - Final checklist he proposes: tool contracts (explicit request/response schemas, idempotency), source-of-truth decisions for conflicting memory states, retry policies and rate limits, scoped permissions, traces and recovery paths. - Closing framing: "When building AI agents, we should also ask **what the system lets it do when it is wrong**." ## Notes on Qualifications - Munaf attributes incidents to preventable systems-thinking gaps, not to model capability per se — a qualification he makes explicit at the end (capability helps but doesn't remove failure modes). - Speaker identification is based on the video title metadata; no other speakers appear in the transcript. # Speaker Attribution Record — Video `01a15ca7-998d-7510-9bc9-bde36ba2ced5` ## Video - **Title:** *AI Agents Are Just Distributed Systems Now — Salman Munaf, TikTok* ## Speakers & Roles | Speaker | Role | Evidence | |---|---|---| | Salman Munaf | **Primary / sole speaker** — presenter (identified as TikTok-affiliated in title) | Delivers entire talk; opens with "Hello everyone… I will be talking about AI agents are also distributed systems" and closes with "Thank you." | | Audience | Unidentified, non-speaking | Implied by "you guys might have heard…" — no dialogue. | - **No guests, narrators, or other identified speakers** appear in the transcript. - **No curated metadata** was supplied beyond title; affiliation with TikTok comes from title only, not stated in transcript. ## Third-Party Claims / Referenced Incidents The speaker cites two real-world incidents as examples (no sources cited beyond naming them): - **Replit AI agent** allegedly deleting a production database. - **Air Canada chatbot** issuing an incorrect refund. These are **speaker attributions only**; the video provides no primary sources or citations for them. ## Promotional Segments - **None identified.** No product, service, or sponsor promotion detected in the transcript. ## Provenance & Availability Notes - No referenced sources, citations, URLs, or datasets. - No comment availability metadata supplied. - Transcript ends with a **`[music]`** marker and contains **`[clears throat]`** markers — stage/audio annotations, not speech. Hello everyone. Good good afternoon. Uh today uh I will be talking about AI agents are also distributed systems. So as uh the models have started to become more complex. Initially the uh LLM models were just text in text out without performing any actions and uh the effect that they can produce was just a wrong model output. However, with now the capability of agent the agent the rise in agent capabilities where the systems can now talk to external systems uh it has turned into a distributed systems and it is important to incorporate distributed systems thinking and concepts when building AI agents. So I will be going over uh that uh in this talk. So you guys might have uh heard about incidents being caused by a AI agents. Uh for instance, the replicate AI agent deleting a production incident production database or Air Canada chatbot basically making an uh an incorrect refund. And both of these uh incidents or a lot of these incidents could have been prevented uh by good systems thinking when building these uh AI agents. So for instance for the replet a uh uh uh incident we could have good uh uh we could have robust backups. We could have scoped authority. we should we shouldn't ideally have uh allow AI agents to delete production databases. Uh moreover for Air Canada chatbot it would have been uh a good idea to have uh authoritative source of truth retrieval so that it's not making uh uh decisions based on stale or incorrect policies. So let's uh go over the transition from chatbot to production system. Uh so uh initially when we were in the uh in the uh age where LLMs were just chat bots uh we had prompt in and we were outputting text there were no side effects the agent was not interacting with any other system. However, uh due to agentic uh in the agentic era in the agentic revolution, now those agents uh by ingesting prompt can uh run an agent loop, call external services, call tools and also perform state changes. The architectural boundary now has moved uh way beyond an LLM model. And the difference is that it can now cause side effects in the outside world. So when basic when building AI agents, it is important to recognize the external systems that it is talking to, \[clears throat\] the states that uh it is interacting with and what credentials does it have and the actions that it can perform. uh I ideally like to think about it as uh uh AI agents as basically having a probabilistic coordinator. In distributed systems as well, we used to have services which were coordinating uh multi-step workflows. However, they were deterministic in nature. But in the case of AI agent, the AI acts as a probabilistic coordinator. The amount of action, the kind of actions that it can take can vary quite a lot. It is not just a decision tree that uh we typically in traditional systems would have mapped out and those uh actions can have severe consequences uh ba uh if they are not confined by our determinist by having deterministic controls in place. So it is important to ensure uh that we have deterministic controls in place to ensure that agent or the AI agent is not performing any uh any actions that might be uh uh problematic. So uh let's uh discuss the how a typical agent loop might look like. So at first it might uh do some planning. Then based on that plan it will it will perform an action and it will then observe the results of those actions and uh it might persist that into some d some data store and then decide what to do next. Each step in this loop is basically crossing a a boundary. During planning, it can interact with data sources to retrieve some data. Uh during action, it can call external APIs, tools, uh databases and perform any actions. During observation phase, it can perform it can get partial results and basically plan or make subsequent actions based on those partial results. It can persist incorrect data or uh and uh when deciding it might also decide to uh perform an incorrect action or uh worse it can also do a retry storm. So it is very important when building an agent loop to persist every step of the process. Whatever actions the agent is doing, whatever context it is retrieving, it is important to uh persist that so that if anything fails, the agent is able to recognize where it failed and it can perform uh a reversible action. Uh it can perform undo operations. Similarly, there should be explicit transactions uh identified for each step. So for instance, if an agent is making a call, if it fails, what it should do? What should be the transaction to compensate for a uh for a irreversible or unsafe operation? For instance, if an agent makes sends an email to a a wrong email to a customer, what should it do to compensate for that? So, uh tool calls are just wrappers around uh external external APIs, databases, cues, uh and so on. And uh with uh when calling the when making these remote calls, there are some failures that you incorporate uh such as network delays, timeouts, uh you can make duplicate requests or worse the server side request uh might succeed. However, the client however the client might be reported an error. We have we have seen uh instances where uh a data by base might have written the data. However, due to some other errors, the server might have reported uh uh to us the error and uh with humans in the loop we can make we can basically perform correct corrective actions based on uh by seeing uh the database and actual source of truth. But in agent's case, we need to ensure that we have uh we have proper guardrails in place. So for instance, an agent calls refund customer uh tool call which basically performs a refund to the customer. The request times out uh that did the refund happen or not? What will the agent uh infer from that? Would it retry uh refunding to the customer? you basically the the timeout does not actually mean that there a failure had occurred. It means unknown. And it is important to have uh when designing these tools, it is important to have request ids, item potency keys so that when making duplicate requests, they are not causing duplicate side effects. uh and the system can always do a status lookup like what the previous request was and what was the status of that so that it is not making side effect it is not making side effects with duplicate a with duplicate requests. So \[clears throat\] AI agents when they whenever they uh uh whenever they uh they face failures they retry the their first uh action is to perform retries. So it is really important to have item potency baked in. uh it if a same request is coming in to an external API or the tool it should recognize that this is a duplicate request and ensure that no side effects are being take are taking place. Moreover, uh we should also prevent uh AI agents to perform retry storms to external APIs because this can cause cascading failures. uh we we should have max turns budget spend and max parallel calls to prevent uh to uh to ensure that the fan out is not that large. Moreover, we should have exponential back back off in place to ensure that uh the downstream dependencies are not being uh burdened and we should also have compensation uh operations in place for uh operations that uh that that can have side effects. Uh so uh a lot of uh teams when building AI agents think of AI agent context as just a AI cont the context that uh the AI agent has as uh as just a context. However, when that context can influence an action, it's a state and that state can become stale that can conflict with the authoritative data or corrupt future actions that the agent might perform. I like to classify it into two different types of uh memory that the agent has. First is the short-term memory which is the jet thread uh that the agent has uh the which is tied to a single execution thread and the second is the long-term memory. It can be project files uh system prompts uh databases that it interacts with the cache layer and so on. It is important to uh to to decide what will be the source of truth when these uh different data sources have conflicting information and we should ideally treat memory as a cache which uh can be invalidated which can have provenence attached to it. So for instance whenever a data store or a database is updated or the source of truth is updated we in we invalidate the context or the memory that the agent has to ensure that it is not making actions based on the uh incorrect or stale data. So usually these agents perform multi-step actions and uh the agent can succeed on uh on uh on the first couple of steps and then it fail. Uh it is important to reverse the entire transaction that was performed and these can uh then can cross system boundaries. So for instance, an agent can update an internal ticket uh send an email to a customer and fail to update the CRM. We need to figure out what is the uh correct compensation operation when it when it hits that failure. So for instance uh as I mentioned earlier that uh it improperly uh it improperly sends an incorrect email to the customer. It is important that the compensation operation is defined for the AI agent to ensure that it is sending an uh uh an apology email to the customer or any or or any email or an email that is correcting that mistake. So uh a the AI agent basically runs in a loop and uh whenever uh like it can it can do multiple calls. It can it can have a retry uh retry loop that it can run based uh whenever it fails. So it is important to have uh circuit breakers whenever it is making making external calls uh to ensure that the uh that the that it is not uh burdening the downstream system. Uh for instance if a downstream is unhealthy there should be system break uh circuit breakers in place that prevents AI agents to call call that dependency. Moreover, it also prevents cascading failures when for instance the downstream dependency is uh unhealthy or uh is saturated. It is also important to assign rate limits and budgets. Uh an agent can uh go over uh can run your cost uh if it's not assigned proper budgets and rate limits. it will uh keep retrying and try try to uh try to solve the problem that if it if it's facing. So it is important that it is uh that we have uh set up max turns, max parallelism, max spend uh to ensure that the model is not uh uh not uh crossing the uh the budget boundary that we have set. Moreover, uh ideally uh usually whenever we are building AI agents, uh we usually try to give all the permissions that it can have to ensure that it has all that it can perform perform the task that we have. That's the that's the uh first uh uh thing that we have that that's the first step that we take usually that to give the AI agents all the uh cred all the uh privileges to perform any actions like for instance if it's interacting with the database we just give it all uh the readr access to the entire table. However, uh it is important to give scoped credentials to it. There should be separate read and write permissions and there should be allow list for the tools that it can call. A harmless model can become dangerous when it can perform unsafe operations. Moreover, uh a human approval shouldn't be tied uh to a blanket approval. It should be tied to uh action, timestamp, actor and expiration. So for instance, if a user has given uh an approval to approve a $30 refund, it shouldn't turn into a subsequent approval for $300 refund. It is important that whenever an approval is given, it should be tied to the particular parameters that it was uh asked for. So, uh observability is an important requirement when building AI agents because uh and logs are not enough. Teams need to reconstruct when an agent failed, what happened, what information was was it reacting to and why it failed. And logs alone are not enough to uh for an agent to uh for teams to determine that. It is important to trace the model that was called, the prompt that was uh that was uh given to it and uh also the tool calls that were made uh the request uh that was made, the response from the tool, the errors that it got, the retrieved context, what the agent was uh was the the retrieved information that the agent was reacting to, the rights that it made, and the approvals that it got and so on. So uh I would like to uh end with uh the idea that yes model capability matters. Having good models uh improves the uh likelihood of it making uh correct operations. Smarter models reduce mistakes. It uh it uh improves the capability that the model has. However, it cannot eliminate network failures, stale data or adversarial input. It is important when building this architecture, we also reason about can we bound, observe and recover from actions performed by the AI agent. It is important to have tool contracts in place to ensure that uh it is only allowed to make uh operations that it is uh given that it is provided the contract and the contracts are clearly establishing the request and response uh response uh response types uh the schema and all these tools have item potency baked into it. so that uh when repeated requests are sent in uh it is not causing unsafe operations to be retried. Moreover, there should be source of truth decisions made uh when there are conflict conflicting uh memory states. It is important uh for the agent to realize this is the source of data that it should rely on and we should have re retry policies uh like rate limits set in to ensure that the agent is not uh retrying uh ext uh aggressively. Moreover, uh permissions should be set up. There should be traces and recovery paths. So when building AI agents, we should also ask what the system lets it do when it is wrong. Thank you. \>\> \[music\]