Cérebros vs. mãos: como executar agents com segurança em produção — Viren Baraiya

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Brains vs Hands: How to Run AI Agents Safely in Production — Viren Baraiya · Canal: AI Engineer · 16:06 · Assistir no YouTube

Tópicos: Agentes de IA, Automação de tarefas e workflows, Engenharia de software com IA, Infraestrutura e hardware de IA

Resumo

Viren Baraiya explica por que executar agents em produção exige mais do que um LLM capaz de usar ferramentas: é preciso um harness que coordene sistemas, pessoas e processos duráveis. A ideia central é separar o planejamento não determinístico do LLM da execução determinística controlada pelo harness. Essa divisão ajuda a garantir aprovações humanas, lidar com efeitos colaterais e tornar as operações previsíveis. A demonstração mostra um agent de SRE que propõe planos convertidos em workflows executáveis com Conductor.

Pontos-chave

Agents em produção podem funcionar em segundo plano, reagir a eventos, executar em horários programados ou coordenar outros agents.
Um harness é a aplicação que controla a execução dos agents e integra ferramentas, sistemas e pessoas.
O harness combina raciocínio não determinístico do LLM com processos determinísticos para ações que exigem previsibilidade.
O agent deve planejar o que precisa acontecer; cabe ao harness executar o plano.
Ações críticas, como reiniciar um cluster de produção, devem seguir etapas definidas e podem exigir aprovação humana.
O harness precisa registrar efeitos colaterais e considerar se as operações são idempotentes.
Sistemas de longa duração precisam ser duráveis para se recuperar de falhas de infraestrutura e rede.
O palestrante descreve harnesses agentic como sagas com associação tardia: o agent propõe workflows a partir de um conjunto definido de ferramentas.
Na demonstração, um agent de SRE analisa evidências, propõe ações e verifica a recuperação em ciclos sucessivos.
Conductor é apresentado como uma plataforma open source de orquestração de workflows que pode executar loops e sistemas agentic.

Capítulos

Início	Capítulo	Resumo
00:01	Agents em produção: além do chatbot	A palestra apresenta diferentes formas de usar agents em produção, como tarefas agendadas, reações a eventos e sistemas multi-agent.
03:07	O harness como aplicação	O palestrante compara harnesses a aplicações compostas por serviços e explica como eles integram agents, sistemas, ferramentas e pessoas.
05:11	Determinismo, duração e resiliência	A discussão aborda a combinação de raciocínio do LLM com processos determinísticos e a necessidade de durabilidade em sistemas de longa duração.
07:12	Separar planejamento e execução	O agent propõe o que deve acontecer, enquanto o harness executa as ações de forma controlada, incluindo aprovações e registro de efeitos colaterais.
10:18	Workflows e sagas com associação tardia	O palestrante relaciona harnesses agentic a sagas e explica como os agents podem propor workflows a partir de ferramentas disponíveis.
11:51	Demonstração de um agent de SRE	A demonstração percorre um ciclo em que um agent analisa o sistema, propõe ações, executa um workflow no Conductor e verifica a recuperação.
15:34	Conductor e encerramento	O palestrante resume a demonstração e apresenta Conductor como plataforma open source, com edição enterprise fornecida pela Orkes.

Citações

A responsabilidade de um agent não determinístico é planejar o que deve acontecer em seguida, não executar as ações. — 08:16

O harness são as mãos; o cérebro é o LLM. — 09:48

A durabilidade é um requisito básico, um custo de entrada. — 06:42

O harness é a aplicação e vice-versa. — 04:10

Conceitos e entidades

