{
  "video_id": "hD9-V56FNRI",
  "channel_slug": "aidotengineer",
  "channel_handle": "aidotengineer",
  "title": "AI Agents Are Just Distributed Systems Now — Salman Munaf, TikTok",
  "duration_seconds": 1188.0,
  "url": "https://www.youtube.com/watch?v=hD9-V56FNRI",
  "upload_date": "",
  "transcript": "[music]\nHello everyone. Good good afternoon. Uh\ntoday uh I will be talking about AI\nagents are also distributed systems.\nSo as uh the models have started to\nbecome more complex. Initially the uh\nLLM models were just text in text out\nwithout performing any actions and uh\nthe\neffect that they can produce was just a\nwrong model output. However, with\nnow the capability of agent the agent\nthe rise in agent capabilities where the\nsystems can now talk to external systems\nuh it has turned into a distributed\nsystems and it is important to\nincorporate distributed systems thinking\nand concepts when building AI agents. So\nI will be going over uh that uh in this\ntalk.\nSo you guys might have uh heard about\nincidents being caused by a AI agents.\nUh for instance, the replicate AI agent\ndeleting a production incident\nproduction database or Air Canada\nchatbot basically making an uh an\nincorrect refund. And both of these uh\nincidents or a lot of these incidents\ncould have been prevented uh by good\nsystems thinking when building these uh\nAI agents. So for instance for the\nreplet a uh uh uh incident we could have\ngood uh\nuh we could have robust backups. We\ncould have scoped authority. we should\nwe shouldn't ideally have uh allow AI\nagents to delete production databases.\nUh moreover for Air Canada chatbot\nit would have been uh a good idea to\nhave uh authoritative source of truth\nretrieval so that it's not making uh uh\ndecisions based on stale or incorrect\npolicies.\nSo let's uh go over the transition from\nchatbot to production system. Uh so\nuh initially when we were in the uh in\nthe uh age where LLMs were just chat\nbots uh we had prompt in and we were\noutputting text there were no side\neffects the agent was not interacting\nwith any other system.\nHowever, uh due to agentic uh in the\nagentic era in the agentic revolution,\nnow those agents uh by ingesting prompt\ncan uh run an agent loop, call external\nservices, call tools and also perform\nstate changes. The architectural\nboundary now has moved uh way beyond an\nLLM model. And the difference is that it\ncan now cause side effects in the\noutside world. So when basic when\nbuilding AI agents, it is important to\nrecognize the external systems that it\nis talking to, [clears throat] the\nstates that uh it is interacting with\nand what credentials does it have and\nthe actions that it can perform.\nuh I ideally like to think about it as\nuh uh AI agents as basically having a\nprobabilistic coordinator.\nIn distributed systems as well, we used\nto have services which were coordinating\nuh multi-step workflows. However, they\nwere deterministic in nature. But in the\ncase of AI agent, the AI acts as a\nprobabilistic coordinator. The amount of\naction, the kind of actions that it can\ntake can vary quite a lot. It is not\njust a decision tree that uh we\ntypically in traditional systems would\nhave mapped out\nand those uh actions can have severe\nconsequences uh ba uh if they are not\nconfined by our determinist by having\ndeterministic controls in place. So it\nis important to ensure uh that we have\ndeterministic controls in place to\nensure that agent or the AI agent is not\nperforming any uh\nany actions that might be uh uh\nproblematic.\nSo uh\nlet's uh discuss the how a typical agent\nloop might look like. So at first it\nmight uh do some planning. Then based on\nthat plan it will it will perform an\naction and it will then observe the\nresults of those actions and uh it might\npersist that into some d some data store\nand then decide what to do next.\nEach step in this loop is basically\ncrossing a a boundary. During planning,\nit can interact with data sources to\nretrieve some data. Uh during action, it\ncan call external APIs, tools, uh\ndatabases and perform any actions.\nDuring observation phase, it can perform\nit can get partial results and basically\nplan or make subsequent actions based on\nthose partial results. It can persist\nincorrect data or uh and uh when\ndeciding it might also\ndecide to uh perform an incorrect action\nor uh worse it can also do a retry\nstorm.\nSo it is very important when building an\nagent loop to persist every step of the\nprocess. Whatever actions the agent is\ndoing, whatever context it is\nretrieving, it is important to uh\npersist that so that if anything fails,\nthe agent is able to recognize where it\nfailed and it can perform uh a\nreversible action. Uh it can perform\nundo operations. Similarly, there should\nbe explicit transactions uh identified\nfor each step. So for instance, if an\nagent is making a call, if it fails,\nwhat it should do? What should be the\ntransaction to compensate for a uh for a\nirreversible or unsafe operation? For\ninstance, if an agent makes sends an\nemail to a a wrong email to a customer,\nwhat should it do to compensate for\nthat?\nSo, uh tool calls are just wrappers\naround uh external external APIs,\ndatabases, cues, uh and so on.\nAnd uh with uh when calling the when\nmaking these remote calls, there are\nsome failures that you incorporate uh\nsuch as network delays, timeouts, uh you\ncan make duplicate requests or worse the\nserver side request uh might succeed.\nHowever, the client however the client\nmight be reported an error.\nWe have we have seen uh instances where\nuh a data by base might have written the\ndata. However, due to some other errors,\nthe server might have reported uh uh to\nus the error and\nuh with humans in the loop we can make\nwe can basically perform correct\ncorrective actions based on uh by seeing\nuh the database and actual source of\ntruth. But in agent's case, we need to\nensure that we have uh we have proper\nguardrails in place. So for instance,\nan agent calls refund customer uh tool\ncall which basically performs a refund\nto the customer. The request times out\nuh that did the refund happen or not?\nWhat will the agent uh infer from that?\nWould it retry uh refunding to the\ncustomer? you basically the the timeout\ndoes not actually mean that there a\nfailure had occurred. It means unknown.\nAnd it is important to have uh when\ndesigning these tools, it is important\nto have request ids, item potency keys\nso that when making duplicate requests,\nthey are not causing duplicate side\neffects. uh and the system can always do\na status lookup like what the previous\nrequest was and what was the status of\nthat so that it is not making side\neffect it is not making side effects\nwith duplicate a with duplicate\nrequests.\nSo [clears throat] AI agents when they\nwhenever they uh uh whenever they uh\nthey face failures they retry the their\nfirst uh action is to perform retries.\nSo it is really important to have item\npotency baked in. uh it if a same\nrequest is coming in to an external API\nor the tool it should recognize that\nthis is a duplicate request and ensure\nthat no side effects are being take are\ntaking place. Moreover, uh we should\nalso prevent uh AI agents to perform\nretry storms to external APIs because\nthis can cause cascading failures. uh we\nwe should have max turns budget spend\nand max parallel calls to prevent uh to\nuh to ensure that the fan out is not\nthat large. Moreover, we should have\nexponential back back off in place to\nensure that uh the downstream\ndependencies are not being uh burdened\nand we should also have compensation uh\noperations in place for uh operations\nthat uh that that can have side effects.\nUh\nso uh\na lot of uh\nteams when building AI agents think of\nAI agent context as just a AI cont the\ncontext that uh the AI agent has as uh\nas just a context. However, when that\ncontext can influence an action, it's a\nstate and that state can become stale\nthat can conflict with the authoritative\ndata or corrupt future actions that the\nagent might perform.\nI like to classify it into two different\ntypes of uh memory that the agent has.\nFirst is the short-term memory which is\nthe jet thread uh that the agent has uh\nthe which is tied to a single execution\nthread and the second is the long-term\nmemory. It can be project files uh\nsystem prompts uh databases that it\ninteracts with the cache layer and so\non.\nIt is important to uh to to decide what\nwill be the source of truth when these\nuh different data sources have\nconflicting information and we should\nideally treat memory as a cache which uh\ncan be invalidated which can have\nprovenence attached to it. So for\ninstance whenever a data store or a\ndatabase is updated or the source of\ntruth is updated we in we invalidate the\ncontext or the memory that the agent has\nto ensure that it is not making actions\nbased on the uh incorrect or stale data.\nSo\nusually these agents perform multi-step\nactions and uh the agent can succeed on\nuh on uh on the first couple of steps\nand then it fail. Uh it is important to\nreverse the entire transaction that was\nperformed and these can uh then can\ncross system boundaries. So for\ninstance, an agent can update an\ninternal ticket uh send an email to a\ncustomer and fail to update the CRM. We\nneed to figure out what is the uh\ncorrect compensation operation when it\nwhen it hits that failure.\nSo for instance uh as I mentioned\nearlier that uh it improperly uh it\nimproperly sends an incorrect email to\nthe customer. It is important that the\ncompensation operation is defined for\nthe AI agent to ensure that it is\nsending an uh uh an apology email to the\ncustomer or any or or any email or an\nemail that is correcting that mistake.\nSo uh\na the AI agent basically runs in a loop\nand uh whenever uh like it can it can do\nmultiple calls. It can it can have a\nretry uh retry loop that it can run\nbased uh whenever it fails. So it is\nimportant to have uh circuit breakers\nwhenever it is making making external\ncalls uh to ensure that the uh that the\nthat it is not uh burdening the\ndownstream system. Uh for instance if a\ndownstream is unhealthy there should be\nsystem break uh circuit breakers in\nplace that prevents AI agents to call\ncall that dependency. Moreover, it also\nprevents cascading failures when for\ninstance the downstream dependency is uh\nunhealthy or uh is saturated.\nIt is also important to assign rate\nlimits and budgets. Uh an agent can uh\ngo over uh can run your cost uh if it's\nnot assigned proper budgets and rate\nlimits. it will uh keep retrying and try\ntry to uh try to solve the problem that\nif it if it's facing. So it is important\nthat it is uh that we have uh set up max\nturns, max parallelism, max spend uh to\nensure that the model is not uh uh not\nuh crossing the uh the budget boundary\nthat we have set.\nMoreover, uh ideally uh usually whenever\nwe are building AI agents, uh we usually\ntry to give all the permissions that it\ncan have to ensure that it has all that\nit can perform perform the task that we\nhave. That's the that's the uh first uh\nuh thing that we have that that's the\nfirst step that we take usually that to\ngive the AI agents all the uh cred all\nthe uh privileges to perform any actions\nlike for instance if it's interacting\nwith the database we just give it all uh\nthe readr access to the entire table.\nHowever,\nuh it is important to give scoped\ncredentials to it. There should be\nseparate read and write permissions and\nthere should be allow list for the tools\nthat it can call. A harmless model can\nbecome dangerous when it can perform\nunsafe operations. Moreover, uh a human\napproval shouldn't be tied uh to a\nblanket approval. It should be tied to\nuh action, timestamp, actor and\nexpiration. So for instance, if a user\nhas given uh an approval to approve a\n$30 refund, it shouldn't turn into a\nsubsequent approval for $300 refund.\nIt is important that whenever an\napproval is given, it should be tied to\nthe particular parameters that it was uh\nasked for.\nSo, uh observability is an important\nrequirement when building AI agents\nbecause uh\nand logs are not enough. Teams need to\nreconstruct when an agent failed, what\nhappened, what information was was it\nreacting to and why it failed. And logs\nalone are not enough to uh for an agent\nto uh for teams to determine that.\nIt is important to trace the model that\nwas called, the prompt that was uh that\nwas uh given to it and uh also the tool\ncalls that were made uh the request uh\nthat was made, the response from the\ntool, the errors that it got, the\nretrieved context, what the agent was uh\nwas the the retrieved information that\nthe agent was reacting to, the rights\nthat it made, and the approvals that it\ngot and so on.\nSo uh I would like to uh end with uh the\nidea that yes model capability matters.\nHaving good models uh improves the uh\nlikelihood of it making uh correct\noperations. Smarter models reduce\nmistakes. It uh it uh improves the\ncapability that the model has. However,\nit cannot eliminate network failures,\nstale data or adversarial input. It is\nimportant when building this\narchitecture,\nwe also reason about can we bound,\nobserve and recover from actions\nperformed by the AI agent. It is\nimportant to have tool contracts in\nplace to ensure that uh it is only\nallowed to make uh operations that it is\nuh given that it is provided the\ncontract and the contracts are clearly\nestablishing the request and response uh\nresponse uh response types uh the schema\nand all these tools have item potency\nbaked into it. so that uh when repeated\nrequests are sent in uh it is not\ncausing unsafe operations to be retried.\nMoreover, there should be source of\ntruth decisions made uh when there are\nconflict conflicting uh memory states.\nIt is important uh for the agent to\nrealize this is the source of data that\nit should rely on and we should have re\nretry policies uh like rate limits set\nin to ensure that the agent is not uh\nretrying uh ext uh aggressively.\nMoreover, uh permissions should be set\nup. There should be traces and recovery\npaths. So\nwhen building AI agents, we should also\nask what the system lets it do when it\nis wrong.\nThank you.\n>> [music]",
  "transcript_chars": 13724,
  "ingested_at": "2026-09-03T10:30:30.913226+00:00",
  "source": "channel",
  "yt_meta": {
    "view_count": null,
    "like_count": null,
    "channel_id": null,
    "categories": null,
    "tags": null
  }
}