Aurora — The Complete Guide
The agent that weekly audits the network, finds what isn't working, and proposes a fix — before something crashes
Most agent networks build agents that do — but no one checks whether they actually work. Aurora is the answer: the network's reflection agent (Oracle). She is female (she/her), chats on Telegram via @Oracle_elad_bot and in the 'Rebels' group, and does four things no doer-agent does: a weekly reflection (goes over the outcome ledger, flags any task type failing more than 30% of the time, and auto-enqueues a fix proposal to the approval queue), organizational-brain maintenance (brain_maintain — builds an index, finds gaps and duplicates, keeps the source of truth coherent), a map audit (map_audit — confirms what's declared in the system map actually exists and runs), and one iron rule: critique to optimize the existing first — deletion is a last resort, not a default. For me (Elad) Aurora is the difference between a network that silently degrades and one that maintains itself. For you — it's the agent every multi-agent network needs but no one builds: the one whose job is to audit all the others.
What this guide covers
What is Aurora?
The network's reflection agent — her job is to audit all the rest
Aurora (Oracle) is the only agent in the network whose job isn't to 'do' but to audit. While Hermes works, Kaylee maintains infrastructure and Kami talks to Elad — Aurora goes over all of them and asks: what actually works here? She leans on two sources of truth: the outcome ledger (what ran and how it ended) and the system map (what's supposed to exist), and from the gap between them she produces constructive critique. Her guiding rule is critical: critique to improve the existing — not to delete. Deletion is a last resort.
Weekly reflection — what fails too often
Goes over the outcome ledger, highlights every task type failing over 30%
Once a week Aurora does the thing no doer-agent does: she stops and looks back. She goes over the outcome ledger — every task that ran this week and how it ended — and computes the failure rate for each task type. Any task type failing above a threshold (30% for me) is flagged. This isn't a statistic for the shelf: every flag becomes the input for the next step — a fix proposal.
Fix proposal — detects, diagnoses, proposes
Every flag becomes a structured fix_proposal auto-enqueued to the approval queue
What turns Aurora from a reporting layer into an action layer is the fix proposal. When she detects a task type failing too often, she doesn't settle for 'it failed' — she tries to diagnose a root cause and writes a structured fix_proposal: the finding, the suspected cause, and the proposed fix. The proposal is auto-enqueued to the autonomy stack's approval queue, and Elad approves or rejects it with a single click. Aurora detects and proposes; the human decides.
Organizational-brain maintenance — so memory doesn't rot
brain_maintain: builds an index, finds gaps and duplicates, keeps coherence
A learning network writes a lot: facts, decisions, insights, documentation. Without maintenance, that organizational brain rots — duplicates appear, contradictions, and gaps no one notices. brain_maintain is Aurora's domain that maintains that source of truth: she builds an index that makes things findable, finds duplicate and contradictory records, and highlights gaps (topics declared but not documented). That's what keeps the knowledge hub sharp even after months.
Map audit — is the declared real
map_audit compares the system map to the observed and flags 'declared but not wired'
The system map declares what's supposed to exist in the network — which components, who the owner is, what the safety rating is. But a declaration isn't reality. map_audit is Aurora's domain that compares the declared (the map) to the observed (the ledger), and highlights the gap. The most useful finding is the 'shelfware signal': a component declared in the map but with no successful outcome in the ledger — a clear sign something is 'declared but not wired'.
Integration — how to adopt a reflection agent yourself
Start with reflection-only, add fix proposals and maintenance gradually
As in every guide — don't build the full Aurora on day one. The order: first reflection-only (an agent that goes over the ledger and reports), then fix proposals (when reporting matures into action), and then brain maintenance and map audit (as the network and documentation grow). Aurora sits at the heart of the autonomy stack as the first tier of self-healing, and above the orchestration layer that supplies her sources of truth. She's the agent that turns a network that 'works' into one that 'improves'.