agent harness (conceito): Camada que coordena agents, controla sua execução e integra ferramentas, sistemas e pessoas em uma aplicação.
deterministic execution (conceito): Execução de ações por processos definidos para produzir um comportamento previsível, especialmente em operações críticas.
durability (conceito): Capacidade de um sistema de longa duração de se recuperar de falhas e retomar o trabalho.
idempotency (conceito): Propriedade de uma operação cujo resultado não muda quando ela é repetida, importante para controlar efeitos colaterais.
late-bound sagas (conceito): Workflows determinísticos cujas etapas são propostas pelo agent em tempo de execução, em vez de serem montadas antecipadamente.
Conductor (ferramenta): Plataforma open source de orquestração de workflows usada na demonstração para executar o plano compilado em um workflow.
Orkes (empresa): Empresa mencionada como provedora da edição enterprise do Conductor.
Viren Baraiya (pessoa): Palestrante que apresenta práticas para executar agents em produção com segurança e previsibilidade.
LangChain (ferramenta): Ferramenta citada como uma das opções cujos agents podem ser executados com Conductor.
OpenAI (empresa): Empresa citada no contexto de agents que podem ser executados com Conductor.

Tradução completa (pt-BR)

00:01 [música] >> Legal. Obrigado a todos por estarem aqui esta manhã. Sei que foi uma semana empolgante. Falou-se muito sobre agents, criar agents, agents de programação e tudo mais. E o que quero discutir nos próximos 15 a 20 minutos é como executar agents em produção.

00:32 E uma das coisas que está na cabeça de praticamente todo mundo quando se trata de criar e executar agents são os harnesses. Antes de começar, gostaria de perguntar ao público: quantos de vocês estão executando agents em produção hoje? Excelente. Muita gente levantou a mão. Estive em outra conferência há algumas semanas e fiz a mesma pergunta. Acho que só uma pessoa levantou a mão, então este resultado é muito bom. Parece que vocês

01:03 sabem, as coisas estão avançando. Certo. Quando pensamos em agents, se voltarmos aos exemplos equivalentes ao “Olá, mundo” dos agents, eles sempre começam com um agent fazendo uma chamada de ferramenta e com a forma como um LLM decide fazer essa chamada, talvez usando algum tipo de contexto ou memória e planejando as coisas com antecedência. O que começamos a perceber é que esse é um quadro bem pequeno e limitado

01:33 quando pensamos nisso. Ao pensar em agents em produção, não se trata apenas de chatbots. Os primeiros exemplos que vimos eram todos do tipo: “Vamos criar um chatbot de atendimento ao cliente” ou algum outro tipo de chatbot. Mas, quando começamos a pensar em agents de forma mais ampla, consideramos agents em segundo plano, processos em segundo plano, agents que são executados em horários programados. Eu gostaria de ter um agent que fosse executado a cada hora para verificar o que está acontecendo na minha agenda e se surgiu algo novo em que eu deveria pensar.

02:04 Agents acionados por eventos, certo? Agents que ficam ouvindo vários eventos. Para dar um exemplo, tenho um sistema de produção em execução, no qual meus alertas disparam de vez em quando. Recebo logs por meio do hotel. Gostaria que meus agents escutassem esses eventos, reagissem a eles e verificassem o que está acontecendo, certo? Eu poderia ter coordenadores de longa duração. Com isso, quero dizer que tenho um agent em execução por um período mais longo. Gostaria de ter um agent

02:35 monitorando esse agent para ver: “Ei, o que está acontecendo? Devo dar um empurrãozinho nesse agent para ele avançar e tomar outra ação?” E coisas assim, certo? Outra coisa são os sistemas multiagentes, certo? Agents conversando com outros agents. A última coisa que você quer é que um agent seja responsável por várias coisas e corra o risco de alucinar. Então, quanto mais pensamos em agents, mais eles começam a parecer uma aplicação, não apenas

03:07 um componente, certo? Se voltarmos à ideia mais tradicional de microsserviços — e provavelmente ainda estamos criando microsserviços —, você não vai colocar em produção um microsserviço que faça tudo, certo? A essa altura, ele deixa de ser um microsserviço. Normalmente, colocamos vários microsserviços em produção. Eles se comunicam por meio de coreografia ou orquestração. E temos uma aplicação que depende

