Zero-Config AI: Moving Project Orchestration into the Registry
The Problem with Per-Repo Config
In the previous post, I described making AI personas portable — decoupled from any specific project. But there was still a question: how does the system know which harness to mount when I enter a directory?
The obvious answer is to drop a .soul or .ai-config file into the project root. But this creates artifact bloat. Your repository starts accumulating metadata that has everything to do with the agent’s reasoning and nothing to do with the software’s execution.
Centralized Orchestration
Following the Unix philosophy — a folder should only contain its own complexity — I moved the managerial layer into the registry.
By reusing an existing PROJECTS.json — the single source of truth for every repository on my machine — I can define the “brief” for every project in one place.
The Schema
The registry now includes a harness_config block that maps architectural constraints to physical paths without touching a single file in the repo:
"klaweht-blog": {
"path": "~/Code/klaweht-blog",
"harness_config": {
"harness": "teddy-architect@v1",
"specialists": ["terrain_mapper", "registry_guardian"],
"manager_brief": "Ensure Astro 5.x standards."
}
}
The Workflow
When I step into a directory, the system performs a lookup:
- Context resolution: Identify the current path.
- Registry lookup: Find the matching project key in the global registry.
- Harness injection: Pull the specific harness version defined for this project.
- Specialist provisioning: Load the specialist agents required for this project.
- Brief injection: Inject the project brief into the system prompt before the first word is typed.
The Result
My repositories stay clean — they contain only the code they’re meant to hold. The instructions on how to build that code stay in the registry.
If I want to upgrade all projects to a new harness version, I change one line. If I want to pivot a project’s priorities, I update the brief. The AI understands its role, tools, and mission the moment it boots into the project.
Next: cross-project memory — passing knowledge from one repository to another during the same session.