Padrão Saga e Transações Compensatórias em Agentes de IA: Consistência em Execuções Distribuídas

A execução autônoma de ferramentas por agentes de IA corporativos introduz mutações no mundo real que comandos SQL não conseguem reverter.

Quando um agente interage com gateways de pagamento, ERPs e operadores logísticos, falhas parciais de rede geram estados inconsistentes caso o fluxo trave.

Protocolos clássicos como Two-Phase Commit (2PC) são inviáveis na web devido ao bloqueio de recursos e à falta de suporte ao padrão XA.

Formulado por Garcia-Molina e Salem (1987)¹, o Padrão Saga decompõe fluxos longos em transações locais com transações compensatórias.

No Programa MaxVision, essa engenharia de resiliência é construída no repositório do cliente durante o sprint de 15 dias com o fundador técnico.

Sistemas distribuídos desacoplados que alteram múltiplos serviços necessitam de isolamento de falhas e mecanismos explícitos de reversão semântica².

Em agentes de IA, esses princípios separam o raciocínio heurístico do modelo da camada determinística de persistência e compensação.

Por que o Two-Phase Commit falha em fluxos de agentes de IA

O Two-Phase Commit (2PC) falha em agentes de IA porque provedores externos de API não suportam XA e o bloqueio de recursos degrada a latência.

Em bancos relacionais monolíticos, transações obedecem rigorosamente ao padrão ACID. Quando a operação cruza múltiplos bancos, o 2PC divide o trabalho em preparação e efetivação³.

Entretanto, agentes corporativos integrarem serviços heterogêneos. Provedores de pagamento (como Stripe) e CRMs expõem apenas APIs REST comuns sem interfaces de commit em duas fases.

A latência de inferência de LLMs oscila entre centenas de milissegundos e vários segundos.

Manter bloqueios em tabelas enquanto a IA processa etapas gera fila de conexões, lentidão severa e risco elevado de travamentos sistêmicos.

Além disso, falhas de conectividade durante a fase de preparação podem deixar transações suspensas indefinidamente nos nós participantes.

A mecânica formal do Padrão Saga e transações compensatórias

O Padrão Saga garante que uma transação longa seja concluída por inteiro ou tenha seus efeitos intermediários desfeitos semanticamente.

No modelo formal de Garcia-Molina e Salem¹, uma transação longa S é estruturada como uma sequência ordenada de subtransações locais:

S = (T_1, T_2, ..., T_n)

Cada subtransação T_i altera o estado do respectivo serviço e comita o resultado no banco local.

Para cada etapa T_i reversível, a arquitetura implementa uma transação compensatória correspondente C_i.

A garantia de execução de uma Saga determina que exatamente um de dois caminhos finais ocorrerá:

1. Caminho de Sucesso: (T_1, T_2, ..., T_n) executado até a conclusão.
2. Caminho Compensado: (T_1, T_2, ..., T_k, C_k, C_(k-1), ..., C_1) onde k < n.

Fluxo de Execução Direta:
[ Início ] ──> [ T_1: Reserva Estoque ] ──> [ T_2: Cobra Cartão ] ──> [ T_3: Emite NF ] ──> [ Sucesso ]

Fluxo de Compensação Semântica (Falha em T_3):
[ Início ] ──> [ T_1: Sucesso ] ──> [ T_2: Sucesso ] ──> [ T_3: FALHA ]
                                                             │
[ Fim: Compensado ] <── [ C_1: Libera Estoque ] <── [ C_2: Estorna Cobrança ] <──┘

A compensação semântica difere de um ROLLBACK de banco de dados tradicional.

Uma transação compensatória C_i é uma nova operação de negócio criada para anular o impacto prático de T_i⁴.

Se T_2 debitou um cartão, C_2 dispara uma requisição de estorno no gateway de pagamento.

Se T_1 bloqueou unidades no estoque, C_1 emite a devolução dessas unidades para o saldo disponível no inventário.

Tipologia de subtransações em fluxos de trabalho autônomos

A arquitetura de uma Saga divide as ações do agente em três categorias distintas de subtransações.

As três categorias descritas na literatura de microsserviços² organizam o fluxo de recuperação:

