Open source · Apache-2.0 · Pre-alpha
A model-agnostic runtime for structured AI organizations — hierarchical multi-agent systems where persistent AI employees operate within defined authority, permission, memory, and resource boundaries, and report ultimately to a human owner.
Complexity belongs inside the organization, not in the user's lap.
Most multi-agent systems expose their complexity directly. You choose agents, wire workflows, select models, coordinate handoffs, and decide which agent does what. OpenEchelon models an actual organization instead: executives, directors, managers, specialists, and workers, each with defined responsibilities, authority, tools, memory, budgets, and reporting lines.
YOU
|
v
CEO
|
+-------------+-------------+
| | |
v v v
CTO CRO CQO
| | |
v v v
Directors Directors Directors
| | |
v v v
Managers Managers Managers
| | |
v v v
Workers Workers Workers
The CEO receives the objective, delegates through the organization, monitors progress, resolves conflicts, commissions reviews, manages scarce model resources, and returns the consolidated result.
The difference is operational, not cosmetic.
| Flat multi-agent swarm | OpenEchelon | |
|---|---|---|
| Structure | Lead plus peer agents | Multi-level organization with departments |
| Context | Often one shared context | Minimum sufficient context per role |
| Model choice | Usually one provider for all agents | Per-task assignment by a Resource Governor |
| Reasoning | Frequently maximized everywhere | Budgeted by rank and task requirement |
| Identity | Agent equals prompt plus model | Persistent employee with history and performance record |
| Scaling | More agents means more running models | Logical identity scales separately from execution |
| Escalation | Retry the same agent | Structured escalation to a stronger resource |
| Audit | Conversation history | Traceable task tree with artifacts and reviews |
In a flat swarm, ten agents on one problem tends to mean ten expensive contexts reasoning about the same thing. Orchestrator-worker systems buy their quality with roughly an order of magnitude more tokens than a single agent, and that multiplier compounds through every handoff. OpenEchelon treats that as the problem to solve, not the price of admission.
Forty architectural constraints. Six that decide the shape.
The organization never structurally places itself above its owner. Autonomy exists within delegated authority; it is not sovereignty.
An employee is a persistent identity with a role, manager, permissions, memory, and performance history. Execution resources are assigned per task.
A thousand registered employees might mean twenty actively executing. One loaded local model can serve hundreds of logical workers over time.
Work starts on local or inexpensive models and escalates only when the attempt proves insufficient — because it is justified, not because a powerful model happens to be available.
Raw worker output does not propagate upward unchanged. Reports keep references to underlying evidence so deeper inspection stays possible.
Prompt injection, authority escalation, information boundaries, credential isolation, and approval gates are design concerns — not prompt instructions added after autonomy.
Pre-alpha, and specific about it.
The Phase 0 organizational data model exists and is tested: employees, departments, grants, tasks and delegation trees, typed messages, artifacts, reviews, execution resources, quota, and routing decisions. A Resource Governor spike measures the escalation ladder against labelled scenarios. There is no organization runtime and no released package.
The spike is deliberately sequenced first. The whole cost argument rests on a component that decides whether a cheap answer was good enough, and published routing work suggests that component generalizes poorly across task classes. Building an organization runtime on an unvalidated estimator would spend the larger investment before testing the premise.
| Phase | Contents | State |
|---|---|---|
| Phase 0 | Organizational data model, identity, permissions, task graph, message protocol, provider abstraction, artifacts | Built and tested |
| Phase 0 | Resource Governor | Spike, measured |
| Phase 1 | Minimum viable organization: CEO, three managers, worker pool, local execution, CLI agent integration, review loop | Not started |
| Phase 2 | Departments, dynamic hiring, persistent memory, approval workflows, performance tracking | Not started |
| Phases 3–4 | Ecosystem interoperability, large organizations, learned routing | Vision |
Direct answers. The full set is in the repository.
OpenEchelon is an open-source, model-agnostic runtime for structured AI organizations. It models a hierarchy of AI agents — CEO, executives, directors, managers, specialists, and workers — where each agent has a defined role, manager, permissions, memory, reasoning budget, and reporting line. The human owner gives an objective to the CEO and retains final authority over everything the organization does.
A swarm is flat: one lead agent fans work out to peer agents, usually sharing one context and one model. OpenEchelon is hierarchical, and the hierarchy carries operational meaning — information access, permissions, reasoning budgets, escalation paths, and model tier all vary by rank. In a flat swarm, ten agents on one problem tends to mean ten expensive contexts reasoning about the same thing. Here, a worker gets a bounded assignment on a cheap model, and only the levels that need judgement pay for judgement.
No. Logical identity is deliberately separated from execution. A logical employee exists persistently without a dedicated model process, container, GPU allocation, or running session. A thousand registered employees might mean fifty assigned and twenty actively executing against a limited pool, and one loaded local model can serve hundreds of logical workers over time.
None. Local inference (Ollama, llama.cpp, OpenAI-compatible servers), CLI coding agents (Codex CLI, Claude Code, Gemini and Antigravity), and hosted APIs all sit behind adapters. OpenEchelon is designed to run meaningfully in a local-only configuration. Cloud and frontier resources enhance capability but must not define the architecture.
A Resource Governor assigns execution resources per task, starting with the cheapest intelligence that could plausibly succeed and escalating when a sufficiency estimator judges the answer inadequate. Inputs include task complexity and importance, uncertainty and risk, remaining provider quota and reset windows, latency, local hardware availability, historical success rates, cost, concurrency, and organizational rank.
Reasoning follows the same discipline. Rank sets a ceiling on spending, never a cap on what a task needs — a task requiring more reasoning than its role permits escalates rather than running under-powered.
Architectural constraints rather than a single guardrail prompt. Permissions are organizational and enforced technically where possible. Information access follows organizational need, so a worker does not receive the whole context. Sensitive external actions — sending messages, publishing, deleting data, financial transactions, production deployments — require an approval chain whose height depends on risk, up to human approval. Execution is interruptible: work can be paused, cancelled, or have its resource access revoked without waiting for an autonomous process to finish voluntarily.
Neither, by explicit non-goal. A visual workflow editor may eventually exist as an advanced feature but must never be required for normal operation; execution plans are constructed from organizational structure, policy, and available resources. And while the default interface is a conversation with the CEO, the substance behind it is persistent identities, delegation trees, permission boundaries, artifact provenance, independent review, and resource governance.
Not yet. It is pre-alpha. The Phase 0 organizational data model and a Resource Governor spike exist and are tested; there is no organization runtime and no released package. The most useful contributions right now are architectural critique, prior-art analysis, and concrete proposals for the core data models and protocols.