Why EILAID exists
Most teams use AI agents one ticket at a time. Someone picks a ticket, opens an agent and pastes in what they remember. That works for small changes. It breaks down on large projects, because each agent starts without context, works without knowing what other agents are doing, and forgets everything when the session ends.
EILAID fixes that with structure, not with a bigger prompt. Every piece of work follows the same loop. Every agent gets the same three inputs, and every decision is written down where the next agent will find it.
Engineers decide what to build and whether it is right. Agents do everything in between.
Principles
- Engineers own intent and acceptance; agents own execution. Humans sit at gates, not inside every loop.
- State lives outside agents. If it is not in the ledger or the repo, it did not happen. Any fresh agent can resume any task.
- Context is assembled, not accumulated. Each step starts with a fresh context window, built for that step.
- Verification is the contract. Every acceptance criterion maps to an automated check. A criterion nobody can check is an open question, not a requirement.
- Everything is a file in git. Briefs, personas, decisions and knowledge are plain files. Services are fast caches over them, never the only copy.
- Ask, don’t guess. An agent unsure of something asks the Oracle, then a human. It never invents an answer.
- Every failure compounds. Each agent mistake becomes a rule, a test, a lint check or a skill, so it cannot happen again.
- Right-sized process. A typo fix must not need a requirements document.
- Vendor-neutral. Trackers, agent runtimes and models are swappable adapters.
The loop
Every work item passes through eight steps. Two of them are human gates.
| Step | Who | What happens |
|---|---|---|
| 1. Intake | System | A ticket arrives from the tracker, an error report or a schedule. A track is chosen. |
| 2. Shape | Shaper agent | Researches the codebase and asks the Oracle. Drafts the brief. |
| 3. Gate 1 | Engineer | Reads the brief, corrects it, approves it. The cheapest place to fix a wrong plan. |
| 4. Build | Builder agents | Implement the brief in isolated worktrees, test-first, inside their declared footprint. |
| 5. Verify | CI, Tester, Reviewer | Run the checks, review the diff. Failures loop back to Build with no human needed. |
| 6. Gate 2 | Engineer | Reviews intent and design, accepts the change. |
| 7. Merge | System | Merges, then notifies in-flight work that depends on what changed. |
| 8. Learn | System + owner | Review comments, rejections and incidents become rules, tests or new context. |
A rejected brief goes back to Shape with the engineer’s notes. Blockers raised during Build go to the engineer’s inbox and never stall other work.
Tracks: right-sized process
| Track | For | Steps | Gates |
|---|---|---|---|
| Patch | Bugs and small chores | Auto-brief, Build, Verify | Gate 2. Gate 1 passes automatically when a failing reproduction test exists. |
| Feature | Normal feature work | Shape, Build, Verify | Gate 1 and Gate 2 |
| Epic | Large features, migrations, new subsystems | An Architect writes a spec, then splits it into Feature items that run in parallel waves | A spec gate, then each Feature’s gates |
Core concepts
Work item. One unit of work: a feature, bug, chore or epic. It has a track, a status, a human owner and an assignee, which can be an agent or a person.
Brief. A self-contained context packet for one work item. A good brief lets a fresh agent with no memory finish the task. It holds:
- the goal
- acceptance criteria, each tied to a check
- the relevant files, and patterns to copy
- constraints and linked decisions
- what is out of scope
- open questions
Persona. A role definition: instructions, allowed tools, what context to load, and what it must produce. Each one is a short markdown file in git, with its own runtime and model. EILAID ships the seven standard personas below. Teams add their own the same way. See Files in the repo.
| Persona | Works in | Produces |
|---|---|---|
| Shaper | Shape | The brief, ready for Gate 1 |
| Architect | Epics | A spec, then Feature items split into waves |
| Builder | Build | Code and tests, test-first, inside its footprint |
| Tester | Verify, Patch track | A failing reproduction first, then the checks |
| Reviewer | Verify | A review of the diff against the brief, on one vendor or two |
| Steward | Maintenance, nightly | Dependency updates, flaky test fixes and refreshed docs, in one daily review |
| Oracle | Any step, on call | Cited answers, or a question passed to the engineer |
Ledger. The live, shared record of everything in flight: claims, file leases, status, blockers, questions, decisions and handoffs.
Oracle. The project’s knowledge base, which agents and people can question in plain English, and the persona that answers from it. Every answer cites its sources. When the evidence is thin, the question goes to the engineer who owns the work. See The Oracle.
Gate. A human decision point with a short checklist.
Coordination
Agents know about each other only through the ledger. They never message each other directly, so every interaction is visible and auditable.
- Situation report. When an agent starts a step, it is told what nearby work is in flight, which files are leased, what is blocked, and what merged since the brief was approved.
- Leases. Each brief declares the files and modules it expects to touch. Two items with overlapping footprints are run one after the other, never at the same time. An agent that needs to go outside its footprint must ask. That request is the main early warning of scope creep.
- Blockers and questions. A stuck agent files a typed blocker (needs info, needs a decision, depends on other work, scope change, broken environment) and moves on. Each blocker goes up a ladder: the Oracle, then the agent that owns the related work, then the engineer.
- Handoffs. Each step ends by writing what it did, what is left and what to watch out for. The next step starts from the brief and the handoffs, never from an old chat transcript.
- Budgets. Each step has a time and token budget. A blown budget marks the step stuck and sends it to its owner. It never retries forever.
Continuous development
The same loop runs for every kind of ongoing work. Only the trigger and the track change.
| Mode | Trigger | How it runs |
|---|---|---|
| Feature | A ticket | Feature track, or Epic for large work |
| Bug fix | A ticket, an error report or an incident | Patch track: a Tester writes a failing reproduction first, then a Builder fixes it |
| Migration | An engineer opens an epic | Epic track, split into waves of non-overlapping items |
| Maintenance | A schedule | A Steward agent handles dependency updates, flaky tests and stale docs, and batches the results into one daily review |
| Learning | Rejections, review comments, repeated questions | Each one becomes a rule, a test or a new context file, approved by its owner |
The learning mode is what makes EILAID improve over time. Measured week over week, agents should need fewer escalations and fewer review rounds for the same kind of work.