01Console delle policy
Una sola schermata contiene l'intera flotta: ogni agente, il suo limite giornaliero, la sua allowlist e quanto ha speso oggi. Nella demo, tre agenti hanno speso €184.20 alle 09:41, con due pagamenti bloccati e uno in attesa di una persona. Le modifiche alle policy sono immediate; l'agente lo scopre alla prossima volta che prova a pagare.
- Budget, allowlist e soglie modificabili per singolo agente
- Spesa, blocchi e approvazioni in sospeso a colpo d'occhio
- Le decisioni delle ultime 24 ore, esportabili
02Approvazioni nel flusso
L'agente propone, una persona decide. Nella demo, Billing Agent chiede di pagare la fattura #088 di Nord Logistics — €120.00, entro il suo budget giornaliero di €200.00 con €64.20 già usati, ma sopra la soglia di approvazione di €50.00 — e la richiesta resta in attesa per 14 minuti di un tocco su Approva o Rifiuta. La policy, la voce in allowlist del merchant e il conto di addebito stanno proprio sotto i pulsanti.
03Wallet per agenti
Ogni agente opera dal proprio wallet, con la propria policy. Il Billing Agent della demo ha ancora €135.80 disponibili su un limite giornaliero di €200.00 — €64.20 spesi in tre pagamenti, con azzeramento alle 00:00 — un tetto di €150.00 per transazione, approvazione umana sopra €50.00 e due merchant autorizzati. I pagamenti recenti riportano il tag auto quando la policy li ha autorizzati da sola.
- Limite giornaliero, spesa, tetto e budget residuo in una sola schermata
- Merchant autorizzati con il loro storico dei pagamenti
- Pagamenti con tag auto o approvati da te
04Creare un agente
Un agente è prima una policy, poi codice. Il Billing Agent della demo riceve un limite giornaliero di €200.00, un tetto di €150.00 per transazione, due merchant dall'allowlist e approvazione umana sopra €50.00 — tutto impostato al passo 2 di 3, prima che esistano le chiavi. Le chiavi vengono emesse una volta sola, mostrate una sola volta, e ogni firma di pagamento porta con sé l'hash della policy.
05L'editor delle policy
Una policy è un documento versionato. La modifica della demo alza il tetto per transazione dell'Ops Agent: la v14 diventa v15, la modifica richiede una nota di audit obbligatoria e viene salvata con la firma dell'operatore e un nuovo hash della policy. Il pannello di replay esegue sulla bozza le decisioni reali delle ultime 24 ore: vedi cosa avrebbe consentito una policy prima che entri in vigore.
- Limite giornaliero, tetto per transazione e massimale mensile per agente
- Nota di audit scritta obbligatoria a ogni salvataggio
- Replay sulle ultime 24 ore sulla bozza prima di confermare
06Audit, decisione per decisione
La decisione DEC-4471 ricostruisce un pagamento per intero: la richiesta, ogni controllo della policy con il suo esito — allowlist superata, tetto superato, soglia da escalare — l'approvazione umana con la sua firma e i €120.00 regolati, con circuito e riferimento. Il registro è concatenato con hash e di sola aggiunta: modificare qualsiasi campo spezza la catena da quel punto in avanti.
07Budget per agente
Un budget è un muro, non un suggerimento. Ogni agente ha un limite giornaliero e un tetto per transazione — nella policy della demo €500.00 al giorno e €150.00 a pagamento — applicati dalla piattaforma prima che il denaro si muova. Il tentativo del travel bot di noleggiare un charter da €640.00 è stato negato subito: oltre il tetto.
08Massimali mensili
Sopra il limite giornaliero c'è un massimale mensile — €6,000.00 nella policy della demo. Un agente che rispetta le regole ogni singolo giorno non può comunque sforare quanto il mese consente.
09Il budget si azzera a orario fisso
I budget giornalieri si azzerano a un orario dichiarato — alle 00:00 CET nella demo — visibile nel wallet dell'agente. La spesa si accumula su una finestra che tutti possono vedere, non su un periodo mobile e opaco.
10Allowlist dei merchant
Gli agenti pagano solo i merchant che hai inserito in anticipo. L'Ops Agent della demo ne conosce esattamente quattro — e un tentativo da €180.00 verso un fornitore non in elenco è stato negato come non presente in lista. Aggiungere un merchant richiede un clic; rimuoverlo ha effetto immediato.
11Soglie di approvazione
Imposta la soglia oltre la quale serve il sì di una persona. La policy della demo porta all'escalation tutto ciò che supera €100.00: l'agente si ferma, una persona riceve la proposta e nulla si muove finché non risponde. Sotto la soglia, l'agente opera in autonomia — entro budget e allowlist.
12Approvazioni umane firmate
Un'approvazione non è una casella da spuntare: viene registrata con chi ha approvato, da quale dispositivo, a che ora e con una firma allegata. La decisione della demo lo mostra: approvata in app, chiave del telefono, 09:41:12.
13Il percorso di escalation
Proposta, escalation, approvazione, autorizzazione — ogni passaggio con il suo timestamp nel registro della decisione. Quando qualcuno chiede perché un pagamento è avvenuto, la risposta è una sequenza, non una scrollata di spalle.
14Registro di audit immutabile
Ogni decisione è a registro: cosa ha tentato l'agente, cosa ha stabilito la policy, chi ha approvato cosa — fino alla rotazione delle chiavi. Le voci sono di sola aggiunta ed esportabili. Quando qualcosa non torna, il registro mostra esattamente cosa è successo e quando.
15Integrità con hash concatenati
Ogni record di audit porta il proprio hash, quello del record precedente e la propria posizione nella catena — #4,471 nella demo. Verifica la catena quando vuoi: qualsiasi modifica, ovunque, spezza tutto ciò che viene dopo.
16Esporta in JSON
Ogni decisione si esporta in JSON, hash incluso — pronta per il tuo archivio, il tuo revisore o la tua analisi degli incidenti. Il registro è tuo da portare via, non nostro da trattenere.
17Kill switch
Un tocco mette in pausa un agente e blocca subito tutti i pagamenti da lui avviati. Le chiavi restano valide, quindi nient'altro si rompe — l'agente semplicemente non può spendere finché una persona non lo riattiva. Nella flotta della demo, il travel bot è in pausa con €0.00 spesi.
18Congelato, non perso
Mettere in pausa un agente congela le sue proposte in sospeso invece di scartarle. Riattivalo e la coda è esattamente dov'era — nessuna proposta muore in silenzio perché una persona ha tirato il freno.
19Chiavi con ambito limitato
Le credenziali di un agente concedono capacità, non accesso indiscriminato. Gli scope come payments.send e refunds.issue si attivano in modo indipendente — nella demo l'agente ha subscriptions.manage disattivato. Revoca o ruota una chiave senza toccare la policy sottostante.
20Chiavi emesse una sola volta
Le chiavi dell'agente vengono mostrate una sola volta all'emissione e mai più. Ciò che la piattaforma non può rimostrare, un attaccante non può richiederlo di nuovo.
21Hash della policy in ogni firma
Ogni pagamento è firmato con la chiave dell'agente e l'hash della policy che lo ha consentito. Un pagamento non dice solo cosa è successo: dimostra quali regole erano in vigore quando è successo.
22Versionamento delle policy
Le policy hanno una versione, un hash, un autore e un timestamp — v14, aggiornata il 17 lug alle 09:12 nella demo. Ogni decisione fa riferimento alla versione esatta della policy che l'ha giudicata.
23Replay prima di confermare
L'editor riesegue sulla tua bozza le decisioni delle ultime 24 ore: cosa sarebbe stato consentito, cosa negato, cosa cambierebbe. Gli errori di policy emergono nell'anteprima, non in produzione.
24Regolamento su circuiti reali
Una proposta approvata diventa un pagamento reale — i €120.00 della demo regolati con SEPA Instant, riferimento 9F21-0716, pochi minuti dopo l'approvazione. Gli agenti spendono dallo stesso core su cui gira il resto della famiglia.
25Endpoint MCP
Gli agenti si collegano via MCP a mcp.protocore.io/agents — qualsiasi framework che parla il protocollo può avere un wallet Protocore. La superficie di integrazione resta minima: proponi un pagamento, ricevi una decisione. La policy vive sulla piattaforma, non nel prompt.
26Flotta di agenti
Usa un agente o molti. La demo ne fa girare tre — ops, procurement, un travel bot — ciascuno con il proprio budget, la propria allowlist e la propria soglia. Ne metti uno in pausa e gli altri continuano a lavorare; la policy non passa mai da un agente all'altro.
