HomeRail is a TypeScript runtime that turns one-off agent chats into auditable, reusable workflows on hardware you own — a homelab, network-attached storage box or home server. Work moves node to node along the explicit edges of a directed acyclic graph rather than pooling in a single conversation, so every handoff is traced and every run can be replayed. The premise is that a person's attention is the scarcest resource in an automation, so the system asks for as little of it as possible.
Present in the tree today are the graph runtime, a command-line interface, a voice surface and the first steps toward a generated interface. The runtime handles multi-agent orchestration with explicit handoffs, workspace isolation per run, replay, scorecards and run evaluation. The CLI starts services, checks readiness, runs and supervises workflows, and scores or evaluates a finished run; workflow definitions and runtime profiles are synced into the manager database for reuse, keyed by a stable workflow identifier. A pattern library covers reusable control-flow designs such as quorum, bounded ratchets, standing goal verification and planner/worker fan-out, which the manager agent can instantiate itself.
The architecture separates a manager service, which coordinates graphs and owns the voice and generated-interface contracts, from a node service that provisions container-backed workers, one per graph node, sharing a workspace per run. Worker runtimes adapt to the Claude Agent SDK and compatible backends, and a decoupled browser interface operates the manager. Because each node has its own context window and receives only the handoff it needs, context never balloons into one thread, and templates map a provider and model per agent with a wildcard fallback, so a stronger model can plan and review while cheaper models do the bulk of the work.
Voice is the preferred input, backed by a contract covering speech recognition, synthesis and voice-activity detection through a desktop voice shell; the agent collects intent across turns before acting, and text input is always available. A coding agent can also drive the CLI directly, taking over planning while the manager still coordinates the graph. Provider credentials live in an encrypted settings store rather than repository files, the manager binds to loopback by default, and reverse-proxied access requires an exact public origin, with forwarded headers never trusted for that decision.
Features
- Graph runtime: multi-agent orchestration with explicit handoffs, per-run workspace isolation, replay and run evaluation
- Command-line control: starting services, readiness checks, running and supervising workflows, scorecards and replays
- Reusable workflows: definitions and runtime profiles synced into the manager database under a stable identifier
- Pattern library: quorum, bounded ratchets, standing goal verification and planner/worker fan-out, instantiable by the manager agent
- Voice surface: speech recognition, synthesis and voice-activity detection with multi-turn intent collection before acting
- Generated interface: structured views produced for the moment instead of raw logs, still being shaped through use
- Container workers: one container per graph node, provisioned by the node service, sharing a run workspace
- Per-node models: a provider and model mapped per agent with a wildcard default, so planning and bulk work can use different models
- Offline profile: a deterministic profile runs a topology check without a model provider configured
- Multi-round graphs: workflows that pause at a durable command boundary and resume selected actors within the same run
- Credential handling: provider keys held in an encrypted settings store, never in repository files
- Network defaults: loopback binding, exact-origin configuration for reverse proxies, and authenticated sockets for remote workers
