The ELO Roadmap: From Agent Sessions to a Governed Work System

AI is getting good enough that people increasingly trust it with work that lasts longer than a single answer.

That creates a new problem.

A useful conversation can disappear into history. A coding agent can run out of context. A different person can take over. A team can switch models, tools, machines, or vendors. The AI may still be capable, but the work itself can become fragmented: goals drift, decisions lose their rationale, evidence becomes hard to find, and nobody is quite sure what the next agent is allowed to change.

For casual questions, that is an inconvenience. For consequential work, it is a control problem.

ELO—the Engagement Lifecycle Orchestrator—is being built to solve that problem.

Our North Star

Make AI work you can trust to continue—across people, tools, and time—without losing the goal, the evidence, the decisions, or who is in control.

That is the human reason ELO exists.

The technical expression is more precise: ELO is intended to make consequential agentic work durable enough to survive changes in models, agents, tools, people, machines, and time while preserving authority, evidence, accountability, continuity, and intent.

But the outcome matters more than the vocabulary. A user should not have to start over because a context window ended. A team should not lose the reason behind a decision because the engineer who made it is unavailable. An organization should not have to trust an agent’s memory when it can instead rely on durable evidence and explicit authority.

The Strategic Thesis

Models and agent harnesses will continue to improve and change. We do not believe the durable layer of value should depend on one model vendor, one coding agent, one chat product, one machine, or one user interface remaining dominant.

ELO therefore sits above execution.

Harnesses such as Claude Code, Codex, OpenClaw, and future systems provide substantial execution capability. Models reason and generate. Tools act. ELO’s job is different: preserve the work as governed organizational state so execution components can be replaced without silently replacing the mission, the evidence, the decision history, or the rules.

This is why harness independence is not merely an adapter feature. It is a product and business strategy. If the best model changes, ELO should benefit. If the best harness changes, ELO should benefit. The customer should not have to choose between adopting a better AI tool and preserving the continuity of important work.

Who ELO Is For

Our beachhead is the group that already feels this problem directly: technical users and teams running long-lived work through agentic harnesses today. They already encounter context resets, model changes, handoffs, parallel workstreams, evidence management, and the difficulty of determining whether an agent’s claim of completion is actually supported.

The opportunity is broader than that beachhead.

As mainstream AI products become more agentic, users of ordinary web and mobile interfaces will increasingly ask AI to perform work over hours, days, and weeks rather than simply answer a question. The concepts that seem specialized today—continuity, authority, evidence, ownership, resumability—become ordinary user expectations once AI is trusted with persistent work.

Our messaging therefore has two jobs at once:

• solve a concrete problem for today’s agentic power users and engineering teams; and
• establish clear, objective language for a broader audience that is still learning what persistent AI work should require.

We expect that education to be cumulative. Terms should be defined carefully, used consistently, and tied to visible product behavior rather than marketing abstraction.

Product Principles

Several principles guide the roadmap:

• Authority over convention. A convenient file or dashboard does not become truth merely because humans can read it.
• Evidence over assertion. Completion should be supported by inspectable evidence, not only by an agent saying that work is done.
• Generality before specialization. Domain rules should be added where they reduce ambiguity, not where they lock users into somebody else’s process.
• Replaceable execution. Models, agents, harnesses, hosts, and interfaces should be interchangeable without taking ownership of the mission.
• Safe coordination before impressive concurrency. Serialization is preferable to distributed behavior whose conflict and recovery semantics are unclear.
• Observability before autonomous control. People should be able to see and understand the system before they are asked to trust it with broader authority.
• Product claims follow qualification. Implemented, qualified, accepted, and productized are different states and should be described differently.

What ELO Can Do Today

ELO already serves as an internal operating system for complex development and operational work. Its present foundation includes:

• durable sessions that survive individual context windows and conversations;
• structured work items with objectives, dependencies, success criteria, and lifecycle state;
• durable artifacts, decisions, receipts, and quality-control evidence;
• generated status and filesystem views derived from a database-backed authority;
• resumable context for Codex, Claude Code, OpenClaw, command-line, and MCP workflows;
• mutation gates, exact-request authorization patterns, rollback records, and independent review;
• read-oriented web views for inspecting work, dependencies, and status; and
• multi-host coordination that deliberately serializes ownership where safe distributed writes do not yet exist.

