About this project

Adrastea is an MIT-licensed Python project (3.10+) that proposes a "symbiotic dual-engine" architecture for autonomous task orchestration. Its central idea is to split work between a predictable execution layer and a reasoning layer that only intervenes when something goes wrong. **System Alpha — deterministic execution engine** Alpha is described as the host process that starts first. It handles lifecycle and bootstrap, then verifies and stabilizes its environment before spawning Beta. Its responsibilities include a task scheduler that dispatches local scripts, binaries and task definitions, plus a local program runner that manages standard I/O, error logging and process lifetimes with an emphasis on reproducible execution. An RL planner guides task sequences using scoring functions tied to outcomes such as latency, exit codes, resource utilization and output validity, and uses pathfinding heuristics to choose execution branches based on historical and tuned weights. Alpha also connects to a local inference runtime (Ollama on `http://127.0.0.1:11434`) for offline, low-overhead operations such as parsing, format extraction and baseline text analysis. **System Beta — probabilistic decision and reasoning engine** Beta is spawned by Alpha after stabilization and acts as the decision layer for non-deterministic problems. It monitors Alpha's telemetry, health metrics and task progress, and steps in when Alpha hits unhandled exceptions, environment drift, repetitive failure states or execution loops. Beta is also responsible for tuning the reward and penalty weights used by Alpha's RL planner, effectively redirecting execution toward more productive paths. Beta runs an autonomous loop with four stated modes: idle/observe (passive monitoring), triage & unstick (diagnosing blocking conditions), optimize (removing redundancies from completed execution paths), and discover & innovate (hypothesizing new task sequences and objectives). It integrates with Model Context Protocol (MCP) servers for external tools and live context, and can consult frontier or external LLMs for deep reasoning, strategic decisions, code generation and troubleshooting. **Inter-process communication** Alpha and Beta run as concurrent processes communicating over a low-latency bidirectional channel such as domain sockets, named pipes or a message bus, carrying structured JSON or Protocol Buffer envelopes. Documented control signals include `SIG_SPAWN`, `SIG_HEARTBEAT`, `SIG_SLEEP`, `SIG_WAKE`, `SIG_TELEMETRY`, `SIG_STUCK`, `SIG_INTERRUPT`, `SIG_DISPATCH`, `SIG_MUTATE` and `SIG_TUNE_WEIGHTS`. Together they cover process bootstrapping, liveness pings, sleep/wake transitions, outcome reporting, stuck-state notification, task abortion, queue injection, in-flight parameter mutation and RL weight updates. **Keep-alive and long-sleep mode** A `KeepAliveProcess` coordinator lets the system sleep for extended periods to reduce CPU, memory and token usage while keeping Alpha's IPC TCP server on `127.0.0.1:8765`, client channels and `DIRECTIVES.txt` watchers active. Signal routing for heartbeat, wake, sleep and dispatch is meant to respond quickly, background Beta subprocesses and task runners stay supervised and are revived if they terminate unexpectedly, and incoming directives or dispatch signals wake the system immediately rather than waiting for the sleep timer. **CLI** The README documents commands such as `python -m adrastea.cli keepalive --sleep-interval 300`, `ping`, `sleep --duration 600` and `wake`. The stated prerequisites are a local Ollama server (with models such as `qwen3-coder:30b` or lighter instruction models), MCP client configuration, a local execution runtime such as PowerShell, Bash, Python or Node, and an asynchronous cross-process transport. Note that the README describes architectural intent and includes "rudimentary" keep-alive wording; no benchmarks or performance figures are provided, so the described behaviors should be treated as the project's design goals rather than measured results. Contributions are welcomed via fork, feature branch and pull request against `main`.