1. Transações Compensáveis (Compensable Transactions): Operações que precedem o ponto de decisão e contam com uma ação reversora C_i. Exemplos: bloqueio de estoque e criação de pedidos provisórios.
2. Transação Pivô (Pivot Transaction): O divisor de águas do fluxo. Se a transação pivô comitar, a Saga avança obrigatoriamente até o fim. Se falhar, aciona a compensação reversa.
3. Transações Retentáveis (Retriable Transactions): Operações após o ponto pivô que possuem garantia de sucesso eventual via retentativas idempotentes com backoff exponencial. Exemplos: envio de e-mails e disparo de webhooks.

Classificação de Passos:
┌───────────────────────────────┐   ┌──────────────────┐   ┌───────────────────────────────┐
│   Transações Compensáveis     │   │ Transação Pivô   │   │    Transações Retentáveis     │
│  T_1: Reserva Inventário (C_1) │──>│  T_3: Autoriza   │──>│  T_4: Despacha Rastreio Frete │
│  T_2: Pré-autoriza Cartão (C_2)│   │  Pagamento SEFAZ │   │  T_5: Notifica via WhatsApp   │
└───────────────────────────────┘   └──────────────────┘   └───────────────────────────────┘

Essa separação impede desenhar reversões inviáveis no mundo real.

Ações sem possibilidade de cancelamento devem ser configuradas estritamente após a transação pivô como etapas retentáveis.

Caso uma etapa retentável encontre indisponibilidade temporária de rede, o motor repete a chamada com chave de idempotência fixa.

Orquestração vs. coreografia na coordenação de agentes de IA

A orquestração centralizada via máquinas de estado é a abordagem recomendada para agentes de IA por assegurar observabilidade e controle determinístico.

Sistemas distribuídos utilizam dois modelos para coordenar etapas de uma Saga⁵:

1. Coreografia (Orientada a Eventos)

Na coreografia, cada serviço escuta eventos em mensageria assíncrona e emite novos eventos ao terminar a tarefa. Não existe controlador central.

Essa abordagem torna a auditoria opaca em fluxos de agentes. Acompanhar raciocínios cognitivos e ramificações condicionais de LLMs torna-se muito complexo em produção.

Quando múltiplos agentes publicam e assinam tópicos sem governança central, o risco de dependências circulares aumenta drasticamente.

2. Orquestração (Saga Orchestrator Centralizado)

Na orquestração, um componente dedicado gerencia a máquina de estados, executa ferramentas e comanda a compensação em falhas⁶.

Para agentes autônomos, a orquestração oferece três benefícios centrais:

• Estado Cognitivo Unificado: O histórico e o progresso residem em um único registro no PostgreSQL.
• Separação de Camadas: O LLM define parâmetros, mas o orquestrador governa travas e regras de execução.
• Recuperação Durável: Reinicializações de servidores permitem retomar a Saga exatamente do ponto salvo no banco de dados.

Modelagem de dados e persistência durável no PostgreSQL

A persistência do estado da Saga no PostgreSQL requer tabelas relacionais com suporte a transações ACID e controle estrito de concorrência.

O esquema relacional registra o ciclo de vida da Saga, vinculando correlações únicas e chaves de idempotência:

CREATE TYPE saga_status AS ENUM (
  'PENDING',
  'RUNNING',
  'COMPLETED',
  'COMPENSATING',
  'COMPENSATED',
  'FAILED'
);

CREATE TYPE step_status AS ENUM (
  'PENDING',
  'RUNNING',
  'COMPLETED',
  'FAILED',
  'COMPENSATED'
);

