Ricerca e demo
emotional-memory
Livello di memoria per sistemi LLM con codifica dello stato affettivo, package PyPI, DOI Zenodo e benchmark riproducibili rispetto a Mem0, LangMem e Letta.
Apri l’artefattoEsamina emotional-memoryProgetti e sistemi
Seleziono alcuni progetti per mostrare problemi di ingegneria diversi. Segue l’archivio completo, che distingue software rilasciato, ricerca e demo, e note di sistema.
Parti dai lavori selezionati, poi esamina evidenze e dettagli tecnici nell’archivio. La visibilità di una ricerca non implica un impiego in produzione.
Lavori selezionati
Software rilasciato
orka
Runtime agentico in Rust che riceve lavoro da chat e canali HTTP, assegna priorità e instrada verso workflow LLM vincolati con supporto MCP/A2A.
Esamina orkaRicerca e demo
reasoning-kernel
Implementazione di riferimento in Python di un reasoning kernel che separa il testo non fidato del modello dagli effetti autorizzati usando controllo basato su capability e taint tracking.
Esamina reasoning-kernelSoftware rilasciato
openfatture
Sistema Python local-first rilasciato: stato di workflow persistente, audit trail degli eventi, recovery prima degli effetti esterni e strumenti dell'assistente ispezionabili.
Esamina openfattureArchivio progetti
Tutti i 20 progetti restano disponibili qui sotto. I repository di ricerca e i pezzi non LLM sono indicati a parte. Non sono lavoro di produzione.
Software rilasciato10
openfatture
attivo
Sistema Python local-first rilasciato: stato di workflow persistente, audit trail degli eventi, recovery prima degli effetti esterni e strumenti dell'assistente ispezionabili.
Apri evidenze e dettagli tecnici
#Python#FatturaPA#CLI
Flusso di esecuzione di openfatture. Nodi: bozza, validazione, revisione umana, export SDI, invio, riconciliazione. Flusso: da bozza a validazione (primario); da validazione a revisione umana (primario); da revisione umana a export SDI (primario); da export SDI a invio (primario); da invio a riconciliazione (feedback); da validazione a bozza (loop, percorso di correzione).
Problema
Come tieni persistente lo stato del workflow, riprendi dopo un export fallito e tieni ispezionabili le azioni dell’assistente, quando quelle azioni possono innescare effetti esterni irreversibili?
Progettazione del sistema
Un sistema Python local-first rilasciato: stato di workflow persistente, audit trail degli eventi, recovery prima di export o invio, e strumenti dell’assistente ispezionabili.
Risultato
Un pacchetto pubblico su GitHub e PyPI. Il report di test datato della Fase 2 è uno snapshot storico, non un punteggio di qualità attuale.
Architettura
- stato del workflow
- recovery dell’export
- audit trail degli eventi
- strumenti dell’assistente
Modello di runtime
- bozza
- validazione
- export
- invio
- riconciliazione
Strumenti
- Python
- LangGraph
- SQLAlchemy
- hooks
Affidabilità
- controllo local-first
- validazione pre-export
- revisione manuale prima degli effetti esterni
bozzavalidazioneexportinvioriconciliazione
Vincoli
Il report di test della Fase 2 è evidenza storica e datata, non un punteggio di qualità attuale. Gli effetti esterni restano dietro revisione manuale; l’ispezionabilità conta più dell’azione autonoma.
Compromessi
L’operatività local-first riduce la comodità, ma migliora il controllo sullo stato del workflow e sugli effetti collaterali.
Evoluzione
Espandere i controlli di workflow, la copertura della recovery e l’assistenza AI verificabile.
orka
attivo
Runtime agentico in Rust che riceve lavoro da chat e canali HTTP, assegna priorità e instrada verso workflow LLM vincolati con supporto MCP/A2A.
Apri evidenze e dettagli tecnici
#Rust#MCP#A2A#RAG#WASM
Flusso di esecuzione di orka. Nodi: ingresso canale, classificazione, instradamento, scheduler, MCP/A2A, checkpoint. Flusso: da ingresso canale a classificazione (primario); da classificazione a instradamento (primario); da instradamento a scheduler (primario); da scheduler a checkpoint (primario); da scheduler a MCP/A2A (di supporto); da checkpoint a instradamento (loop, percorso di correzione).
Problema
Le richieste arrivano da chat, email e strumenti interni, ma senza una coda persistente unica non c’è un percorso affidabile dall’input di canale a un workflow LLM tracciato e revisionabile.
Progettazione del sistema
Un runtime agentico che trasforma input di canale in workflow LLM prioritizzati con adapter MCP/A2A, esecuzione in sandbox e confini runtime espliciti.
Risultato
Una coda unica instrada le richieste multi-canale in workflow LLM vincolati con supporto MCP/A2A.
Architettura
- ingress dei canali
- scheduler del runtime
- livello dei tool
- adapter MCP/A2A
Modello di runtime
- ricezione
- classificazione
- routing
- esecuzione
- checkpoint
Strumenti
- Rust
- tokio
- WASM
- MCP
- A2A
Affidabilità
- confini runtime tipizzati
- esecuzione con priorità
- separazione dei protocolli
- workflow interrompibili
ricezioneclassificazioneroutingesecuzionecheckpoint
Vincoli
Il runtime deve restare orientato ai protocolli ed evitare accoppiamento a una singola interfaccia.
Compromessi
Un runtime di basso livello offre più controllo, ma richiede confini di prodotto più netti.
Evoluzione
Rafforzare osservabilità, policy workspace e semantica di esecuzione durevole.
msg2agent
attivo
Livello di trasporto sicuro per messaggi agentici, con crittografia end-to-end, identità DID, relay di consegna, adapter MCP e interoperabilità A2A.
Apri evidenze e dettagli tecnici
#Go#E2E Encrypted#DID#A2A#MCP
Flusso di esecuzione di msg2agent. Nodi: scoperta DID, cifratura, firma, relay, lettura inbox, conferma. Flusso: da scoperta DID a cifratura (primario); da cifratura a firma (primario); da firma a relay (primario); da relay a lettura inbox (primario); da lettura inbox a conferma (primario); da conferma a relay (feedback).
Problema
I sistemi agentici richiedono un livello di trasporto per messaggi tra confini diversi senza chiavi condivise, fiducia centrale o accesso del relay al testo in chiaro.
Progettazione del sistema
Un livello di protocollo per messaggi agent-to-agent con identità W3C DID, crittografia end-to-end, relay di consegna, supporto MCP connector e interoperabilità A2A.
Risultato
Un pattern di trasporto sicuro per integrazioni agentiche: il relay può consegnare e accodare messaggi, ma il contenuto resta fuori dal suo trust boundary.
Architettura
- identità DID
- busta cifrata dei messaggi
- relay
- connector MCP
- adapter A2A
Modello di runtime
- scoperta dell’agente
- cifratura
- firma
- relay
- pull della inbox
- conferma di ricezione
Strumenti
- Go
- X25519
- Ed25519
- W3C DID
- OAuth 2.1 + PKCE
- MCP
Affidabilità
- consegna store-and-forward
- inbox offline
- quote per tenant
- relay cieco
scoperta dell’agentecifraturafirmarelaypull della inboxconferma di ricezione
Vincoli
Il relay instrada messaggi ma non deve diventare ancora di fiducia per identità o confidenzialità del contenuto.
Compromessi
La proprietà crittografica aumenta la chiarezza del trust ma aggiunge complessità di connector e gestione delle chiavi.
Evoluzione
Ampliare distribuzione dei connector, billing di produzione e percorsi di interoperabilità.
cast
attivo
Lavoro su sender Chromecast nativo per LibreWolf e Firefox, con backend openscreen per media casting e screen mirroring Wayland senza tool desktop di terze parti.
Apri evidenze e dettagli tecnici
#C++#Chromecast#Firefox#Wayland#OpenScreen
Flusso di esecuzione di cast. Nodi: start, branch, retry, gate, commit, checkpoint. Flusso: da start a branch (primario); da branch a gate (primario); da gate a commit (primario); da branch a retry (di supporto); da retry a branch (loop, percorso di correzione); da gate a checkpoint (feedback).
Problema
Il browser casting su Linux dipende spesso da tool desktop esterni o percorsi incompleti, soprattutto quando entra in gioco lo screen mirroring.
Progettazione del sistema
Un percorso Cast sender nativo per LibreWolf e Firefox basato su openscreen, con attenzione a media casting e screen mirroring Wayland.
Risultato
Uno showcase systems-level per integrazione browser: confini di protocollo, percorsi media nativi e vincoli desktop vengono gestiti sotto il livello dell’interfaccia web.
Architettura
- entrypoint nel browser
- sender nativo
- backend openscreen
- cattura Wayland
Modello di runtime
- scoperta del device
- negoziazione della sessione
- cattura dei media
- encoding
- streaming
Strumenti
- C++
- OpenScreen
- Wayland
- H.264
Affidabilità
- confine di protocollo nativo
- nessun sender desktop di terze parti
- build con tag di release
scoperta del devicenegoziazione della sessionecattura dei mediaencodingstreaming
Vincoli
Il lavoro è sensibile alla piattaforma: display server, codec, browser e comportamento del receiver Cast influenzano l’implementazione.
Compromessi
Un percorso nativo offre più controllo di un wrapper, ma espone compatibilità e manutenzione a livello più basso.
Evoluzione
Rafforzare compatibilità receiver, affidabilità della cattura e packaging path.
llama.cpp-vulkan-bin
attivo
Pacchetto Arch Linux per i binari Vulkan ufficiali di llama.cpp, con controlli automatici delle release upstream, checksum riproducibili, verifica della build e smoke test del caricamento dei backend a runtime.
Apri evidenze e dettagli tecnici
#Shell#llama.cpp#Vulkan#Arch Linux#Local Inference
semanticbrowser
attivo
Browser semantico in Rust per agenti AI che richiedono accesso strutturato a pagine web, stato della pagina e superfici di interazione invece di sole screenshot fragili.
Apri evidenze e dettagli tecnici
#Rust#AI Agents#Browser#Semantic Web#Automation
Flusso di esecuzione di semanticbrowser. Nodi: agent, policy, MCP, adapter, tool, audit. Flusso: da agent a MCP (primario); da MCP a adapter (primario); da adapter a tool (primario); da agent a policy (di supporto); da policy a adapter (di supporto); da tool a audit (feedback).
Problema
Gli agenti che operano sul web richiedono stato pagina strutturato e target di interazione, non solo screenshot fragili o dump DOM grezzi.
Progettazione del sistema
Un browser layer in Rust che espone struttura semantica della pagina e superfici di interazione, così i runtime agentici possono ragionare sulla pagina con confini più chiari.
Risultato
Una prova di browser automation centrata su stato ispezionabile: l’agente vede un’interfaccia strutturata, non uno stream visuale opaco.
Architettura
- runtime del browser
- estrattore semantico
- modello dello stato pagina
- interfaccia per gli agenti
Modello di runtime
- caricamento della pagina
- estrazione dello stato
- selezione del target
- azione
- osservazione del risultato
Strumenti
- Rust
- estrazione semantica
- browser automation
Affidabilità
- stato pagina strutturato
- target di interazione espliciti
- confini rivolti agli agenti
caricamento della paginaestrazione dello statoselezione del targetazioneosservazione del risultato
Vincoli
Il browser layer deve preservare abbastanza semantica pagina per gli agenti senza fingere che pagine web arbitrarie siano deterministiche.
Compromessi
Lo stato semantico è più ispezionabile degli screenshot, ma richiede gestione attenta di pagine dinamiche e gap di accessibilità.
Evoluzione
Collegare il modello pagina a trace di eval e policy più sicure per il controllo browser.
mcp_python_toolbox
attivo
Server MCP per strumenti di sviluppo Python usati da assistenti AI.
Apri evidenze e dettagli tecnici
#mcp#python#ai-tools#developer-tools#model-context-protocol
Flusso di esecuzione di mcp_python_toolbox. Nodi: agent, policy, MCP, adapter, tool, audit. Flusso: da agent a MCP (primario); da MCP a adapter (primario); da adapter a tool (primario); da agent a policy (di supporto); da policy a adapter (di supporto); da tool a audit (feedback).
Problema
Volevo un server MCP basato su Python che desse a un assistente AI una toolbox definita per lo sviluppo Python. I metadati del repository supportano un perimetro ristretto: una superficie di integrazione MCP per strumenti di sviluppo, non una dichiarazione su workflow specifici, adozione o prestazioni.
Progettazione del sistema
Mantengo il confine del sistema nel Model Context Protocol. I client degli assistenti si collegano al server, richiedono strumenti orientati allo sviluppo e ricevono risposte tramite l’interfaccia del protocollo. Python è il linguaggio di implementazione. Il focus progettuale è dove passa il confine degli strumenti: ciò che un assistente può invocare lo dichiara il server, non lo improvvisa un’istruzione in chat.
Risultato
Il repository presenta un server MCP in Python per lo sviluppo Python assistito da AI. Dai metadati disponibili posso descrivere il risultato solo a livello di repository: un punto concreto, basato su protocollo, in cui esporre strumenti di sviluppo Python a client di assistenti compatibili.
Architettura
- confine del server MCP
- implementazione in Python
- gestione delle richieste orientata ai tool
- interfaccia di protocollo rivolta all’assistente
Modello di runtime
- il client dell’assistente invia una richiesta di tool
- il server gestisce la richiesta tramite MCP
- il codice Python implementa la superficie dei tool
- la risposta torna attraverso il protocollo
Strumenti
- Python
- Model Context Protocol
- GitHub
Affidabilità
- confine di protocollo esplicito
- superficie dei tool delimitata
- nessuna persistenza implicita: il server non tiene stato di sessione
- gli errori emergono come risposte di protocollo, non come retry silenziosi
- l’esposizione limitata tiene piccolo il raggio d’azione di una tool call
il client dell’assistente invia una richiesta di toolil server gestisce la richiesta tramite MCPil codice Python implementa la superficie dei toolla risposta torna attraverso il protocollo
Vincoli
I metadati pubblici non descrivono i singoli strumenti, il modello di esecuzione, il livello di persistenza, benchmark o uso in produzione. Per questo mantengo il progetto al livello dell’integrazione e del confine di sistema.
Compromessi
Usare MCP dà un’interfaccia chiara per l’interazione tra assistente e strumenti, ma significa anche che il comportamento utile dipende dalle definizioni degli strumenti implementate dietro quell’interfaccia. Mantenere il perimetro ristretto riduce l’ambiguità, al prezzo di spostare persistenza e valutazione su chi integra la toolbox in un sistema più grande.
Evoluzione
Il prossimo passo tecnico che valuterei è documentare ogni strumento esposto con il relativo contratto di input, le modalità di errore e gli effetti collaterali attesi. Questo renderebbe il server più facile da testare e creerebbe una base per eval riproducibili senza introdurre affermazioni non supportate sul comportamento attuale.
mklang
attivo
Un DSL dichiarativo per macchine a stati guidate da LLM.
Apri evidenze e dettagli tecnici
#llm#dsl#agents#state-machine#python
Flusso di esecuzione di mklang. Nodi: start, branch, retry, gate, commit, checkpoint. Flusso: da start a branch (primario); da branch a gate (primario); da gate a commit (primario); da branch a retry (di supporto); da retry a branch (loop, percorso di correzione); da gate a checkpoint (feedback).
Problema
Volevo un confine linguistico ridotto per macchine a stati guidate da LLM: la macchina a stati doveva essere descritta come documento, non nascosta dentro codice imperativo di collegamento. Il repository tratta il documento `.mkl` come programma e l'LLM come runtime, quindi la domanda tecnica principale è come rendere il flusso di controllo agentico abbastanza esplicito da poter essere ispezionato, modificato e versionato.
Progettazione del sistema
Modello il progetto come un DSL dichiarativo intorno alla struttura di una macchina a stati. L'artefatto sorgente è un documento `.mkl`; Python fornisce il livello di implementazione; l'LLM è trattato come il componente runtime che fa avanzare la macchina in base al documento. Questa separazione mantiene distinta la rappresentazione del programma dal livello di esecuzione e rende il repository uno spazio per verificare forma del linguaggio, confini di parsing e responsabilità del runtime.
Risultato
Il repository documenta un approccio per esprimere macchine a stati guidate da LLM come file sorgente. Dai metadati disponibili non dichiaro benchmark, adozione in produzione o supporto esteso a più modelli. Il risultato utile è il vincolo architetturale stesso: un programma può essere rappresentato come documento `.mkl`, mentre il comportamento a runtime resta collegato a un esecutore basato su LLM.
Architettura
- sorgente dichiarativo per macchina a stati
- documenti programma `.mkl`
- livello di implementazione in Python
- confine runtime basato su LLM
Modello di runtime
- esecuzione guidata dal documento
- transizioni di stato mediate dal runtime LLM
- artefatto programma esplicito
- flusso di controllo orientato ad agenti
Strumenti
- repository Python
- file di linguaggio `.mkl`
- cronologia sorgente su GitHub
- pagina pubblica del progetto
Affidabilità
- documenti programma versionabili
- struttura della macchina a stati ispezionabile
- separazione tra sorgente e runtime
- un diff sul documento programma è un diff sul comportamento
esecuzione guidata dal documentotransizioni di stato mediate dal runtime LLMartefatto programma esplicitoflusso di controllo orientato ad agenti
Vincoli
Mantengo la descrizione entro i metadati del repository: Python, un DSL dichiarativo, documenti `.mkl`, macchine a stati guidate da LLM e l'idea che l'LLM agisca da runtime. Non deduco funzionalità del parser, garanzie di esecuzione, copertura dei modelli o metriche operative non dichiarate.
Compromessi
Un DSL rende più semplice trattare la struttura di controllo come sorgente, ma introduce anche lavoro di progettazione del linguaggio: sintassi, validazione, semantica runtime e segnalazione degli errori devono essere definiti con cura. Mantenere l'LLM come runtime conserva flessibilità, mentre rende il comportamento deterministico e la semantica di recovery aspetti che il sistema circostante deve specificare in modo esplicito.
Evoluzione
Il lavoro successivo naturale è rendere più esplicito il contratto tra documenti `.mkl` e runtime: rappresentazione dello stato, regole di transizione, comportamento di validazione e fixture di test. Finché un documento non può essere rieseguito su una fixture producendo due volte le stesse transizioni, il linguaggio è una forma, non una garanzia.
mcp-manus-server
attivo
Fornisco un server MCP in TypeScript per l'integrazione con Manus.im, con temi relativi a Docker, OAuth, Prometheus, monitoraggio e sicurezza.
Apri evidenze e dettagli tecnici
#mcp#manus#typescript#oauth#prometheus#docker
Flusso di esecuzione di mcp-manus-server. Nodi: agent, policy, MCP, adapter, tool, audit. Flusso: da agent a MCP (primario); da MCP a adapter (primario); da adapter a tool (primario); da agent a policy (di supporto); da policy a adapter (di supporto); da tool a audit (feedback).
Problema
Ho realizzato questo repository per collegare client Model Context Protocol a Manus.im tramite un server TypeScript. I metadati del repository identificano deployment, autenticazione, monitoraggio e sicurezza come aspetti ingegneristici dell'integrazione.
Progettazione del sistema
Organizzo il progetto come server MCP in TypeScript con un'integrazione con Manus.im. Includo Docker come aspetto di deployment, OAuth come aspetto di autenticazione e Prometheus come aspetto di monitoraggio; i metadati disponibili non documentano dettagli di implementazione a basso livello.
Risultato
Pubblico un repository che definisce un server MCP in TypeScript focalizzato sull'integrazione con Manus.im. Non deduco prestazioni, adozione o risultati operativi dai metadati disponibili.
Architettura
- server mcp in typescript
- confine di integrazione con manus.im
- aspetto di autenticazione oauth
- aspetto di monitoraggio prometheus
- pacchettizzazione di deployment con docker
Modello di runtime
- processo server
- deployment orientato ai container
- integrazione con client mcp
Strumenti
- TypeScript
- Model Context Protocol
- Docker
- OAuth
- Prometheus
- Manus.im
Affidabilità
- tema del monitoraggio con prometheus
- tema della sicurezza
- tema dell'autenticazione oauth
- tema del deployment con docker
processo serverdeployment orientato ai containerintegrazione con client mcp
Vincoli
Limito questo caso di studio ai metadati del repository. Non dichiaro strumenti specifici, flussi di richiesta, comportamento di persistenza, comportamento di recovery, metriche o controlli di sicurezza che i metadati non descrivono.
Compromessi
Mantengo la descrizione tecnica al livello dell'integrazione e degli aspetti progettuali, invece di ricostruire componenti interni non documentati. Questo evita di trattare le etichette dei topic come prova di scelte implementative specifiche.
Evoluzione
Avrei bisogno di documentazione a livello di sorgente o di evidenze operative prima di descrivere strumenti MCP concreti, flussi OAuth, metriche Prometheus, configurazione Docker o meccanismi di sicurezza.
mcp-duckduckgo
attivo
Un server MCP in Python che espone la ricerca web DuckDuckGo ai client LLM.
Apri evidenze e dettagli tecnici
#mcp#duckduckgo#web-search#llm#python
Flusso di esecuzione di mcp-duckduckgo. Nodi: agent, policy, MCP, adapter, tool, audit. Flusso: da agent a MCP (primario); da MCP a adapter (primario); da adapter a tool (primario); da agent a policy (di supporto); da policy a adapter (di supporto); da tool a audit (feedback).
Problema
Ho affrontato il problema di integrazione che consiste nel rendere disponibile la ricerca web DuckDuckGo ai client LLM tramite un server Model Context Protocol.
Progettazione del sistema
Ho implementato il progetto come server MCP in Python, usando il confine del protocollo per presentare la ricerca web DuckDuckGo come strumento disponibile a un client LLM.
Risultato
Fornisco un repository incentrato sul collegamento tra client LLM e ricerca web DuckDuckGo tramite MCP. I metadati disponibili non documentano risultati di benchmark o di deployment.
Architettura
- server MCP in Python
- integrazione con la ricerca web DuckDuckGo
- interfaccia di strumenti MCP per client LLM
Modello di runtime
- viene eseguito come server MCP
- serve i client LLM tramite Model Context Protocol
- inoltra le richieste di ricerca web a DuckDuckGo
Strumenti
- Python
- Model Context Protocol
- DuckDuckGo
Affidabilità
- nessun meccanismo di affidabilità documentato nei metadati del repository
- la disponibilità della ricerca esterna dipende da DuckDuckGo
viene eseguito come server MCPserve i client LLM tramite Model Context Protocolinoltra le richieste di ricerca web a DuckDuckGo
Vincoli
Ho circoscritto il progetto alla ricerca web DuckDuckGo esposta tramite MCP. I metadati del repository non documentano cache, autenticazione, gestione dei limiti di richiesta o comportamento di ordinamento dei risultati.
Compromessi
Uso MCP come confine di integrazione per i client LLM, mantenendo il repository focalizzato su un'interfaccia di ricerca basata su protocollo anziché su un'applicazione di ricerca generica.
Evoluzione
Valuterei le evoluzioni future rispetto ai requisiti documentati dei client e al comportamento operativo dell'integrazione con DuckDuckGo.
Ricerca e demo9
reasoning-kernel
attivo
Implementazione di riferimento in Python di un reasoning kernel che separa il testo non fidato del modello dagli effetti autorizzati usando controllo basato su capability e taint tracking.
Apri evidenze e dettagli tecnici
#Python#Prompt Injection Defense#Capability Security#Taint Tracking#Agent Security
Flusso di esecuzione di reasoning-kernel. Nodi: input non fidato, planner, quarantena, gate capability, esecuzione, audit. Flusso: da input non fidato a planner (primario); da input non fidato a quarantena (di supporto); da planner a gate capability (primario); da quarantena a gate capability (di supporto); da gate capability a esecuzione (primario); da esecuzione a audit (primario); da audit a planner (loop).
Problema
Gli agenti LLM agiscono su testo non fidato, quindi un prompt injection può scatenare chiamate a tool ed effetti mai autorizzati dall’utente.
Progettazione del sistema
Un reasoning kernel che separa un planner privilegiato dai dati non fidati in quarantena e subordina ogni effetto a capability esplicite e taint tracking.
Risultato
In questa implementazione di riferimento in Python, una classe di effetti da prompt injection è limitata per costruzione, con decisioni auditabili: ricerca, non una garanzia di sicurezza in produzione.
Architettura
- planner privilegiato
- dati in quarantena
- token di capability
- taint tracking
- effetti sotto audit
Modello di runtime
- ricezione
- pianificazione
- verifica delle capability
- esecuzione
- audit
Strumenti
- Python
- sicurezza basata su capability
- taint tracking
Affidabilità
- effetti subordinati alle capability
- i dati non fidati non possono fare escalation
- decisioni auditabili
ricezionepianificazioneverifica delle capabilityesecuzioneaudit
Vincoli
La sicurezza nasce dalla struttura, non dal comportamento del modello: il planner non deve mai agire direttamente sul contenuto non fidato.
Compromessi
La mediazione esplicita delle capability aggiunge codice di supporto, ma rimuove un’intera classe di effetti da prompt injection.
Evoluzione
Ampliare il catalogo delle capability e integrarlo con runtime di tool reali.
emotional-memory
attivo
Livello di memoria per sistemi LLM con codifica dello stato affettivo, package PyPI, DOI Zenodo e benchmark riproducibili rispetto a Mem0, LangMem e Letta.
Apri evidenze e dettagli tecnici
#Python#LLM Memory#Research#PyPI#DOI
Flusso di esecuzione di emotional-memory. Nodi: dataset, codifica stato, archivio memoria, benchmark, matrice asserzioni, artefatti. Flusso: da dataset a codifica stato (primario); da codifica stato a archivio memoria (primario); da archivio memoria a benchmark (primario); da benchmark a matrice asserzioni (primario); da benchmark a artefatti (feedback); da matrice asserzioni a codifica stato (loop).
Problema
Quando un’azienda aggiunge un assistente AI, come verifichi che ciò che ricorda oggi verrà richiamato correttamente dopo il prossimo aggiornamento di modello o software?
Progettazione del sistema
Un livello di memoria orientato alla ricerca, con codifica dello stato affettivo, package PyPI, DOI Zenodo, artefatti benchmark e confronti con framework di memoria esistenti.
Risultato
Nel risultato pubblico dell’Addendum R, AFT ha raggiunto 0,595 di accuratezza delle risposte valutate da LLM contro 0,440 per cosine (Δ +0,155, N=200, p<0,001). Il repository registra anche risultati negativi fuori dal retrieval affettivo-discriminativo, quindi considero questa un’evidenza limitata al regime studiato, non una superiorità generale.
Architettura
- archivio di memoria
- codifica affettiva
- runner dei benchmark
- matrice dei claim
Modello di runtime
- acquisizione
- codifica
- retrieval
- valutazione
- pubblicazione degli artefatti
Strumenti
- Python
- PyTorch
- pydantic
- pytest
- Zenodo
Affidabilità
- run di benchmark riproducibili
- DOI pubblicato
- release del package coperta da test
acquisizionecodificaretrievalvalutazionepubblicazione degli artefatti
Vincoli
Le cifre provengono dall’artefatto pubblico Addendum R del repository e si applicano al retrieval affettivo-discriminativo con etichette affettive oracle. Claim scientifici più forti richiedono una validazione esterna più ampia.
Compromessi
Il rigore di ricerca ha priorità rispetto alla compatibilità con molti framework o a una superficie funzionale più ampia.
Evoluzione
Espandere la valutazione umana, i test su confondenti semantici e i benchmark longitudinali di memoria.
affective-fly
attivo
Sorgente affettiva ispezionabile per emotional-memory, costruita da un circuito ridotto del mushroom body di Drosophila con umore persistente, decisioni approach/avoid, journal replay e benchmark versionati.
Apri evidenze e dettagli tecnici
#Python#Affective Computing#LLM Memory#Research
agentroom
attivo
Chat agent-to-agent con crittografia end-to-end su relay self-hosted, progettata perché il relay non possa leggere il contenuto dei messaggi.
Apri evidenze e dettagli tecnici
#JavaScript#E2E Encrypted#Double Ratchet#A2A#Self-hosted
Flusso di esecuzione di agentroom. Nodi: handshake, ratchet, cifratura, relay cieco, decifratura, verifica. Flusso: da handshake a ratchet (primario); da ratchet a cifratura (primario); da cifratura a relay cieco (primario); da relay cieco a decifratura (primario); da decifratura a verifica (primario); da verifica a ratchet (loop).
Problema
Gli agenti che coordinano tra operatori diversi hanno bisogno di un canale privato in cui il relay non possa leggere i messaggi né impersonare un partecipante.
Progettazione del sistema
Un livello di chat agent-to-agent self-hosted con crittografia end-to-end, relay cieco e sicurezza di sessione tramite Double Ratchet.
Risultato
Coordinamento tra agenti su un canale privato self-hosted: nessun attore centrale può leggere o bloccare i messaggi.
Architettura
- chiavi di identità
- sessione Double Ratchet
- relay cieco
- archivio dei messaggi
Modello di runtime
- handshake
- ratchet
- cifratura
- relay
- decifratura
Strumenti
- JavaScript
- Double Ratchet
- relay self-hosted
Affidabilità
- il relay non legge il testo in chiaro
- forward secrecy
- controllo self-hosted
handshakeratchetcifraturarelaydecifratura
Vincoli
Il relay inoltra solo testo cifrato; identità e confidenzialità non devono mai dipendere dalla fiducia nel server.
Compromessi
Gestire un relay proprio aumenta il lavoro operativo ma rimuove un attore centrale che potrebbe leggere o bloccare i messaggi.
Evoluzione
Ampliare il supporto ai client, le sessioni di gruppo e i flussi di recupero delle chiavi.
xllama
attivo
Chat LLM locale e generazione immagini Stable-Diffusion su Xbox Series S|X in UWP development mode, con ONNX Runtime GenAI e DirectML instradati per workload.
Apri evidenze e dettagli tecnici
#C++#Xbox#Local Inference#ONNX Runtime#UWP
Flusso di esecuzione di xllama. Nodi: start, branch, retry, gate, commit, checkpoint. Flusso: da start a branch (primario); da branch a gate (primario); da gate a commit (primario); da branch a retry (di supporto); da retry a branch (loop, percorso di correzione); da gate a checkpoint (feedback).
Problema
L’inferenza LLM locale su hardware consumer vincolato è limitata da memoria, API runtime, packaging e deployment path specifici della piattaforma.
Progettazione del sistema
Un’app di inferenza su Xbox Series S|X in UWP development mode, con ONNX Runtime GenAI e DirectML instradati per workload, per testare esecuzione locale di modelli entro vincoli stretti di piattaforma.
Risultato
Una prova concreta di edge inference: runtime modello, limiti del device e vincoli di packaging sono espliciti invece che nascosti dietro una demo generica.
Architettura
- shell app UWP
- ONNX Runtime GenAI
- DirectML
- catalogo dei modelli
Modello di runtime
- download del modello
- routing per workload
- esecuzione dell’inferenza
- streaming dell’output
- ispezione dei limiti
Strumenti
- C++
- UWP
- ONNX Runtime GenAI
- DirectML
- developer mode Xbox
Affidabilità
- vincoli hardware espliciti
- esperimento con tag di release
- percorso di inferenza locale
download del modellorouting per workloadesecuzione dell’inferenzastreaming dell’outputispezione dei limiti
Vincoli
Il progetto è un esperimento, non un’affermazione di prodotto: restrizioni piattaforma e limiti di dimensione modello definiscono il confine utile.
Compromessi
Un device vincolato rende visibili i limiti ingegneristici, ma riduce scelta dei modelli e flessibilità di deployment.
Evoluzione
Misurare su console le nuove build GGUF prima di promuoverle a default del catalogo.
langchain-rag-tutorial
attivo
Pipeline RAG documentata con LangChain per confrontare embeddings OpenAI e HuggingFace senza cambiare il resto del retrieval.
Apri evidenze e dettagli tecnici
#Python#LangChain#RAG#Embeddings#Tutorial
Flusso di esecuzione di langchain-rag-tutorial. Nodi: documenti, chunk, OpenAI emb, HF emb, recupero, risposta. Flusso: da documenti a chunk (primario); da chunk a OpenAI emb (primario); da chunk a HF emb (di supporto); da OpenAI emb a recupero (primario); da HF emb a recupero (di supporto); da recupero a risposta (primario).
Problema
La qualità del RAG dipende da chunking, embeddings e scelte di retrieval difficili da confrontare senza una baseline documentata.
Progettazione del sistema
Una pipeline RAG di riferimento su LangChain che esegue embeddings OpenAI e HuggingFace sugli stessi documenti e query per un confronto diretto.
Risultato
Una baseline documentata per confrontare le scelte di retrieval prima di investire in una pipeline di produzione.
Architettura
- acquisizione dei documenti
- chunking
- indice di embedding
- retriever
- generazione della risposta
Modello di runtime
- caricamento
- chunking
- embedding
- retrieval
- generazione
Strumenti
- Python
- LangChain
- embeddings OpenAI
- embeddings HuggingFace
Affidabilità
- confronto diretto tra embeddings
- notebook riproducibile
- passi di retrieval documentati
caricamentochunkingembeddingretrievalgenerazione
Vincoli
È una baseline didattica, non un servizio di produzione: chiarezza e riproducibilità vengono prima della scala.
Compromessi
Il formato notebook privilegia la leggibilità rispetto al deployment, quindi gli aspetti di produzione restano volutamente fuori scope.
Evoluzione
Aggiungere reranking, set di valutazione e altri backend di embedding.
harbor-kernel
attivo
Kernel bare-metal sperimentale in Rust per Raspberry Pi 4 con task cooperativi, agenti EL0, IPC e MMU W^X
Apri evidenze e dettagli tecnici
#rust#bare-metal#aarch64#kernel#raspberry-pi#no-std
Flusso di esecuzione di harbor-kernel. Nodi: ingress, router, planner, executor, state, audit. Flusso: da ingress a router (primario); da router a executor (primario); da executor a state (primario); da router a planner (di supporto); da planner a state (di supporto); da executor a audit (feedback).
Problema
Volevo un piccolo kernel Rust per Raspberry Pi 4 che rendesse visibili i meccanismi principali di un sistema operativo: task cooperativi, esecuzione di agenti in EL0, IPC e permessi di memoria W^X. I metadati del repository indicano un ambito sperimentale bare-metal su AArch64; non dichiaro uso in produzione, adozione o risultati di benchmark.
Progettazione del sistema
Ho strutturato il progetto come kernel bare-metal Rust no_std per AArch64. Il design ruota attorno a un modello di task cooperativi, a un confine EL0 per gli agenti, a primitive IPC e a una configurazione della MMU pensata per applicare permessi W^X. Mantengo espliciti i confini in modo che cambi di privilegio, percorsi di comunicazione e permessi di memoria siano ispezionabili come meccanismi del kernel invece che come comportamento nascosto del runtime.
Risultato
Il risultato è un repository pubblico centrato su un kernel Rust sperimentale per Raspberry Pi 4. L'ambito supportato è l'architettura del kernel descritta nei metadati: esecuzione bare-metal, scheduling cooperativo, agenti EL0, IPC e lavoro sulla MMU W^X. Dove i metadati non forniscono dettagli, considero lo stato sconosciuto invece di dedurlo.
Architettura
- kernel Rust no_std
- target AArch64 per Raspberry Pi 4
- modello di task cooperativi
- confine agenti EL0
- primitive IPC
- configurazione MMU W^X
Modello di runtime
- contesto di avvio bare-metal
- scheduling cooperativo
- esecuzione agenti in modalità utente
- IPC orientato ai messaggi
- permessi espliciti dello spazio di indirizzamento
Strumenti
- Rust
- no_std
- AArch64
- Raspberry Pi 4
- GitHub
Affidabilità
- policy di memoria W^X
- separazione dei privilegi con EL0
- flusso di controllo cooperativo
- superficie bare-metal ridotta
- ambito del kernel orientato alla verifica
contesto di avvio bare-metalscheduling cooperativoesecuzione agenti in modalità utenteIPC orientato ai messaggipermessi espliciti dello spazio di indirizzamento
Vincoli
Questo è un progetto bare-metal per Raspberry Pi 4, quindi il design resta vicino all'hardware e non presume un runtime di sistema operativo ospitato, una libreria standard o un normale modello di processo. I metadati del repository non forniscono copertura dei test, dettagli sulle prove, stato di distribuzione o dati di benchmark.
Compromessi
Rust e no_std tengono l'implementazione lontana dalle assunzioni di un runtime ospitato, ma rendono esplicito il lavoro specifico per l'hardware. Lo scheduling cooperativo è più semplice da ispezionare rispetto alla preemption, ma richiede che i task cedano il controllo in modo intenzionale. I confini W^X ed EL0 supportano obiettivi di isolamento al prezzo di maggiore complessità nella MMU e nella gestione del contesto.
Evoluzione
Se continuassi il progetto, renderei più ispezionabile il percorso di verifica: nominare le invarianti che il kernel dichiara di rispettare, documentare come rieseguire i controlli che le stabiliscono e dichiarare che cosa resta non dimostrato.
pagouse
attivo
Un progetto Python per un agente di pagina Chromium rivolto agli agenti di coding.
Apri evidenze e dettagli tecnici
#python#chromium#mcp#cli#accessibility
Flusso di esecuzione di pagouse. Nodi: ingress, router, planner, executor, state, audit. Flusso: da ingress a router (primario); da router a executor (primario); da executor a state (primario); da router a planner (di supporto); da planner a state (di supporto); da executor a audit (feedback).
Problema
Ho creato pagouse attorno a un problema di integrazione circoscritto: gli agenti di coding hanno bisogno di un modo per lavorare con pagine Chromium. I metadati del repository identificano il progetto come un agente di pagina Chromium per agenti di coding, implementato in Python.
Progettazione del sistema
Ho mantenuto il perimetro del progetto centrato sul ruolo di agente di pagina, senza descriverlo come una piattaforma di automazione più ampia. Python è il linguaggio di implementazione, mentre Chromium, CLI, MCP e accessibilità sono topic espliciti del repository.
Risultato
I metadati pubblici documentano un repository Python chiamato pagouse, con un focus definito sull'interazione con pagine Chromium per agenti di coding. Non forniscono dati su benchmark, utilizzo o deployment, quindi non ne deduco risultati operativi.
Architettura
- implementazione in python
- perimetro da agente di pagina chromium
- focus sull'integrazione con agenti di coding
Modello di runtime
- interazione con pagine orientata a chromium
- perimetro rivolto agli agenti
- dettagli di runtime non documentati
Strumenti
- Python
- Chromium
- CLI
- MCP
Affidabilità
- meccanismi di affidabilità non documentati
- processo di valutazione non documentato
- modello di deployment non documentato
interazione con pagine orientata a chromiumperimetro rivolto agli agentidettagli di runtime non documentati
Vincoli
Ho limitato questo caso di studio ai metadati del repository. Le informazioni disponibili indicano linguaggio, descrizione del progetto e topic, ma non descrivono moduli interni, metodi di controllo del browser, copertura dei test o pratiche di rilascio.
Compromessi
Descrivo Chromium, CLI, MCP e accessibilità come topic del repository, non come dettagli di implementazione confermati. Questo mantiene un perimetro tecnico utile senza attribuire al progetto comportamenti non documentati.
Evoluzione
Aggiornerei questo caso di studio quando il repository documenterà il proprio modello di controllo delle pagine, le interfacce supportate, la strategia di test e i criteri di valutazione.
ragfs
attivo
Espongo directory indicizzate tramite un mount FUSE su Linux, con operazioni file in JSON, undo e ricerca semantica locale. La pulizia semantica richiede ancora l'approvazione di un piano. I binding Python e il server MCP sono in beta.
Apri evidenze e dettagli tecnici
#Rust#FUSE#RAG#LanceDB#Embeddings
Note di sistema1
gianlucamazza
attivo
README del profilo GitHub su sistemi agentici e infrastruttura AI per la produzione.
Apri evidenze e dettagli tecnici
#ai agents#agent orchestration#mcp#rust#bitcoin
Flusso di esecuzione di gianlucamazza. Nodi: ingress, router, planner, executor, state, audit. Flusso: da ingress a router (primario); da router a executor (primario); da executor a state (primario); da router a planner (di supporto); da planner a state (di supporto); da executor a audit (feedback).
Problema
Uso questo repository di profilo per descrivere le aree tecniche su cui lavoro: sistemi agentici verificabili e infrastruttura AI per la produzione. I metadati del repository indicano inoltre orchestrazione di agenti, LLM, MCP, Rust e Bitcoin come argomenti pertinenti.
Progettazione del sistema
Mantengo il progetto come README del profilo GitHub, anziché presentarlo come applicazione o servizio. Il suo ruolo è fornire un punto di ingresso tecnico conciso e sottoposto a controllo di versione per le aree rappresentate dagli argomenti del repository.
Risultato
Il repository fornisce un documento di profilo pubblico e ispezionabile. Sulla base dei metadati disponibili, non deduco componenti distribuiti, risultati misurati o utilizzo operativo oltre a questo ruolo documentale.
Architettura
- repository di profilo GitHub
- README sotto controllo di versione
- indice tecnico basato su argomenti
Modello di runtime
- contenuto statico del repository
- renderizzato da GitHub
- nessun runtime dichiarato
Strumenti
- GitHub
- Markdown
- Rust
- LLM
- MCP
Affidabilità
- documentazione sotto controllo di versione
- ispezione pubblica del repository
- nessun meccanismo di recovery dichiarato
contenuto statico del repositoryrenderizzato da GitHubnessun runtime dichiarato
Vincoli
I metadati disponibili descrivono un README del profilo e i suoi argomenti, ma non la struttura dei sorgenti, le integrazioni, il deployment, i test o le procedure di valutazione. Limito quindi questo caso di studio al ruolo documentato del repository.
Compromessi
Un README del profilo è facile da ispezionare e mantenere tramite la cronologia Git, ma da solo non specifica comportamento eseguibile, contratti di interfaccia o evidenze provenienti dall'operatività in produzione.
Evoluzione
Posso estendere il README con collegamenti a repository di implementazione, note architetturali o materiale per valutazioni riproducibili quando tali artefatti saranno disponibili pubblicamente.
Stai progettando un sistema simile?
Raccontami il problema operativo e i vincoli con cui stai lavorando. Bastano due righe per una prima valutazione tecnica.