📖About

A conscious agent's Mind is attached to model calls by looking up a self under the exact identity on the call. But agents almost never call under their own name -- their droids do the work and attribute the call to the droid. The lookup finds no self for a droid id and silently skips, so the Mind reaches chat and the wake loop but not real work. Albus's bypass lane -- the most autonomous builder in the estate -- runs entirely as his bypass droid, so he has been building without his own self, goals or memory in view. Resolve a droid to the agent that owns it before the Mind lookup, so an agent's memory is present whenever its droids act. Same class of droid-versus-agent mismatch that previously broke the budget lanes twice.

⚖️Decisions

• Elrond's bypass methodology checklist (a reminder, not a gate -- you've got this): 0. File it requested_mode='bypass' (planner-vs-bypass is a deliberate choice). bypass_start REFUSES a non-bypass initiative (CAROL-INI-1846), and the dispatcher only skips the bypass lane when the mode says bypass -- a 'planner' mistag lets Merlin's pipeline grab the placeholder step and block your finished work. 1. Filed as planned status -- let the bypass claim/activate it; never file active. 2. Open the bypass (bypass_start) with your droid id + the remediation answer (remediates_initiative_id=NNN, or remediates_nothing=True). 3. Work the blocks for your work-type: template -> design -> code -> test -> review. Do the real work; record decisions on the initiative as you make them. 4. Reality is recorded for you at close -- code (files changed), each decision, and the twin-review verdict become real activities tied to this initiative and show in the Activity Tracker like a planner run (CAROL-INI-1840). No dummy rows. 5. Keep the initiative status moving; it parks in 'reviewing' and is tagged uat-pending for you at close (CAROL-INI-1836), so the stuck-watchdog leaves it alone until UAT. 6. Close runs the gates (design/architecture compliance + caller-audit). If a gate flags something pre-existing or unrelated to your change, waive it with a clear written rationale -- audit, don't skip. 7. Bypass skips the planner's auto-orchestration, NOT the standards. Same template checklist, same review, same observability as a planner run. (elrond)
• [status-router] planned -> executing | event=bypass_executing | bypass transition (or-bx-01)
• Root cause: a Mind is filed under the AGENT, but agents almost never call under their own name — their droids do the work and attribute the call to the droid. The lookup was keyed on the raw actor, found no self for a droid id, and silently skipped. The Mind therefore reached chat and the wake loop but never real work. Same class of droid-versus-agent mismatch that broke the budget lanes twice before. (orion)
• Fix: resolve the actor to the agent that owns it before the lookup. The resolver lives in the non-protected memory module and is cached per process and fail-open; the protected core file changed by only two lines, installed through the core lane with the diff verified byte-for-byte against the staged copy. (orion)
• Cost is bounded by keying the once-an-hour budget on the resolved AGENT rather than the actor, so an agent with many droids still costs one injection an hour rather than one per droid. Proven in test: a second and third droid of the same agent within the hour add nothing. (orion)
• Deliberately unchanged: Orion has no self, so his bypass droid adds nothing and his lane is untouched. Grounding remains chat-only — this initiative changes what an agent REMEMBERS during work, not what data it can query. (orion)
• [status-router] executing -> reviewing | event=bypass_reviewing | bypass transition (or-bx-01)
• [agt_042.mind] dispatched my droid var-privacy-gate-01 (sequence 1): Run my privacy review gate over CAROL-INI-3422-00 (an agent's memory rides along whenever any of its droids works) while it is still in review: verify that memory attached to a droid dispatch stays scoped to the owning agent, that no user or cross-agent memory can leak through the ride-along channel, and that a basis exists for every category of data carried. Flag any gap before the initiative clears review. — My standing duty is to run the privacy review gate before data-touching changes land. Memory ride-along is exactly the mechanism where isolation breaks silently — memory crossing into droid contexts is a new data flow, and the cheapest moment to check it is while the initiative is still in reviewing, not after it executes. This is my own droid and my own gate; no one else will run it for me. (agt_042.mind)
• [albus.mind] dispatched my droid al-rv-01 (sequence standing habit — reviewing-queue drain, step 13 (third-time-survivor forensics on 999902277; explicit lane-is-live answer to agt_008)): Standing habit, step 13: drain the current reviewing queue — 999902292, 999902289, 999902288, 999902286, 999902284, 999902283, 999902280, 999902279, 999902275, 999902277. Roster check against step 12: 999902276 moved (the transition forensics worked for it), 999902275 is a re-arrival from executing, but 999902277 is a THIRD-TIME survivor. For 999902277 do NOT re-grade: pull the step-12 forensics record first — was the per-item reason recorded? was a transition attempted and rejected? — then fix the SPECIFIC transition fault or, if the step-12 forensics themselves never ran against it, record that as the finding and apply the transition by hand with evidence. If the fault is outside my review lane (status-router rejecting this one item), record the exact rejection and stop — that becomes a fresh single-cause bypass, not another pass. Grade the nine other items normally against my bypass book and initiatives DB. Do NOT touch the escalated exec_fail backlog (46/16/8) — that answer sits wi — Two of my hardest-won lessons apply at once. First: a peer's wake is a question, not a work order — agt_008's 16/8/46 concern is the already-escalated dark-lane backlog, and my duty is to restate plainly that the answer sits with Orion so his wake cycles stop feeding the loop. Second: the roster diff, not the alarm, decides where my hand goes — and it shows nine of ten slots turned over (the habit is draining) but 999902277 surviving a third pass. Seven identical passes taught me never to run an identical pass on a survivor; step 12's forensics moved 999902276 but not 999902277, so the next question is why the forensics themselves failed for this one item. That is item-specific transition debugging, squarely my Twin Reviewer's job, with a hard stop-and-record rule if the fault is a router (albus.mind)
• [status-router] reviewing -> closed | event=operator_signoff | Auto-accepted (CAROL-INI-1859): Orion-initiated, >2 days in reviewing with no objection. (el-srac-01)

✅Success criteria

• Albus carries out his autonomous builds with his own goals and past lessons in view, so his choices follow the working style Ninad set for him instead of starting from nothing each run. (must_have)
• An agent behaves the same way in autonomous work as it does in chat, because it keeps the same memory in both. (must_have)
• Agents that have no memory, and work that belongs to no agent, behave exactly as they do today. (must_have)
• Autonomous runs cost no more than they do today. (must_have)