TypeScript ESM
100% del codice.
Pipeline a tre fasi (input, tool, output) con dieci controlli built-in di governance. Multi-tenancy a livello database con isolamento per istanza. Encryption AES-256-GCM per i segreti di istanza. Audit log su tabelle PostgreSQL dedicate. Stack TypeScript ESM, NestJS 11, Vercel AI SDK v4.
100% del codice.
Server, controller, dependency injection.
Astrazione del provider LLM (Anthropic, OpenAI, Mistral, AWS Bedrock per modelli privati, modelli open source ospitati).
pgvector per embeddings e memoria semantica + PostgreSQL FTS per ricerca full-text. Drizzle ORM 0.45.2.
Built-in per i segreti di istanza.
Frontend admin panel.
Docker Compose per self-host standard; manifest Kubernetes disponibili per cluster del cliente.
Il messaggio dell'utente entra nel runtime. I controlli built-in attivi su istanza valutano il messaggio: prompt-injection, message-length-limit, topic-guardrail. Esito: allow (proseguo), warn (segnalo all'operatore ma proseguo), block (blocco con motivazione strutturata). Tutte le decisioni vengono registrate in governance_events.
Il messaggio (eventualmente arricchito dal contesto della memoria persistente) viene inviato al modello LLM configurato per l'istanza. Il modello può scegliere di chiamare tool dal registry dell'agente. Per ogni tool call, i controlli built-in valutano: tool-domain-filter, tool-rate-limit, tool-param-validator. La risposta del tool torna al modello.
Prima che la risposta del modello esca dal runtime e raggiunga il canale, i controlli built-in valutano l'output: credential-detector, pii-detector, system-prompt-leakage, internet-access se rilevante. Esito: allow, warn, block.
Tutta la sequenza viene registrata in pipeline_traces (latenza per fase) e ai_logs (token consumati, costo stimato per provider).
Ogni agente è un'istanza con UUID dedicato (PRIMARY KEY in instances). L'istanza ha: configurazione propria (system prompt, tool registry, canali, policy), segreti propri (cifrati AES-256-GCM), workspace isolato in packages/engine/workspaces/<instanceId>/, memoria propria (pgvector con namespace dedicato).
L'isolamento è a livello database: le configurazioni di un'istanza non sono accessibili dalle altre, neanche con accesso runtime al singolo agente. La chiave master è in variabile d'ambiente del runtime, configurabile dal cliente con KMS o HSM esterni in deploy enterprise.
Il runtime espone un endpoint /v1/chat/completions compatibile con la API OpenAI Chat. Client esistenti (libreria OpenAI, Anthropic SDK con base URL custom) parlano con Polyant senza modifiche.
Long polling, nessun webhook pubblico richiesto.
No inbound webhook richiesto.
Webhook per inbound. Outbound via API WAHA.
Per email aziendale e altri canali (Microsoft Teams, sistemi proprietari), l'integrazione si realizza in fase di delivery.
L'export per ispezione regolatore è una query SQL standard configurabile dal team compliance del cliente.
table: governance_events # una riga per decisione runtime
}
cols: assistantId, conversationId, phase, gateType,
}
: policyId, action, confidence, reason, evidence
}
table: pipeline_traces # latenza per fase
}
cols: phase, duration_ms, created_at
}
table: ai_logs # chiamate al modello LLM
}
cols: provider, model, input_tokens, output_tokens,
}
: cost_estimate_usd, duration_ms, created_at
} Quickstart self-host, sicurezza del prodotto, governance e audit. Tre porte tecniche di approfondimento per il Solution Architect del cliente.