Technical vision

Status: proposal. This document describes intended concepts, not implemented interfaces, supported integrations, security guarantees, or an available runtime.

Proposed architecture

A local coordinator would maintain a goal specification, invoke a user-selected agent through an adapter, evaluate artifacts, and enforce a stopping policy. Adapters would isolate agent-specific invocation and result handling from the protocol. Model selection and compute would remain with the user and their agent.

A possible iteration flow is:

goal + criteria → agent execution → evaluation → structured learnings → strategy decision → stop or next attempt

Evaluation is central. Criteria should identify what constitutes success and which checks are required. Deterministic checks such as tests and builds should be used where appropriate; human review or model-assisted judgments should be identified as such, with limitations and uncertainty retained. Agent assertions must not be treated automatically as successful evaluation.

Separate records and decisions

• History: inputs, actions, artifacts, evaluator outputs, resource use, and outcomes.
• Learning: an observation linked to evidence, its scope, confidence, and unresolved questions.
• Optimization: a proposed strategy change, its rationale, expected effect, and constraints.

A next-attempt decision should reference the learning that motivated it. Unsupported inferences should remain hypotheses. Recording these relationships enables later analysis; it does not itself prove improvement.

Proposed CLI and configuration

A possible future CLI is npx xelon init. It is not implemented or advertised as available. No package installation is required or implied by this document.

A future configuration might express:

# Illustrative proposal; not a supported schema or executable configuration.
goal: "Complete the authentication-system task"
agent_adapter: "user-selected adapter"
criteria:
  - "Required authentication tests pass"
  - "Specified security checks pass"
  - "Existing interfaces remain compatible"
  - "Production build succeeds"
limits:
  max_iterations: 3
  max_elapsed_seconds: 900
  max_tokens: 100000
stop_on:
  - "all required criteria satisfied"
  - "any resource limit reached"
  - "unsafe action or human decision required"
  - "no justified strategy change remains"

All example limits are illustrative choices, not defaults or performance claims. A future design must define how elapsed time, tokens, monetary cost, cancellation, and in-flight calls are accounted for. If usage cannot be measured reliably, it must be reported as unknown rather than silently treated as zero.

Local-first and execution boundaries

Configuration, iteration records, and artifacts should stay local by default. External agent/model services may still transmit data and incur charges under the user’s configuration. Local-first does not mean fully offline execution. Secrets should be excluded or redacted from stored records. Retention, export, access control, workspace isolation, tool permissions, and evaluator integrity need explicit design and validation. XELON should not expand an agent’s existing authority. Untrusted outputs must not become coordinator instructions.

The framework/protocol should remain separate from any marketing website. A website demonstration must not be represented as a working runtime.

Open questions

Adapter contracts, evaluator APIs, strategy selection, storage formats, restart behavior, concurrent execution, and reliable budget enforcement remain undecided. A small prototype and benchmark should inform these choices before broad support or production readiness is claimed.