Um único backbone de eventos. Zero provedores pré-programados.
Cada integração — de entrada ou saída — fala uma única língua: CloudEvents 1.0. Esse contrato único é o que permite ao catálogo crescer sem precisar reescrever o motor central.
Ingestão
Os agentes e conectores normalizam qualquer origem em CloudEvents padrão sobre um backbone Kafka — o mesmo envelope, não importa a origem.
Rota
O motor de fluxo de trabalho faz a correspondência de cada evento por padrão, cron ou webhook e executa o grafo por ele ativado.
Ação
Os nós chamam conectores, acionam agentes de IA, ramificam em condições ou pausam para validação humana — 42 tipos de nós em um único painel.
Composição
Cada saída é um novo CloudEvent, de modo que qualquer automação pode acionar outra. Nenhuma integração ponto a ponto, nunca.
42 tipos de nós de fluxo
Elementos básicos suficientes para expressar operações reais — gatilhos, fluxo de controle, transformações de dados, chamadas de integração e etapas com intervenção humana.
Visual para operadores. SDK para desenvolvedores.
Os não desenvolvedores criam sobre uma área visual de arrastar e soltar. Desenvolvedores estendem a plataforma com um SDK TypeScript tipado e uma CLI.
Construtor Visual
Um painel visual com zoom, minimapa e histórico de execução em tempo real — inspecione, dirija e estenda o fluxo de trabalho de qualquer modelo.
TypeScript SDK & CLI
zervanor init | Gera um novo projeto de agente com seu manifesto e estrutura inicial. |
zervanor dev | Fez funcionar o seu agente localmente com recarga rápida (hot reload). |
zervanor push | Desenvolve na plataforma via HTTP puro — nenhum Docker local requerido. |
zervanor status | Verifica o status de deploy do seu projeto na plataforma. |
Tell it what you want. Zervanor builds it.
Describe your operation in plain language. Zervanor assembles a real, validated workflow — grounded in your actual connectors and agents — and shows it to you step by step before anything runs.
- Grounded in your live catalog — it selects real connectors/agents, never hallucinates one.
- Contract-validated — every step is checked against the canonical workflow schema, with in-place repair.
- Human-in-the-loop — it asks at real forks and never applies or deploys without your explicit approval.
Agente + Conector + Fluxo = Modelo de Solução
Um Modelo de Solução não é «um fluxo de trabalho». É um processo operacional de negócios ativo, montado a partir de três camadas e implantado em um clique.
Criado para operadores, robustecido para a produção.
A plataforma cuida das etapas que costumam atrasar um projeto — a conexão das contas e a manutenção das integrações saudáveis.
Onboarding OAuth em um clique
O operador registra a aplicação OAuth de cada provedor uma única vez. Os tenants conectam suas contas em seguida com um só clique — suporte gerenciado pela plataforma para OAuth 2.0 e OAuth 1.0a, sem configuração por tenant.
Testes & monitoramento dos conectores
Cada conector realiza testes periódicos com métricas Prometheus, painéis do Grafana e alertas Alertmanager — mais uma página pública de status livre de tokens. Suas conexões não falham em silêncio.
Multi-tenant por construção
Namespaces do Kubernetes por tenant no GKE, RBAC no nível de organização e consultas filtradas por organização — validado por auditoria de segurança bem-sucedida (47/47).
O catálogo se torna uma força de trabalho.
O catálogo nativo baseado em contratos foi desenhado para fluxos. Acontece que ele também é a biblioteca de habilidades de uma força de agentes autónomos — os mesmos pacotes que alimentam os modelos em um clique se projetam em ferramentas utilizáveis por agentes IA.
- Generic Agentic Runtime shell — um único agente neutro em relação aos fornecedores (carregador de manifesto → bootstrap de ferramentas → ciclo de planejamento ReAct). Novos agentes são manifestos + ferramentas, sem código a medida.
- Projeção de ferramentas — as ações de um conector certificado são expostas a agentes através de uma API de ferramentas. Certifique uma vez → disponível para fluxos e agentes ao mesmo tempo.
- Traga seu próprio modelo — OpenAI / Gemini hoje via fornecedor/base-url; a plataforma nunca se amarra a um único fornecedor.
- Adaptadores de canal — um único agente atende a várias superfícies (chat, webhook, agendamentos).
Disponível hoje: o shell do runtime, dois agentes ativos (ai-agent + research-agent) com execução de metas de ponta a ponta, BYOK de organização para LLMs e console de gerenciamento. O catálogo de 40 agentes nas 4 camadas corresponde ao cronograma de desenvolvimento planejado.