Databricks Mostra Como Criar Agentes Duráveis com Temporal e Lakebase, mas a Demonstração Expõe a Parte Difícil

A Databricks publicou, em 8 de setembro, uma implementação de referência mostrando como criar agentes duráveis com Temporal e Lakebase apesar de falhas de workers, tentativas repetidas e revisões de vários dias. O sistema aplica essa arquitetura à análise de crédito para empréstimos pessoais, em que perder uma verificação concluída pode corromper o histórico de uma decisão.

A mudança importante não é mais um framework de agentes nem um modelo maior. Databricks e Temporal dividiram o estado do agente entre dois sistemas com responsabilidades diferentes. O Temporal preserva o fluxo de controle, enquanto o Lakebase expõe dados operacionais que aplicações, revisores e analistas podem consultar.

Essa divisão também cria a tensão central. A execução durável pode recuperar o trabalho registrado, mas não consegue garantir que todo efeito externo ocorra exatamente uma vez. A aplicação ainda precisa de identificadores estáveis, gravações protegidas no banco de dados, regras de versão de políticas e reconciliação quando os componentes divergem.

Databricks Transforma a Durabilidade de Agentes em um Sistema Testável

A implementação de referência trata um agente como um processo de negócios de longa duração, e não como uma sessão temporária de chat.

A implementação de referência acompanha uma solicitação de empréstimo desde a coleta de evidências até uma decisão humana. Seu agente realiza verificações de crédito, renda, relação dívida-renda e política de subscrição como operações separadas.

O exemplo usa solicitantes e provedores simulados, portanto não processa pedidos reais de empréstimo. Essa escolha mantém o experimento focado no comportamento de execução, em vez do desempenho do modelo de crédito.

Um solicitante de exemplo tem pontuação de crédito de 665 e uma sinalização de inadimplência não material. O agente coleta as evidências, avalia limites de política específicos para a finalidade e gera uma recomendação. Ele não pode tomar a decisão final de crédito.

Um analista de crédito precisa aprovar, recusar ou solicitar mais informações. Essa última opção estende o mesmo caso para outra interação com o agente, preservando as evidências anteriores e a justificativa do revisor.

O cenário é deliberadamente mais difícil do que uma única solicitação a um modelo. Um worker pode parar depois que várias verificações forem concluídas. Uma gravação no banco de dados pode ser confirmada antes que sua conclusão chegue ao Temporal. Um revisor pode deixar o caso aberto por dias.

Um navegador desatualizado também pode enviar um comando obsoleto depois que o caso avançou. Ao mesmo tempo, a política de subscrição pode mudar sem uma implantação correspondente da aplicação.

Essas situações geram seis requisitos práticos: recuperação, tentativas repetidas controladas, esperas duráveis, visibilidade operacional, governança em tempo de execução e histórico de auditoria. Uma transcrição por si só não consegue atendê-los.

Uma transcrição registra mensagens, mas não necessariamente todo o fluxo de controle. Ela não mostra automaticamente qual operação foi concluída, qual resultado foi aceito ou qual comando avançou o processo.

A implementação, portanto, atribui a cada execução de empréstimo um Workflow do Temporal. Um Workflow é um fluxo de controle durável cujo histórico registrado permite que outro worker reconstrua seu estado.

Chamadas a modelos, bancos de dados e ferramentas de subscrição são executadas como Activities. Uma Activity é uma operação que pode ser repetida e cujo resultado pode ser registrado no Event History do Workflow.

As respostas dos revisores chegam como Signals, que são comandos assíncronos entregues a um Workflow aberto. O Temporal pode manter essa espera sem reservar um processo de worker por vários dias.

React e FastAPI tratam a aplicação voltada ao usuário. Eles iniciam execuções, exibem evidências, listam casos e enviam decisões de revisão. O Temporal Cloud armazena o histórico de execução e distribui tarefas aos workers.

O Lakebase Postgres mantém a projeção voltada à aplicação. Uma projeção é uma representação consultável do estado atual do workflow, construída a partir de atualizações produzidas durante a execução.

O Unity Catalog continua sendo a fonte das regras de subscrição. Uma tabela continuamente sincronizada disponibiliza essas regras pelo Lakebase, para que os workers possam ler políticas atualizadas sem uma implantação de código.

Essa arquitetura torna o comportamento diante de falhas dos agentes visível e reproduzível. Ela transforma a durabilidade de uma promessa genérica em um conjunto de contratos específicos de recuperação e consistência.

