An AGI Runtime Implementation Path Based on Eva-CLI

If "building AGI" means producing a single model with unlimited general intelligence, Eva-CLI should not claim that. A more useful engineering definition is a local runtime that can understand goals, preserve long-term context, decompose work, call tools, verify results, learn from execution, and safely upgrade its workflows while remaining constrained by permissions, audit, and rollback.

The current Eva-CLI architecture already has the pieces for that runtime: a Rust-owned runtime boundary, Lua Agents, a Topic EventBus, Scheduler, AdapterRegistry, MemoryService, KnowledgeService, ContextBuilder, AgentDiscoveryService, Lua capability hot reload, Release Snapshot, BackupService, MigrationPackageService, process-level Runtime generation switching, and Supervisor. The AGI implementation path is to connect these pieces into a controlled loop from goal intake to action, verification, memory, and upgrade.

This article treats AGI as a controlled autonomous Agent runtime built on Eva-CLI's current design. It does not claim that the project already ships full AGI. The important goal is to let Agents propose plans and improvements while the Runtime enforces authority, validation, evidence, and rollback.

Defining AGI inside Eva-CLI

Inside Eva-CLI, AGI is better understood as a runtime capability rather than a single model. The runtime needs seven capabilities: goal understanding, long-term context, task decomposition, tool access, plan execution, result verification, and the ability to turn experience into memory or capability updates.

This avoids two unsafe shortcuts. First, model output is not treated as system truth; the Runtime validates it with schemas, policies, tests, snapshots, and audit records. Second, automation is not treated as authorization. An Agent may request file access, an external CLI call, memory writes, or a generation switch, but Rust decides whether that request is allowed.

Capability	Eva-CLI boundary	Constraint
Goal understanding	entry Agent, Topic events, ContextBuilder	Goals become structured events, tasks, constraints, and verification criteria.
Long-term context	Agent memory, project memory, KnowledgeService	Memory has source, confidence, scope, TTL, and audit metadata.
Task decomposition	Lua Agents, workflows, Topic subtasks	Plans are emitted as schedulable tasks, not hidden inside prompts.
Capability calls	AdapterRegistry, Rust Tool Layer, MCP, SkillAdapter	Lua expresses intent; Rust owns paths, secrets, shell, network, and process lifecycle.
Execution and recovery	Scheduler, private queues, Durable Event Log	Accepted events should be recoverable and side effects should be idempotent.
Verification	VerificationService, tests, schema checks, health checks	Completion criteria must be executable and recorded.
Self-improvement	Lua generation swap, Release Snapshot, Runtime generation	Agents propose upgrades; Runtime owns activation and rollback.

Runtime-governed autonomy

The outer boundary is the Rust Runtime. Permissions, state, filesystem access, network access, shell execution, secrets, Adapter lifecycle, MCP transport, hardware handles, backups, migrations, snapshots, release pointers, audit logs, and recovery policy all live there. Lua Agents operate inside that boundary through narrow host APIs.

User input, CLI calls, API requests, MCP clients, or external events are normalized into Events. The EventBus publishes them, and the Scheduler routes them by Topic, target Agent, subscription rules, priority, and load. Each Agent has a private inbox and independent Lua State. That isolation is what lets long-running autonomy remain observable instead of becoming implicit shared prompt state.

Goal
  -> /input/user
  -> /goal/normalized
  -> /plan/proposed
  -> /task/created
  -> /adapter/invoke
  -> /task/verified
  -> /memory/proposed
  -> /capability/upgrade/proposed
  -> /release/snapshot/requested

From natural language to executable task trees

The first Agent should not immediately execute a user request. It should produce a structured goal package containing the raw request, intent, constraints, risk level, desired output, high-risk actions that require confirmation, candidate verification steps, and context requirements. The model can help produce that package, but Runtime schema validation should accept or reject it.

The planner then converts the goal into Task Specs. Each Task Spec declares inputs, outputs, dependencies, allowed capabilities, required permissions, timeout, retry policy, completion criteria, failure behavior, and whether human confirmation is required. That turns planning into a schedulable contract rather than a narrative.

Memory and knowledge

