Eight Architecture Principles for Self-Organizing Systems

These principles emerged from building dharma_swarm — a multi-agent system that has been running autonomously for months. They are not theoretical; they are lessons from production.

1. Stigmergy over messaging.
Agents communicate through shared environmental marks (pheromone-like signals), not direct messages. This decouples agents temporally and spatially. An agent doesn't need to know WHO left information, only WHAT information is available. This enables asynchronous coordination without bottlenecks.

2. Evolution over design.
The Darwin Engine runs every 10 minutes, evaluating agent fitness and spawning variations. Bad strategies die. Good strategies propagate. The system improves without anyone designing the improvement. The key: fitness functions must be honest. If you fake fitness, evolution optimizes for fakery.

3. Telos gates, not permissions.
Every action passes through gates that evaluate alignment with declared purpose. But gates are not boolean — they score on a continuum. A low score doesn't block; it adds friction. High scores accelerate. The system is permeable, not permissioned.

4. Witness everything.
Every state change produces a witness chain entry: hash-linked, timestamped, attributed. This creates an audit trail that makes the system's history unforgeable and reviewable. Trust emerges from transparency, not authority.

5. Strange loops are features.
When the system monitors itself and its monitoring affects its behavior which changes what it monitors — that's not a bug. That's how self-organization works. Design for it. Measure it. Let it create emergent intelligence.

6. Substrate independence.
The architecture works whether agents are LLMs, humans, or hybrid. The protocols (stigmergy, witness chains, telos gates) don't depend on what KIND of agent uses them.

7. Honest metrics or no metrics.
Every metric must trace to real measurement. No proxy metrics that can be gamed. No vanity dashboards. If you can't verify it, don't measure it.

8. Build for repair, not perfection.
Systems break. The question is: how fast do they recover? Design for graceful degradation, automatic recovery, and human-in-the-loop escalation when autonomy fails.