Whisperops

---

A ideia inicial desse projeto foi colocar à prova alguns conceitos de DevOps e SRE e, de quebra, testar alguma feature com IA diretamente.

Principais Destaques

Pois bem, existem algumas formas de ler esse projeto, que, aos poucos, se tornou um pequeno monstrinho.

1. Do ponto de vista de funcionalidade para o usuário final, trata-se de um projeto extremamente simples. O usuário cria o seu próprio agente para analisar um CSV qualquer. A plataforma cria dois agentes que conversam entre si, o planner e o worker, onde o usuário interage com o planner através de um frontend de chat, fazendo perguntas sobre o dataset. O worker, por sua vez, tem instruções definidas para rodar comandos Python em um sandbox, analisar o dataset, gerar uma resposta determinística e, quando achar necessário, adicionar também um gráfico interativo na resposta do chat.

2. Já do ponto de vista da aplicação, temos alguns recursos interessantes como objeto de estudo aqui:

   1. O primeiro e mais relevante deles é o uso do IDP (Backstage usando CNOE) integrado com ArgoCD e Crossplane Compositions. Em vez de termos vários templates Nunjucks, temos uma Composition XDatasetAgent passando por um pipeline do Crossplane com 6 funções (validate-dataset → compute-tuning → render-iam → render-workloads → render-dashboard → emit-budget) que, no fim da cadeia, cria e gerencia cerca de 22 recursos do k8s e GCP. Há 100% de controle multi-tenant sobre cada deploy, onde, pela própria UI do IDP, é possível controlar o ciclo de vida de cada agent-app, trocando configurações (controle de budget, troca de dataset, etc.) e deletando todo o contexto de forma isolada e segura. Todas as ações realizadas também são auditáveis e monitoráveis.

   2. Cada agent-app possui um budget configurável via IDP e com 100% de observabilidade dentro do ciclo de vida do agent. Quando o budget predefinido atinge 100%, o chat para de funcionar imediatamente.

3. O projeto conta com um bundle de observabilidade bem completo, usando uma stack full LGTM (OTel Collector, Grafana Alloy, Mimir e Loki) e entregando 9 dashboards extremamente detalhados, além de mais um dashboard para cada agent-app deployado (também controlado pelo fluxo do IDP + Compositions). Esse talvez seja um dos pontos mais fortes desse projeto.

   1. Cluster Health (USE Method) 🖥️ A saúde da máquina por baixo de tudo. Utilization/Saturation/Errors de CPU, memória, disco e rede do node, além de OOMKills, restarts de containers e pods fora de Running. Se a VM e2-standard-8 sufocar, você vê aqui primeiro.

   2. LLM Platform Overview 🤖 A visão de topo do produto. RED do chat (req/min, erro %), TTFT p50/p95, tokens/min in+out, agentes ativos, turnos de conversa e execuções do sandbox. O “single pane” para saber se a plataforma de agentes está saudável.

   3. Agent Lifecycle Activity 📋 Trilha de auditoria Day-2. Quantos agentes foram scaffoldados, ações nas últimas 24h, quem fez (top actors), destroys recentes e breakdown por agente/tipo. Responde “quem mexeu em quê e quando” via logs do Loki.

   4. SLO Compliance 🎯 Os contratos de confiabilidade. Availability 99%, TTFT@30s 95%, sandbox success 99%, com error-budget restante e burn-rate multi-window. É o painel que dispara, e justifica, os alertas de SLO.

   5. Service Map 🕸️ A topologia via Tempo spanmetrics + service-graphs. Grafo de dependências (chat→planner→worker→sandbox A2A), calls/min, p95 e erro % por serviço, operações mais lentas e arestas inter-serviço. Onde a latência mora no caminho.

   6. Cost & Token Economics 💰 O dinheiro. Custo lifetime, spend rate $/min, budget total vs restante por agente, throughput de tokens (in/out/cached), cache hit rate, economia acumulada de cache e custo por turno. Calibrado para o pricing do Gemini.

   7. RED Method (per service) 🔴 RED granular por serviço, não agregado. Rate/Errors/Duration separados para chat-frontend, sandbox e planner, incluindo erros do sandbox por tipo. Quando o D2 acusa problema, este isola qual serviço é o culpado.

   8. Apdex per Agent 😊 Satisfação do usuário traduzida em número. Apdex por agente (T=30s, tolerável=90s, calibrado para o Pro): satisfeito/tolerável/frustrado por TTFT, percentis, heatmap e quais agentes caíram na “frustrated zone” (<0.7).

   9. ArgoCD + Crossplane Platform Health ⚙️ A saúde do GitOps/control-plane. Apps ArgoCD Synced/Healthy, latência de reconcile, sync churn, decisões/violações do Kyverno por policy, fase dos pods Crossplane e restarts de provider. O painel de “a plataforma que roda a plataforma”.

   10. Per-Agent Detail 🔍 Um dashboard gerado automaticamente para cada agente no scaffold. Mostra, filtrado apenas para aquele agente, a saúde (availability, TTFT, Apdex), o custo (spend vs budget), uso de tokens/sandbox e recursos, além de logs e traces. Serve para investigar a fundo um agente específico quando ele se comporta mal.

