Carolopedia

A friendly guide to Carol, her ecosystem, and the agents who built her.

📖 CarolopediaServicesBuild InitiativesAll activitiesINI-999902803Guide page
📋

CAROL-INI-3883-00: Rich chat phase 6: an agent's memory is the PERSON's, not the environment's - one person key across channels, services and projects, separate scrolls and one memory

Initiative
Open in Initiatives →

📖About

Ninad ruling, 2026-08-16 (CLI-268), given when CAROL-INI-3868 slice (b) hit it head-on: "Agent's memory is user specific, period. If the same user appears on internal chat and external chat, because he may be a subscriber and an employee, the agent remembers him as a person, and hence shares all information about him, including the documents shared. This reflects how humans interact: they know a person, and all transactions associated with that person is what they remember, irrespective of whether the transactions happen across channels, across services and across projects."

Asked for the blast radius, Ninad ruled SEPARATE SCROLLS, ONE MEMORY: conversations stay distinct threads per window, and everything the agent knows about the person reaches every one of them.

WHAT THIS AMENDS. Cookbook 1335 (chat isolation is the four-tuple) keeps its STORE dimension - a conversation still lives in exactly one (project, window_class) environment, internal/external/operator scrolls never merge, every store accessor still requires full scope. What it loses is its MEMORY dimension: what an agent REMEMBERS about a person is keyed on the PERSON, not the environment.

WHAT IS MISSING TODAY. There is no stable person identity across doors. The org window calls the owner 'admin'; the person-store doors call the same human 'web:'; Carol's WhatsApp lane knows a phone. The users record already carries channel and linked_user_id, and identity_sync already mirrors across linked folders - so the parts exist and are not joined up. Memory cannot follow a person until a person has ONE key.

SCOPE. (1) One person resolver, in the isolation module beside the scope binder, honouring linked_user_id so a phone and an email that are one human resolve to one key. (2) Re-key the three memory seams onto it: documents given to an agent (3868 b), the recall of the person's earlier conversations (3873), and episodic memory (912). (3) Amend cookbook 1335 to say store vs memory in as many words, and sweep design 563 in the same change. (4) The fence that REMAINS absolute: another PERSON. Nothing here widens what one person can see of another, and confidential-means-own-records-only (P.01.03.05.16) is untouched.

Blocks CAROL-INI-3868 criterion 2, whose wording ("readable in the same conversation and nowhere else") is narrower than this ruling and is restated by it.

--- Made a PHASE of the rich-chat arc by Ninad, 2026-08-16 (CLI-268). The arc is now SIX phases: 1 rich replies (3864/3865/3866) - 2 live stages + named threads (3867) - 3 the self-correcting turn + WhatsApp convergence (3873) - 4 files, charts, canvas (3868) - 5 get-back-to-me (3869) - 6 one memory per person (3883). Voice was removed from the arc on 2026-08-16 and DISCARDED on 2026-08-16 (was parked). Phase 6 sits after phase 4 in dependency: it restates phase 4's document criterion, and phase 4 ships narrower than the ruling until this lands.

⚖️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)
  • [status-router] executing -> reviewing | event=bypass_reviewing | bypass transition (or-bx-01)
  • [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

  • One person resolver answers a stable key for the same human arriving as admin on the org window, as web:<email> on a subscriber window, and on a linked channel - and answers DIFFERENT keys for two different humans (must_have)
  • A document given to an agent in one conversation is readable by that same agent when talking to the SAME person in another conversation, another window class and another project (must_have)
  • That document is unreadable to every OTHER person, and unreadable to another agent - the person fence is absolute where the environment fence is lifted (must_have)
  • The conversation stores are UNCHANGED: a scroll still belongs to one (project, window_class), internal and external histories never merge, and the 3875 isolation checks still pass unmodified (must_have)
  • Cookbook 1335 states the store/memory split in as many words, and design 563 is swept in the same change (must_have)