Plataforma
Um monolito modular com fronteiras explícitas.
Seis módulos de domínio, uma base de dados relacional como fonte de verdade e um runtime que trata a aprovação humana como estado, não como notificação.
Processos
Registo do processo real com baseline quantificado: minutos por execução, volume mensal, custo/hora e taxa de erro.É a única forma de calcular retorno sem depender de estimativas do fornecedor.
Conhecimento
Ingestão, fragmentação e recuperação do conhecimento operacional, com ACL por fragmento e proveniência até ao documento.Um output sem fonte não é auditável; um output com fonte que o utilizador não podia ver é uma fuga.
Workflows
Definições versionadas em especificação portável. Uma versão ativa por chave, com arquivo automático das anteriores.Rollback previsível e capacidade de sair da plataforma sem reescrever a lógica.
Runtime de agentes
Executor de passos re-entrante, com gateway de modelos, avaliação de risco e gates de aprovação de primeira classe.A execução pode parar à espera de uma pessoa e retomar exatamente no passo seguinte.
Integrações
Conectores de ação com catálogo de operações declarado e modo de simulação para testes.É o único ponto onde o sistema escreve fora de si; convém ser estreito e registado.
Observabilidade
Trace por passo, atribuição de tokens e custo, registo de utilização por modelo e auditoria append-only.Sem isto, «funciona» é uma afirmação sem prova.
Runtime
Os sete tipos de passo.
Cada tipo tem uma responsabilidade única e um contrato de saída conhecido. É isso que permite inspecionar uma execução sem ler código.
| Tipo | Responsabilidade | Saída |
|---|---|---|
| RETRIEVE | Recupera contexto da base de conhecimento respeitando o ACL de cada fragmento. | consulta + fragmentos com proveniência |
| CLASSIFY | Atribui uma etiqueta a partir de um conjunto fechado, com nível de confiança. | etiqueta + confiança + sinal de limiar |
| GENERATE | Produz texto fundamentado no contexto recuperado, com o prompt do agente. | texto + tokens + custo |
| RULE | Avalia asserções determinísticas. Por omissão, falhar interrompe a execução. | resultado por asserção |
| VALIDATE | Verifica campos obrigatórios e exige fundamentação quando configurado. | válido + lista de problemas |
| APPROVAL | Cria um pedido de decisão humana e suspende a execução. Sem condição, exige sempre aprovação. | estado de espera + papel exigido |
| ACTION | Escreve num sistema externo através de um conector, com payload registado. | resposta do conector + identificador |
Especificação portável
O workflow é um documento, não um estado interno.
Guardamos a definição como um objeto versionado e validado. É o artefacto que sai na exportação e é o que garante que a saída da plataforma é testável antes de ser necessária.
A validação acontece antes de persistir: versão suportada, pelo menos um passo, identificadores únicos e tipos reconhecidos. Um spec guardado é sempre um spec executável.
As expressões em risk.rules, rule.assertions e approval.when são avaliadas num interpretador restrito: literais, nomes do contexto, acessos, aritmética, comparações e booleanos. Sem chamadas de função e sem acesso a atributos privados — a definição é dado do cliente e nunca deve poder executar código arbitrário.
Exemplo reduzido
A definição completa usada na demonstração está visível no console, em Workflows.
{
"spec_version": "1.0",
"inputs": {
"subject": "string",
"body": "string",
"amount": "number?"
},
"risk": {
"default": "LOW",
"rules": [
{
"when": "input.amount > 25000",
"level": "HIGH",
"reason": "Valor acima de 25.000 EUR exige revisão humana."
}
]
},
"steps": [
{
"id": "context",
"type": "retrieve",
"config": {
"query_from": "input.subject",
"top_k": 4
}
},
{
"id": "draft",
"type": "generate",
"config": {
"agent": "proposal-writer"
}
},
{
"id": "checks",
"type": "rule",
"config": {
"assertions": [
"steps.context.hit_count > 0"
]
}
},
{
"id": "gate",
"type": "approval",
"config": {
"when": "risk in ['MEDIUM','HIGH']"
}
},
{
"id": "commit",
"type": "action",
"config": {
"connector": "crm",
"operation": "create_note"
}
}
]
}Modelos
O gateway de modelos existe para que o domínio não conheça o fornecedor.
Toda a chamada passa por um único ponto que devolve texto, tokens e custo. Trocar de fornecedor, usar chave própria ou encaminhar por avaliação é uma decisão de configuração.
Chave própria
A organização pode usar as suas credenciais. O custo continua a ser atribuído por passo, o que mantém a análise comparável.
Fornecedor determinístico
No protótipo, o fornecedor por omissão é determinístico e offline: a mesma entrada produz sempre a mesma saída, e os testes correm sem chaves.
Degradação explícita
Se um fornecedor remoto for pedido sem credencial, a chamada degrada para o determinístico e registra a razão na evidência do passo — nunca falha em silêncio.