These capabilities make ELO useful today, but they do not yet constitute the complete product vision. Several important boundaries remain:

• campaign support has substantial development behind it but is not active in production authority;
• multiple harnesses are supported, but full harness independence has not yet been demonstrated through one end-to-end conformance standard;
• the web experience is primarily observational, not a complete authenticated enterprise control plane;
• multi-host coordination is not yet a distributed lease or consensus system;
• domain-specific lifecycle rules and configurable Human/LLM decision authority are planned, not shipping features; and
• the public Community Edition has not completed its repository, packaging, installation, release, and support gates.

Current State and Aspirational State

Dimension	Current ELO	Aspirational ELO
Product role	A governed lifecycle engine used internally for agentic work	A system of record and control plane for governed human-and-machine work
Work structure	Sessions containing work items, prompts, and artifacts	Worktrees containing campaigns, sessions, decisions, evidence, and ownership history
Authority	Local database authority with generated projections	Portable local and server authority services with replayable policy decisions
Execution	Strong integrations with several agent tools	Replaceable, conformant harnesses with no harness-specific logical ownership
Continuity	Durable sessions, goals, artifacts, memory, and restart context	Measured continuity across context, model, agent, host, filesystem, and harness changes
Decision governance	Core lifecycle and operation-specific authority rules	Configurable Human/LLM authority based on domain, phase, risk, evidence, and policy
Observability	Operational status and dependency views	Role-aware campaign, portfolio, risk, critical-path, evidence, and outcome views
Control	Command-line and typed service operations	Authenticated, auditable enterprise web and API control surfaces
Distribution	Serialized host claims and selected federation	Safe distributed orchestration with explicit consistency and recovery semantics
Release posture	Active development and internal dogfooding	Reproducible Community and Enterprise releases backed by exact evidence

The Architectural Direction

ELO separates authority from execution and projection.

People, organizations, and enterprise policy define what is permitted. Models and agents perform work through replaceable harnesses. ELO evaluates typed requests, records accepted lifecycle truth, and produces evidence, recovery records, and generated views. Dashboards and Markdown files make the system understandable, but they do not become the authority merely because they are convenient to read.

Strategic Directive 1: Establish a Trustworthy Release Base

The immediate priority is credibility, not feature count.

We are completing trust-boundary hardening, independent falsification, exact-source qualification, rollback proof, and multi-host release convergence. A feature is not considered production-ready because it works in a development checkout. It must survive focused and comprehensive tests, independent review, integration at the exact reviewed source revision, deployment receipts, monitoring, and recovery checks.

The development and repository split belongs here as an enabling milestone rather than as a strategic destination of its own. Lifecycle authority should own private development sessions and artifacts. The distributable source repository should contain product source, tests, specifications, and release tooling—not private operational history. The clean release line is also intended to adopt calendar versioning and a clear Community Edition boundary.

Strategic Directive 2: Add Campaigns, Ownership, and Stateless Requests

ELO currently organizes detailed work into sessions. The next authority model adds campaigns above sessions so strategic objectives can coordinate multiple workstreams without collapsing them into one oversized session.

The important visual idea is plurality. A campaign is not a box containing one session, one card, one seed, or one prompt. It is a durable objective coordinating many governed objects whose ownership and history remain explicit.

Each object should have one current logical parent while immutable history records initial assignment and later transfers. Generated files may be materialized in different locations, but filesystem location must not be confused with logical ownership.

This phase also includes stateless MCP compatibility. Request, identity, authorization, and evidence semantics should travel with each operation rather than depend on an opaque conversation connection. That makes the same governance model easier to carry across harnesses and future service deployments.

Strategic Directive 3: Prove Continuity and Harness Independence

Harness independence should be demonstrated, not inferred from a list of adapters.

We intend to run the same governed work through context resets, model changes, agent handoffs, machine changes, filesystem rematerialization, and harness replacement. The important measurement is not merely whether the next command succeeds. It is whether the strategy, unresolved risks, decision history, evidence, and next lawful action survive intact.

The relationship among ELO, harness, and model also needs to be visually understandable. ELO does not replace the harness. The harness already provides substantial capabilities, including model access and tool execution. ELO connects to that execution layer while preserving the governed work above it.

