AI Collaboration Protocol · Ehoro Village · Living Document
A living collaboration protocol that gives every AI session and every teammate the same shared understanding of the product — what we're building, why we're building it, and what not to touch. One document, carried into every working session, so nobody drifts.
6
Person Team
24+
Build Sessions
V3.3
Living Version
0
Context Rebuilds
The Problem
Teams adopting AI hit the same wall: the tool is fast, but it has no memory, no taste, and no shared context. Every new conversation is a blank slate. And when multiple people on a team are running their own AI sessions against the same product, the result is drift — contradictory decisions, duplicated work, regressions that undo what someone built yesterday.
Across the first phase of building Ehoro Village, that's exactly what happened. Sessions were productive in isolation but incoherent in aggregate. Design intent eroded. The product was growing, but the team's shared understanding of it wasn't keeping up.
The manifesto is my answer to that problem. Not more meetings. Not a longer Notion doc nobody reads. A single living document that every session — human or AI — reads first, so the team's mental model of the product survives across every context switch.
The Artifact
Core idea
"The document IS the product. The code just implements it."
Documentation describes what was built. The manifesto describes what the product is — the philosophy, the constraints, the decisions that have already been made and why. It's the document the team builds against, not a record they write after.
The manifesto covers everything a new session or a new teammate needs to start contributing without breaking what already exists:
Product philosophy — what kind of experience this is, who it's for, what it should feel like. This isn't a PRD. It's the one-paragraph articulation that prevents an AI from accidentally turning a cozy companion app into a competitive game.
Design constraints — hard rules. Not style guides — behavioral constraints with reasoning attached. "Don't add mechanics that demand active attention" isn't a preference. It's the product's identity, and every session needs to understand it before touching anything.
Decision history — what's been tried, what failed, and why. When Session 21 attempted a visual redesign and it was reverted, that became a rule. The manifesto learns from the team's mistakes and makes them unrepeatable.
Data model and system architecture — a shared understanding of how the product actually works, so nobody builds a feature that contradicts the existing system.
Session log — a running record. Every session appends what it changed, what's still open, and what the next session should know. It's the team's institutional memory.
In Practice
Without the manifesto, every AI session starts with 10–20 minutes of re-explaining: what the product is, what the data looks like, what was built last time. With the manifesto, every session starts at full velocity. The document carries the context. The team doesn't have to.
Receipt — 24+ sessions across Ehoro Village. Zero time spent re-establishing context at the start of any session after the manifesto was introduced.
When six people are building a product and multiple AI tools are in the loop, design intent is the first thing that erodes. The manifesto holds the product philosophy still — what this product should feel like, who it's for, what it should never become — so that velocity doesn't come at the cost of coherence.
Receipt — Ehoro Village's core identity — a lo-fi companion that rewards presence, not attention — survived 24+ sessions because it was written into the manifesto as a hard constraint, not a soft suggestion.
Most teams lose their lessons in Slack threads nobody searches. The manifesto's session log captures what went wrong and converts it into a new rule or a new constraint. The document gets smarter every session. A mistake made once becomes a constraint the entire team — and every AI session — respects going forward.
Receipt — Session 21 attempted a full visual redesign. It was reverted. That failure became two new rules in the manifesto — and no subsequent session repeated it.
A new teammate, a new contractor, a new AI model — the manifesto is the same onboarding artifact for all of them. Instead of tribal knowledge spread across six people's heads, there's one document that reconstructs the entire product's mental model from scratch in minutes.
Receipt — Multiple AI models (Claude, ChatGPT, Gemini) have been used across the project. The manifesto made model-switching seamless — same document, same constraints, same output quality.
The person who writes the manifesto shapes the product. It's not a passive spec that engineering interprets — it's an active collaboration protocol that encodes design decisions, product philosophy, and UX constraints directly into the workflow. I wrote the manifesto, so my design intent is the thing the entire team — and every AI session — builds against.
Receipt — The manifesto is how I lead a team of 6 without managing through meetings. The document is the authority. The team builds against it. I own the document.
Evolution
It didn't start as a 12-section spec. It started as a one-page set of rules after the first phase of building produced too many regressions. Over 24+ sessions, it evolved organically — each session adding the constraints it needed, each failure becoming a new rule.
Phase 1 · Sessions 1–14
Before the manifesto
Building fast, but context lost between sessions. Regressions, naming conflicts, design drift. No shared source of truth.
Phase 2 · Sessions 15–17
First version
Core rules, product philosophy, data model. Immediately eliminated the context-rebuilding problem. Sessions started landing cleanly.
Phase 3 · Sessions 18–21
Stress-tested
Backend work, economy balancing, a failed redesign. Each challenge added new rules. The manifesto proved it could learn from failure.
Phase 4 · Sessions 22–24+
Mature methodology
Surgical precision. Sessions targeted, clean, no regressions. The manifesto's maturity visible in the quality of the output.
The moment that proved it works
Session 21: a full redesign was attempted and reverted.
An AI session attempted a wholesale visual overhaul. The result looked worse than what 20 prior sessions had carefully built. I reviewed it, reverted it, and added two new rules to the manifesto. The lesson didn't live in one person's memory — it became a permanent constraint that no future session could violate. That's the system working exactly as designed.
Outcomes
Team alignment
One document replaced the alignment meetings.
A six-person team (product, engineering, sound design, illustration, PM) working across multiple AI tools stayed aligned without syncs about "what are we building again?" The manifesto was the meeting. Everyone read the same document. Everyone built against the same intent.
Velocity
24+ sessions with zero context-rebuild overhead.
No session after the manifesto's introduction spent time re-establishing what the product is, what's been built, or what the constraints are. Every session started working immediately. That compounding time savings is the difference between shipping and stalling.
Quality
Design intent survived the entire build.
Ehoro Village shipped as a cozy, low-pressure companion — exactly what it was designed to be. Across 24+ sessions, six teammates, and multiple AI models, the product's identity never drifted. The manifesto held it still while velocity went up.
Portability
The specific content of the Ehoro Village manifesto is unique to that product. But the structure — product philosophy, design constraints, decision history, system model, session log — is universal. Every AI-augmented project I touch now starts with a manifesto.
Break Lab was built under it. The UX Feedback Analyzer was built under it. Each project's manifesto looks different — different data model, different constraints, different philosophy — but the discipline is the same.
The argument this page makes is simple: AI-augmented teams need a collaboration protocol, and the designer who writes it shapes everything downstream. I write the manifesto. The team builds against it. The product stays coherent.
The Argument
The team that writes down what it's building — and carries that document into every session — is the team that stays coherent when AI is in the loop.
This isn't about any specific technology. It's about team cognition under new constraints. AI introduced a collaborator with no memory and no shared context by default. The manifesto is the protocol that fills that gap — giving every session, every model, and every teammate the same foundation to build from.
It's the work that makes the other work possible. And it's the kind of work that only comes from someone who's been in the room when things drift — and decided to build the system that prevents it.