03:37 desse conjunto de microsserviços, que essencialmente seguem o princípio da responsabilidade única para ajudar a alcançar os objetivos de negócio. Há um paralelo bem claro com os agent harnesses. Pense em um harness responsável por alcançar um objetivo específico. Digamos que eu tenha um harness para fazer meu trabalho de SRE. Ele opera com vários agents para ver o que está acontecendo, certo? Talvez esteja escutando eventos que vêm do meu sistema de logging,

04:10 conversando com meu cluster Kubernetes por meio de um agent para descobrir o que está acontecendo. Com meus sistemas de métricas, meus painéis de atendimento ao cliente e assim por diante. E o que quero enfatizar é que, se você pensar bem, seu harness é a aplicação, e vice-versa. Um agent sozinho não concretiza toda a proposta. Isso acontece quando você começa a juntar as coisas e cria um harness que controla a execução do agent. É aí

04:41 que você começa a pensar em uma aplicação, certo? Nela, há sistemas, como bancos de dados, sistemas internos e sistemas empresariais. Há pessoas, com humanos no circuito. Há ferramentas, por meio de APIs ou MCP, e tudo isso funciona em conjunto. E, como mencionei, o harness executa mais do que apenas um loop de agent. Isso é algo importante que aprendi ao tentar criar harnesses para casos de uso reais em produção.

05:11 É uma combinação de partes determinísticas e não determinísticas da aplicação, certo? A não determinística é fornecida por um LLM, em termos de raciocínio e processo de pensamento. E há também a parte determinística, certo? Não queremos que o não determinismo se infiltre nela. Pense em pagamentos. Ou, digamos, se eu tiver um agent harness responsável por monitorar meu deploy em produção, como

05:41 gerencio meus clusters Kubernetes: provavelmente quero ter um workflow muito bem definido, com a sequência de etapas que executo quando quero reiniciar meu cluster. Esse é um conjunto de processos determinísticos que, sempre que é executado, sei exatamente o que faz. Portanto, quero que meu harness garanta o determinismo quando isso for importante. E, claro, o harness é um processo de longa duração, certo? Ele continua em execução ao longo do tempo. Pode durar de alguns segundos, se for

06:12 algo muito rápido, como “Ei, veja o que está acontecendo”, até dias, meses ou até mais, certo? Pense em processos de longa duração, como sistemas de gestão de pedidos, nos quais você espera que serviços de terceiros entreguem sua encomenda ou espera que pessoas tomem medidas, aprovem coisas e assim por diante. Ou o harness simplesmente fica esperando, certo? Ele espera que aconteçam eventos. Quando o evento acontece, você toma uma ação e faz algo a respeito. Isso traz outro ponto importante,

06:42 certo? Quando pensamos em sistemas de longa duração, precisamos de durabilidade. Você precisa conseguir se recuperar quando as coisas falham, porque, no fim das contas, esses harnesses estão sendo executados em algum lugar da sua infraestrutura, certo? Talvez na nuvem, talvez em um sandbox, mas esses ambientes podem ficar disponíveis ou indisponíveis. Pode haver falhas de rede, partições ou qualquer outro problema. Portanto, os harnesses precisam ser duráveis. E uma coisa sobre durabilidade é que ela é um requisito básico, certo? No fim das contas, durabilidade é o preço de entrada. Não é o recurso que você

07:12 procura em um harness. E, como mencionei, o loop executado pelo harness abrange o agent e todo o restante. Então, vamos pensar em como os harnesses funcionam. Se você pensar em um harness e em um loop, essencialmente, o que ele faz é manter um estado do mundo. Ele sabe qual trabalho foi concluído.

07:44 O que foi registrado em termos de efeitos colaterais, certo? Por exemplo, se reiniciei um cluster, sei que isso foi registrado. Se enviei um e-mail, sei que isso aconteceu. Sei o que funcionou ou não e, com base no estado atual do mundo e no objetivo, sei o que precisa acontecer em seguida, certo? É aí que o raciocínio e o LLM entram em cena. E o que realmente acontece aqui é que, se pensarmos numa distinção clara — e esta é a coisa mais importante —, se