The diagram deliberately distinguishes the common/default experience from advanced configuration. Claude Code is primarily experienced as a Claude-family harness. Codex presents OpenAI models by default while supporting configurable model-provider paths. OpenClaw exposes a much broader provider catalog. The strategic point is not that every harness has the same model menu; it is that ELO should preserve the work when those menus differ or change.

Strategic Directive 4: Make Observability a First-Class Product Surface

The database architecture makes ELO possible. Observability makes ELO legible.

A non-developer should be able to answer basic questions without reading a database schema or a terminal transcript:

• What are we trying to accomplish?
• What is moving, and what is blocked?
• What decisions were made, and why?
• What evidence supports a claim of completion?
• Who or what is responsible for the next action?
• Where does authoritative state differ from a generated view?

The web experience will therefore grow from read-oriented diagnostics toward role-aware campaign and portfolio views: directionality, critical paths, blocked clusters, stale evidence, ownership, active responsibility, risk, and outcomes. Read-only observability remains the safe default while authenticated control surfaces mature separately.

This is more than a convenience layer. It is where the underlying governance model becomes visible to executives, program leaders, reviewers, and future mainstream users.

Strategic Directive 5: Add Domain Lifecycles and Configurable Decision Authority—Carefully

General-purpose lifecycle governance is flexible, but it asks users and language models to infer more behavior from prompts and goals. Domain-specific lifecycles can move important behavior out of probabilistic reasoning and into explicit rules.

That benefit has a corresponding danger: a lifecycle that is too specific or poorly matched to the user’s real process can be worse than a general lifecycle. It can deterministically force the wrong behavior.

Our default therefore should be generality.

Specialization is appropriate where lifecycle rules are stable, well understood, and valuable enough to justify replacing model discretion with deterministic policy. Flight testing is a useful example. A general flight-test lifecycle could define broad gates, required evidence, safety review, and acceptance concepts. A service-level or enterprise overlay could refine those rules. An individual squadron could then supply local prompts and policy for procedures that genuinely differ—or engage Octocore to build a lifecycle that fits its process more precisely.

Decision authority should be equally configurable. Different organizations may require:

• a human decision;
• an LLM decision within a bounded policy;
• either an authorized human or an authorized LLM;
• an LLM recommendation followed by a human decision;
• an LLM decision followed by mandatory human review; or
• a versioned authority pattern defined by the customer.

An LLM-only rule would never mean that a model can grant itself authority. It would mean that a separately authenticated agent principal is permitted to decide a bounded class of questions under an explicit, versioned policy. Service authorization, evidence, audit, and recovery invariants would remain in force.

Strategic Directive 6: Build Enterprise Control and Distributed Operation

The enterprise direction includes authenticated identity, delegated roles, separation of duties, policy administration, compliance-grade audit, multi-tenant authority, portfolio observability, high availability, and disaster recovery.

At that scale, ELO becomes less like an agent orchestrator and more like a system of record and control plane for governed autonomous work.

Orchestration asks: What should this agent do next?

ELO increasingly asks: What is the organization trying to accomplish? What is currently true? Who may change it? What evidence supports it? What remains unresolved? What is allowed to happen next? And can another human or machine continue safely?

Distributed orchestration will require more than allowing several agents to write at once. It must specify consistency, leases, fencing, partitions, conflicts, replay, and recovery. Until those semantics are explicit and tested, ELO will continue to prefer safe serialization over impressive but ambiguous concurrency.

Community, Enterprise, and Commercialization Hypotheses

The edition boundary remains an active product decision, but the business logic is becoming clearer.

A plausible progression is:

developer and power-user adoption → team governance → organizational control plane → regulated and domain-specific enterprise deployments.

Our current hypothesis is that the Community Edition should include a genuinely useful local lifecycle core: authority, sessions, campaigns, typed operations, evidence, and basic harness portability. Community should help create adoption, credibility, interoperability, and an ecosystem around governed agentic work.

Enterprise value is more likely to concentrate in identity federation, advanced policy, separation of duties, compliance, portfolio controls, distributed authority, fleet administration, high availability, supported domain packages, and organization-specific lifecycle governance.

Professional services may also be important, particularly where customers have mature domain procedures that benefit from explicit lifecycle engineering. The goal should not be to make every customer dependent on consulting. The opportunity is to help organizations encode well-defined operating practice into reusable governed lifecycles where that work creates real value.

