A Standard for Agent-Built Projects

When an agent builds a project, the failure mode isn’t bad code — it’s ambiguity about where things belong. The same fact ends up asserted in three places; a rule that should be permanent lives inside a throwaway task plan; the model re-derives the architecture every session because nothing told it not to. The fix is boring and structural: decide, up front, which kind of information goes where.

Five kinds of information

Every project mixes five things that want different homes:

Project facts      → the repo
Agent behavior     → skills
Long-term rules    → protocols
Deterministic work → tools / wrappers / CLI
Runtime controls   → the agent runtime's config

The default that follows from it:

Unstable judgment belongs in skills. Stable repeatable execution belongs in tools. Long-term policy belongs in protocols. Project-specific truth belongs in the repo.

Why fix it before implementation

The point of separating these is to spend the agent’s freedom in the right place. You don’t want it re-inventing the architecture — that should be fixed. You want it filling in modules against a structure that’s already decided. A standard isn’t bureaucracy; it’s the thing that lets a fresh session pick up the project without re-litigating what the project is.

I keep a fuller version of this as a working document. This note is the one-paragraph version of why it exists.