// ARCHITETTURA TECNICA

Architettura del runtime di Polyant.

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.

02 STACK TECNICO

Componenti del runtime.

LINGUAGGIO

TypeScript ESM

100% del codice.

BACKEND

NestJS 11

Server, controller, dependency injection.

AI SDK

Vercel AI SDK v4

Astrazione del provider LLM (Anthropic, OpenAI, Mistral, AWS Bedrock per modelli privati, modelli open source ospitati).

DATABASE

PostgreSQL 16 + pgvector

pgvector per embeddings e memoria semantica + PostgreSQL FTS per ricerca full-text. Drizzle ORM 0.45.2.

ENCRYPTION

Node.js crypto · AES-256-GCM

Built-in per i segreti di istanza.

ADMIN PANEL

Next.js 15 + Tailwind 4 + shadcn/ui

Frontend admin panel.

DEPLOYMENT

Docker Compose · Kubernetes

Docker Compose per self-host standard; manifest Kubernetes disponibili per cluster del cliente.

03 PIPELINE A TRE FASI

Ogni decisione di un agente passa per una pipeline di tre fasi.

01

Input governance

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.

02

LLM call con tool

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.

03

Output governance

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).

04 MULTI-TENANCY

Ogni agente è un'istanza con UUID dedicato.

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.

05 CANALI NATIVI

Quattro canali nativi del runtime al T+0.

HTTP

OpenAI-compatible

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.

TELEGRAM

Bot via grammY

Long polling, nessun webhook pubblico richiesto.

SLACK

Bot via @slack/bolt Socket Mode

No inbound webhook richiesto.

WHATSAPP

WhatsApp Business via WAHA

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.

06 REGISTRO AUDIT

Schema delle tre tabelle principali (PostgreSQL nel database del cliente).

L'export per ispezione regolatore è una query SQL standard configurabile dal team compliance del cliente.

// PER APPROFONDIRE

Dal runtime alla produzione governata.

Quickstart self-host, sicurezza del prodotto, governance e audit. Tre porte tecniche di approfondimento per il Solution Architect del cliente.

08 PER APPROFONDIRE

Tre porte tecniche.