These are commercialization hypotheses, not a final entitlement map or pricing model. They should be tested against ecosystem health, safety, customer outcomes, willingness to pay, support cost, and the sustainability of continued development.

How We Will Communicate Progress

Roadmaps become unhelpful when every item sounds equally complete. We will distinguish among:

1. governed concept or discovery;
2. implemented development capability;
3. qualified technical capability;
4. accepted and converged production capability; and
5. productized capability validated by customer or operational outcomes.

We will not describe campaign support as production-ready before its authority migration is accepted. We will not call several adapters proof of harness independence. We will not call serialized coordination a distributed consensus system. We will not present a technical preview as an enterprise control plane. And we will not announce a Community Edition availability date before its objective release conditions are true.

What Comes Next

The current dependency sequence is:

1. complete and independently accept the current trust-boundary hardening;
2. integrate and converge the exact accepted release across required systems;
3. ratify and qualify campaigns, ownership, managed artifacts, and stateless request compatibility;
4. complete the physical and logical release separation required for a clean Community Edition;
5. prove cross-harness continuity with measurable conformance tests;
6. expand diagnostic observability into a first-class product experience;
7. ratify decision-authority, domain-lifecycle, enterprise-control, and edition architectures; and
8. release the Community Edition only when every objective predicate is satisfied.

These are dependency-ordered strategic directives, not promises that every later design discussion must wait for every earlier engineering task to finish. Research and product discovery can proceed in parallel while release-critical dependencies remain explicit.

Technical Appendix: R&D Reference Diagrams

The primary figures above are communication artifacts. The following diagrams preserve implementation-oriented views for engineers and reviewers who need to ask more technical questions.

Authority gate

flowchart TB
    H[Authorized human or organization] --> R[Typed request]
    A[Authenticated agent principal] --> R
    P[Versioned policy] --> G{Authority gate}
    R --> G
    G -->|accept| E[Immutable authority event]
    G -->|refuse| X[Typed refusal and evidence]
    E --> S[(Authoritative state)]
    E --> Q[Receipt and audit evidence]
    S --> V[Generated views and projections]
    S --> N[Next lawful action]

Campaign-era logical ownership

flowchart TD
    W[Worktree and authority scope] --> C[Campaign]
    C --> S1[Session A]
    C --> S2[Session B]
    C --> S3[Session C]
    S1 --> K1[Cards]
    S1 --> D1[Seeds]
    S1 --> P1[Cold-start prompts]
    S2 --> K2[Cards]
    S2 --> A2[Artifacts and evidence]
    S3 --> K3[Cards]
    S3 --> A3[Artifacts and evidence]

Abridged campaign-era relational model

erDiagram
    AUTHORITY_SCOPE ||--o{ CAMPAIGN : contains
    CAMPAIGN ||--o{ CAMPAIGN_DEFINITION_REVISION : preserves
    CAMPAIGN ||--o{ SESSION_CAMPAIGN_ASSIGNMENT : receives
    SESSION ||--o{ SESSION_CAMPAIGN_ASSIGNMENT : has_history
    SESSION ||--o{ CARD : contains
    CARD ||--o| SEED : specializes
    CARD ||--o| COLD_START_PROMPT : specializes
    SESSION ||--o{ MANAGED_ARTIFACT_SCHEMA22 : owns
    CARD o|--o{ MANAGED_ARTIFACT_SCHEMA22 : produces

The managed-artifact entity remains a Schema 22 design target rather than a claim about today’s production table set.

Abridged seed lifecycle

stateDiagram-v2
    [*] --> draft: author intake
    draft --> inbox: readiness plus authority
    inbox --> in_progress: start work
    in_progress --> on_hold: hold with reason
    on_hold --> in_progress: resume
    in_progress --> complete: fitness for purpose met
    draft --> abandoned: approved stop
    inbox --> abandoned: approved stop
    on_hold --> abandoned: approved stop
    in_progress --> abandoned: approved stop
    draft --> superseded: successor owns scope
    inbox --> superseded: successor owns scope
    on_hold --> superseded: successor owns scope
    in_progress --> superseded: successor owns scope
    complete --> [*]
    abandoned --> [*]
    superseded --> [*]

The ambition is significant: make important AI work dependable enough that people and organizations can entrust it with more responsibility without giving up continuity, visibility, or control.

The discipline is equally important: publish what is accepted, label what is in development, and treat the rest as direction until the evidence says otherwise.