AIBE — AI Business Engine
Agentes especializados precisam de coordenação, contratos e limites.
O repositório contém um registro de execução anterior. Esta revisão extraiu o resumo e o hash do arquivo, sem reexecutar a suíte. O artefato é uma evidência histórica do autor, não uma verificação independente nem uma medição atual.
O problema e a proposta
O AIBE investiga uma dificuldade diferente da do StratHUB: coordenar agentes especializados que recebem tarefas, usam modelos e ferramentas e compartilham contexto. Adicionar vários prompts não resolve atribuição de responsabilidade, falhas, custos ou acompanhamento das decisões.
A proposta do AI Business Engine é uma plataforma experimental para organizar esse trabalho. O código reúne catálogo e ciclo de vida de agentes, roteamento de tarefas, comunicação por eventos, controle de orçamento e uma interface de operação. Trata-se de um projeto pessoal privado, descrito aqui por seus mecanismos de engenharia.
Arquitetura e inicialização do sistema
Um orquestrador central inicializa infraestrutura compartilhada, registro de ferramentas e agentes. A criação usa um catálogo/factory e pode selecionar grupos e excluir agentes. A inicialização ocorre em ordem de camadas, seguida de acompanhamento de estado e encerramento coordenado.
A base é Python assíncrono, com FastAPI na camada de API, NATS no barramento de mensagens e clientes para memória, modelos e persistência. O lifespan da aplicação integra orquestrador, rastreador de tarefas e ponte de eventos para WebSocket. Separar esses componentes torna explícito o que pertence ao runtime e o que pertence à interface.
Agentes: identidade, estado e ciclo de vida
A classe-base define identidade, papel, estado, orçamento e capacidades comuns. Agentes podem registrar handlers, iniciar loops assíncronos e interrompê-los com cancelamento e coleta de tarefas. Exceções em um loop incrementam contadores e são registradas, evitando confundir uma tarefa interrompida com uma entrega concluída.
O catálogo agrupa especialidades como produto, pesquisa, segurança, finanças e marketing. Esses papéis descrevem funções pretendidas dentro da simulação; não representam profissionais humanos, departamentos operacionais reais ou garantias de que todas as integrações de cada agente estejam completas.
Delegação: escolher quem faz a tarefa
O roteador de tarefas trabalha com especificações e regras de delegação. Um alvo explícito tem prioridade; sem ele, o tipo da tarefa determina uma lista de agentes preferidos e alternativas. A disponibilidade no registro participa da seleção. Se não houver agente elegível, o fluxo produz erro em vez de inventar uma atribuição.
O rastreador acompanha estados como submitted, assigned, running, completed e failed. Na implementação analisada, esse rastreador mantém registros em memória. Repositórios de banco e modelos persistentes também existem, mas não seria correto afirmar que todo estado da interface já é durável apenas pela presença de SQLAlchemy.
Roteamento de modelos e respostas estruturadas
O roteamento de modelos é separado da escolha do agente. O ModelRouter seleciona uma cadeia de modelos por tipo de tarefa, integra OpenRouter e permite parâmetros de saída estruturada. Isso centraliza decisões de modelo e tratamento de indisponibilidade, em vez de repetir chamadas independentes em cada agente.
O código inclui circuit breaker, alternativas configuradas e registro de tokens, custo e duração. Também há redução de contexto baseada em estimativa de tamanho: preserva partes iniciais e recentes e remove trechos intermediários. Essa heurística ajuda a limitar contexto, mas não equivale a uma sumarização semântica garantida.
Orçamento e degradação controlada
O projeto trata custo de inferência como estado do sistema. Há mecanismos de orçamento por agente, reserva antes da operação, liberação de reservas e registro de custo real, com locks assíncronos para coordenar alterações. Rotinas de checagem podem orientar downgrade de modelos ou suspensão de chamadas conforme limites configurados.
É importante distinguir os componentes: a implementação contém mecanismos de orçamento em evolução, cuja integração completa precisa ser verificada no runtime. O objetivo de engenharia é evitar que concorrência e tentativas sucessivas tornem o custo invisível. Esta página não apresenta economia percentual ou orçamento real de produção sem medição.
Mensagens, integridade e prevenção de loops
O barramento utiliza mensagens tipadas para tarefas e eventos. Há código para assinatura HMAC-SHA256 e verificação de integridade, além de middleware de telemetria e proteção contra loops. Esses recursos procuram tornar a comunicação entre agentes identificável e impedir que uma cadeia de mensagens se retroalimente indefinidamente.
A assinatura protege contra alterações quando corretamente configurada e aplicada; não substitui autenticação, autorização ou isolamento de ferramentas. Descrever esses mecanismos não significa certificar a segurança do sistema. A arquitetura precisa ser avaliada como um todo antes de operar com dados ou ações de maior impacto.
Memória, ferramentas e persistência
O cliente de memória define operações de armazenamento, recall e busca semântica por namespaces. A integração com OpenViking depende de um serviço externo e admite modo mock quando não configurada. Separar namespaces e metadados organiza contexto compartilhado e contexto de agentes, sem transformar memória em uma capacidade sempre disponível.
O registro de ferramentas centraliza descoberta e execução; modelos e repositórios SQLAlchemy/PostgreSQL representam tarefas, reuniões e custos. Redis e componentes de telemetria complementam a infraestrutura. A presença desses módulos demonstra desenho e implementação de componentes, enquanto durabilidade, disponibilidade e integração ponta a ponta exigem validação adicional.
Supervisão, reuniões e interface de operação
O supervisor inspeciona estados, limita reinicializações e usa cooldown para evitar ciclos de recuperação sem controle. O mecanismo de reuniões combina participantes, pauta, turnos e registro de decisões como forma de coordenação. Há também trilhas de degradação para lidar com componentes indisponíveis.
A interface Next.js/React/TypeScript oferece visões de agentes, tarefas, custos e métricas. A API FastAPI publica rotas correspondentes e uma ponte WebSocket distribui atualizações. Essa interface torna o runtime observável para o operador; uma tela ou um endpoint existente, porém, não prova que todos os fluxos por trás estejam completos.
Verificação, limites e competências demonstradas
O repositório inclui suítes para tipos, configuração, roteamento, orçamento, mensagens, ferramentas, supervisão, degradação, agentes, delegação, reuniões e API. Muitos cenários usam mocks para isolar dependências. A análise conferiu a estrutura e as asserções dos testes, sem declarar a suíte aprovada ou um percentual de cobertura que não foi medido nesta revisão.
Há diferenças entre contratos e caminhos de integração, além de componentes experimentais e modos mock. Por isso, o AIBE é apresentado como projeto em desenvolvimento, não como uma empresa autônoma comprovadamente operante. Ele demonstra prática em APIs assíncronas, modelagem de estados, integração de LLMs, coordenação por eventos, observabilidade e controle de recursos. O código e a configuração privada não são publicados nesta página.
Repositórios privados. Resumos autorizados; o código-fonte não é distribuído aqui.