Long-running autonomy depends on memory. Eva-CLI should use three layers: Agent private memory, project memory, and a source-backed knowledge base. Private memory stores local tool preferences, failures, task state, and hypotheses. Project memory stores facts that should apply across Agents: architecture decisions, release constraints, user preferences, and known risks. The knowledge base indexes documents, code, release notes, issues, pull requests, and approved external excerpts.

Writes should pass through a promotion path. An Agent may propose memory, but MemoryService checks scope, source, sensitive data, duplicates, conflicts, confidence, TTL, and audit metadata. ContextBuilder then returns compact context packs instead of dumping all history into a prompt.

Adapters as controlled actuators

An AGI runtime needs to call external capabilities: LLMs, CLIs, MCP servers, local models, code tools, hardware, browsers, test runners, and deployment commands. Eva-CLI's key rule is that Lua does not access these directly. Lua calls `ctx.tools.invoke_agent` or emits `/adapter/invoke`; the Rust Tool Layer performs routing and policy enforcement.

An Adapter is not a command string. It is `manifest + capability + policy + transport + protocol + runtime state`. Codex CLI, Claude API, Gemini, local models, MCP servers, workflow skills, and hardware devices can all become Adapters only after they declare capabilities, schemas, limits, paths, network rights, secret sources, audit rules, and health checks.

The execution and learning loop

The main AGI loop can be implemented as Observe, Plan, Act, Verify, Reflect, and Improve. Observe collects the current event, state, memory, knowledge, and tool results. Plan builds a task tree. Act calls Adapters and Lua capabilities. Verify runs declared checks. Reflect records evidence, failures, risks, and reusable lessons. Improve turns that evidence into memory, configuration, Lua workflow updates, or candidate capabilities.

Verification is the hard boundary. Without it, the system is just generating text. With it, the system can accumulate trustworthy capability. VerificationService should cover schema checks, static checks, unit tests, integration tests, smoke tests, migration dry runs, health probes, and human approval gates.

Self-upgrade without self-authorization

Self-improvement is powerful and dangerous. Eva-CLI should keep one rule: Agents can propose upgrades, but they cannot authorize upgrades. Behavior changes such as prompts, Lua Agent scripts, Lua tools, Lua skills, route mappings, and response shaping can use Lua generation swaps. Capability metadata changes can enter a candidate registry. Runtime boundary changes such as new permissions, transports, state backends, MCP surfaces, or host APIs require Supervisor-managed Runtime generation switching.

Every accepted upgrade should create a Release Snapshot. It records source revision, config digest, policy digest, manifest registry digest, Lua capability generation, AdapterRegistry generation, State Store schema, Durable Event Log watermark, verification output, migration package ID, backup artifact ID, rollback eligibility, and audit identity. Without that evidence, self-upgrade becomes untraceable mutation.

Minimum viable path

The first phase is not full AGI. It is a recoverable multi-Agent task runtime: Event schema, Topic matcher, Scheduler, private Agent queues, Lua Agent containers, AdapterRegistry, controlled `ctx.tools.invoke_agent`, tracing, audit, dead letter handling, and basic state persistence.

The second phase adds memory and knowledge with structured storage, promotion, conflict tracking, TTL, sensitive data rejection, source citations, and compact context packs. The third phase makes execution verification-driven: every Task Spec declares completion criteria, and tasks are only completed after evidence passes.

The fourth phase adds Lua capability hot reload through a Rust Capability Kernel and Lua Capability Runtime. The fifth phase adds Release Snapshot, BackupService, MigrationPackageService, Supervisor, Ingress Gate, and Recoverable EventBus. Only after those safety contracts exist should Eva-CLI expand autonomy into automatic planning, candidate upgrade generation, failure diagnosis, cost control, and policy-aware execution.

Conclusion

The practical path to AGI in Eva-CLI is not one unrestricted super Agent. It is a runtime that can host autonomy safely. Rust owns boundaries, state, permissions, verification, recovery, and release evidence. Lua owns business intent, local orchestration, and hot-reloadable logic. EventBus owns the long-running event chain. MemoryService and KnowledgeService own promoted experience. AdapterRegistry owns external action. Release Snapshot and generation switching own evolution and rollback.

That route is slower than letting an Agent edit everything directly, but it lets capability grow while the system remains explainable, auditable, and recoverable.