Do sistema tradicional à arquitetura distribuída multiagente

Qual é a missão?

Chegar à próxima etapa com uma arquitetura conceitual clara. Não é para entregar o sistema distribuído pronto e não é para implementar todos os bots.

Não é a tarefa

• reescrever o projeto do zero;
• implementar IA antes de definir contratos;
• criar serviços só para “parecer distribuído”;
• duplicar regras de negócio sem necessidade;
• ler trabalhos antigos de estudantes para copiar solução.

3. Bot tradicional primeiro; IA como fallback

Comando específico e parametrizável não precisa consumir interpretação de IA. O roteador tenta casar intenção e parâmetros; só encaminha para agente de IA quando a mensagem é ambígua ou exige raciocínio.

Filas separadas

• entrada/comunicação;
• worker do banco relacional;
• worker de indexação/RAG;
• tarefas de IA;
• auditoria/eventos;
• canal humano prioritário.

Um único bot fazendo tudo cria fila, acoplamento e dificuldade de diagnóstico.

5. Protocolo entre agentes

Definam um envelope pequeno e previsível. Os agentes precisam concordar sobre formato, versão, ação, alvo, correlação e resposta.

{
  "version": "1.0",
  "request_id": "req-2026-0001",
  "actor": "human",
  "action": "inventory.delete",
  "target": { "record_id": 2174 },
  "requires_confirmation": true,
  "reply_to": "supervisor-human"
}

Isso é um exemplo conceitual; o contrato definitivo nasce antes da implementação.

6. Relatórios pré-prontos

Consultas previsíveis continuam melhores como funções tradicionais. “Todas as peças emprestadas”, “itens atrasados” ou “estoque por categoria” são consultas que o sistema já consegue definir e testar.

8. Como expandir o artigo

1. Preservar a versão tradicional: visão geral, requisitos, regras, telas, DFD/DER e módulos atuais.
2. Adicionar “Arquitetura AS-IS”: o que roda hoje e onde está cada responsabilidade.
3. Adicionar “Arquitetura TO-BE”: containers/serviços, limites e justificativas.
4. Definir agentes/bots: responsabilidade, entrada, saída e o que não fazem.
5. Definir protocolo: envelope, ações, erros, correlação, autenticação e confirmação.
6. Definir dados: fonte relacional, projeção RAG, indexação e consistência.
7. Definir comunicação: síncrona, assíncrona, fila, timeout e fallback.
8. Definir prioridade humana: supervisor/bypass e autorização de ações sensíveis.
9. Definir interoperabilidade: API HTTP e, quando fizer sentido, MCP/A2A.
10. Fechar com plano de implementação futura: o que será feito nas semanas seguintes, sem fingir que já está pronto.

O que só entra se for essencial

• novo serviço com responsabilidade real;
• fila quando houver desacoplamento/carga/falha a tratar;
• bot quando houver função autônoma clara;
• IA quando interpretação/recuperação justificar;
• novo banco somente com papel de dados diferente e contrato explícito.

9. Entrega obrigatória

• artigo-base expandido, sem apagar o que já está correto;
• diagrama AS-IS do sistema atual;
• diagrama TO-BE do sistema distribuído;
• mapa de containers/serviços e responsabilidades;
• fluxo de um comando determinístico;
• fluxo de uma solicitação com fallback de IA;
• estratégia relacional → evento/fila → RAG;
• proposta de protocolo entre agentes;
• prioridade/supervisão humana;
• justificativa das APIs/protocolos escolhidos.

10. O que será avaliado

• coerência entre problema e arquitetura;
• fronteiras que realmente reduzem acoplamento;
• clareza entre bot tradicional e agente de IA;
• tratamento de falha, fila e confirmação;
• fonte de verdade dos dados bem definida;
• rastreabilidade das decisões;
• diagrama legível e texto que explica “por quê”;
• evolução acumulativa: a semana 2 aproveita a semana 1.