08:16 houvesse uma coisa que eu gostaria que todos levassem daqui, seria este slide: a responsabilidade de um agent não determinístico é planejar, planejar o que deve acontecer em seguida, não fazer as coisas de fato. Quem executa é o harness. E isso é importante por vários motivos, certo? Um deles é que o harness é um trecho de código determinístico que realmente entende o que está envolvido na execução de uma tarefa. Então, como eu

08:46 mencionei, certo? Se estou tentando criar um harness que executa meus agents de DevOps ou SRE, quando o agent diz: “Ei, este cluster está instável e você deveria reiniciá-lo”, o harness deve decidir como reiniciar o cluster, o que está envolvido na reinicialização do cluster e, pelo menos no meu mundo, isso precisa ser um conjunto de processos muito determinístico, certo? Para que toda reinicialização de cluster seja exatamente igual. Não há outra categoria aí, certo?

09:17 Além disso, se for necessária uma aprovação, por exemplo, se estou tentando reiniciar um cluster de produção, provavelmente quero ter uma etapa de aprovação humana, talvez enviar uma mensagem no Slack para alguém dizendo: “Ei, vou reiniciar este cluster. Você acha que tudo bem fazer isso ou não?” E não quero deixar isso por conta de uma alucinação de um LLM que, sabe, decida que não precisa fazer isso. Isso precisa ser garantido em termos de execução. Então, esse tipo de coisa precisa ser muito determinístico. Idealmente, quero que isso seja idempotente e, se não for, quero que fique registrado que não é

09:48 idempotente e o que aconteceu. Assim, posso cuidar dos efeitos colaterais ou tratá-los separadamente, certo? Então, esta é a coisa mais importante, certo? A separação clara entre o que gostamos de chamar de cérebro e mãos. O harness são as mãos, o cérebro é o LLM. Então, sim, se o agent escreve o plano, o harness executa o plano, e vou mostrar brevemente, em uma demonstração curta, como todas essas coisas

10:18 se encaixam. Mas este é um conceito novo? Pensando bem, não é necessariamente um conceito novo. Isso existe há algum tempo, certo? Pense nos workflows como sagas, que costumávamos escrever e definir exatamente o que acontece. Era — e ainda é — um conjunto de processos muito determinístico. Os harnesses agentic são essencialmente sagas com vinculação tardia. Com isso, quero dizer que eles têm um conjunto muito finito e determinístico de ferramentas e tarefas nas quais podem

10:49 operar. Em vez de juntá-las de antemão, o agent propõe e as constrói em tempo de execução. Portanto, são essencialmente sagas com vinculação tardia, certo? Mas você obtém, desde o início, todos os benefícios de uma saga tradicional em um workflow, em termos de visibilidade do que está acontecendo, capacidade de controlar as coisas e de iterar sobre, sabe, o quanto o agent consegue planejar com antecedência. Você pode planejar uma etapa por vez ou várias etapas de cada vez.

11:21 E, pensando bem, certo? É mais como um workflow com ramificações. Se ao menos fosse possível criar um workflow com todas as combinações possíveis de ramificações, então ele construiria isso para você. Em vez disso, os agents simplificam o trabalho. Se você tem n ferramentas, elas podem realizar n combinações diferentes de execuções, algo que, de outra forma, seria quase impossível de prever e fazer com antecedência. Então, vamos dar uma olhada. O que

11:51 vou fazer é mostrar rapidamente uma execução concluída, sobre o que falei antes. Aqui está um dos meus agents de exemplo, que atua essencialmente como um agent de SRE. O trabalho dele é entender o que está acontecendo no sistema atual, tentar planejar o que deve acontecer em seguida e executar essas ações. Então,

12:22 é essencialmente um loop de remediação que é executado duas vezes. Na primeira iteração, ele tenta entender a causa raiz do problema, tenta reagir a ela, observa o resultado e, em seguida, executa outro loop e planeja outro conjunto de etapas para ver o que deve acontecer em seguida, certo? Então, como entrada para o meu agent, vamos ver qual foi a entrada fornecida aqui. A primeira etapa é que ele faz uma chamada ao LLM. Como vocês podem ver,