No entanto, a demonstração não reúne esses contratos em um único banco de dados. Temporal e Lakebase continuam sendo sistemas separados, e a lacuna entre eles conduz às questões de engenharia mais difíceis.

A Memória do Agente Não É Estado de Execução

Um agente durável precisa de decisões registradas sobre o fluxo de controle, não apenas de mensagens armazenadas ou memórias recuperadas.

Muitos sistemas de agentes descrevem a persistência como memória. Eles salvam uma conversa, recuperam documentos anteriores ou colocam um resultado intermediário em um banco de dados. Essas capacidades ajudam os modelos a recuperar contexto, mas não reconstroem a execução.

Suponha que um worker conclua uma verificação de crédito e depois seja encerrado. Um substituto precisa determinar se o resultado foi registrado, se outra tentativa é segura e qual operação deve ser executada em seguida.

Esse é um problema de fluxo de controle. Ele inclui Activities agendadas, resultados concluídos, temporizadores, comandos humanos aceitos, tentativas de repetição e a rodada de revisão atual.

O Temporal armazena essas informações em um Event History ordenado. Durante a reprodução, o código do workflow consome esses eventos registrados e reconstrói variáveis como evidências, uso de tokens e estado da revisão.

Um resultado de Activity registrado retorna durante a reprodução, em vez de ser executado novamente. Portanto, uma verificação de crédito concluída ou uma resposta de modelo registrada permanece fixa para aquela execução de workflow.

Uma conclusão não registrada apresenta outro caso. Um provedor de modelos pode terminar de processar uma solicitação imediatamente antes de o worker perder a conectividade. Se o Temporal nunca receber o resultado, poderá agendar outra tentativa.

Essa limitação importa porque chamadas a modelos não são isentas de efeitos colaterais nem têm garantia de determinismo. Uma segunda resposta pode diferir da primeira, mesmo com entrada idêntica.

A demonstração atribui políticas de repetição a tipos individuais de operação. Activities de modelo permitem até quatro tentativas dentro de uma janela de três minutos entre agendamento e fechamento.

Activities de ferramentas permitem até três tentativas, com um timeout de 60 segundos entre início e fechamento. Activities do Lakebase permitem até cinco tentativas, com um timeout de 15 segundos entre início e fechamento.

Esses números descrevem a configuração de exemplo, não padrões universais de produção. As equipes precisam definir limites de repetição de acordo com o comportamento do provedor, as metas de latência, os modos de falha e as consequências posteriores.

O modelo de execução durável do Temporal aborda a recuperação de processos ao preservar o histórico necessário para a reprodução. Ele não torna automaticamente um pagamento, e-mail, mutação de banco de dados ou solicitação a modelo seguro para repetição.

Cada operação externa precisa de um contrato de idempotência. Idempotência significa que tentativas repetidas convergem para um resultado pretendido, em vez de produzirem efeitos duplicados.

A demonstração de empréstimo constrói esse contrato com identificadores determinísticos. Uma execução, mensagem, chamada de ferramenta, evento, rodada de revisão e decisão do revisor recebem, cada um, uma identidade estável.

Chaves primárias e restrições de unicidade do Postgres impedem que as tentativas repetidas criem cópias ilimitadas. Upserts permitem que uma tentativa repetida tenha como alvo a mesma linha lógica.

Atualizações protegidas acrescentam outra camada. Elas permitem apenas transições válidas de estado, como mover uma chamada de ferramenta pendente para concluída sem reabrir um registro terminal.

Ainda assim, até uma atualização protegida precisa de interpretação cuidadosa. O PostgreSQL pode afetar zero linhas sem gerar erro quando o alvo já atingiu um estado terminal.

O artigo da Databricks reconhece que o wrapper atual de Activity nem sempre transforma esse resultado de zero linhas em falha. O código de produção deve inspecionar o estado armazenado antes de tratá-lo como inofensivo.

Esse detalhe separa uma referência útil de engenharia de um padrão de produção finalizado. A orquestração durável fornece o mecanismo de recuperação, enquanto os desenvolvedores da aplicação ainda definem semânticas de negócio seguras.

O mesmo princípio se aplica fora da subscrição. Provedores de pagamento precisam de chaves de idempotência, sistemas de e-mail precisam de identificadores estáveis de mensagem, e ferramentas sem suporte precisam de registros de reconciliação.

