--- name: agent-context-memory-and-profile-handoff description: Decisions sur l'injection de contexte, la memoire durable, l'etat live et le handoff de profil entre agents IA. metadata: type: project --- # Agent Context, Memory, and Profile Handoff ## Resume This note captures the current product direction for IdeA around agent context injection, project memory, live state, and profile handoff between AI providers. See also: - `idea-product-directives-main-handoff` for product priorities and UX constraints. - `remaining-work-idea-agent-control-ide` for the current implementation status and remaining work. ## Context Injection - Agent context must be injected by IdeA at launch time; the model should not be expected to discover `AGENTS.md` or `CLAUDE.md` by itself. - The existing `contextInjection` architecture is the right mechanism, especially `conventionFile` for providers that support a conventional file in the run directory. - The current implementation is strongest for `conventionFile`; `flag`, `stdin`, and `env` do not yet receive the same fully-composed IdeA context. - The `flag` strategy appears fragile with the isolated run directory model because the relative path passed to the CLI may not resolve from the run directory. ## Shared Project Context - `.ideai/CONTEXT.md` is intended as shared project context. - It is not created automatically; it only exists if something writes it. - It should carry active project constraints and contribution rules. - Example content for `CONTEXT.md`: architectural constraints, workflow rules, and operating conventions that every agent must apply immediately. ## Durable Memory - `.ideai/memory/` is intended as durable, project-scoped memory shared by all agents of the same project. - It is not created automatically; it only exists once at least one memory note is saved. - The durable memory is a knowledge base, not a live activity log. - It should contain stabilised knowledge such as: - architecture decisions - feature summaries to implement later - user preferences that persist across sessions - important project facts and references - Durable memory should stay curated and low-noise. ## Live State Versus Durable Memory - Durable memory should not be used as a shared real-time state feed for all agents. - IdeA should distinguish between: - global context (`.ideai/CONTEXT.md`) - durable memory (`.ideai/memory/`) - live operational state (separate store) - handoff summaries between sessions or profiles - Real-time work tracking, who-is-doing-what, and transient status should live in a dedicated state mechanism, not in durable memory. ## Memory Consumption by Agents - The current launcher reads shared project context from `.ideai/CONTEXT.md` if present. - It also recalls project memory via `MemoryRecall` and injects a `# Memoire projet` section into the convention file. - This injection currently happens only for `conventionFile` profiles. - The recalled memory is shared at the project level, but each agent may receive a different subset depending on its persona and recall query. - Memory recall is computed at launch time and written into the generated context file. - There is currently no automatic live refresh when `.ideai/memory/` changes during an active session. ## Recommendation for Live Memory Refresh - Automatic memory refresh could be useful, but it should be explicit and controlled. - If IdeA wants agents to benefit from memory changes while they are active, it should regenerate their effective context when needed instead of treating durable memory as a constantly streaming log. - For PTY agents, no automatic reread exists today. - For structured Claude/Codex sessions, each turn relaunches the CLI, but the generated convention file is not automatically rewritten when durable memory changes. ## Profile Handoff and Session Continuity - A direct native session transfer from Claude to Codex is not the right mental model. - The correct model is continuity of work state, not native provider-session continuity. - IdeA should persist: - a canonical conversation log - a cumulative handoff summary - the agent state - the provider conversation id when useful - On provider swap, IdeA should launch the new profile with: - regenerated project context - regenerated durable memory recall - the current agent persona - a handoff summary plus recent transcript - The handoff summary should not be created only at the moment of swap. - IdeA should maintain summaries incrementally or at checkpoints so that a swap is still possible when the current provider is near a token or session limit. ## Agent Ability To Write Durable Memory - Agents should be allowed to promote important knowledge into durable memory. - This should not rely on the agent guessing the capability. - IdeA should expose the capability explicitly through tools or commands and should inject a clear rule explaining when an agent may save durable knowledge. - This write ability should be constrained to stable, high-value information, not transient state. ## Practical Classification Rule - Put immediate project rules and operating constraints in `.ideai/CONTEXT.md`. - Put stable, reusable project knowledge in `.ideai/memory/`. - Put current activity and coordination state in a separate live-state mechanism. - Put cross-session or cross-profile recovery material in a handoff/session layer. ## Current Product Direction - Keep `CONTEXT.md` for project rules. - Keep `.ideai/memory/` for curated durable knowledge. - Introduce a separate live-state mechanism if agents must stay aligned on in-progress work. - Introduce persistent conversation logs and incremental handoff summaries to support profile swaps such as Claude to Codex.