Comunidade AWS testa padrão orquestrador-executor com Amazon Connect e Lex

Quem projeta automação conversacional na AWS esbarra cedo numa pergunta: o que fica por conta do LLM e o que fica por conta de um bot determinístico? Um projeto publicado no dev.to pela desenvolvedora peruana Sofia Torres Vilca, batizado de AppBarrio, responde essa pergunta com uma arquitetura que separa as duas responsabilidades em componentes diferentes, usando Amazon Q in Connect e Amazon Lex V2 lado a lado.

O caso de uso é doméstico: em muitos bairros do Peru, reservar uma quadra comunitária depende de controle informal, o que abre espaço para cobrança por fora e para os mesmos grupos sempre ocuparem os melhores horários. A solução proposta foi um agente de chat que responde dúvidas sobre preço e regulamento e também processa a reserva, sem aplicativo dedicado. O interessante para quem arquiteta sistemas na AWS não é o problema de negócio, mas a decisão estrutural por trás dele.

Por que um agente, e não só regras

Segundo a autora, um fluxo baseado só em regras já resolveria distinguir uma pergunta de uma reserva. A escolha por um agente de IA foi deliberada: ela queria que a conversa aceitasse frases que não encaixam em um fluxo fixo, sem abrir mão de determinismo nas operações críticas.

A AWS oferece capacidades de agente com LLM nativas dentro do Amazon Connect, já integradas ao chat, à transferência para atendente humano e ao Lex. Em vez de montar essa orquestração do zero com um LLM genérico, o projeto aproveitou o que o serviço gerenciado já entrega pronto.

Orquestrador e executor: quem faz o quê

A arquitetura final tem quatro papéis bem demarcados, e entender essa divisão é o que torna o padrão reaproveitável para qualquer time que for desenhar algo parecido:

Um detalhe que vale registrar para quem for auditar esse tipo de stack: ao abrir o console do Lex, aparecem dois bots, mas só um deles carrega regra de negócio. O outro existe exclusivamente como ponte técnica entre o agente e o Lex, o que pode confundir quem chega depois sem o contexto do design.

O que acontece quando a mensagem chega

O fluxo se divide em dois caminhos bem distintos. Numa pergunta como "quanto custa a quadra de futebol", o Amazon Q in Connect reconhece a intenção informativa, busca nos documentos indexados no S3 via base de conhecimento e redige a resposta, sem tocar no Lex.

Já numa frase como "quero reservar amanhã às 7", o agente identifica a operação transacional e repassa a conversa para o bot-reservas. A partir daí, o Lex assume e preenche os slots que faltam até acionar a Lambda de fulfillment, com um evento no formato:

{
 "sessionState": {
 "intent": {
 "name": "ReserveCourtIntent",
 "slots": {
 "sl_customer_dni": { "value": { "interpretedValue": "76543210" } },
 "slt_court_types": { "value": { "interpretedValue": "futbol" } },
 "sl_date": { "value": { "interpretedValue": "2026-11-01" } },
 "sl_time": { "value": { "interpretedValue": "19:00" } }
 }
 },
 "invocationSource": "FulfillmentCodeHook"
 }
}

A Lambda processa a solicitação, grava em DynamoDB e devolve o código de confirmação. Note que o LLM nunca chega a manipular diretamente DNI, data ou hora: ele só decide o roteamento, e quem valida e persiste o dado sensível é o bot determinístico.

Decisões de design que valem a pena copiar

Três escolhas de arquitetura aparecem no material e fazem sentido para qualquer time desenhando um agente sobre dados transacionais:

• Dado crítico vai para slot de Lex, não para o LLM. DNI, data e hora são coletados por slots validados, reduzindo o risco de um modelo alucinar ou interpretar errado um campo que vira registro no banco.
• Lambda separada por responsabilidade. Consulta de saldo, gestão de reserva e geração de resumo rodam em funções distintas, então uma falha isolada não derruba as outras operações.
• Permissão mínima por função. Cada Lambda só acessa a tabela de DynamoDB que precisa, sem política ampla concedida à aplicação inteira.

Me quedo con una idea: un agente de IA y un bot determinista se complementan.

Me quedo con una idea: un agente de IA y un bot determinista se complementan.Sofia Torres Vilca, desenvolvedora e autora do projeto AppBarrio

O gap entre IaC e o que o SAM realmente cobre

Aqui está o ponto que mais interessa a quem vive de Infrastructure as Code: o deploy usa AWS SAM, e o template cobre Lambdas, tabelas DynamoDB, roles e políticas de IAM. Mas a instância do Amazon Connect, a configuração do agente no Amazon Q in Connect, os documentos e a base de conhecimento no S3, os bots do Lex V2 e o frontend web ficam fora do stack, exigindo configuração manual via console ou scripts à parte.

Isso não é um defeito do projeto, é uma limitação real de maturidade de IaC para esses serviços hoje. Vale o alerta para quem for reproduzir o padrão em produção: ter um template SAM ou Terraform não significa que o ambiente inteiro suba de um único sam deploy, e o runbook de recuperação de desastre precisa cobrir manualmente as peças que ficam de fora.

O que ainda falta para ser produção

A própria autora é explícita sobre os limites do que foi entregue, e essa lista funciona como checklist de pendências para quem for levar o padrão adiante:

• Nenhuma medição de custo real de operação foi feita.
• Latência e comportamento sob carga não foram avaliados.
• A base de conhecimento tem poucos documentos; não se sabe como o RAG se comporta com volume maior.
• Não há autenticação: a identificação do usuário depende só do DNI informado no chat.
• Não houve avaliação sistemática da qualidade das respostas geradas pelo agente.

Para quem desenha sistemas em produção, cada item dessa lista é um gate de Well-Architected que precisa ser fechado antes do go-live: observabilidade de custo e latência, hardening de autenticação e um processo de avaliação de qualidade de resposta do LLM, algo que normalmente entra como pipeline de teste automatizado antes de liberar prompt novo.

Quando vale aplicar o padrão, e quando não vale

O padrão orquestrador-executor compensa quando a conversa tem dois regimes claramente distintos: um regime de consulta aberta, que se beneficia de linguagem natural e RAG, e um regime transacional, que exige validação e auditoria. Nesse caso, usar Amazon Q in Connect só para roteamento e deixar o Lex cuidar do dado sensível evita que o LLM vire ponto único de falha para uma operação que precisa ser determinística.

Se o fluxo inteiro é previsível, com poucas variações de frase, manter tudo em Lex clássico ainda é mais simples de operar e mais barato de manter, já que não exige configurar agente, base de conhecimento nem lidar com os custos (ainda não medidos, segundo a própria autora) de uma camada de IA generativa. O código-fonte, as capturas de tela e a documentação técnica do AppBarrio estão publicados no GitHub da autora, linkado no artigo original.

Fonte: DEV Community — #aws