As equipes que criam um agente interno também precisam de uma camada pesquisável de evidências. Uma base de conhecimento de engenharia estruturada pode ajudar pessoas a examinar documentação, decisões e contexto técnico em torno desses workflows.

A lição mais ampla é precisa: a memória ajuda um modelo a lembrar, enquanto a execução durável ajuda um sistema a continuar. Agentes de produção geralmente precisam de ambos, mas os dois não são intercambiáveis.

Crie Agentes Duráveis com Temporal e Lakebase Separando Responsabilidades

O design funciona porque Temporal e Lakebase mantêm diferentes tipos de verdade para diferentes consumidores.

O Temporal é responsável pela verdade da execução. Seu histórico determina quais tarefas foram concluídas, quais temporizadores dispararam, quais Signals chegaram e o que um worker em reprodução deve fazer em seguida.

O Lakebase é responsável pela visão atual da aplicação. Ele armazena status de execução, mensagens, evidências de ferramentas, registros de revisão, eventos operacionais, metadados de recomendação e métricas de repetição em tabelas relacionais.

Essa divisão permite que a interface do usuário consulte casos atuais com padrões SQL comuns. Revisores podem encontrar casos pendentes, inspecionar uma recomendação ou comparar medições operacionais entre execuções.

As evidências aparecem antes do fechamento de um Workflow. Assim que a consulta de política é concluída, o resultado estruturado fica disponível junto com limites, valores reais, resultados de regras, justificativa e fonte da política.

Isso importa em sistemas com revisão humana. Um revisor não deve esperar que todo o processo termine antes de ver as evidências por trás de uma recomendação.

A aplicação usa dois esquemas do Lakebase. O esquema agent_ops mantém registros operacionais, enquanto agent_policy contém uma cópia somente leitura da política de subscrição governada.

Cada Activity grava linhas usando identificadores alinhados ao Workflow. Assim, uma repetição pode atualizar o mesmo registro lógico enquanto a projeção do banco de dados se atualiza.

O Lakebase não se torna parte da reprodução do Temporal. Esse limite impede que consultas comuns da aplicação decidam a execução do workflow, mas também significa que as atualizações não são atômicas entre os dois sistemas.

Um evento do Temporal pode ser registrado enquanto uma projeção do Lakebase permanece temporariamente atrasada. Uma gravação no banco de dados também pode ser confirmada antes que o Temporal registre a conclusão da Activity correspondente.

A arquitetura aceita essa lacuna e usa consistência eventual. Consistência eventual significa que visualizações separadas podem divergir brevemente, mas convergem por meio de tentativas repetidas e gravações determinísticas.

Esse é um design razoável para dashboards e listas de casos. Ele exige mais cautela quando uma visualização do banco de dados é usada para validar um comando que afeta o estado de negócio.

O Lakebase oferece acesso familiar ao Postgres e indexação orientada à aplicação. Seu modelo de banco de dados operacional também oferece suporte a memória de agentes, estado atual e cargas de trabalho de serving de recursos.

Sua capacidade computacional pode escalar automaticamente dentro dos limites configurados. O scale-to-zero pode suspender capacidade ociosa, embora a primeira consulta após um período de inatividade possa sofrer latência de ativação.

Esses recursos de banco de dados ajudam com tráfego irregular de agentes. Eles não eliminam o planejamento de capacidade, os limites de conexão, a configuração de pools ou os testes de recuperação.

O caminho das políticas é igualmente importante. O Unity Catalog armazena limites específicos por finalidade, incluindo regras de crédito e de relação dívida/renda. Uma tabela sincronizada continuamente apresenta esses valores dentro do Lakebase.

Os responsáveis pelas políticas podem atualizar a fonte sem reimplantar o worker ou a API. Uma consulta posterior pode ler as regras propagadas do Postgres.

Isso evita incorporar todos os limites de negócio ao código da aplicação. Também introduz uma questão de sincronização das políticas que a camada de orquestração precisa responder explicitamente.

Um caso em aberto deve manter as regras aplicadas no início ou adotar uma política mais recente durante uma etapa posterior? Ambas as escolhas têm consequências para consistência, auditabilidade e tratamento do cliente.

A demonstração registra os limites aplicados e a fonte junto à recomendação. Essa evidência permite que revisores reconstruam qual política embasou um resultado específico.

Quando o Lakebase está indisponível, o exemplo pode usar uma política de fixture e registrar esse caminho de fallback. O artigo observa corretamente que um fluxo de trabalho regulado poderia, em vez disso, falhar de modo fechado.

