A private engineering environment built to keep many agents, model providers, tools, projects, and long-running experiments attached to evidence. Enki does not begin with the premise that an answer is work. It begins with the harder question: what changed, who changed it, why was it accepted, and did the program actually do what was asked?
Read the system argumentTHE ENGINEERING PROBLEM
Enki was assembled around an observed failure of contemporary code agents: they are fluent at proposing changes and unreliable at carrying responsibility for the consequences.
A generated answer may be syntactically convincing while naming a file that does not exist, replacing a mature project with a generic scaffold, or stopping after an endpoint returns HTTP 200. A second agent may repeat the same mistake because the first failure was logged as conversation rather than converted into durable operational knowledge. A third may overwrite the target while another process is still evaluating it. The individual responses can each sound competent while the aggregate system steadily loses contact with the program.
Enki treats this as an orchestration and memory problem. Work begins inside a real project boundary. A handler claims a target, reads the current implementation, writes a complete candidate into controlled state, and reports the candidate for comparison. Validation records what was accepted, rejected, deferred, or left unresolved. Runtime evidence remains separate from source. Knowledge judged useful returns to later work through the hive queue. The system is designed so that another process can inspect the chain without trusting the prose of the process that created it.
This architecture is deliberately plural. Python owns the operator surface, project automation, validation, provider access, and much of the durable state. TypeScript hosts MCP and A2A agents, workspace contracts, tool calls, and additional rewrite producers. JavaScript Wanderers carry selected knowledge between active work and memory. Pi, Hermes, and OpenClaw provide external agent processes through an explicit gateway. The point is not to collapse these runtimes into one framework. It is to make their handoffs legible.
AIDES
Aides explores a distributed cognitive run in which an Oracle coordinator can remain alive while local computers join, contribute computation and sensorium devices, disappear, and reconnect to the same durable run.
The distinction between identity and rank is central. A transient PyTorch process-group rank describes one current communication arrangement; it cannot by itself represent a participant that returns after a network failure. The implemented federation work therefore adds persistent actor identity, coordinator-issued leases, heartbeats, reconnect tokens, checkpoint compatibility, task retry, and explicit sensor and compute channels around the existing Ai.py system. Cameras, microphones, screens, mice, keyboards, CPUs, GPUs, and NPUs remain attached to the local participants that own them. The coordinator preserves run state and work ownership rather than pretending those devices live in Oracle.
This permits local machines to be contributors rather than thin terminals. They can execute model work while also supplying the changing sensorium. When one leaves, its lease expires and unfinished work becomes eligible for reassignment. When it returns, it resumes under the same actor identity if its checkpoint and run are compatible. The design does not create a separate miniature controller that stands in for the intelligence. It extends the existing process with the minimum durable coordination needed for continuity.
THE LIVE RUNTIME
The supported Windows path enters through NoGUI.bat or the visible GUI launcher, continues through run_gui_with_logging.ps1, and starts launch_gui.py. The launcher owns duplicate-instance detection, environment assembly, process preservation, and rotating GUI session logs. This matters because a useful autonomous runtime cannot be tested by starting an ad hoc second copy with different configuration and then drawing conclusions about the first.
The PyQt workbench divides observation from intervention. Main Interface exposes projects, files, agents, generated candidates, and manual actions. System Monitor exposes live services and status. Knowledge Graphs surfaces the hive, Wanderers, memory, performance, and accumulated guidance. Neural Manager holds neural telemetry and utilities. These are not separate products. They are views over a runtime whose authoritative evidence remains in logs, SQLite state, saved state, and the behavior of the project being changed.
The TypeScript MasterControlProgram runs five hosted agents and mounts A2A surfaces. Its output enters the Python validation system through structured events instead of writing around it. External MCP tools enter through the shared Python tool plane. OpenClaw identities receive project-specific work and configured provider routes through the gateway client. This arrangement lets new workers participate without granting each one its own uncontrolled source-writing path.
MEMORY WITHOUT AMPLIFICATION
Enki maintains project history, candidate outcomes, provider health, conversations, knowledge graph records, and a consumption queue for productive guidance. The difficult boundary is deciding what deserves durability. A completed implementation, a failure pattern, a verified dependency rule, or a project-specific constraint can improve future work. Heartbeats, telemetry samples, internal persistence requests, and recursive bookkeeping usually cannot.
The Wanderer and hive paths therefore classify internal events and merge useful packets rather than persisting every message indiscriminately. This is an architectural defense against feedback amplification. If integrating knowledge produces another knowledge event which produces another persistence request, the system can consume thousands of operations without learning anything. The repair is not a larger queue. It is recognizing which event is the causal producer and keeping bookkeeping on the non-semantic side of the boundary.
Successful self-programming work can be stored as searchable guidance and later injected into a related improvement prompt. TypeScript rewrite pipelines can emit the same kind of productive packet. The value of this memory is tested when it changes later behavior: avoiding a known broken launcher, preserving an established project contract, selecting a viable provider, or running the proof that a previous attempt omitted.
WHAT THE SYSTEM IS FOR
Enki operates across software that does not share a single definition of done. A Django and Godot game needs authenticated server behavior, synchronized catalogues, export integrity, and an actual playable build. A Montessori tracker needs durable SQLite history, server-confirmed timers, backup import, and an accessible browser flow. SEPL needs a parser, compiler, service, and workbench that agree about the language. A remote Oracle service needs the target interpreter, systemd, loopback health, routed health, and external behavior. The system's orchestration must preserve these differences rather than reducing them all to “tests passed.”
This is why workingdir/ projects remain real, independent programs. Enki can select work, supply agents, preserve claims, evaluate candidates, and carry lessons between projects, but the project owns its acceptance criteria. The intended outcome is not an autonomous system that produces more autonomous-system activity. It is a system that completes more difficult work while leaving a better account of how the result was obtained.
Read the UCIP validation architecture Read the compute-mesh research