ERP, Shop, CRM e Document Manager su un unico dominio dichiarativo, con un agente AI che opera trasversalmente su tutti i moduli.
Scopri Pwas-One →Pwas.Orchestrator trasforma una richiesta in linguaggio naturale in un piano verificato, eseguito e completamente tracciabile.
Pwas.Orchestrator ricostruisce l'obiettivo dietro una richiesta, lo verifica contro ciò che è realmente disponibile, compila un piano logico verificato e ne governa l'esecuzione — conferme, limiti e audit trail completo inclusi, non un agente che improvvisa chiamate a tool.
Il registro di tool (CRUD + pipeline di esecuzione) è generato automaticamente dalla descrizione del tuo dominio — non è mai scritto a mano, e si rigenera da solo quando quella descrizione cambia.
Ogni richiesta diventa un grafo di attività con le proprie dipendenze, eseguito con retry, timeout e circuit breaker — non una sequenza di chiamate a tool improvvisate.
Il progresso di ogni run è trasmesso via WebSocket, con eventi persistiti e un contatore monotono per riprendere esattamente da dove un client si è disconnesso.
Prima di finalizzare un piano, l'orchestratore può fare una domanda specifica invece di inventare un valore — fino a 4 turni, poi il run fallisce esplicitamente.
Ogni post/put/delete resta in attesa di conferma umana, con il payload esatto che verrebbe scritto già visibile — Pwas.Framework applica comunque l'autorizzazione reale, non l'assunzione del piano.
Ogni tool invocato, la decisione (allowed / confirmed / blocked / denied), la regola di policy applicata e la motivazione dichiarata dal planner — un log separato da quello HTTP di Pwas.
L'orchestratore decodifica il JWT ottenuto da Pwas.Framework solo per leggere ruoli e filtrare i tool disponibili — l'unico vero punto di enforcement resta Pwas stesso.
Ogni richiesta attraversa le stesse sei fasi, completamente osservabili — niente è deciso da un'unica chiamata al modello non verificata.
Risolve il chiamante, i suoi ruoli, l'ambiente attivo e la versione di configurazione, poi recupera solo le entità, i workflow e i componenti realmente rilevanti.
La richiesta diventa intenti, parametri, filtri ed effetti desiderati. Un fatto mancante o una lettura ambigua mette in pausa il run con una domanda specifica, non un'ipotesi.
La conoscenza dei workflow lega l'intento alle sue precondizioni ed effetti; il planner costruisce un grafo di dipendenze tra attività — ancora indipendente da come verrà eseguito.
Un compilatore deterministico risolve il piano contro le reali capability del backend, traccia tipo e origine di ogni risultato intermedio, e simula letture, scritture e chiamate esterne prima che qualcosa venga eseguito.
Gli step indipendenti girano in parallelo, gli effetti in conflitto vengono serializzati, le azioni sensibili si fermano per conferma con i valori già risolti — Pwas.Framework applica l'autorizzazione reale, non l'assunzione del piano.
Il risultato non è solo un dato — è cosa è cambiato, cosa richiede attenzione, cosa viene dopo. Un presentation planner sceglie un componente dal catalogo di Pwas.Client per mostrarlo.
POST /api/exec/run/orchestrator.route_ticket Authorization: Bearer <agent-token> { "ticket_id": 4821, "signal": "refund_requested" }
{
"execs": {
"orchestrator.route_ticket": {
"role": ["SERVICE"],
"inputs": ["ticket_id", "signal"],
"endpoint": "/api/exec/run/…"
}
}
}
Pwas.Orchestrator è sviluppato da Pooel Srl. Scrivici per vedere come collegarlo alla tua istanza di Pwas.Framework.