AI organisation runtime
OpenEchelon
How does intelligence work together?
An organisation model for AI work: persistent identities, explicit responsibility and governed resource choices. The first prototype tests the premise before the full runtime.
- State
- Pre-alpha · models + governor spike
- Working with
- Python / typed data models / resource routing
01 The constraint
OpenEchelon investigates how agents can work as an organisation with roles, delegation, review and resource limits. Logical employees are separate from the resources that execute their work. A large organisation therefore need not mean a model running for every registered employee.
02 The decisions
Model responsibility before execution.
The Phase 0 implementation defines employees, departments, permissions, tasks, typed messages, artifacts and execution resources. These relationships make handoffs and authority explicit before a scheduler or persistent organisation runtime is introduced.
Test the economic premise first.
Choosing the cheapest sufficient model depends on knowing whether its answer is sufficient. The Resource Governor spike comes before the full organisation because a poor quality estimator can either escalate everything or cheaply accept wrong answers.
Make abstention part of the interface.
The governor separates estimation from escalation policy. An estimator must have evidence for the task class; missing evidence causes abstention and escalation. Routing decisions record the score, threshold and outcome so future verification can revisit them.
- 01Task requirements
- 02Available resource
- 03Sufficiency estimate
- 04Accept or escalate
03 What exists
The current repository contains the organisational data model and a Resource Governor spike evaluated against labelled scenarios. The architecture decision record identifies quality estimation as the critical dependency and makes false acceptance a visible failure mode rather than hiding it behind aggregate cost savings.
04 Still open
OpenEchelon is pre-alpha with no released package or usable organisation runtime. Permissions are modelled but not technically enforced. Storage, scheduling and the executive interface are still future work. Scenario-based governor evaluation does not establish reliability with real providers or general tasks.
Follow the evidence
Based on project code and documentation reviewed in October 2026. Evaluation results are reported by the projects; they were not independently rerun for this portfolio.
- Project state
Current components and the distinction between implementation and roadmap.
- Phase 0 model
Organisational relationships and acceptance criteria.
- Quality estimation decision
Why the governor is tested first and how abstention shapes policy.
- Governor implementation
Resource selection, reasoning limits and recorded escalation attempts.