12:53 certo? É um agent de SRE. Claro, é uma demonstração, então tudo está meio que planejado de antemão e dá para demonstrar. A saída do LLM, como vocês podem ver, são as etapas que ele deve seguir. Ele fala sobre isso. Como vocês podem ver, há mais uma coisa aqui: em vez de executar uma etapa de cada vez, ele está propondo uma sequência de etapas. Você deve coletar evidências, analisar os logs e, se necessário,

13:24 com base nas evidências coletadas, deve reverter um deploy e depois verificar a recuperação. Isso é então enviado a uma ferramenta especializada chamada Plan and Compile. Este é o plano que o agent forneceu. Ele é compilado em um workflow muito determinístico. Aqui estamos usando o Conductor como mecanismo de execução de workflows. O resultado é um workflow totalmente executável. Ele é executado. Então, vou mostrar rapidamente como isso fica.

14:01 Esta é a primeira etapa da execução, certo? Se olharmos aqui, como eu disse, analisamos os logs, consultamos as métricas, decidimos fazer um rollback, verificar a recuperação e tudo mais. Então, a primeira etapa foi concluída. Ele executa outro loop. A mesma coisa acontece aqui. Na próxima iteração, ele decide: “Certo, parece que essas coisas já foram feitas. Vamos

14:32 verificar os sistemas dependentes. E, se necessário, verificar a recuperação e concluir”, certo? E então o próximo loop é executado e conclui a tarefa. Mas aqui está um exemplo de um loop que planeja por conta própria. Para mostrar claramente o que está acontecendo, aqui está um loop. A cada etapa, ele está observando o estado atual do mundo. Este é o meu loop agentic, que entende o mundo, planeja e executa; em vez de planejar uma etapa de cada vez, ele

15:03 na verdade, planeja várias etapas de cada vez, executa, verifica e conclui o loop. Agora, isso pode ser executado em produção quantas vezes você quiser. Pode ser executado em resposta a eventos. Pode ser executado em uma programação. Como eu disse, tudo isso pode ficar em execução por muito mais tempo, em vez de ser executado apenas por um período curto. Certo. Estamos chegando ao fim.

15:34 Esta é uma visão geral do que acabamos de fazer. Como vocês podem ver, na segunda iteração decidimos não fazer um rollback porque ele já tinha sido feito na primeira iteração. Mas é isso sobre harnesses e agents e como eles trazem determinismo às suas aplicações de produção. O exemplo que mostrei é executado no Conductor. O Conductor é uma plataforma open source de orquestração de workflows que oferece suporte à criação de loops agentic e também de sistemas agentic. É totalmente open

16:06 source. A Orkes oferece a edição empresarial. Mas fiquem à vontade para experimentar. Aqui está um QR code. Experimentem. Entrem no nosso Slack e, se tiverem dúvidas, teremos prazer em ajudar. Temos um estande da Orkes aqui. Apareçam se quiserem ver uma demonstração ao vivo. Se quiserem executar seus agents do LangChain, da OpenAI ou qualquer tipo de agent, o Conductor dá conta de tudo isso. Obrigado.

Transcrição original

[00:01] [music] >> 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.

[00:32] 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

[01:03] 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

[01:33] 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

[02:04] 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

[02:35] 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

[03:07] 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

[03:37] 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,

[04:10] 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

[04:41] 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.

[05:11] 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

[05:41] 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

[06:12] 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,

[06:42] 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

[07:12] 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

[07:44] 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

[08:16] 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

[08:46] 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

[09:17] 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

[09:48] 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

[10:18] 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

[10:49] 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.

[11:21] 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

[11:51] 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

[12:22] 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

[12:53] 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

[13:24] 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

[14:01] 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

[14:32] 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

[15:03] 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.

[15:34] 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

[16:06] 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.