Essa escolha não pode ser delegada a uma biblioteca de repetição. Responsáveis pelo produto, equipes de compliance e engenheiros precisam definir se uma política desatualizada ou de fallback é legal e operacionalmente aceitável.

O caminho de retorno proposto usa o Lakebase Change Data Feed. Depois de ativado, ele pode capturar mutações no banco de dados e publicá-las em tabelas de histórico Delta gerenciadas pelo Unity Catalog.

A Databricks afirma que o feed agrupa mudanças aproximadamente a cada 15 segundos. Esse intervalo é adequado para auditoria e análise retrospectivas, enquanto a aplicação lê o estado atual diretamente do Lakebase.

No entanto, o repositório apenas prepara seus esquemas para esse caminho. Ele não contém uma execução observada de ponta a ponta do feed no ambiente de destino.

Portanto, criar agentes duráveis com Temporal e Lakebase exige três limites claros: verdade de execução, verdade operacional e histórico analítico governado.

O padrão se torna valioso quando esses limites são explícitos. Ele se torna perigoso quando as equipes presumem que a palavra “durável” significa que todos os componentes sempre concordam.

A Revisão Humana Expõe o Trade-off de Consistência

A espera pelo analista mostra por que a durabilidade precisa incluir identidade de comando, rejeição de estado desatualizado e validação independente do Workflow.

Depois que o modelo produz uma recomendação, o Workflow cria um identificador de revisão a partir da execução e da rodada atual. Ele registra a revisão pendente no Lakebase e entra em AWAITING_REVIEW.

O Temporal então aguarda uma condição sem manter um worker ocupado. O Workflow aberto pode sobreviver à substituição de processos enquanto o humano leva tempo para responder.

A API aceita aprovação, recusa ou um pedido de mais informações. Primeiro, ela verifica se o Lakebase ainda mostra a revisão relevante como pendente.

Ela também compara o identificador de revisão enviado com a rodada de revisão atual. Uma divergência produz um conflito em vez de encaminhar uma decisão obviamente desatualizada.

Essa pré-verificação no banco de dados melhora a experiência do usuário, mas não é autoritativa. A projeção do Lakebase pode ficar atrasada em relação ao Temporal, especialmente enquanto uma Activity é repetida.

Por isso, a API envia o comando como um Signal, e o Workflow o valida novamente em relação ao estado da execução. Decisões duplicadas ou desatualizadas são ignoradas dentro do fluxo de controle durável.

Essa segunda verificação é essencial. Uma aba do navegador pode permanecer aberta enquanto outro revisor avança o caso, ou uma solicitação anterior pode chegar depois que uma nova rodada de revisão começa.

Uma resposta HTTP 202 confirma apenas que o Temporal recebeu o Signal. Isso não significa que o Workflow aceitou a decisão de negócio.

O cliente deve atualizar a visualização do Lakebase para observar o estado resultante. Essa distinção impede que a confirmação de transporte seja confundida com a aprovação do empréstimo.

Quando o Workflow aceita uma decisão, uma Activity idempotente do Lakebase a persiste. A aprovação ou a recusa conclui a execução.

Um pedido de mais informações retoma a execução. A justificativa do revisor torna-se uma nova mensagem de usuário, a rodada avança, e a próxima recomendação recebe um novo identificador de revisão.

Esse mecanismo dá a cada rodada de revisão um limite estável. Ele também torna visível o principal trade-off: o estado responsivo da aplicação é separado do estado autoritativo da execução.

As equipes precisam projetar para divergências temporárias. As interfaces devem comunicar claramente comandos pendentes, conflitos, projeções atrasadas e ações desatualizadas rejeitadas.

Os painéis operacionais também precisam distinguir a espera intencional da falha. Um caso aguardando um analista está saudável, enquanto uma Activity presa em repetições requer intervenção.

A demonstração expõe métricas nos níveis de Workflow, rodada e tentativa de Activity. Operadores podem inspecionar o histórico do Temporal, consultar o estado do Lakebase e verificar o ambiente do worker separadamente.

Essa separação ajuda a diagnosticar se uma demora vem da revisão humana, da disponibilidade do modelo, da autenticação do banco de dados ou de uma ferramenta com falha.

Ela também amplia a superfície operacional. As equipes precisam monitorar Temporal, Lakebase, implantações de workers, pools de conexão, tarefas de sincronização e os contratos que os conectam.

