A small agent workflow can get by on context for a while. The user gives a task. The run reads a few files, makes a decision, maybe writes code, maybe leaves a note. If the next run starts soon enough and the context is still nearby, the work feels continuous.
Then the handoff breaks.
The repo has startup files, but they are stale. The project rules live in one place and the actual approval commands live in another. A decision was made during a deploy check, but the reason only exists in a chat transcript. An outbox contains a pending action, but nobody can tell whether it is still valid. A correction was given after a bad run, yet the next run repeats the same setup because the correction was never turned into a scoped record.
This is the part that often gets flattened into the phrase agent memory. It is a convenient phrase, but it is too vague for the work it is being asked to do.
Memory Is The Wrong Shape
A memory file sounds simple. Write down useful facts. Read them later. Let future runs benefit from the past.
That can help with small tasks, but it does not hold up once the records start affecting behavior. A note that says use pnpm in this repo is different from a note that says skip approval for a deploy command. A handoff note from yesterday is different from a project rule that should survive for months. A run observation is different from a policy. A failed deploy check is different from a reusable procedure.
If all of those become memories, the system loses the distinctions that make the records safe to use. The next run may retrieve a fact without knowing where it came from, who approved it, what scope it applies to, or whether it has been replaced. The record may be true for one repository and wrong for another. It may have been useful during an incident and harmful during normal work.
The problem is not that agents need bigger notebooks. The problem is that agentic systems need governed ways to turn work into future capability.
That means the record needs a shape. It needs scope. It needs authority. It needs lifecycle. It needs provenance. It needs revocation. Without those, a memory store becomes a pile of plausible text near the work.
Capability Formation Is A Systems Problem
Capability formation is the process by which observations, corrections, procedures, skills, policies, run evidence, and revisions become reusable behavior for later runs.
The phrase is longer than memory because the work is larger than recall. A useful system does not merely save that something happened. It preserves enough context for another run to decide whether the record should matter now.
Consider a repo note. It might say that tests require a local service to be running. That is useful, but only if the note says which repo it applies to, which command starts the service, what evidence established the note, and when it should be reconsidered. If the repo later moves to a different test runner, the old note must be revised or revoked. Otherwise the system preserves friction instead of removing it.
The same pattern shows up in handoff notes. A handoff note is not a universal instruction. It is a record from a particular point in the work. It may name unfinished files, blocked approvals, or a deploy check that has not been run. That record is valuable because it lets work resume cleanly. It is dangerous if it becomes an unscoped rule.
Project rules have a different weight. They may define which commands require approval, where generated files belong, or how outboxes are handled. Those records need clearer authority than casual observations. They also need a way to be superseded, because rules drift as the project changes.
This is why ACFS, the Agent Capability Formation Standard, is organized around governed records rather than loose memory. It asks what a system must preserve so later runs can use prior work without reconstructing the whole situation from isolated context.
The Other Side Of MCP
MCP gives agents a standard way to interact with external systems. It gives shape to tool access, resources, and integration boundaries. That matters because agent runs do not operate in a blank room. They read repositories, call services, inspect tickets, run commands, and write changes.
ACFS is about the other side of that loop.
After a run interacts with the world, what should be retained? Which records are allowed to influence future behavior? How does a later run know whether a correction came from a user, a tool result, a policy file, or an inferred pattern? How does the system prevent a temporary workaround from becoming permanent instruction?
Those questions are not answered by tool calling alone. They sit after the tool result, after the approval command, after the deploy check, after the user correction. MCP can provide access to the systems where work happens. ACFS defines a way to govern the durable records that work produces internally.
That is why ACFS is not a replacement for MCP. It depends on the same world of concrete operations, but it addresses a different failure mode. MCP helps a run reach external context and tools. ACFS helps a system preserve the right internal records with enough structure that future runs can retrieve, revise, or ignore them responsibly.
Why The First Durable Version Matters
We just pushed the first durable public version of ACFS to GitHub. Durable does not mean finished. It means the work has enough shape that FlowOS can build against it without treating every detail as private scratch space.
The repo now includes schema validation, examples, conformance docs, lifecycle docs, retrieval rules, MCP binding, and trust and safety guidance. Those pieces are not decoration. They are the difference between a concept and a standard-shaped foundation.
Schema validation matters because records need predictable structure. Examples matter because the difference between a run observation and a project rule should be visible in ordinary use. Conformance docs matter because independent implementations need some way to disagree clearly. Lifecycle docs matter because records are born, revised, deprecated, and revoked. Retrieval rules matter because not every relevant-looking record should enter a run. MCP binding matters because external interaction and internal record formation meet in practice. Trust and safety guidance matters because retained records can change future behavior.
None of this makes ACFS mature. It makes the experiment inspectable.
That distinction is important. A private convention can move quickly, but it is hard to build around. A public standard draft can be questioned. It can be implemented badly and corrected. It can expose missing fields, awkward lifecycle states, and weak assumptions about authority. That is useful work.
The Work Ahead
The next phase is less about naming the problem and more about using the standard under real pressure.
A capable system has to handle ordinary mess. Notes will conflict. Startup files will drift. A run will write a useful procedure with poor scope. A correction will arrive after the wrong record has already been used. A deploy check will produce evidence that should affect only one release branch. An outbox item will become invalid because ownership changed.
Those are not edge cases. They are the operating conditions.
ACFS is an attempt to give those conditions a durable record model. It treats capability as something formed through governed artifacts, not something implied by a larger context window or a folder of memories. The goal is modest and practical: preserve the parts of prior work that can be used again, make their authority visible, and keep a path for correction when the record stops being true.
ACFS is not finished. It is a first standard-shaped foundation for FlowOS to build on.