Prova de execução, não promessa: a plataforma multi-tenant está construída — 39 engines em 10 camadas, governada e verificável por evidência, não por slide. Esta página é para quem vai abrir o capô: arquitetura, performance, qualidade, governança e segurança, com o status real de cada coisa.
A fronteira honesta: O dogfood: a Fluxomind rodando o próprio comercial dentro do produto — a prova viva de que o agente opera e evolui.
Em sistemas tradicionais, o código chama o LLM quando precisa. Aqui, o inverso: um orquestrador decide o que fazer, consulta memória e conhecimento, planeja e aciona ferramentas — tudo governado por política e visível como um grafo de estado, auditável passo a passo.
Roteamento por perfil de custo/qualidade, fallback automático entre provedores e custo medido por chamada.
O agente compõe primitivas existentes — não gera código solto. Execução visível e reproduzível.
Estende o modelo do tenant via ferramentas governadas (create-only), com as tabelas-base do sistema bloqueadas — dogfooding, não auto-modificação.
A plataforma não entrega valor uma vez — ela gira. Dois loops acoplados sobre um único cérebro semântico: a intenção vira app, o app gera operação, a operação devolve a próxima ação, e cada volta parte de um ponto mais alto.
Você descreve a intenção; a plataforma cria objeto, campos e telas — sem ciclo de engenharia no caminho.
Operar gera dado real; a plataforma lê a operação e devolve a próxima ação — mais precisa que a anterior. Maturidade: a volta completa se prova com o dogfood — próximo capítulo.
Classifica as entidades do negócio automaticamente (embedding + LLM, alinhado a Schema.org) — sem projeto manual de ontologia. Maturidade: em construção (Parcial).
A tese: quanto mais você usa, mais o Atlas sabe — e mais barato fica entregar a próxima coisa. É o que separa um produto-flywheel de uma ferramenta: a ferramenta entrega o mesmo na milésima vez; o flywheel entrega mais, por menos. A volta completa é o que o dogfood vai provar.
39 engines organizadas em 10 camadas (verificável em src/engine/) — abaixo, as camadas com engines representativas de cada uma. Cada engine é um módulo isolado com boundaries estritos — import indevido entre internals é bloqueado pelo verificador de boundaries, que roda no pipeline de deploy. Evolução por camada, sem ruptura.
As capacidades de escala estão na arquitetura. Os números de produção chegam com os pilotos.
Parcial — capacidade de designMétricas Prometheus, SLO por tier, detecção de anomalia (z-score/IQR) e cost trace por execução.
monitoringEngineFila distribuída com retries, backoff e DLQ; cache em camadas; pools de conexão e detecção de query lenta.
queueEngine · cacheEngine · dataEngineDR multi-region, auto-scaling e self-healing (desenhado), backup tier-based com RPO/RTO, tracing distribuído (OpenTelemetry).
operationsEngineO princípio é “confiança conquistada por evidência”: a plataforma se verifica por código — suítes que provam isolamento, integridade e contratos, não checklist.
ImplementadoIsolamento (probes cross-tenant + RLS via pgTAP), integridade, contratos, resiliência, compliance e evolvability. Boundaries, testes e gate de eval rodam sob demanda e no pipeline de deploy; a suíte de isolamento, em workflow dedicado.
validationEngineLLM-as-Judge e testes baseados em propriedade barram regressão antes de promover um fluxo.
evalEngineContratos de API (OpenAPI) e de eventos (AsyncAPI) verificados; testes co-localizados ao código.
validationEngine · co-located testsPolítica declarativa que o runtime aplica em toda a plataforma, com pessoa no circuito quando importa.
Parcial — núcleo implementado; self-service no roadmapGuardrails versionados (checksum), avaliados com cache e explain; aprovação humana (human-in-the-loop) em ações sensíveis.
policyEngineRate limiting, usage tracking e enforcement por tenant; reserva atômica e overrides aprovados.
quotaEngineCiclo de consentimento GDPR/LGPD e trilha de auditoria imutável por hash-chain (ver Segurança).
securityEngine · auditTrailEngineMulti-tenancy forte, criptografia e masking — desde o primeiro dia, sem o cliente configurar.
ImplementadoTraga a própria chave KMS (AWS/GCP/Azure). Crypto-shredding: revogou a chave, os dados ficam ilegíveis na hora — independente da plataforma.
securityEngine · spec-byokSchema dedicado por cliente + RLS como backstop. O tenantId nunca vem do payload — deriva do contexto da requisição.
securityEngine · dataEngineDados sensíveis mascarados (4 estratégias) antes de chegar ao LLM; guardas contra prompt-injection/jailbreak.
securityEngine · spec-content-safetyDual token + RBAC; trilha SHA-256 append-only — adulteração é criptograficamente detectável e verificável por tenant.
securityEngine · auditTrailEngine · spec-hash-chainA plataforma tem scanners automatizados de controles SOC2 (CC6/CC7/CC8) e GDPR (Art. 17/20/30/32) — verificação por código, não checklist manual. Hoje rodam sob demanda; a execução contínua agendada está no roadmap.
| Pilar | O que já entregamos | Status | Próximo passo |
|---|---|---|---|
| Segurança | BYOK, masking de PII, RBAC, audit hash-chain | Implementado | Fail-closed amplo + pen-test externo |
| Qualidade | Invariantes de qualidade, LLM-as-Judge, contratos | Implementado | Cobertura de carga em escala |
| AI-first | Orquestração multi-agente governada; multi-provider com fallback e custo medido | Parcial | Jornada multi-worker em hardening; mais padrões de autonomia |
| Governança | Políticas+HITL, cotas/entitlements, consentimento | Parcial | Billing/payment + painel self-service de governança |
| Performance | SLO, cost trace, DR multi-region, self-healing (design) | Parcial | Números de escala em produção (pós-piloto) |
| Compliance | Scanners SOC2/GDPR automatizados (sob demanda) | Parcial | Execução contínua + certificação SOC2 Type II (auditoria externa) |
Damos acesso ao data room técnico (arch docs, specs, evidências), uma sessão de arquitetura com engenharia e um ambiente de avaliação isolado.