Live System Inventory
This page is the public operating map for the agent lanes I am building. It separates what is live now, what is already runnable, and what is still planned. The goal is simple: show actual systems architecture, not inflated claims.
The current build runs from one main control surface with a separate review relay for bounded checks. The rule stays the same: prove the contract locally first, then promote only the stable parts.
Anchor Desk
|
+-- global manager
| |
| +-- RouterAgent -> queue + dispatch
| +-- GuardianAgent -> policy + maintenance
| +-- DebuggerAgent -> bounded verification
|
+-- Operator briefing surface
+-- Internal forge -> primary git remote
+-- Governed credentials
|
+-- review relay
|
+-- supervised lane
+-- bounded health checks
+-- bounded worker lanes
I run a private governed operations stack that tracks queues, handoffs, approvals, and safety state. This page is the public-safe mirror of that system: real structure, real operating rules, and enough detail to show the work without mapping the private setup.
Agent roles, execution boundaries, promotion rules, and the way the work is structured from intake to verification.
Private node names, internal addresses, credentials, exact access paths, and implementation detail that would create unnecessary exposure.
It shows real agent-system work in progress: observable, governed automation with visible safety mechanisms and an operating model that can scale.
The private operator briefing surface. It handles free-text intake, explicit quick actions, and status updates without becoming the execution engine itself.
The pair that decides what may run, when it may run, and when the system should stop instead of improvising.
Private operator messaging surface. It is the human interface layer, not a catch-all execution lane.
Runs the daily platform preflight: tools, credentials, APIs, local services, and relay reachability.
Controlled remote lane for the always-on relay. Today it performs allowlisted health checks only.
Focused verification lane for fast local checks. It exists to shorten feedback loops and keep failures explicit.
A bounded content engine for evidence-anchored drafting, deterministic review gates, and operator approval before anything is promoted.
The record-keeping lane for job opportunities, statuses, notes, and operational context.
These lanes are defined because the ownership is clear, but they are intentionally not overclaimed as finished products.
Small allowlists, bounded commands, and explicit human approval for higher-risk actions.
Startup checks, remote health probes, service checks, visible failure states, and a private control tower before trust is assumed.
Build locally, prove the workflow, then move reliable pieces to scheduled or remote execution.
A paid baseline reasoning subscription is kept available, with short premium bursts only when a higher-capacity sprint is worth the spend.
Secondary model families are kept in free-tier or promotional lanes where practical, so comparison and redundancy stay available without unnecessary fixed cost.
Local open-weight models remain part of the stack so private workflows and no-API experiments do not depend entirely on hosted services.
This is not meant to imply a giant autonomous platform already runs unattended. It is meant to show how I structure automation work: define boundaries, separate responsibilities, keep the safety model legible, and add control surfaces gradually.
If you want the build sequence, go to the Build guide. If you want the system map, browse the Architecture pages. This page sits in the middle: it is the operational inventory.
This page is a living inventory. It should stay honest: live means live, runnable means implemented but not always-on, and planned means the contract exists but the lane is not promoted yet.