CREATE TABLE sagas (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  correlation_id VARCHAR(128) NOT NULL UNIQUE,
  saga_type VARCHAR(64) NOT NULL,
  status saga_status NOT NULL DEFAULT 'PENDING',
  payload JSONB NOT NULL,
  current_step_index INT NOT NULL DEFAULT 0,
  error_details JSONB,
  created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
  updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

CREATE TABLE saga_steps (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  saga_id UUID NOT NULL REFERENCES sagas(id) ON DELETE CASCADE,
  step_index INT NOT NULL,
  step_name VARCHAR(64) NOT NULL,
  status step_status NOT NULL DEFAULT 'PENDING',
  forward_action VARCHAR(64) NOT NULL,
  forward_payload JSONB,
  forward_response JSONB,
  compensating_action VARCHAR(64),
  compensating_payload JSONB,
  compensating_response JSONB,
  idempotency_key VARCHAR(128) NOT NULL,
  retry_count INT NOT NULL DEFAULT 0,
  executed_at TIMESTAMPTZ,
  compensated_at TIMESTAMPTZ,
  created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
  CONSTRAINT uq_saga_step UNIQUE (saga_id, step_index)
);

CREATE INDEX idx_sagas_status ON sagas(status);
CREATE INDEX idx_saga_steps_idempotency ON saga_steps(idempotency_key);

Cada etapa registra os parâmetros originais de envio e os dados para execução compensatória.

Em caso de falha, o orquestrador recupera todas as informações do disco e executa o cancelamento sem consultar novamente o LLM.

Essa abordagem garante que mesmo falhas catastróficas de infraestrutura não causem perda do contexto operacional de reversão.

Implementação do Orquestrador de Sagas em TypeScript

O motor de orquestração executa os passos de forma determinística e comuta automaticamente para a sequência reversa ao identificar erros irrecuperáveis.

O trecho a seguir apresenta a estrutura central de um orquestrador resiliente em TypeScript:

import { createHmac } from "node:crypto";

export interface SagaStepDefinition<TContext> {
  name: string;
  forward: (context: TContext, idempotencyKey: string) => Promise<unknown>;
  compensate?: (context: TContext, idempotencyKey: string) => Promise<unknown>;
}

export class SagaOrchestrator<TContext extends { correlationId: string }> {
  constructor(
    private readonly steps: SagaStepDefinition<TContext>[],
    private readonly secretKey: string
  ) {}

  private generateKey(correlationId: string, index: number, action: string): string {
    return createHmac("sha256", this.secretKey)
      .update(`${correlationId}:${index}:${action}`)
      .digest("hex");
  }

  public async execute(context: TContext): Promise<{ success: boolean; error?: unknown }> {
    const executedStepIndexes: number[] = [];

    for (let i = 0; i < this.steps.length; i++) {
      const step = this.steps[i];
      const forwardKey = this.generateKey(context.correlationId, i, "forward");

      try {
        await step.forward(context, forwardKey);
        executedStepIndexes.push(i);
      } catch (error) {
        await this.rollback(context, executedStepIndexes);
        return { success: false, error };
      }
    }

    return { success: true };
  }

  private async rollback(context: TContext, executedIndexes: number[]): Promise<void> {
    for (let j = executedIndexes.length - 1; j >= 0; j--) {
      const stepIndex = executedIndexes[j];
      const step = this.steps[stepIndex];

      if (step.compensate) {
        const compensateKey = this.generateKey(context.correlationId, stepIndex, "compensate");
        try {
          await step.compensate(context, compensateKey);
        } catch (compensationError) {
          console.error(`Falha crítica na compensação do passo ${step.name}:`, compensationError);
        }
      }
    }
  }
}

A geração determinística de chaves (generateKey) garante que retentativas no loop de compensação não causem chamadas duplicadas nos gateways externos.

Com chaves únicas por etapa e ação, os serviços externos reconhecem requisições repetidas e retornam a resposta cacheada com segurança.

Como o Programa MaxVision constrói arquiteturas de IA em produção

A consultoria 1:1 de 15 dias do Programa MaxVision implementa esteiras completas de engenharia e resiliência diretamente na infraestrutura do cliente.

Em vez de diagnósticos teóricos em slides, o trabalho acontece no código-fonte ao vivo com o fundador técnico da empresa parceira.

Os quatro pilares do método de co-building de 15 dias:

1. Engenharia em Código Real: Desenvolvimento direto no repositório Git corporativo (origin/main), sem intermediários proprietários.
2. Modelo BYOK (Bring Your Own Key): Controle total de dados e infraestrutura, com credenciais e chaves pertencendo à sua organização.
3. Fatia Vertical em Produção (Thin Vertical Slice): Uma esteira funcional operando com máquinas de estado, Sagas e telemetria após 15 dias.
4. Acervo Técnico Permanente: Quatro sessões ao vivo gravadas em vídeo com todo o racional de arquitetura documentado.

Para implementar agentes autônomos em produção com tolerância real a falhas, consulte os detalhes de aplicação em /maxvision.

Fontes primárias e referências técnicas