Viren Baraiya, co-founder and CTO of Orkes and original creator of Netflix Conductor, explains how to run AI agents safely in production. He covers background, scheduled, event-driven and long-running agents; argues that the harness around an agent is itself an application mixing deterministic and non-deterministic parts; and introduces his 'brain and hands' split where the LLM plans what should happen next while a deterministic, durable harness executes with approval gates, idempotent steps and recorded side effects. He frames agent harnesses as late-bound sagas—workflows the agent assembles at runtime—and demos an SRE agent whose plan is compiled into a Conductor workflow and executed over two check-and-re-plan loops. Recorded at the AI Engineer World's Fair 2026 in San Francisco. # Video Identity Observations ## Source Material Overview - **Title:** *Brains vs Hands: How to Run AI Agents Safely in Production — Viren Baraiya* - **Format:** Conference talk (~15–20 minutes) with a live/demo walkthrough, presented to an in-person audience. ## Intended Audience ### Practitioners running agents in production - The speaker opens by polling the room: *"How many of our many of you are running agents in production today? Awesome. So, a lot of hands up."* - Content assumes familiarity with engineering concepts such as **microservices, Kubernetes, sagas, idempotency, and workflow orchestration** — e.g., *"if you go back to the old school thought of microservices… you are not going to ship a microservice in production that does everything."* - Examples are operations-oriented: **SRE agents, DevOps, alert monitoring, cluster restarts** — *"I have a production system running where my alerts are firing every now and then… I would like my agents to listen to those events and react."* ### Builders evaluating agent architecture - The talk frames a design pattern for engineers choosing between agentic and deterministic control flow: *"the responsibility of a non-deterministic agent is to plan… not really to do things. Um and then Harness is the one who does actually execution."* ## Claimed Scope ### Problem scope - Addresses production operation of **broad agent types**, not just chatbots: *"when we start thinking about agents in a broader terms… background agents, background workers, agents that are running on schedule… event-driven agents… long-running coordinators… multi-agent systems."* ### Core claimed insight - The **"brains vs hands" separation**: *"Harness is the hands, the brain is the LLM"* — with the agent proposing plans and a deterministic harness executing them, including **human approval gates** (*"I probably want to have a human gate, uh probably send a Slack message"*). - Framed as an evolution of known patterns: *"this is not necessarily a new concept… they are essentially late bound sagas."* ### Demonstrated (not just claimed) - A demo showing a **self-planning remediation loop** compiled into a deterministic workflow: *"This gets compiled into a very deterministic workflow. We are relying on a conductor as a workflow execution engine here."* The speaker explicitly flags its staged nature: *"Of course it's a demo so you know everything is kind of pre-planned."* ## Self-Description / Commercial Evidence - **Organizational affiliation:** The speaker represents **Orkes**: *"Orkes, we provide enterprise edition."* - **Product promotion:** *"The example that I showed you runs on conductor. Conductor is an open source workflow orchestration platform that supports building agentic loops as well as agentic systems."* - **Interoperability claim:** *"If you want to run your LangChain agents or OpenAI agents or any kind of agents, Conductor can handle all of those things."* - **Audience engagement calls to action:** *"Join our Slack… We have a booth here at Orkes. Drop by if you want to see a live demo."* ## Distinguishing Observations - **Creator claims:** durability as "table stakes," determinism guarantees, human-gated approvals — all stated design positions, not verified outcomes. - **Demonstrated patterns:** a pre-planned canned demo; claims about real production SRE usage are asserted (*"I have a production system running"*) but not independently shown in the material. # Delivery Observations: "Brains vs Hands: How to Run AI Agents Safely in Production" *Speaker: Viren Baraiya. Source: transcript only. Curated metadata was not supplied.* ## 1. Overview The transcript shows a **conversational, filler-heavy** speaking style, a **consistent use of "right?" as a tag**, and a **deliberate structure** built on signposting, analogy, and a single named takeaway. All observations below come from text alone, so vocal qualities such as pitch, pace, and emphasis cannot be assessed. ## 2. Tone and Register - **Informal and conversational.** The speaker addresses the room directly and uses contractions and spoken fillers throughout. > "Cool. Thank you all for joining this morning. I know it's been an exciting week." - **Audience-involving.** The speaker polls the room mid-talk. > "How many of our many of you are running agents in production today? Awesome. So, a lot of hands up." - **Measured, not promotional, in the technical sections.** Claims are framed as personal experience or preference. > "at least in my world, has to be very deterministic set of processes" ## 3. Vocabulary and Recurring Phrases ### Verbal tags and fillers | Feature | Approximate frequency | Example | |---|---|---| | **"right?"** as a tag | Very frequent | "If you think about it, right? Your harness is the application and vice versa, right?" | | **"Um" / "Uh"** fillers | Very frequent | "Um What What we start to kind of realize is" | | **"kind of" / "kinda"** hedging | Frequent | "It kind of stops being a microservice at that point in time." | | **"So,"** as a sentence opener | Frequent | "So, let's take a look at it right." | ### Self-referential recall The speaker repeatedly reattaches to earlier points with a stock formula. > "And as I mentioned, right? Harness runs more than just an agent loop." > "And as I mentioned, right? The loop that the harness runs spans across agent" > "as I said, right? Like we did analyze the logs" This recall pattern appears at least three times, suggesting a habit of linking back to earlier material. ### Coined or repeated terms - **"harness"** is used as the central term for the orchestrating layer, defined in terms of the agent: "a harness that is responsible for achieving a specific goal." - **"brains and the hands"** is introduced as a memorable framing: "The clear separation between as we would like to call, right? The brains and the hands. Harness is the hands, the brain is the LLM." - **"late bound sagas"** is a named reframing of an older concept: "When you think about agentic harnesses, they are essentially late bound sagas." - **"cost of admission"** is used as a contrast phrase: "durability is a cost of admission. That's not the feature that you're looking for in a harness." ## 4. Teaching Habits ### Signposting the key point The speaker explicitly flags importance several times. > "And this is an important thing that I kind of learned uh, while trying to build harnesses for real-world production use cases." > "If If one thing that I would like everyone to take away from here is this slide" > "So, this is the most important thing, right?" These markers appear at multiple points, so the speaker consistently tells the audience when a point matters. ### Analogy to familiar concepts The speaker maps new ideas onto established ones: - **Microservices:** "There is kind of a very clear uh parallel to that when it comes to agent harnesses" - **Sagas and workflows:** "If you think about workflows as sagas, which we used to write ourselves and define exactly what happens." ### Reframing the category The speaker repeatedly contrasts a narrow starting picture with a broader one. > "that's a very small narrow picture if you think about it. When you think about agents in production, it's not just always about chatbots." > "the agent starts to feel more like an application, not just a component, right?" ### Contrast pairs Many points are built as explicit either/or contrasts: > "the responsibility of a non-deterministic agent is to plan, is to plan what should happen next, not really to do things." > "Harness should decide how to restart the cluster" ### Concrete scenario walkthroughs Abstract claims are followed by specific examples: restarting a Kubernetes cluster, sending a Slack approval message, and an SRE agent running a remediation loop. ## 5. Communication Patterns ### Hedged prescriptions Recommendations are often softened with first-person preference language. - "I probably want to have a human gate" - "I would like this to be idempotent" - "I would like to have an agent that runs every hour" The hedging is consistent in prescriptive passages, but the speaker also makes firm statements such as "it has to be very deterministic." ### Self-aware demo framing > "Of course it's a demo so you know everything is kind of pre-planned and a can demo." The speaker discloses that the demo is scripted, a candid framing that appears once. ### Call to action > "feel free to try it out. Here's a QR code. Give it a try. Join our Slack and you know, if you have questions, happy to help." The close shifts from content to product: the speaker points to the open-source project, the enterprise edition, and a booth. ## 6. Structural Pattern The talk follows a recognizable arc: 1. **Audience check:** a poll about production use. 2. **Reframe:** from chatbots to broader agent systems. 3. **Analogy:** agents as microservices and applications. 4. **Core claim:** deterministic harness, non-deterministic planning. 5. **Named concept:** "brains and the hands," "late bound sagas." 6. **Demo:** a scripted SRE remediation run. 7. **Close:** product pointer and call to action. ## 7. Confidence and Limitations - **Single source.** Only one transcript was provided, so "recurring" means repeated within this talk. Cross-talk consistency cannot be established. - **Text-only evidence.** Filler counts reflect transcription, which may omit or normalize some sounds. - **Transcript artifacts.** Some duplications such as "If If" and "What What" may be transcription errors, not delivery features, so they are not treated as stylistic. - **No vocal evidence.** Pace, pitch, and emphasis are not observable here. # Observation Record: "Brains vs Hands: How to Run AI Agents Safely in Production" **Speaker:** Viren Baraiya (per title; transcript uses no name, but a single continuous first-person talk consistent with the title attribution) --- ## 1. Context and Audience Framing - The speaker opens by polling the audience on how many are running agents in production, noting "a lot of hands up." He contrasts this with a conference a couple of weeks prior where "I think I had like one hand" — offered as evidence that "things are moving forward." - He situates the talk against a week of heavy discussion about agents and coding agents. ## 2. Claims About the Scope of Production Agents The speaker argues the common "hello world" mental model — an agent making a tool call, using context/memory, and planning — is "a very small narrow picture." ### Broader agent categories he identifies - **Background agents / workers** — e.g., an agent running hourly to check his schedule for new items. - **Event-driven agents** — citing his own production system where alerts fire and logs stream; he wants agents listening to those events and reacting. - **Long-running coordinators** — an agent monitoring another long-running agent and potentially nudging it to move forward or take different action. - **Multi-agent systems** — he claims "the last thing you want is to have an agent be responsible for multiple things and risk hallucinations," implying single-responsibility agents. ## 3. Core Position: The Harness Is the Application - The agent "starts to feel more like an application, not just a component." - He draws a parallel to **microservices**: you don't ship one microservice that does everything (it "stops being a microservice"); you ship multiple single-responsibility services coordinated via choreography/orchestration. - Applied to agents: a harness with a specific goal (e.g., SRE work) operates multiple agents — listening to logging events, talking to a Kubernetes cluster agent, metrics systems, dashboards. - **Key formulation:** "Your harness is the application and vice versa." An agent alone doesn't deliver the premise; a harness controlling the agent's execution does. - The full system includes databases/internal/enterprise systems, **human in the loop**, and tools via APIs or MCP. ## 4. Deterministic vs. Non-Deterministic Composition - Described as something he "learned while trying to build harnesses for real-world production use cases." - **Non-determinism** (LLM reasoning, thinking) is desirable only where appropriate. - **Determinism** must not be contaminated: he cites payments, and a Kubernetes cluster restart that should be "a very deterministic set of processes... every time it runs, I know exactly what it does." ## 5. Harness Characteristics - **Long-running:** from a few seconds to days, months, or longer (order management waiting on third parties or human approvals); often just waiting on events. - **Durability:** required because harnesses run on infrastructure that can fail (cloud outages, network partitions). Notably, he qualifies durability as **"a table stake thing... a cost of admission"** — not the feature you seek in a harness. - The harness loop maintains a **state of the world**: completed work, recorded side effects (cluster restart done, email sent), what worked or didn't — then decides next steps based on state + goal. ## 6. Central Takeaway: Brains and Hands Separation He flags this slide as the one thing he'd like everyone to take away: > "The responsibility of a non-deterministic agent is to plan... not really to do things... and then Harness is the one who does actual execution." - The **harness is deterministic code** that knows what executing work actually involves — e.g., *how* to restart a cluster; "every cluster restart is exactly same." - **Human gates** must be guaranteed: for a production cluster restart, a Slack approval message should be sent — "I do not want this to be left to a hallucination by an LLM." - Execution should be **idempotent**, or if not, the non-idempotence and side effects should be recorded and handled separately. - Summary formulation: **"Harness is the hands, the brain is the LLM. The agent writes the plan, Harness executes the plan."** ## 7. Historical Framing: "Late-Bound Sagas" - He explicitly states this is "not necessarily a new concept," comparing to **workflows as sagas** written by hand — fully deterministic processes. - Claim: agentic harnesses are **"late bound sagas"** — a finite, deterministic set of tools and tasks, but assembled by the agent at runtime rather than upfront. - Benefits inherited from traditional sagas: visibility, controllability, choice of planning horizon (one step vs. multiple steps ahead). - Analogy to a **branching workflow**: with *n* tools, agents can produce *n* execution combinations "which otherwise is going to be almost impossible to think ahead of time." ## 8. Demo Description (SRE Remediation Agent) - The speaker discloses the demo is pre-planned: "of course it's a demo so you know everything is kind of pre-planned and a can demo." - Flow shown: 1. LLM call produces a **proposed sequence of steps** (gather evidence, analyze logs, optionally roll back deployment, verify recovery) — not one step at a time. 2. A specialized **"plan and compile"** tool compiles the plan into a deterministic workflow. 3. **Conductor** (an open-source workflow execution engine) executes it. 4. The loop runs twice; in iteration two, it decides **not** to roll back because rollback already occurred in iteration one — illustrating state awareness. - He claims this pattern "can run in production as many times as you want," on events or schedules, for arbitrarily long durations. ## 9. Product Promotion (Concluding Segment) - The demo runs on **Conductor**, described as an open-source workflow orchestration platform supporting agentic loops and systems; **Orkes** provides an enterprise edition. - Claim: Conductor can run "LangChain agents or OpenAI agents or any kind of agents." - Audience invited to QR code, Slack, and the Orkes booth for live demos. --- ## Notes on Qualifications and Unresolved Points - The demo's pre-scripted nature is acknowledged by the speaker but not demonstrated otherwise. - Hallucination risk is cited as motivation for determinism, but no error or failure case is shown in the demo. - The claim that agents should be single-responsibility to limit hallucination risk is asserted without supporting evidence in the transcript. - Durability is framed as necessary but explicitly downgraded to "table stakes," not a differentiator — a qualification preserved as stated. # Speaker & Provenance Record — "Brains vs Hands: How to Run AI Agents Safely in Production — Viren Baraiya" ## Speaker Identification - **Speaker: Viren Baraiya** (per video title) - **Role: Conference presenter** — delivers a 15–20 minute technical talk to a live audience ("Thank you all for joining this morning"), including audience Q&A-style hand-raising and a live demo. - **Organizational affiliation: Orkes** — the speaker says "we provide enterprise edition," "We have a booth here at Orkes," identifying himself as representing the company. - No other speakers, guests, or interviewers appear in the transcript. ## Talk Structure (Provenance of Claims) - All technical claims are **first-person from the presenter** in the talk itself; no cited external sources, papers, or studies are referenced. - Presenter explicitly frames one segment as a **prepared demo**: *"Of course it's a demo so you know everything is kind of pre-planned and a canned demo."* Later claims about the demo's behavior should not be treated as live production evidence. - Claims described as drawn from personal production experience: - Running an event-driven production system with alerts and logs. - Learning about harness design *"while trying to build harnesses for real-world production use cases."* ## Referenced Tools & Systems (Named by Speaker) - **Conductor** — open-source workflow orchestration platform; the demo runs on it. - **Orkes** — company providing the Conductor enterprise edition. - **LangChain agents / OpenAI agents** — named as agent types Conductor can run. - General infrastructure references: Kubernetes, LLMs, MCP, APIs, Slack, microservices, saga/workflow patterns. ## Promotional Segments (Flagged) - **Closing promotion for Conductor/Orkes**: "Conductor is an open source workflow orchestration platform… Orkes, we provide enterprise edition. But feel free to try it out. Here's a QR code… Join our Slack… We have a booth here at Orkes. Drop by if you want to see a live demo." - This is a **direct product promotion embedded in the talk** — the presenter has a commercial stake in the demonstrated platform. ## Third-Party Claims - **Audience claim**: Many attendees raised hands indicating they run agents in production; compared to another conference where, per the speaker, only one hand went up. (Anecdotal, unverified.) - No external research, statistics, or third-party assertions are cited. ## Comment Availability - No information in the source material about comments or audience Q&A following the talk. ## Evidence Boundaries - Transcript only; no curated metadata beyond title and video ID. - Demo outputs shown verbally ("analyze the logs, look at the query of the metrics, decided to do a rollback") — actual screenshots/visuals not verifiable from transcript. \>\> Cool. Thank you all for joining this morning. I know it's been an exciting week. A lot of talk about agents, building agents, coding agents and everything. And what I want to talk in the next 15-20 minutes is is about running agents in production. Um And things that is kind of on the top of pretty much everybody's mind when it comes to building agents and running agents is you know, harnesses. Before I get started, like I would like to ask in the audience, right? How many of our many of you are running agents in production today? Awesome. So, a lot of hands up. Um I was in another conference couple of weeks ago and I asked the same question. I think I had like one hand, so this is pretty good. It seems like, you know, things are moving forward. Um All right. So, when we think about agents, right? Like if we go back to kind of the hello world equivalent examples of agents, uh it's always starts with, you know, an agent with a tool call and how well an LLM kind of decides to call the tool, maybe use some sort of context or a memory and and plans things ahead, right? Um What What we start to kind of realize is is you know, that's a very small narrow picture if you think about it. When you think about agents in production, it's not just always about chatbots. The early examples that we had seen were all about like, you know, hey, we are going to build a customer service chatbot or some sort of chatbot. Um But when we start thinking about agents in a broader terms and picture, think about background agents, background workers, agents that are running on schedule. Um I would like to have an agent that runs every hour to check uh what's happening with my schedule and if there is something new that has popped up that I should think about. Uh event-driven agents, right? Agents that are listening on various events. Um to give you an example, I have a production system running where my alerts are firing every now and then. I have a logs coming through hotel. I would like my agents to listen to those events and react on it and see what's going on there, right? Um I could have long-running coordinators and what I mean by that is I have an agent running for a longer period of time. I would like to have an agent monitoring that agent to see, "Hey, what's going on there? And should I nudge that agent to kind of move forward, take a different action?" And things like that, right? Um also one more thing is about multi-agent systems, right? Agents talking to other agents. Uh the last thing you want is to have an agent be responsible for multiple things and risk hallucinations. Uh So, more we think about agents, right? Uh the way I would like to think about is the agent starts to feel more like an application, not just a component, right? Um If you go back to the old school thought of microservices, when we and probably we are still building microservices, right? Um you are not going to ship a microservice in production that does everything, right? It kind of stops being a microservice at that point in time. Uh typically, we are shipping multiple microservices. They are talking to each other through choreography or orchestration. And you have an application that is relying on that the set of microservices, uh which essentially are single responsibility principles uh to kind of deliver the business goals. There is kind of a very clear uh parallel to that when it comes to agent harnesses, right? If you think about a harness that is responsible for achieving a specific goal. So, let's say I have an harness for doing my SRE work. Um, it's operating on multiple agents to see what's going on there, right? Maybe it's listening on events coming from my logging system, talking to my Kubernetes cluster as an agent uh, to find out, you know, what's going on there. Uh, my metric systems, my customer service uh, dashboards and and so on and so forth. Um, and what I want to drive there is that if you think about it, right? Your harness is the application and vice versa, right? An agent alone doesn't kind of deliver the whole premise, but rather when you start putting things together and you build an harness that controls the execution of the agent, delivers on the premise, that's where you start thinking about um, an application, right? And which is you have systems uh, which are your databases, your internal systems, enterprise systems. You have humans, human in the loop. Um, you have tools through either APIs or MCP that is all kind of playing together. Um, and as I mentioned, right? Harness runs more than just an agent loop. And this is an important thing that I kind of learned uh, while trying to build harnesses for real-world production use cases. It's a combination of both deterministic and non-deterministic part of the application, right? Non-determinism is delivered by an LLM in terms of the reasoning, in terms of thinking process. Um, and then there is non-deterministic and there is deterministic part, right? Which you do not want non-determinism seeping into it, right? Think about payments. Um, or let's say if I have an agent harness that is responsible for monitoring my production deployment, how I manage my Kubernetes clusters, I probably want to have a very well-defined workflow in terms of what are the sequence of steps that I execute when I want to restart my cluster. And that's a very deterministic set of processes which every time it runs, I know exactly what it does. So, I want a determinism to be delivered by my harness when it matters. Um and of course the harness is a long running process, right? It runs across the time. It can run um anywhere from few seconds if it's uh something very quick like hey, check what's going on here to all the way running for days, months, uh even longer than that, right? Think about long running processes, order management systems where you are waiting on third party services to deliver your shipment or waiting on humans to take actions and approve things and so on and so forth. Or Harness is just waiting, right? It's waiting for events to happen. So, when that event happens you take an action and do something around it. So, that brings in another important point, right? That when you think about long running systems, you need durability, right? You want to be able to recover when things fail because at the end of the day this harnesses are running somewhere in your entire infrastructure stack, right? Maybe in the cloud, maybe on a sandbox but those things can go up, go down. There could be network failures, partitioning, anything that could be happening. So, you need the harnesses to be durable. And one thing about durability here is it's a table stake thing, right? At the end of the day durability is a cost of admission. That's not the feature that you're looking for in a harness. Um And as I mentioned, right? The loop that the harness runs spans across agent um and everything else. So, now let's think about uh how the harnesses kind of operate, right? Um If you think about a harness, right? And and a loop, essentially what it is doing it it has a state of the world. It knows what work been completed. Um what has been recorded in terms of the side effects, right? So, like if I did a cluster restart, uh I know I have that recorded. Uh if I sent an email, I know that has happened. Um I know what worked or didn't work, and then based on the current state of the world and the goal, I know what needs to happen next, right? And that's where the reasoning and LLM comes into the picture. Um and what really happens here is that if you think about a clear distinction, and this is the most important thing. If If one thing that I would like everyone to take away from here is this slide, which is that the responsibility of a non-deterministic agent is to plan, is to plan what should happen next, not really to do things. Um and then Harness is the one who does actually execution. And And this is important for uh various reasons, right? One being that Harness is a deterministic piece of code that actually understands what is involved in, you know, actually executing a piece of work. So, as I mentioned, right? If I am trying to uh build a Harness that runs my uh DevOps or SRE uh agents, uh when the agent says that, "Hey, this cluster is unhealthy and you should restart." Harness should decide how to restart the cluster, what involves in restarting cluster, and that has to be, at least in my world, has to be very deterministic set of processes, right? So, that every cluster restart is exactly same. There is no other uh category there, right? Um Also, if it needs to have an approval, for example, if I am trying to restart a production cluster, I probably want to have a human gate, uh probably send a Slack message to somebody to say, "Hey, I'm going to restart this cluster. Do you think it's okay to do that or not, right?" And I do not want this to be left to a hallucination by an LLM that, you know, it doesn't need to do it. It needs to be guaranteed in terms of execution. So, it has to be very deterministic when it comes to those kind of things. Uh ideally, I want this to be idempotent and if not, I want it to be recording that, you know, it is not idempotent and this is what has happened. So, I can get take care of the side effects or I can handle the side effects separately, right? Uh So, this is the most important thing, right? The clear separation between as we would like to call, right? The brains and the hands. Harness is the hands, the brain is the LLM. Um So, yeah, if the agent writes the plan, uh Harness executes the plan, uh and I'll show you in a brief uh a short demo in terms of how all of these things kind of matches together. Um But, is this a new concept? Like, if you think about it, this is not necessarily a new concept. This has been around for a while, right? If you think about workflows as sagas, which we used to write ourselves and define exactly what happens. It was a very and it is a very deterministic set of processes. When you think about agentic harnesses, they are essentially late bound sagas. And what I mean by that is that they have a very finite and deterministic set of tools uh and the task that they can operate on. Instead of putting them together upfront, the agent is kind of proposing and building them at runtime. Um and therefore, they are essentially late bound sagas, right? Uh but you get all the benefits of a traditional saga in a workflow out of the box in terms of visibility, what's happening, being able to control things, and iterating upon like, you know, how far ahead in the future uh the agent is able to plan. You are able to kind of plan one step at a time or multiple steps at a time. Um And yeah, if you think about it, right? It's it's more like a branching workflow. If only you could build a workflow with every possible combination of a branch, um then, you know, it kind of builds that thing for you right versus with agents that kind of simplifies the work. If you have n number of tools it can do n different combinations of executions which otherwise is going to be almost impossible to you know think ahead of time and and do it. So let's take a look at it right. So what I'm going to do is I'll quickly show a completed run. Of what I talked about earlier right. Here is one of my example agent that essentially is acting like an SRE agent right. What its job is to do is understand what's going on in the current system and try to plan what should happen next and execute on those things. So it's essentially a remediation loop that runs twice. In the first iteration it tries to understand the root cause of the problem, tries to react to that, observes the output of it and then runs another loop and plans another set of steps to see what should happen next right. So as an input to my agent let's see what was the input given right here. So step number one is you know it makes a call to LLM. So as you can see right like it's an SRE agent. Of course it's a demo so you know everything is kind of pre-planned and a can demo. The output of LLM as you can see right are the steps what it should do. It's talking about so as you can see one more thing here right is that instead of just doing one step at a time essentially it is proposing a sequence of steps to do. You should gather evidences, you should analyze logs and if required based on the evidence that you gathered you should either roll back a deployment and then verify recovery. This is then given to a specialized tool called plan and compile. So, this is the plan that agent gave. This gets compiled into a very deterministic workflow. We are relying on a conductor as a workflow execution engine here. So, the output is a fully runnable workflow. This gets executed. So, like you know, what I'm going to show you here very quickly is how that looks like. Um So, this is the first step of execution, right? If we look at it here as I said, right? Like we did analyze the logs, look at the query of the metrics, decided to do a rollback and verify recovery and everything. So, step number one is completed. It runs another loop. Um same thing goes here. Um In the next iteration, it decides that, okay, looks like, you know, these things have been done. Let's check the downstream. And if required, verify the recovery and complete it, right? Um And then the next one runs and completes the task. But here is an example of a loop that is self uh kind of uh planning, right? So, and to show you very clearly what's going on here, here is a loop. Um At every step of the way, essentially, it is looking at the current state of the world. So, this is my agentic loop that is kind of understanding the world, planning and executing uh one step instead of one step at a time, it is actually planning multiple steps at a time, executing that, verifying, and completing the loop. Um Now, this can run in production as many times as you want. This can be running on the events. It can be running on a schedule. Um As I said, right? Like this the whole thing could be running for a much longer period of time um as opposed to just running in a short period of time. All right. So, that's towards the end of it. This is kind of overview of what we just did here. As you can see right in the second iteration, we decided not to do a rollback because it was already done in the first iteration. But yeah, that's about the harnesses and agents and how they bring determinism to your production application. The example that I showed you runs on conductor. Conductor is an open source workflow orchestration platform that supports building agentic loops as well as agentic systems. It's fully open source. Orkes, we provide enterprise edition. But feel free to try it out. Here's a QR code. Give it a try. Join our Slack and you know, if you have questions, happy to help. We have a booth here at Orkes. Drop by if you want to see a live demo. If you want to run your LangChain agents or OpenAI agents or any kind of agents, Conductor can handle all of those things. Thank you.