4. E, não menos importante, também configurei alguns guardrails de segurança interessantes para o cenário desse projeto:

   1. Sandbox blindado: o código gerado pelo LLM roda como não-root, com filesystem read-only, sem capabilities e sem token do K8s, a fim de evitar prompt injection e afins.

   2. Egress default-deny: o sandbox fala apenas com GCS, DNS e OTel; qualquer tentativa de exfiltração para fora do cluster é bloqueada pela NetworkPolicy.

   3. Nenhum Git Secret: todas as chaves de SA são geradas a cada deploy e rotacionadas, portanto não há credencial commitada nem persistida.

   4. IAM least-privilege: cada SA tem apenas o papel mínimo (Vertex = inferência; agente = apenas seu próprio bucket), limitando o estrago se uma chave vazar.

   5. Kyverno admission cluster-wide: 6 políticas bloqueiam imagens de registries não confiáveis, containers privilegiados e pods sem resource limits.

   6. Day-2 com SSO + RBAC mínimo: ações operacionais exigem login Keycloak (built-in no CNOE) e rodam sob um SA que não pode criar agentes nem se auto-conceder permissão.

   7. Trilha de auditoria: toda ação Day-2 registra ator, ação e agente no Loki, dando rastreabilidade total sobre qualquer ação do IDP.

   8. Riscos residuais assumidos: bootstrap SA amplo, ~60s de latência no budget e key da Vertex replicada, todos documentados com o caminho de mitigação (GKE + Workload Identity).

Outras funcionalidades

• O controle dos datasets é feito em um bucket do GCP, onde podemos fazer o upload diretamente de qualquer CSV. Ao criar um agent-app, o IDP mostra um menu drop-down com todos os CSVs disponíveis no bucket. Essa feature também funciona via Compositions (XDataset), que monitora o estado do bucket, valida os CSVs, faz algumas normalizações e os disponibiliza no IDP de forma recorrente.

• O controle de budget dos agentes também é feito através de uma Composition (XAgentBudget) que passa por um pipeline de 3 steps (fetch-spent obtém o valor gasto através do Mimir, decide analisa o resultado do ratio e, por fim, o render atualiza os Deployments dos agents de acordo com o resultado).

• O projeto foi pensado para ser um one-shot deploy por se tratar de uma demonstração. Todos os principais recursos do projeto são GitOps first, então, para agilizar o processo de deploy, existe um Makefile que sobe a infra com Terraform, gera as imagens e sobe todo o código da estrutura para um Gitea no próprio cluster. O processo de deploy demora cerca de 30 minutos e é totalmente idempotente.

• Não é bem uma funcionalidade, porém, dentro do diretório docs, existem muitos diagramas e explicações sobre cada layer do projeto. São documentações técnicas e detalhadas sobre cada decisão do projeto. Em breve, vou discorrer mais sobre alguns detalhes em posts específicos desse blog.

• Esse projeto foi inteiramente desenvolvido usando Spec Driven Development com Claude. O framework escolhido para executar o projeto foi um fork pessoal do AgentSpec.