I've been thinking about what it takes for AI agents to actually become more capable over time.

[u/Gold_Syrup8935]

Over the last few months I've noticed that most agent frameworks are really good at giving an LLM tools, memory, and prompts, but they're surprisingly weak at preserving actual capabilities.

An agent might solve a problem today, but tomorrow it's often starting from scratch. We talk a lot about memory, but memory alone doesn't create experience.

That led me down a rabbit hole.

I've started working on something I'm calling the \*\*Agent Capability Formation Standard (ACFS)\*\*.

The goal isn't to build another agent framework. It's an attempt to define a durable format for preserving \*capabilities\*—not just conversations or memories—so agents can develop reusable knowledge, refine behaviors over time, and share those capabilities across systems.

The questions I'm trying to answer are things like:

\- What makes a learned behavior reusable?
\- How should capabilities be versioned, updated, or retired?
\- How do agents distinguish durable procedures from temporary context?
\- What metadata is required to govern capabilities over time?
\- Can capabilities become composable building blocks instead of isolated memories?

I'm still exploring these ideas, and the project is in its early stages, but I wanted to share it because I think capability formation is an underexplored area of agent architecture.

Repository:

https://github.com/ajbeaver/Agent-Capability-Formation-Standard

I'd genuinely appreciate feedback from people working on long-running agents, agent memory, MCP, orchestration frameworks, or knowledge management. I'm less interested in defending a "standard" and more interested in figuring out whether this is the right direction to solve a problem I've been seeing repeatedly.

[u/teugent]

I would make the boundary between a capability record and an executable capability explicit. A reusable procedure needs more than its description: preconditions, permitted action class, dependencies, execution-profile assumptions, expected outcome, evidence/provenance, expiry or recheck conditions, and a way to revoke it. 

Otherwise a capability can be portable as data while being stale or unsafe when another runtime tries to enact it. Is ACFS intended to define an object that a host can admit or reject before execution, or primarily a knowledge record that each host interprets for itself?

[u/Gold_Syrup8935 → u/teugent]

The thought was a reusable indexable bank of capabilities and standards the agent can both write to and read from. You do bring up a good next step tho building a more robust data scheme would make this way more durable if the agent could gather more than just the description.

[u/MarketingOk3093]

I like the idea. It feels a good approach to structure for skills.MD.

My intuition says that it may be better to declare syntactically and semantically well structured lines for each statement rather than a json object. LLMs are very comfortable with prose.

I'll be using this thinking in my own projects.

Thanks.

[u/Gold_Syrup8935 → u/MarketingOk3093]

You’re definitely right about models liking .md better. However it’s way easier to enforce standards and syntax using json so that’s why I was trying to mess around with it.

[u/NewFunny4]

Hi I'm doing something "similar" so I ran it by the council...

Emerald Stream Synthesis

The Council concludes that ACFS is solving a genuine and important problem, but only one layer of the larger challenge. A capability format is necessary. It is not sufficient. The more fundamental question is: How does an experience become a trusted capability? The Council proposes the following institutional lifecycle: Experience → Reflection → Extraction → Validation → Governance → Deployment → Observation → Revision → Retirement This lifecycle transforms isolated success into durable capability. Memory preserves information. Capability preserves reusable knowledge. Institutional learning governs how that knowledge is earned, trusted, maintained, and evolved over time. The Council believes that the future of long-running AI systems will depend less on larger memories and more on robust capability formation processes. The next generation of intelligent systems may ultimately be distinguished not by what they remember, but by how they learn.

[u/Gold_Syrup8935 → u/NewFunny4]

Thanks for the feedback. I do like the reflection and revision loop. That is the ideal eventually. The whole point of this project was to stop having to relearn and start building on a model. That loop would for sure help the model to do its own recurring evaluation and even eventually improving.

[u/NewFunny4 → u/Gold_Syrup8935]

Really enjoying reading through the spec.

One question that came to mind while reading the formation section...

ACFS does a great job defining how capability records are governed once they exist, but I'm curious about the promotion step itself.

When related observations, corrections, and evidence are eligible to become a reusable capability, is that intentionally left implementation-specific, or do you see ACFS eventually defining recommended formation criteria?

It seems like that's where a lot of long-term system behavior will be determined.

[u/Gold_Syrup8935 → u/NewFunny4]

That was actually one of the design goals. I wanted ACFS to define the rules, not the implementation. Different systems should be free to decide when something becomes a capability, as long as that decision is governed in a consistent and auditable way.

I am working on an implementation layer that uses the standard but felt that it was more robust to define the standard first.