Journal № 13

Fylle Commons: Why We Opened Our Agents, and What Still Doesn't Travel

Agent behavior is shareable. Compounding context is not.

Davide Scantamburlo CEO, Fylle
7 min read
product
Fylle brand artwork: a dark field of green signal lines and points flowing into a glowing central sphere, suggesting portable behavior orbiting around a dense private context core.

I’ve lost count of how many prompt libraries, agent hubs, and skill marketplaces have launched in the last year. Every week, a new collection promises to make you more productive by sharing the “best” prompts or agent blueprints.

The paradox is obvious: with so much shared, why does so little of it actually transfer value?

Copying a prompt or agent doesn’t copy the memory of your organization, the feedback that shaped it, or the context in which it makes decisions. Agents are commodity. Context is the product. That’s the line I keep coming back to, and it’s the reason Fylle Commons exists at all.

What’s actually shareable in an agent

Prompts, skills, agent definitions, even entire multi-agent pipelines, these are all building blocks. They can be sophisticated, well-designed, and operationally useful. But none of them, by themselves, create a durable advantage.

The real value accumulates elsewhere: in the data an agent has seen, the memory it carries between runs, the feedback that corrected it, the operational rules that emerged from experience, the relationships it learned by being used in your environment.

A prompt you copy brings none of that with it. The behavior is portable. The compounding context is not.

The .fylle protocol: packaging, not content

This is why we built the .fylle protocol. .fylle is an open, portable format for describing an agent: identity and role, prompt, inputs and outputs, skills, required capabilities, guardrails, memory configuration, metadata, dependencies. It defines the container, not the specific content, and not the runtime.

The analogy I use is Docker and the OCI spec. The spec tells you how to package and move an image, not what your application does or how it runs.

.fylle is the packaging spec. Fylle Commons is the set of reusable images built to that spec. Fylle Platform is the runtime that pulls models, tools, and services together to execute one. Your private context is the volume mounted at runtime, the layer that turns a generic image into something specific and cumulative for you.

The birth of Fylle Commons

Two weeks ago, I merged a pull request into our protocol repository that added a new folder: commons/. It sits next to spec/, sdk/, and examples/.

That folder is Fylle Commons: a curated library of skills, agents, and workflows built with the .fylle format and given away for anyone to use, inspect, or fork.

But Fylle Commons is not a prompt dump. An artifact only ships if it’s:

This bar is high on purpose. Publishing a public prompt dump is easy and worth little. Publishing a workflow that’s been battle-tested, generalized, and documented is harder, and that’s the only kind worth sharing.

Protocol, Commons, runtime, context

Fylle Commons uses the .fylle protocol, but it doesn’t extend or modify it. Shipping a new workflow doesn’t require a new version of the spec. It’s content that conforms to a standard that already exists. That separation is intentional.

Composition happens at three levels:

  1. In the repository: commons/ lives beside spec/, sdk/, and examples/.
  2. In artifacts: Multiple .fylle agents can be assembled into a .fyllepack, a multi-agent pipeline.
  3. At execution: The runtime combines public behavior from Commons, whatever tools are available, and your private context into a single run.

This structure keeps the protocol stable, the Commons focused, and the runtime flexible. Your private context, memory, data, feedback, operational rules, is always mounted at runtime, never baked into the portable artifact.

A concrete example: Critical Reviewer

Take the skill called Critical Reviewer. There’s a native version for harnesses like Codex, the canonical source, the one I trust first. There’s also a maintained .fylle adapter with the same behavior.

The native version is the source of truth. The .fylle version is a kept copy, not a replacement.

This separation lets a specific environment stay excellent without pretending that portability across environments is free.

The first Commons workflows are deliberately unglamorous: a blog post with a hero image, a social post with a visual, static ad variants, a ten-second video ad. These are repeatable jobs, not demo-day tricks, and that’s the point. They’re published because they’re genuinely used, not because they look good in a demo.

Why share skills and pipelines at all?

It’s not that prompts and skills have no value. They do. They require real design, maintenance, and operational discipline. But they’re easier to copy than the context that makes them truly effective.

Open skills don’t compete with private context. They depend on private context existing somewhere else to mean anything.

Sharing these artifacts makes portability verifiable, not just a claim. It improves the protocol through real-world cases. It reduces lock-in to a single runtime. It creates a common language for describing agents. And it lets people share processes without sharing private data.

Limits and open questions

A public commons requires maintenance. Models, tools, and adapters can become obsolete. Different representations can diverge. Sanitization has to be rigorous. Portability has to be verified, not just claimed. There’s no evidence yet for broad adoption, no user counts, no case studies, no claim of a standard.

What I know: Separating the protocol from Commons was the right call. Bundling them would have turned every new workflow into pressure to bump the spec, and the spec would have drowned in content decisions.

What I don’t know: Whether our sanitization is rigorous enough. I reviewed every artifact that shipped, but “reviewed by me” is a weaker claim than “verified through independent use,” and I won’t blur that difference.

What I think: The agent travels light. The context stays where it compounds. Publishing the Commons isn’t generosity. It’s an architectural bet. If .fylle only worked inside our own runtime, it wouldn’t be a protocol; it would be a feature with good branding. Making it open means someone outside Fylle can test whether portability holds, which is a harder check than any internal demo I could run myself.

Fylle makes agents portable. Fylle Commons makes portability tangible. Your context makes them yours.

The part that actually compounds was never small enough to fit in the package to begin with.

Sources

← Back to Journal

Get the next entry in your inbox.

One email per article. Roughly. Plus the occasional update, when it ships.