A autenticação introduz outra preocupação de longa duração. O cliente Lakebase usa OAuth machine-to-machine e atualiza seu pool de conexões antes que as credenciais temporárias do banco de dados expirem.

Sem rotação de credenciais, um worker pode falhar em uma programação previsível mesmo que seu Workflow permaneça recuperável. Um fluxo de controle durável não torna conexões expiradas utilizáveis.

Desenvolvedores que comparam frameworks de agentes duráveis devem, portanto, olhar além do suporte a checkpoints. Devem perguntar como os comandos são identificados, como os efeitos colaterais são desduplicados e onde vive o estado autoritativo.

Também devem testar deliberadamente interações desatualizadas. Abra duas sessões de revisão, avance uma delas e, em seguida, envie a decisão mais antiga.

Uma implementação correta deve rejeitar ou ignorar com segurança esse comando. Ela deve reter evidências suficientes para explicar o resultado posteriormente.

O exemplo de empréstimo é útil porque conecta esses detalhes a uma decisão relevante. A aprovação humana não é uma pausa decorativa entre chamadas ao modelo.

Ela é uma transição de estado com identidade, autorização, contexto de política e requisitos de auditoria. Isso a torna um teste de durabilidade mais rigoroso do que um assistente conversacional reiniciando após um erro.

A Demonstração Não Comprova Prontidão para Produção

A Databricks apresenta uma arquitetura crível, mas suas próprias evidências deixam pendentes a conformidade em crédito, a escala e a validação completa do ciclo de dados.

O repositório relata 21 testes aprovados cobrindo sequenciamento de workflow, comportamento de revisão, construção de OAuth, persistência idempotente, contratos de métricas, inicialização da API e configurações de worker.

Um exercício de recuperação após falha usa um provedor determinístico. Ele interrompe a execução do worker e verifica que o progresso registrado sobrevive após o retorno do processo.

Esses testes sustentam a alegação restrita de durabilidade. Eles mostram que o fluxo de controle e os contratos de persistência do exemplo se comportam como esperado sob falhas selecionadas.

Eles não validam o agente como um sistema de crédito. Registros de solicitantes e respostas de provedores são fixtures, enquanto o provedor roteirizado padrão evita uma dependência de modelo ao vivo.

O repositório não estabelece qualidade do modelo de crédito, conformidade regulatória, segurança de produção, disponibilidade regional ou desempenho em escala. A Databricks declara essas limitações diretamente.

O exercício local de falha também foi executado com o Lakebase desativado. Ele isola a recuperação do Temporal, mas não verifica a recuperação em todo o caminho de dados integrado.

Da mesma forma, o caminho do Change Data Feed continua sendo uma tarefa de ativação e implantação. O exemplo prepara as tabelas, mas não mostra a chegada observada do histórico de ponta a ponta.

O Change Data Feed estava em Public Preview quando o artigo foi publicado. O status de prévia é relevante para equipes que exigem compromissos maduros de suporte ou cobertura regional validada.

O banco de dados e o Workflow não compartilham uma transação. Identificadores estáveis e repetições proporcionam convergência, mas as equipes ainda precisam de reconciliação para divergências prolongadas ou inesperadas.

Um processo de reconciliação em produção deve localizar Workflows sem projeções correspondentes. Também deve detectar efeitos confirmados no banco de dados cujos resultados de Activity nunca entraram no Event History.

A sincronização de políticas merece o mesmo escrutínio. Uma execução posterior pode consumir uma política atualizada sem implantação, mas uma execução em aberto precisa de uma regra documentada de versão de política.

O comportamento de fallback cria outro risco. A demonstração pode substituir uma política de fixture quando o Lakebase está desativado ou uma linha de política não está disponível.

Esse comportamento ajuda no desenvolvimento local, mas um fallback silencioso seria inaceitável em muitos ambientes regulados. O sistema registra o fallback, mas os responsáveis pelas políticas precisam decidir se a execução deve continuar.

O desempenho permanece sem testes nas evidências publicadas. Cargas de trabalho de agentes podem criar gravações em rajadas, históricos longos, transcrições extensas e filas de revisão desiguais.

Retenção do histórico do Temporal, volume de repetições, latência do modelo, concorrência de workers, limites de conexão do banco de dados e atualizações de projeção afetam o comportamento do sistema.

