7
Responsibilities
Where each part of the system's work belongs.
MFM Spec · getting started
Turn rough intent into shared system memory.
Follow one real example, then create a hosted project your coding agents can read and evolve. The first useful result is a committed specification—not an installed connector.
01 · Inspect the result
From “AI incident responder” to a coherent product
A startup defines an incident-investigation agent that gathers evidence, proposes action, and keeps consequential execution under human control. The published snapshot makes the design inspectable before you create an account.
2
Features
What an operator can do or observe across those responsibilities.
3
Criteria
The design pressure the agent must preserve while proposing change.
1
Evaluation
What was learned without silently rewriting product intent.
02 · Choose the boundary
Workspace first, then project
Workspace
Your organization or team boundary. It controls membership and keeps customer state isolated.
MFM project
One system, product, or initiative whose design memory must stay coherent. It may span more than one repository.
03 · Let your agent author
Connect once. Bind the real work explicitly.
Create the project, connect the shared MFM server, then place the generated project instructions in the repositories where work happens. Your agent—not MFM—supplies the judgment.
Starter request for your agent
Use MFM Spec for this project. Read the active project policy first. If no specification exists, interview me about the system's intent, responsibilities, observable behavior, and design criteria. Challenge vague or conflicting assumptions before you create the first coherent revision.
04 · Know when it worked
The first revision appears.
A copied instruction block only confirms a clipboard action. Onboarding succeeds when your agent commits the first valid revision and the project opens as a live, readable specification. From there, every change keeps its reasoning, validation, and history.
Understand MFM Spec in more detail →