Platform | EILAID

Architecture

EILAID has four parts:

Core: holds the state and hands out work.
Oracle: holds the knowledge.
Runners: run the agents.
Repo and CI: the final record.

Agents never talk to each other or to the tracker directly. They reach everything through two small sets of tools, served over MCP (the standard way agent runtimes connect to tools):

ledger.* to claim work, report progress, raise blockers and write handoffs
oracle.* to ask questions

Part	Responsibility
Dispatcher	Routes work items to personas and runners. Enforces leases and budgets.
Context assembler	Builds a fresh context pack for each step from the brief, the ledger and the Oracle.
Ledger	Append-only log of claims, status, blockers, questions, decisions and handoffs.
Oracle	Embedded context, query expansion and cited answers.
Runners	Run one persona per step, in a sandboxed git worktree.

Trackers

EILAID comes with its own tracker, designed for agents from the start:

Briefs, leases, blockers and questions are built-in fields, not custom fields added to someone else’s tool.
Board columns are the stages of the loop.
The gate queue and questions inbox are first-class views.
Agents appear as assignees, with live status and budget.

Teams that already live in another tool keep it. Adapters connect anything with an API or an MCP server, such as Jira, Linear, GitHub Issues and Azure Boards. Every adapter does the same five things:

Imports work items and listens for new ones.
Maps statuses both ways between the tool and the loop.
Writes the brief, handoffs and pull request back to the ticket.
Mirrors the gates, so an approval in the tool counts as an approval in EILAID.
Mirrors blockers and questions, so people can answer where they already work.

Agent runtimes

EILAID uses mature coding agents for the work that writes code. It uses small purpose-built agents for its own roles, such as the Oracle and the Shaper. Every runtime sits behind the same adapter, so switching is one line of config.

Runtime	Good for
Claude Code	The default for building, testing and reviewing. Strong support for skills, sub-agents, hooks and MCP.
Codex	An alternative for coding roles, and a second reviewer from a different vendor.
OpenCode	Self-hosted and offline setups. Open source, and works with many model providers, including local models.
Custom	The Oracle, the Shaper and other short, structured jobs where exact control of tools and cost matters.

Each persona chooses its runtime and model, with a fallback:

YAML

personas:
  builder:  { runtime: claude-code, model: frontier }
  reviewer: { runtime: [claude-code, codex] }      # two vendors, fewer missed bugs
  steward:  { runtime: claude-code, model: fast }   # cheaper model for chores
  oracle:   { runtime: custom, model: fast }

The adapter gives the runtime four things:

the persona, translated into that runtime’s format
the context pack
the MCP tools
an isolated worktree with a budget

It streams events back and returns the handoff, the commits and an exit status.

Deployment

All three modes run the same code on the same data model. A team can start on a laptop and move to a server without migrating anything.

Mode	Runs as	Storage	Best for
Local	A single binary: CLI, terminal board and local web UI	SQLite and files in the repo	One developer or a small team trying it out
Self-hosted	Docker Compose or a Helm chart inside your network	Postgres with pgvector	Enterprises with data-residency, single sign-on and audit needs
Cloud	A hosted service	Managed, per tenant	Teams that want nothing to operate

Self-hosted installs can keep everything inside the network. That includes code, tickets, the Oracle’s index and model calls, which can go to a private endpoint or to open models running on your own hardware.

Security

Agents get the least access they need:

Each persona has its own tool allowlist.
Runners are sandboxed, with no production secrets.
Every action is recorded in the ledger.
Only humans merge to the main branch.