Source-linked AI summary
PrimeAgentOrchestrator: Memory-Primed Agent Spawning for Personal AI Infrastructure
Myron Koch
TL;DR
LLM coding agents lose prior work and user-specific knowledge when sessions begin with empty context. PAO queries heterogeneous personal databases in parallel and delivers compiled briefings through Claude Code’s startup configuration mechanism. Primed agents won 3 of 5 comparisons, averaging 9.6 versus 7.2 for cold agents, but the evaluation is small-scale and limited by its judge and task design.
Problem
The paper addresses coding agents’ loss of prior work and user-specific knowledge when each new session starts with an empty context.
Method
PAO queries two independently-operated memory backends in parallel, compiles their results, and delivers a briefing through Claude Code’s startup configuration mechanism.
Results
Primed agents won 3 of 5 comparisons, averaging 9.6 versus 7.2 for cold agents, with the strongest advantage on domain-specific tasks.
Takeaways & Limitations
PAO demonstrates an infrastructure-level way to provide newly spawned agents with relevant cross-session knowledge without modifying the agents themselves.
Takeaways & Limitations
The evaluation covers only 5 tasks, uses an LLM judge, and allows cold agents to discover the same information through tool use, so the priming advantage may diminish over multi-turn interactions.
Abstract
from arXiv · showhide
Large language model (LLM) coding agents start each session with an empty context window, discarding accumulated knowledge from prior work. We present PrimeAgentOrchestrator (PAO), a system that spawns new instances of Claude Code -- Anthropic's terminal-based coding agent -- pre-loaded with relevant memories compiled from the user's existing personal databases. At spawn time, PAO queries two independently-operated memory backends in parallel (a PostgreSQL entity-observation database and a Cloudflare Worker semantic search index), fuses results using backend-specific retrieval strategies, and delivers the compiled briefing via filesystem injection that exploits the host agent's configuration auto-read behavior. PAO manages the full agent lifecycle including trust pre-seeding, readiness polling with error detection, and adaptive terminal text injection. We report on four months of regular deployment (December 2025 through March 2026) as an experience report, documenting three generations of context delivery mechanisms, the failure modes that motivated each redesign, and the engineering tradeoffs of bridging heterogeneous memory systems rather than building a unified one.
1 Introduction
PAO addresses cold-started coding agents by compiling relevant cross-session personal memory into briefings before spawning new Claude Code instances. The experience report presents heterogeneous-memory bridging, filesystem delivery, and lifecycle automation as its core contributions.
- Motivation: PAO addresses cold-start sessions that discard prior work, user preferences, and domain-specific decisions, forcing users to re-explain context.The paper frames context engineering, rather than model capability, as the bottleneck in AI-assisted development.
- Positioning: Unlike multi-agent and memory-augmented systems, PAO transfers accumulated personal memory to newly spawned agents across sessions using external databases.Related systems either initialize agents cold, preserve memory within one agent, or transfer memory only within a single task session.
- Core system: PAO spawns specialized Claude Code agents with relevant slices of the user’s accumulated personal memory at initialization.The system compiles knowledge from multiple independent storage systems into a coherent briefing before task execution.
- Scope: The paper reports four months of deployment as an experience report documenting architecture, failure modes, and engineering lessons rather than controlled primed-versus-cold experiments.Its contribution is the architecture and practical knowledge of automating terminal-based agent spawning with memory injection.
- Core system: PAO queries heterogeneous memory backends in parallel, compiles results into a structured briefing, and delivers it through filesystem injection.This protocol eliminates the timing dependencies of clipboard-based context delivery.
- Design tradeoffs: The “bridge, don’t own” approach preserves ecosystem independence and lowers integration cost, but introduces schema coupling and non-uniform retrieval quality.PAO uses existing independently-operated databases rather than requiring a unified memory architecture.
- Engineering contributions: PAO also contributes practical CLI lifecycle techniques covering trust pre-seeding, readiness polling, adaptive terminal injection, and concurrent-safe registry management.These deployment problems receive limited academic treatment but materially affect real-world operation.
2 Background and Related Work
Prior work addresses agent coordination, persistent memory, or dynamic spawning, but PAO focuses on transferring cross-session personal knowledge to newly spawned agents. It differs through external heterogeneous backends and persistent lifecycle management for a human developer’s workflow.
- Agent coordination: Multi-agent frameworks initialize agents with task descriptions and system prompts, whereas PAO addresses what agents know when they start.PAO targets initialization knowledge rather than runtime coordination.
- Persistent memory: Persistent-memory systems such as MemGPT and Generative Agents optimize memory management for a single persistent agent identity.They do not address transferring accumulated personal memory to newly spawned agents at initialization.
- Memory architectures: PAO delivers externally compiled memory once at spawn time, while MemGPT manages memory during operation and MAGMA fuses views within a unified architecture.PAO instead bridges pre-existing, independently-operated databases without a unifying layer.
- Agent spawning: AgentSpawn is the closest prior work, transferring selective intra-session parent memory to child agents during dynamic code-generation workflows.PAO transfers cross-session personal knowledge accumulated over months.
- Agent spawning: AgentSpawn uses a single in-process memory store, whereas PAO queries independently-operated external databases with different query models.This distinction follows from their different memory scopes and backend architectures.
- Lifecycle and deployment: PAO maintains a concurrent-safe registry with pause, resume, checkpointing, and multi-agent coordination commands, unlike AgentSpawn’s task-local lifecycle tracking.The systems also differ in deployment context: PAO targets a human developer’s daily workflow rather than automated benchmarks.
- Context engineering: A study of 328 public Claude Code configurations found that 72.6% specify architecture information in CLAUDE.md, supporting PAO’s choice of this context-injection mechanism.The related work positions PAO’s warm-start approach opposite fresh-context subagents.
- Governance: PAO’s registry operationalizes tracking and identification concerns discussed for external AI-agent governance, while its unrestricted-permission design raises governance implications.The paper links these concerns to its single-user deployment context.
3 System Architecture
PAO orchestrates memory retrieval, briefing composition, file-based delivery, trust setup, spawning, and readiness handling around Claude Code’s configuration system. Its architecture bridges two native-query memory backends while accepting deployment-specific security and integration tradeoffs.
- System overview: PAO comprises two TypeScript CLI tools, a nine-module shared library, and a template totaling approximately 1,800 lines at initial evaluation.The system targets Claude Code as its host agent.
- Spawn pipeline: The seven-step pipeline validates inputs, gathers memory in parallel, composes a briefing, delivers files, pre-seeds trust, spawns Claude Code, and polls readiness.A post-readiness nudge is non-critical because local files retain the context.
- Heterogeneous memory fusion: PAO queries two existing backends using native retrieval: PostgreSQL full-text search with ILIKE fallback, and Cloudflare semantic embedding search over conversation transcripts.The backends have fundamentally different schemas and query models.
- Heterogeneous memory fusion: The “bridge, don’t own” design preserves independent backend evolution and avoids schema migration, but produces non-uniform retrieval quality, schema coupling, and no cross-backend relevance normalization.An earlier SQLite backend was removed after keyword retrieval produced false positives without improving overall precision.
- File-based context delivery: Claude Code auto-reads CLAUDE.md during startup, so PAO writes a briefing before process launch and avoids race conditions inherent in runtime delivery.The behavior is observed in current versions but is not a documented API guarantee.
- File-based context delivery: PAO separates CONTEXT BRIEFING.md from project CLAUDE.md so project instructions remain intact and briefings can be regenerated independently.The separation also distinguishes pre-loaded context from project configuration.
- Trust and readiness: Trust dialogs can silently consume terminal input, so PAO pre-creates workspace- and project-level trust artifacts before launch.Readiness polling uses positive and negative indicators to detect success or bail out early on errors.
- Terminal abstraction: PAO supports Terminal.app and tmux through a dispatch layer, using backend-specific clipboard or buffer injection and adaptive submission timing.The tmux path avoids send-keys because characters such as # and ; can be interpreted as command separators.
4 Evaluation and Operational Experience
PAO was deployed for four months and evaluated through illustrative cold-versus-primed case studies, operational measurements, and failure-mode analysis. Primed agents showed a directional advantage, while the pipeline delivered briefings reliably and required fixes for terminal-spawning issues.
- 4.1 Illustrative Case Studies: Cold vs. Primed Agents: Five qualitative case studies compared simultaneous cold and primed Claude Code agents receiving identical prompts and equal response time.
- 4.5 Evaluation Scope: The evaluation is directional rather than statistically significant because it used N=5 qualitative case studies.
- 4.1 Illustrative Case Studies: Cold vs. Primed Agents: Primed agents won 3 of 5 comparisons, averaging 9.6 versus 7.2 for cold agents.The advantage was strongest on domain-specific knowledge tasks, while cold agents won two tasks through aggressive filesystem exploration.
- 4.2 Pipeline Performance: All 15 evaluation tasks produced briefings successfully, with 586ms average end-to-end latency and 4,816-character briefings containing 11.5 memory items per task.
- 4.3 Operational Experience: The deployment identified and resolved three spawn failures involving resume-mode selection, trust-dialog interception, and swallowed Enter keystrokes.Fixes included explicit --new mode selection, dual-level trust pre-seeding, and separate paste and Enter calls with a 500ms delay.
- 4.4 Backend Evolution: Removing the keyword backend reduced out-of-domain retrieved items from 12 to 4 while in-domain precision remained stable at 57.4% versus 56.9%.
5 Discussion
PAO’s discussion frames heterogeneous-memory bridging as a pragmatic response to pre-existing independent systems, while identifying contradiction handling and platform coupling as important tradeoffs. The architecture is generalizable in pattern but not in its Claude Code-specific implementation.
- 5.1 Bridging vs. Unifying Memory Systems: The “bridge, don’t own” design preserves ecosystem independence and lowers integration cost, but introduces schema coupling and non-uniform retrieval quality.
- 5.1 Bridging vs. Unifying Memory Systems: PAO lacks chronological overriding or conflict resolution when backends return contradictory memories, leaving resolution to the receiving agent.
- 5.1 Bridging vs. Unifying Memory Systems: A unified architecture could provide cross-backend relevance normalization and joint ranking, but would require migration and sacrifice ecosystem independence.
- 5.2 Generalizability: The architectural pattern of querying memory, compiling a briefing, and injecting it into agent configuration is generalizable, but PAO’s implementation is not.
- 5.3 Limitations of the Evaluation: The cold-versus-primed comparison offers initial evidence for knowledge-recall benefits, but five tasks, same-vendor judging, and tool access limit interpretation over longer interactions.
6 Limitations
PAO’s evidence is limited by its single-user, single-platform deployment and small evaluation. Retrieval quality is only partially assessed, and the terminal interface depends on macOS-specific tooling.
- PAO is personal infrastructure designed for one developer and one coding-agent platform.
- The cold-versus-primed comparison covers only 5 tasks and uses an LLM judge; larger studies with human judges would strengthen the findings.
- Backend query strategies are coupled to current schemas, while remaining backends lack per-item confidence scoring and relevance filtering beyond native ranking.
- The Terminal.app backend depends on AppleScript and macOS Accessibility permissions.
7 Conclusion
PAO addresses coding-agent cold starts by compiling cross-session memory into configuration-delivered briefings without modifying the agents. Its practical alternative to unified memory remains constrained by a small, same-vendor evaluation.
- PAO addresses coding-agent cold starts at the infrastructure level without modifying the agents themselves.
- Its engineering contributions target recurring terminal-agent automation failures through trust pre-seeding, readiness polling, and adaptive terminal injection.
- The primary limitation is a small N=5 case-study evaluation using a same-vendor LLM judge.