O escalonamento automático do Lakebase pode responder à demanda, mas novas conexões e dados aquecidos continuam sendo importantes. A redução para zero também pode trocar eficiência em inatividade por latência de reativação.

Os requisitos de segurança vão além de TLS e credenciais temporárias. Uma plataforma real de análise de crédito precisaria de autorização rigorosa, controles sobre dados sensíveis, regras de retenção e limites de acesso para auditoria.

A recomendação do modelo também precisa de governança independente. Registrar evidências e políticas melhora a rastreabilidade, mas não estabelece que a recomendação seja justa ou precisa.

Uma avaliação completa testaria o raciocínio sobre ação adversa, evidências ausentes, dados conflitantes de provedores, mudanças de política e tentativas de manipular entradas de ferramentas.

Ela também testaria incidentes operacionais que cruzam limites entre componentes. Exemplos incluem sincronização de políticas indisponível, projeções atrasadas, rotação parcial de credenciais e provedores externos indisponíveis.

Portanto, a arquitetura deve ser interpretada como orientada à produção, não certificada para produção. Essa distinção fortalece a referência porque torna visível o trabalho restante.

A Databricks mostrou como atribuir responsabilidade entre orquestração, armazenamento operacional e dados governados. Ela não eliminou a necessidade de validar cada contrato sob carga real.

Três Sinais Mostrarão se Este Padrão se Sustenta

As próximas evidências devem testar a recuperação integrada, a consistência das políticas e a adoção além da demonstração controlada de análise de crédito.

O primeiro sinal é uma implantação observada de ponta a ponta do Change Data Feed. O sistema publicado prepara tabelas operacionais, mas deixa incompletas a ativação do feed e a verificação do destino.

Uma validação bem-sucedida deve rastrear uma execução, desde a evidência da ferramenta, passando pela revisão humana, até o histórico gerenciado pelo Unity Catalog. Ela também deve documentar atraso, duplicatas, mudanças de esquema e recuperação após interrupção.

Esse resultado fortaleceria a alegação de que a atividade operacional pode retornar ao histórico analítico governado. A dependência contínua de um caminho não verificado enfraqueceria a narrativa do ciclo completo de dados.

O segundo sinal é um estudo público de carga e falhas que use Lakebase durante todo o teste de recuperação. Ele deve incluir falhas de worker, repetições do banco de dados, rotação de credenciais e atraso de projeção.

Resultados úteis relatariam o comportamento de conclusão, a distribuição de repetições, a rejeição de comandos desatualizados e o tempo necessário para o estado da aplicação convergir.

Isso testaria a arquitetura como um sistema combinado, em vez de validar a recuperação do Temporal de forma isolada. Também revelaria onde aparecem limites de escalabilidade ou gargalos operacionais.

O terceiro sinal é a adoção em um fluxo de trabalho real com revisão humana. Crédito é apenas uma demonstração, mas requisitos semelhantes aparecem no processamento de sinistros, em compras, na resposta a incidentes de segurança e em aprovações reguladas.

Uma implementação confiável deve explicar como versiona políticas, reconcilia o estado, controla o comportamento de fallback e audita intervenções humanas. Essas práticas importam mais do que o provedor de modelo escolhido.

As evidências de uma implementação desse tipo sustentariam o julgamento central do artigo. Agentes duráveis são aplicações distribuídas cujas falhas precisam ser modeladas explicitamente.

Uma implementação que reduza a durabilidade a checkpoints de conversação apontaria na direção oposta. Ela deixaria efeitos colaterais, longas esperas e políticas em constante mudança fora do contrato de recuperação.

Para desenvolvedores, a questão imediata não é se todo agente precisa de Temporal e Lakebase. Muitas tarefas curtas e somente de leitura não justificam dois sistemas gerenciados e uma camada de projeção.

A questão é se um agente pode sobreviver ao seu worker, alterar estado externo, esperar por pessoas ou aplicar políticas que mudam de forma independente. Essas características criam a necessidade de execução durável.

Se elas descrevem seu sistema, analise a arquitetura de agentes, reproduza seus testes de falha e questione cada efeito colateral que possa ser repetido. Em seguida, teste o que acontece quando a verdade da execução e a verdade operacional divergem temporariamente.

Esse é o padrão prático para equipes que buscam criar agentes duráveis com Temporal e Lakebase. Comece com um fluxo de trabalho consequente, defina a autoridade de cada sistema e torne as evidências de recuperação parte da revisão do produto.