Plataforma de agentes e automações

Um sistema de agentes precisa trabalhar com fontes externas e executar etapas dentro de regras de negócio.

• O estudo de caso descreve um runtime de execução e seus conectores.
• Também apresenta componentes de observabilidade desenvolvidos em uma linha separada, com sua situação explicitamente diferenciada.

Uma proposta pode usar uma fonte inadequada, mudar depois de aprovada ou ser retomada duas vezes.

• Melhorar o prompt não resolve essas fronteiras.
• O sistema precisava verificar o contexto autorizado, a versão aprovada e a posse da execução antes de continuar.

Separar interpretação, proposta, aprovação e efeito.

• A automação deve reconhecer o que pode executar e quando precisa interromper ou pedir revisão humana.
• O objetivo técnico do recorte foi tornar essas regras verificáveis em cenários positivos e negativos.

O runtime TypeScript utiliza estados explícitos para propostas, aprovações e retomada.

O servidor estabelece a organização, as capacidades e a fonte autorizada; a entrada da interface não escolhe livremente credenciais ou escopo.

Next.js, React, Supabase e PostgreSQL aparecem na estrutura do produto.

Os testes publicados exercitam componentes locais com provedores e stores simulados; não certificam a operação integrada dessa arquitetura.

O recorte reúne ciclo de agentes, vínculo entre fonte e capacidade, aprovação humana, retomada de execuções, protocolos de leitura e tratamento de falhas.

Cada fronteira possui estados e condições de recusa.

O módulo adicional de observabilidade contém ferramentas Python de integridade de evidências e sanitização OTLP.

Ele é uma implementação em desenvolvimento, validada localmente, sem prova de ativação completa no produto.

O cliente MCP negocia o protocolo e lista recursos por resources/list.

• A capacidade encontrada deve corresponder à operação solicitada.
• O recorte não implementa um servidor genérico de ferramentas nem comprova tools/call ou comunicação entre agentes por A2A.

O conector de Microsoft Graph controla paginação e escopo documental.

Os testes usam transportes injetados: cobrem o comportamento sem leitura de uma conta externa real.

TypeScript sustenta o runtime, os contratos e os conectores.

• Next.js e React fazem parte da aplicação; Supabase e PostgreSQL aparecem na persistência e nas migrations.
• Python é usado nos componentes de evidência e telemetria.

MCP é um protocolo de integração; OTLP é um formato/protocolo de telemetria.

Sua presença não demonstra, por si só, um ecossistema completo de agentes ou tracing de LLM em produção.

Preferi negar fontes ambíguas a resolver permissões implicitamente.

• A aprovação é vinculada à proposta exata, à organização, à versão e ao fingerprint.
• Se a proposta muda, a revisão anterior deixa de autorizar a nova ação.

A retomada utiliza claim e registra a conclusão antes de anunciar sucesso.

São escolhas que exigem contratos mais explícitos, mas tornam possíveis testes de concorrência e revisão das condições de execução.

Human-in-the-loop significa revisão de uma ação específica, não autorização aberta para qualquer operação futura.

O runtime diferencia proposta inválida, aprovação pendente e execução apta a continuar.

O comportamento do modelo é simulado no recorte local.

Os testes demonstram regras determinísticas que cercam a decisão assistida; não são apresentados como uma operação de agentes com LLM externo em produção.

Há manifests de Docker Compose e scripts para ambiente nonprod no código analisado.

• Essa evidência comprova a definição da infraestrutura, não sua disponibilidade operacional nesta auditoria.
• Nenhum container foi executado na máquina Windows para validar os projetos.

Persistência real, transportes externos e operação continuada exigem validação integrada em ambiente autorizado.

Não atribuo certificação de deploy do produto com base apenas nos arquivos existentes.

Os componentes Python verificam referências e integridade de evidências e projetam payloads OTLP pelos campos permitidos.

São 12 testes de núcleo forense e 18 de sanitização aprovados localmente em uma linha separada de desenvolvimento.

A ausência de sinal permanece uma lacuna de observação; não vira uma afirmação de saúde.

Este recorte não comprova toda a cadeia de coleta e exportação, painéis Grafana ativos ou tracing completo de agentes.

Source binding vincula a fonte à organização e à capacidade requerida.

• Ausência, revogação ou ambiguidade impedem a leitura.
• Os testes também exercitam rejeição de aprovação de outro contexto e verificações de política de rotas.

As migrations incluem RLS em PostgreSQL/Supabase, mas sua execução em banco real não foi comprovada nesta auditoria.

Testes estruturais de políticas não substituem uma certificação completa de autenticação e isolamento.

Uma solicitação gera uma proposta.

• O runtime verifica contexto, capacidade e fonte.
• Quando exigida, a pessoa revisa a proposta exata.
• A execução autorizada avança por estados e a retomada verifica quem possui o claim antes de continuar.

Leituras externas têm timeout, retry limitado e circuit breaker.

• Um erro 401 não é repetido indiscriminadamente; paginação para domínio externo é recusada.
• Esses cenários foram exercitados com respostas controladas.

Conduzi a definição das fronteiras de execução, a implementação dos componentes e a validação dos controles de agentes e integrações.

• No módulo de observabilidade, trabalhei com integridade e minimização de telemetria.
• Os exemplos públicos foram generalizados para preservar confidencialidade.

Foram aprovados 33 testes de agentes, source binding, aprovação, retomada e política de rotas, mais 8 testes de protocolo e readiness.

Essa evidência cobre comportamentos locais com stores e provedores simulados.

Os 30 testes de observabilidade pertencem ao módulo em desenvolvimento e são contados separadamente.

Não são somados como se certificassem o runtime integrado do produto.

A integração operacional completa, a persistência transacional real e a leitura de provedores externos não estão certificadas pelas suítes locais apresentadas.

O módulo de observabilidade foi analisado em linha de desenvolvimento separada; ativação e integração completas não foram comprovadas.

Avaliação generativa, frameworks multiagentes específicos e novas capacidades de protocolo são possíveis evoluções, não experiência concluída demonstrada neste caso.

O resultado técnico verificável é a aprovação dos cenários locais de isolamento, proposta alterada, fonte ausente/revogada/ambígua, retomada concorrente, negociação incompatível e falhas de leitura.

O store em memória permite exercitar a lógica de retomada, sem provar locks de banco ou recuperação após falha de infraestrutura.

O relatório público reúne escopo das suítes, contagens, hashes de fontes e registros de execução, sem paths internos nem conteúdo confidencial.

Este briefing documenta decisões e limites e oferece uma versão Markdown.

Não há demo pública deste runtime com serviços reais.

• Código e logs originais permanecem privados.
• O relatório sanitizado permite examinar a cadeia de evidências publicada, mas não reproduzir sozinho as suítes privadas.

Orquestração de agentes com estados, human-in-the-loop, integração MCP de recursos, APIs REST, isolamento de contexto, timeout, retry, circuit breaker e testes negativos.

No módulo em desenvolvimento: Python, sanitização OTLP e integridade de evidências.

Supabase, PostgreSQL, RLS e Docker Compose aparecem como implementações com prova operacional parcial, não como ambientes integralmente certificados por esta auditoria.

A pesquisa de mercado valoriza agentes, arquitetura, integrações, segurança, observabilidade e capacidade de entregar sistemas verificáveis.

Este caso demonstra decisões e testes nesses eixos, diferenciando o runtime principal do módulo em desenvolvimento.

A pesquisa também menciona operação de IA em produção, cloud, RAG e frameworks específicos.

Esses requisitos não são declarados como atendidos quando este material não oferece prova correspondente.