Un formato portabile per gli agent

Continuavo a riscrivere agent che funzionavano perfettamente.

Non perché fossero sbagliati. Perché il framework cambiava. CrewAI aggiornava la sua API. Usciva un tool migliore. Un cliente voleva cambiare provider. E ogni volta, stessa storia: ricostruire da zero.

I prompt, le configurazioni del modello, i tool, i guardrails · tutto accoppiato a un singolo runtime. L’agent era prigioniero della piattaforma che lo eseguiva.

Alla terza volta che è successo, ho smesso di curare il sintomo e ho iniziato a guardare la struttura.

Il gap

Ogni altro livello dello stack ha risolto questo problema anni fa.

Le app hanno Docker · un container che separa quello che un’app è da dove gira. I pacchetti hanno npm. L’infrastruttura ha Terraform. Gli agent AI non hanno nulla.

Non esiste un modo standard per dire “questo è il mio agent” · identità, istruzioni, capacità, vincoli · in un formato che qualsiasi framework possa capire.

CrewAI usa YAML. OpenAI usa JSON. LangChain usa Python. Claude Code usa file markdown. Cambi framework, riscrivi tutto.

Questo gap esiste perché la maggior parte dei framework tratta la definizione dell'agent e il runtime dell'agent come la stessa cosa. Non lo sono.

Perché questo è importante per noi

Se hai letto il primo post di questo blog, conosci la nostra tesi: gli agent sono commodity. Il context è il prodotto.

L’intelligenza non vive nel modello o nell’agent. Vive nel context strutturato che li alimenta. I modelli migliorano ogni trimestre. I framework vanno e vengono. Ma la conoscenza sul tuo cliente, il tuo dominio, le tue regole di compliance · quella fa compound.

Se credi a questo, allora un formato agent proprietario è architetturalmente sbagliato.

Pensaci. Se l’agent è commodity, deve essere portabile. Chiuderlo dentro un framework è come costruire un container che funziona solo su un camion. Il container dovrebbe andare ovunque. Il carico · il tuo context · è ciò che ha valore.

Questo è il ragionamento dietro .fylle.

Cos’è

Un file .fylle è un ZIP. Dentro, tutto ciò che definisce un agent:

my-agent.fylle/
├── manifest.json
├── identity/
│   ├── system_prompt.md
│   └── persona.json
├── model/
│   └── preferences.json
├── tools/
│   └── tool_definitions.json
├── guardrails/
│   └── rules.json
└── io/
    ├── inputs.json
    └── outputs.json

Leggibile da un umano. Versionabile in Git. Agnostico rispetto al framework.

Cosa non contiene, di proposito: il context stesso. Le card, le knowledge base, l’intelligence sul cliente · quelle restano nella tua infrastruttura di context. Un file .fylle può referenziare sorgenti di context, ma non le include.

L'agent viaggia leggero. Il context resta dove fa compound.

Cosa fa oggi

v0.1.0. SDK Python. Quattro adapter per framework.

Import da CrewAI (YAML), OpenAI Assistants (JSON), OpenClaw/SOUL.md, o Claude Code workspace. Export verso ognuno di questi.

Stai passando da OpenClaw a Claude Code? L’export genera un workspace completo · CLAUDE.md, settings, rules. Tre righe di Python. Da CrewAI a OpenAI Assistants? Stesso agent, nuovo runtime, nessuna riscrittura.

72 test che passano. Presto, ma funzionale.

Perché open source

Questa è la parte su cui tutti chiedono. Perché regalarlo?

Perché tenerlo chiuso avrebbe contraddetto tutto ciò in cui crediamo.

Se l’agent è commodity, il container che lo contiene è infrastruttura. Come un formato file, non un prodotto. Il valore non è nella struttura del ZIP. È in quello che ci metti dentro · e ancora di più, nell’infrastruttura di context che rende quegli agent efficaci.

Abbiamo reso .fylle open source perché pensiamo che un formato agent portabile sia un vantaggio per chiunque costruisca con agent AI. E pensiamo che l’ecosistema ne abbia bisogno più di quanto una singola azienda abbia bisogno di un lock-in proprietario.

Se sia la scelta strategica giusta è qualcosa che non posso ancora dimostrare. Ma è coerente con la tesi, e la coerenza conta più della furbizia quando stai costruendo qualcosa che dovrebbe durare.

Cosa viene dopo

Più adapter per framework. Supporto migliore per composizioni multi-agent. Un modello di capability più ricco per le definizioni dei tool.

Stiamo anche esplorando come i file .fylle possano referenziare sorgenti di context esterne in modo standardizzato · mantenendo la separazione tra agent portabili e context persistente pulita ed esplicita. Questa è la parte difficile, e non l’abbiamo ancora risolta.

Se costruisci con agent AI e hai sentito questo problema, ci farebbe piacere sentirti.

La spec è aperta. L’SDK è MIT. I contributi sono benvenuti.