I read through the entire stack: Pi's extensions/skills/system-prompt, COT's runner/tools/briefing/prompt/maintain-runner, the architecture analysis document, and every major extension. Here's what I found.
\nPi and COT both do the same thing at their core:
\nloop:\n LLM generates → tools execute → context accumulates → repeat\nBoth use createAgentSession from the Pi SDK. Both call session.prompt(). Both have tool registries, context management, error handling. But they share zero implementation above the SDK level:
| Concept | \nPi Implementation | \nCOT Implementation | \n
|---|---|---|
| Tool registry | \nExtensions (loaded at startup, permanent) | \nregistry.ts (factory pattern, on-demand) | \n
| bash/read/write/edit | \nPi SDK built-in tools | \nSeparate tool modules (import side-effects) | \n
wa/index.ts extension (CLI wrapper) | \nwa-*.ts tools (DB query wrappers) | \n|
google/index.ts (API wrapper) | \nemail-*.ts tools (DB query wrappers) | \n|
| Memory | \nagent-memory/index.ts extension | \ncot-memory.ts + search-agent-memory.ts | \n
| Search | \nunified-search/index.ts extension | \nunified-search.ts tool | \n
| Agent delegation | \nagents-runtime (child processes) | \nspawn_sub_agent (in-process sessions) | \n
| Context management | \nSmart-read progressive modes | \nSub-agent isolation | \n
| Guidance | \nAGENTS.md + 27 skills | \n242-line system prompt + briefing | \n
Every capability is implemented twice. When you add a new data source, you build it twice. When you fix a bug, you fix it twice. This isn't DRY — it's two complete agent systems that happen to share a database.
\n1. The guidance stack is inverted.
\nPi loads ~10K tokens of system prompt (AGENTS.md) on every turn. It includes environment details, Codex delegation rules, tool routing decision trees, workspace conventions — most irrelevant to most turns. Then skills add another 2-7K tokens each when loaded. The model processes all of this before doing anything.
\nThe architecture doc proved: 52% of sessions are <5K chars with 1.6 tools. The system is optimized for the 0.5% complex case while every session pays the cost.
\n2. Tool loading is all-or-nothing.
\nPi loads 51+ tools permanently. Each tool definition costs tokens in the cached prefix — and more importantly, costs model attention on every turn (the model must consider all tools before choosing). The architecture doc showed 4 tools account for 70% of usage. The other 47 tools are loaded for every session but used rarely.
\nCOT loads all 65+ tools too, but organized into groups. Only COT_PROCESS_TOOLS + ORCHESTRATOR_READ_TOOLS go to the main session. Sub-agents get scoped subsets. This is better but still manual and static.
3. Context has no economic model.
\nNeither system gives the model information about its own context budget. The read tool consumes 52.2% of all tool result bytes. Smart-read added progressive disclosure modes (peek/head/grep/structure), but the model doesn't know why it should use them. It doesn't know how much budget remains, what it's already consumed, or what the cost of a mode: full read will be.
4. Agent composition is three different systems.
\nagent_spawn creates child pi processes (full extension loading, DB-backed lifecycle, message passing)spawn_sub_agent creates lightweight in-process sessions (shared tool deps, no DB, synchronous)These can't interoperate. A Pi child agent can't use COT's database tools. A COT sub-agent can't use Pi's browser extension. Codex can't do either. They're three islands.
\n5. The ESA pattern is ceremony, not architecture.
\nCOT's system prompt mandates Explore→Synthesize→Act every run. This makes sense when there's lots of new data to process. But when nothing's changed? The model still goes through the motions — spawning empty explorers, synthesizing nothing, writing the same scratchpad. The pattern is burned into the prompt, not emergent from the situation.
\nEvery "agent" in the current system is the same thing: an LLM session with tools, a context budget, and a lifecycle policy. The differences are configuration, not architecture.
\n| Current Thing | \nWhat It Actually Is | \n
|---|---|
| Pi interactive session | \nSession(trigger=human, tools=universal, trust=high, lifecycle=multi-turn) | \n
| COT process run | \nSession(trigger=timer, tools=orchestrator, trust=medium, lifecycle=stateful-one-shot) | \n
| COT sub-agent | \nSession(trigger=parent, tools=scoped, trust=inherited, lifecycle=one-shot) | \n
| COT maintain worker | \nSession(trigger=queue, tools=task-specific, trust=low, lifecycle=one-shot) | \n
| Pi child agent | \nSession(trigger=parent, tools=inherited, trust=inherited, lifecycle=multi-turn) | \n
| Codex delegation | \nSession(trigger=parent, tools=sandboxed, trust=sandboxed, lifecycle=multi-turn) | \n
They should all be the same runtime with different configuration.
\nThe entire system reduces to five concepts:
\ninterface Session {\n id: string;\n model: Model;\n tools: Tool[];\n budget: ContextBudget;\n lifecycle: Lifecycle;\n trust: TrustLevel;\n state: SessionState;\n\n prompt(input: string): AsyncIterable<Event>;\n spawn(contract: SessionContract): Session;\n dispose(): void;\n}\nOne loop. One implementation. Every "agent" type uses it.
\nThe critical difference from what exists today: budget is a first-class concept, not an afterthought. The session knows how much context it has consumed, what percentage remains, and can make intelligent decisions (or expose this to the model).
interface Capability {\n name: string; // e.g., "email", "whatsapp", "code-editing"\n tools: ToolDefinition[]; // the tools this capability provides\n guidance: string; // usage guidance injected with the tools\n dependencies?: string[]; // other capabilities this requires\n cost: number; // token cost of loading this capability\n}\nThis replaces three separate concepts:
\nA capability is tools + the knowledge to use them correctly, loaded as one unit. When you load "email," you get email_read, email_search, email_list_threads AND the guidance about using snippets instead of full bodies, two-pass patterns, triage integration.
This kills the current problem where tools exist in extensions but their usage guidance lives in skills. They should never be separated.
\nCapability tiers:
\n| Tier | \nLoaded When | \nExamples | \n
|---|---|---|
| Core | \nAlways | \nbash, read, write, edit, memory | \n
| Domain | \nWhen session contract includes them | \nemail, whatsapp, calendar, web, search | \n
| Specialist | \nWhen explicitly requested | \nbrowser, codex, agents, garmin | \n
| Ephemeral | \nCreated for specific contexts | \ndatabase query wrappers, workflow-specific tools | \n
interface Profile {\n name: string;\n capabilities: string[]; // which capabilities to load\n trust: TrustLevel; // approval requirements\n lifecycle: LifecycleConfig; // how the session starts, runs, ends\n budget: BudgetConfig; // context limits, compaction strategy\n guidance: string; // profile-specific system prompt\n}\nProfiles replace the current fragmented configuration:
\nconst PROFILES = {\n interactive: {\n capabilities: ["core", "memory", "search"],\n // other capabilities loaded on demand\n trust: "high",\n lifecycle: { type: "multi-turn", humanInLoop: true },\n budget: { compactAt: 0.7, defaultReadMode: "peek" },\n guidance: "..." // minimal — human is watching\n },\n \n orchestrator: {\n capabilities: ["core", "memory", "delegation", "orchestrator-tools"],\n trust: "medium",\n lifecycle: { type: "stateful-one-shot", stateStore: "scratchpad" },\n budget: { compactAt: 0.6, defaultReadMode: "structure" },\n guidance: "..." // ESA-like but advisory, not mandatory\n },\n \n worker: {\n capabilities: ["core"],\n // additional capabilities specified per-task\n trust: "low",\n lifecycle: { type: "one-shot", maxTurns: 10 },\n budget: { compactAt: 0.5 },\n guidance: "Execute the task. Return structured results. No exploration."\n },\n \n child: {\n capabilities: [], // inherited from parent + task-specific\n trust: "inherited",\n lifecycle: { type: "scoped", maxTurns: 5 },\n budget: { inherit: "parent-remaining" },\n guidance: "" // set by parent\n }\n};\ninterface StateStore {\n // Ephemeral (within session)\n context: Message[]; // conversation history\n \n // Persistent (across sessions) \n memory: MemoryStore; // long-term knowledge (current system)\n scratchpad: ScratchpadStore; // inter-run state (COT's current approach)\n queue: QueueStore; // background task queue (maintain)\n}\nThe current memory system works. Keep it. The scratchpad pattern (inter-run state for autonomous sessions) works. Keep it. The maintain queue works. Keep it.
\nWhat changes: these are all accessible through the same state interface, not through separate tool implementations per system.
\ninterface ContextBudget {\n total: number; // model's context window\n used: number; // current consumption\n remaining: number; // total - used\n percentUsed: number; // 0-100\n \n // Exposed to the model via tool results\n report(): BudgetReport;\n \n // Automatic policies\n compactAt: number; // percentage threshold\n readDefault: ReadMode; // default mode for read tool\n \n // Adaptive behavior\n suggestReadMode(fileSize: number): ReadMode;\n shouldDelegate(estimatedCost: number): boolean;\n}\nThis is the genuinely new thing. Neither system has it today.
\nEvery tool result includes a budget footer:
\n[Context: 47% used | 106K remaining | Read mode: peek recommended]\nThe model can then make informed decisions without explicit instructions. It doesn't need 500 tokens of AGENTS.md telling it when to use peek mode — it can see the budget and reason about it.
\nBefore: AGENTS.md (10K tokens) + 51 permanent tools + 27 skills\nAfter: Profile guidance (2K tokens) + 5 core tools + capabilities loaded on demand\nAGENTS.md gets decomposed:
\nSkills get merged into capabilities:
\nresearch skill + web_search/web_fetch tools → "research" capabilitywhatsapp skill + wa tools → "whatsapp" capabilitygithub skill + git tools → "github" capabilityThe model starts with 5 tools and ~2K guidance. It asks for more when it needs them (or the system auto-loads based on the conversation).
\nBefore: 242-line system prompt + 65+ tools + hardcoded ESA + briefing builder\nAfter: Profile guidance (advisory ESA) + orchestrator capabilities + briefing as input\nThe ESA pattern becomes advisory, not mandatory:
\nYou receive a briefing with the current state of Aaron's digital life.\nYour goal: surface what needs attention, maintain state, queue background work.\n\nWhen data is large or complex, delegate reads to child sessions to \npreserve your context for synthesis and action. When the situation is \nsimple, act directly.\nSame tools, but loaded as capabilities:
\nThe briefing builder stays. It's good. But it now also includes budget information.
\nBefore: spawn_sub_agent with manual tool list and 5 params\nAfter: session.spawn({ capabilities: ["email"], prompt: "...", maxTurns: 3 })\nSame mechanism, cleaner contract. The sub-agent gets the email capability (tools + guidance) instead of a raw tool list. Trust and budget are inherited.
\nBefore: maintain_runner.ts with task claiming, model resolution, pipeline execution\nAfter: Queue trigger → Session(profile="worker", capabilities=task.capabilities)\nThe maintain runner's lifecycle management (claiming, locking, heartbeats, retries) wraps around a standard session. The session itself is identical to any other.
\nBefore: agent_spawn with pi process launch, DB lifecycle, message passing\nAfter: session.spawn({ capabilities: [...], prompt: "...", lifecycle: "multi-turn" })\nThe agents-runtime's DB-backed lifecycle and message passing become the implementation of session.spawn for the multi-turn case. Lightweight spawns (one-shot) don't need DB tracking.
Before: codex_start/codex_turn/codex_stop with 14 extension tools\nAfter: session.spawn({ provider: "openai/codex", capabilities: ["code-editing"], sandbox: true })\nCodex becomes just another session with a different model provider and sandbox constraints. The context management rules (the codex skill's hard-won empirical data) become part of the Codex capability's guidance.
\nThis is the most important new abstraction. It replaces extensions + skills + COT tool groups.
\ncapabilities/\n core/ # Always loaded\n index.ts # bash, read, write, edit\n guidance.md # "Use read with mode:peek for large files..."\n \n memory/ # Always loaded\n index.ts # memory_search, memory_read, memory_write\n guidance.md # "Search before writing. Concrete examples..."\n \n email/ # Loaded when needed\n index.ts # email_read, email_search, email_list_threads\n guidance.md # "Use snippets, not full bodies. Two-pass pattern..."\n pi-adapter.ts # Gmail API implementation (for Pi)\n cot-adapter.ts # DB query implementation (for COT)\n \n whatsapp/\n index.ts\n guidance.md\n pi-adapter.ts # wa CLI wrapper\n cot-adapter.ts # DB query wrapper\n \n orchestration/ # COT-specific\n index.ts # scratchpad, priorities, telegram, queue\n guidance.md\n \n code-editing/ # Pi-specific\n index.ts # enhanced read modes, search, find\n guidance.md # workspace conventions, file patterns\n \n research/\n index.ts # web_search, web_fetch\n guidance.md # "Verify docs before relying..."\n \n agents/\n index.ts # session.spawn\n guidance.md # delegation patterns, when to parallelize\nThe biggest duplication today is data access. Pi reads email via Gmail API (google extension). COT reads email via PostgreSQL queries (tool-builder). Same data, different access patterns.
\nThe capability system uses adapters:
\ninterface EmailCapability extends Capability {\n tools: [\n { name: "email_read", execute: (params) => adapter.readThread(params) },\n { name: "email_search", execute: (params) => adapter.search(params) },\n { name: "email_list", execute: (params) => adapter.list(params) },\n ];\n}\n\n// Pi context: use Gmail API directly\nclass GmailAdapter implements EmailAdapter {\n async readThread(params) { /* Gmail API call */ }\n}\n\n// COT context: use synced DB (faster, no API quota)\nclass CotEmailAdapter implements EmailAdapter {\n async readThread(params) { /* SELECT FROM cot.emails */ }\n}\nThe tools and guidance are identical. Only the data access layer changes. This eliminates the entire duplication problem.
\nThe architecture doc identified read as the 52.2% context killer. Smart-read was a good patch. But the real fix is making the model budget-aware.
class ContextBudget {\n private total: number;\n private consumed: number = 0;\n \n addToolResult(result: string): string {\n const cost = estimateTokens(result);\n this.consumed += cost;\n \n // Append budget report to every tool result\n const report = this.formatReport();\n return result + "\\n\\n" + report;\n }\n \n formatReport(): string {\n const pct = Math.round(this.consumed / this.total * 100);\n const remaining = this.total - this.consumed;\n \n if (pct < 50) return `[Budget: ${pct}% used | ${remaining} tokens remaining]`;\n if (pct < 70) return `[⚠️ Budget: ${pct}% used | Consider using peek/grep modes]`;\n if (pct < 85) return `[🔴 Budget: ${pct}% used | Delegate large reads to child sessions]`;\n return `[🚨 Budget: ${pct}% used | Compact or finish soon]`;\n }\n \n suggestReadMode(fileSize: number): ReadMode {\n const costEstimate = fileSize / 4; // rough token estimate\n const remainingBudget = this.total - this.consumed;\n \n if (costEstimate < remainingBudget * 0.05) return "full"; // <5% of remaining\n if (costEstimate < remainingBudget * 0.15) return "head"; // <15% of remaining \n return "peek"; // large relative to budget\n }\n}\nThe model doesn't need instructions about when to use peek mode. It sees:
\n[🔴 Budget: 73% used | Delegate large reads to child sessions]\nAnd it reasons about it naturally. This is cheaper and more reliable than 500 tokens of guidance in AGENTS.md.
\nconst readTool = {\n name: "read",\n execute: async (params, { budget }) => {\n const stats = await fs.stat(params.path);\n const suggestedMode = budget.suggestReadMode(stats.size);\n \n // If user specified full but budget suggests otherwise, warn\n if (params.mode === "full" && suggestedMode !== "full") {\n // Still honor the request, but include warning\n const content = await readFull(params.path);\n return budget.addToolResult(\n content + `\\n\\n[Note: This file consumed ~${estimateTokens(content)} tokens. ` +\n `Suggested mode was '${suggestedMode}' given current budget.]`\n );\n }\n \n const mode = params.mode ?? suggestedMode;\n const content = await readWithMode(params.path, mode, params);\n return budget.addToolResult(content);\n }\n};\nThe current guidance stack:
\nAGENTS.md (10K tokens, always loaded)\n → Extension tool descriptions (2K tokens, always loaded)\n → Skills (2-7K tokens, loaded on demand)\n → Memory (retrieved on demand)\nThe proposed stack:
\nProfile guidance (1-2K tokens, always loaded)\n → Core capability guidance (500 tokens, always loaded)\n → Domain capability guidance (loaded with capability)\n → Memory (retrieved on demand)\n → Budget signals (appended to tool results)\nProfile guidance (always loaded, <2K tokens):
\nCore capability guidance (always loaded, <500 tokens):
\nDomain capability guidance (loaded with capability, 500-2K each):
\nNOT in guidance anymore (moved to memory or eliminated):
\nThe current system has three delegation mechanisms. The proposal has one: session.spawn(contract).
interface SpawnContract {\n // What it gets\n capabilities: string[]; // which capabilities to load\n prompt: string; // the task\n \n // How it runs\n model?: string; // default: inherited or tier-appropriate\n maxTurns?: number; // default: 5\n trust?: TrustLevel; // default: inherited\n budget?: BudgetAllocation; // default: split from parent\n \n // How it returns\n maxOutput?: number; // truncate result for parent's context\n structured?: boolean; // expect JSON output\n \n // Lifecycle\n sync?: boolean; // wait for result (default: true)\n persist?: boolean; // DB-backed lifecycle (default: false)\n}\nThis replaces:
\nspawn_sub_agent({ model, tools, prompt, max_turns, max_output })agent_spawn({ task, tools, model, thinking, timeout, ... })codex_start({ cwd, instructions, model, sandbox })run_workflow(name, context)maintain_write({ task_type, tools, prompt, model, ... })All five become different configurations of session.spawn():
// COT sub-agent: lightweight, synchronous, scoped\nsession.spawn({\n capabilities: ["email"],\n prompt: "Summarize unread threads",\n model: "sonnet",\n maxTurns: 3,\n sync: true\n});\n\n// Pi child agent: multi-turn, persistent, full capabilities\nsession.spawn({\n capabilities: ["core", "search", "web"],\n prompt: "Research X and write a report",\n maxTurns: 50,\n persist: true, // DB-backed lifecycle\n sync: false // parent continues\n});\n\n// Codex delegation: sandboxed, external provider\nsession.spawn({\n capabilities: ["code-editing"],\n prompt: "Create these 5 files...",\n model: "openai/codex",\n trust: "sandboxed",\n maxTurns: 20\n});\n\n// Background worker: queued, one-shot, isolated\nsession.spawn({\n capabilities: ["research", "memory"],\n prompt: "Find papers on topic X",\n model: "opus",\n sync: false,\n persist: true, // survives parent session\n scheduled: "next-maintain-cycle"\n});\nUnder the hood, spawn routes to the right implementation:
sync: true, persist: false → in-process session (current spawn_sub_agent approach)sync: false, persist: false → child process (current agents-runtime approach)sync: false, persist: true → queue-backed (current maintain approach)model: "openai/codex" → Codex bridge (current codex extension approach)The implementations exist. They just need a unified interface.
\nThe architecture doc proposed 7 innovations. This proposal agrees with some, diverges on others:
\n| Architecture Doc | \nThis Proposal | \nDifference | \n
|---|---|---|
| Progressive read modes | \n✅ Keep (smart-read exists) | \n+ Budget-aware auto-selection | \n
| Token-aware tool loading | \n✅ Capability system | \nCapabilities = tools + guidance, not just tools | \n
| Context % compaction | \n✅ Budget-driven | \n+ Model sees its own budget in real-time | \n
| Skill triggers | \n❌ Replace with capabilities | \nCapabilities auto-load when session contract specifies domain | \n
| Memory auto-proposal | \n✅ Keep as post-session hook | \nNo change needed | \n
| Trust gradient | \n✅ Profile system | \nProfiles are richer than just trust | \n
| Read tool analytics | \n✅ Budget tracking provides this | \nNatural telemetry from budget system | \n
Capabilities as tools + guidance (not separate). This is the biggest architectural change. Currently tools live in extensions and guidance lives in skills. They must always be loaded together, never separated.
\nBudget as a runtime concept the model can see. Not just token counting for compaction. The model receives budget signals in every tool result and can reason about its own resource constraints.
\nAdapter pattern for data access. Same capability interface, different backends (API vs DB). Eliminates the entire Pi-vs-COT tool duplication.
\nUnified spawn contract. One interface for all delegation patterns. The implementation varies, but the model only sees one tool.
\nProfile-driven session configuration. Not two separate systems with different code, but one system with different profiles.
\nThis isn't a rewrite. It's a convergence. Each step delivers value independently.
\nExtract the first capability from the overlap zone: memory.
\ncapabilities/memory/\n tools.ts → memory_search, memory_read, memory_write (from agent-memory extension)\n guidance.md → extracted from memory-architect skill + AGENTS.md memory section\n adapter.ts → PostgreSQL (shared by Pi and COT)\nBoth Pi and COT load the same capability. Pi via extension wrapper, COT via tool registration. Same tools, same guidance, one implementation.
\nThen: email, whatsapp, search. Each extraction eliminates one duplication.
\nAdd ContextBudget to the session. Doesn't require any architectural change — it's a wrapper around token counting that appends budget reports to tool results.
Measurable impact: reduced context blow from read tool (the 52.2% killer).
Create profiles for interactive and orchestrator. Extract guidance from AGENTS.md and COT's system prompt into profiles + capabilities.
AGENTS.md shrinks from ~10K tokens to ~2K. COT's prompt shrinks similarly. The rest moves into capability guidance loaded on demand.
\nCreate the spawn contract interface. Implement it as a thin adapter over existing mechanisms:
spawn_sub_agent codeagents-runtime codemaintain_write codecodex_start/codex_turn codeThe model sees one tool. The implementation dispatches to the right backend.
\nFor capabilities with dual implementations (email, whatsapp, calendar), create the adapter interface. Pi uses API adapters, COT uses DB adapters. Same tools, same guidance, different data access.
\nEvery phase is independently reversible:
\nSome things in the current system work well. Don't touch them.
\nThe biggest risk is building the compatibility layer and never completing the convergence. You end up with three systems instead of two: Pi, COT, and "unified capabilities" that neither fully uses. The migration phases must each deliver standalone value, or stop after phase 2 (budget system).
\n", "body_markdown": "I read through the entire stack: Pi's extensions/skills/system-prompt, COT's runner/tools/briefing/prompt/maintain-runner, the architecture analysis document, and every major extension. Here's what I found.\n\n## The Core Problem: Two Systems, One Mechanism\n\nPi and COT both do the same thing at their core:\n\n```\nloop:\n LLM generates → tools execute → context accumulates → repeat\n```\n\nBoth use `createAgentSession` from the Pi SDK. Both call `session.prompt()`. Both have tool registries, context management, error handling. But they share **zero implementation** above the SDK level:\n\n| Concept | Pi Implementation | COT Implementation |\n|---------|-------------------|---------------------|\n| Tool registry | Extensions (loaded at startup, permanent) | `registry.ts` (factory pattern, on-demand) |\n| bash/read/write/edit | Pi SDK built-in tools | Separate tool modules (import side-effects) |\n| WhatsApp | `wa/index.ts` extension (CLI wrapper) | `wa-*.ts` tools (DB query wrappers) |\n| Email | `google/index.ts` (API wrapper) | `email-*.ts` tools (DB query wrappers) |\n| Memory | `agent-memory/index.ts` extension | `cot-memory.ts` + `search-agent-memory.ts` |\n| Search | `unified-search/index.ts` extension | `unified-search.ts` tool |\n| Agent delegation | `agents-runtime` (child processes) | `spawn_sub_agent` (in-process sessions) |\n| Context management | Smart-read progressive modes | Sub-agent isolation |\n| Guidance | AGENTS.md + 27 skills | 242-line system prompt + briefing |\n\nEvery capability is implemented twice. When you add a new data source, you build it twice. When you fix a bug, you fix it twice. This isn't DRY — it's two complete agent systems that happen to share a database.\n\n## The Five Deeper Problems\n\n**1. The guidance stack is inverted.**\n\nPi loads ~10K tokens of system prompt (AGENTS.md) on every turn. It includes environment details, Codex delegation rules, tool routing decision trees, workspace conventions — most irrelevant to most turns. Then skills add another 2-7K tokens each when loaded. The model processes all of this before doing anything.\n\nThe architecture doc proved: 52% of sessions are <5K chars with 1.6 tools. The system is optimized for the 0.5% complex case while every session pays the cost.\n\n**2. Tool loading is all-or-nothing.**\n\nPi loads 51+ tools permanently. Each tool definition costs tokens in the cached prefix — and more importantly, costs model attention on every turn (the model must consider all tools before choosing). The architecture doc showed 4 tools account for 70% of usage. The other 47 tools are loaded for every session but used rarely.\n\nCOT loads all 65+ tools too, but organized into groups. Only `COT_PROCESS_TOOLS` + `ORCHESTRATOR_READ_TOOLS` go to the main session. Sub-agents get scoped subsets. This is better but still manual and static.\n\n**3. Context has no economic model.**\n\nNeither system gives the model information about its own context budget. The `read` tool consumes 52.2% of all tool result bytes. Smart-read added progressive disclosure modes (peek/head/grep/structure), but the model doesn't know *why* it should use them. It doesn't know how much budget remains, what it's already consumed, or what the cost of a `mode: full` read will be.\n\n**4. Agent composition is three different systems.**\n\n- Pi's `agent_spawn` creates child pi processes (full extension loading, DB-backed lifecycle, message passing)\n- COT's `spawn_sub_agent` creates lightweight in-process sessions (shared tool deps, no DB, synchronous)\n- Pi's Codex extension creates OpenAI Codex sessions (external API, sandbox, context management)\n\nThese can't interoperate. A Pi child agent can't use COT's database tools. A COT sub-agent can't use Pi's browser extension. Codex can't do either. They're three islands.\n\n**5. The ESA pattern is ceremony, not architecture.**\n\nCOT's system prompt mandates Explore→Synthesize→Act every run. This makes sense when there's lots of new data to process. But when nothing's changed? The model still goes through the motions — spawning empty explorers, synthesizing nothing, writing the same scratchpad. The pattern is burned into the prompt, not emergent from the situation.\n\n---\n\n## The Proposal: Sessions All the Way Down\n\n### Core Insight\n\nEvery \"agent\" in the current system is the same thing: **an LLM session with tools, a context budget, and a lifecycle policy.** The differences are configuration, not architecture.\n\n| Current Thing | What It Actually Is |\n|---------------|---------------------|\n| Pi interactive session | Session(trigger=human, tools=universal, trust=high, lifecycle=multi-turn) |\n| COT process run | Session(trigger=timer, tools=orchestrator, trust=medium, lifecycle=stateful-one-shot) |\n| COT sub-agent | Session(trigger=parent, tools=scoped, trust=inherited, lifecycle=one-shot) |\n| COT maintain worker | Session(trigger=queue, tools=task-specific, trust=low, lifecycle=one-shot) |\n| Pi child agent | Session(trigger=parent, tools=inherited, trust=inherited, lifecycle=multi-turn) |\n| Codex delegation | Session(trigger=parent, tools=sandboxed, trust=sandboxed, lifecycle=multi-turn) |\n\nThey should all be the same runtime with different configuration.\n\n### Five Primitives\n\nThe entire system reduces to five concepts:\n\n#### 1. Session (the core loop)\n\n```typescript\ninterface Session {\n id: string;\n model: Model;\n tools: Tool[];\n budget: ContextBudget;\n lifecycle: Lifecycle;\n trust: TrustLevel;\n state: SessionState;\n\n prompt(input: string): AsyncIterable