• Instruction memory is manually curated, hierarchical configuration injected into the system context by priority (organization level → user level → project level → local level; local takes precedence). Project coding specifications and behavior rules are stored here. It is written by humans and stable.
• Automatic memory is persistent knowledge written autonomously by the Agent, with a type taxonomy (user / feedback / project / reference) and a capped index. Writing is a two-step operation: first write the topic file, then update the index. The cap prevents unlimited growth — if not cleaned up, new entries will be silently truncated.
• Session extraction runs as a background Agent at the end of the session. It directly writes to automatic memory — first topic file then index — following the same two-step save invariant. A mutex ensures that if the main Agent has already written memory in the current round, the extractor skips directly. This is the autonomous learning loop.
• Review and promotion audits all memory layers and proposes cross-layer moves (automatic memory → project specifications, personal settings or team memory). It never applies changes autonomously — proposals require explicit user approval.

In Claude Code: Use

/remember

to audit and promote automatic memory entries across layers.

• More memory layers = richer recall but higher maintenance burden. If not cleaned up regularly, the index cap will cause silent data loss.
• Session extraction adds latency at the end of the session, but greatly improves cross-session learning ability.

• Discovery is budget-constrained: the Agent sees a compact list of all available skills (name, description, trigger prompts concatenated together), each with a hard character limit, and the total amount is limited to about 1% of the context window. Put trigger keywords first — the rest will be truncated.
• Loading is lazy: only metadata enters the always-online context. The full skill content is only loaded when activated, and idle token cost is close to zero.
• Execution can be inline (shared context) or isolated (fork child Agent with its own token budget). Isolation prevents heavy skills from exhausting the parent context.
• Sources can be built-in, user-installed, or dynamically loaded from plugins. Deduplication is done via canonical paths to prevent the same skill from appearing twice in overlapping source directories.

• Lazy loading saves tokens but adds an extra round of latency on first activation.
• Fork execution provides isolation but loses the context already accumulated by the parent.

• Registration uses fail-closed defaults: tools are not concurrent and not read-only by default, unless the developer actively marks them. This prevents accidental parallel execution of state-changing operations.
• Concurrency classification is per call, not per tool type: the same tool is safe for some inputs and unsafe for others. The runtime splits a batch of tool calls into consecutive groups — safe calls are executed in parallel, and any unsafe call starts a serial segment.
• Permission pipeline evaluates rules from multiple sources in strict priority order, covering configuration files (user, project, local, flags, policies), CLI parameters, command-level rules and session authorization. The evaluator is stateful — it tracks rejection counts, transitions modes, and updates state as a side effect.
• Handler distribution varies by execution environment: interactive (human prompt), automated (orchestrator) or asynchronous (Swarm Agent). The same permission rules feed different approval interfaces.

In Claude Code: Use

/update-config

to configure permission rules and Hook.

• Fail-closed default means new tools are secure out of the box, but developers must actively mark concurrency safety — forgetting to mark read-only tools will silently reduce throughput.
• Multi-source permission layering is powerful but difficult to debug when rules conflict.

• Select — load on demand, don't load all at once. Use three-level progressive disclosure: metadata (always present, cheap), instructions (loaded on activation), resources (loaded on demand). Memoize expensive context builders, only invalidate at known change points — don't make it reactive.
• Write back — context is not read-only. The Agent writes information back to persistent storage: automatic memory entries, background extraction output, task status, permission rules. The write-back loop is the key to turning a stateless tool caller into a learning system.
• Compress — long sessions exhaust the window. Reactive compaction summarizes old rounds in the middle of the session, retaining recent context while reclaiming budget. Mark snapshot data as snapshots so the model knows to re-fetch the current state.
• Isolate — delegated work must not pollute the parent context. Coordinator workers have zero context inheritance (only explicit prompts). Fork children inherit the full context but have a single-layer limit (cannot recursively fork). File system level isolation (worktree) gives the Agent its own working copy.

• Aggressive caching reduces latency but carries the risk of obsolescence — each change point must explicitly clear the cache, otherwise the model will use stale data for the rest of the session.
• Progressive disclosure saves tokens but means the model cannot reason about the full capabilities of a skill before activation.

• Fork only has one layer — recursive fork will exponentially amplify context cost.
• Swarm teammates cannot generate other teammates — the list is flat to prevent uncontrolled growth.
• Results arrive asynchronously; fire-and-forget registration returns an ID immediately, and the parent can continue working.

1. Define phased workflow: research → synthesis → implementation → verification
2. Write self-contained prompts for each worker (don't use "based on your findings")
3. Filter each worker's toolset to only provide required tools
4. Decide on continue vs new strategy: continue if context overlaps, must create new for verification phase

• Coordinator is the safest but slowest — each phase waits for the previous phase to complete.
• Fork is the fastest but only has one layer, sharing the full context cost of the parent.
• Swarm is the most flexible but hardest to coordinate — peers can only communicate through shared task lists.

• Hook attaches side effects at defined lifecycle moments (before/after tool execution, prompt submission, Agent start/stop). Trust is all-or-nothing: all Hooks are skipped when the workspace is untrusted — not just suspicious ones. Session-level Hooks are temporary and cleaned up when the session ends.
• Long-running work is tracked through a typed state machine. Each work unit has a typed prefixed ID, strict lifecycle (running → completed / failed / killed), and disk-backed output. Reclamation is two-stage: disk is cleared immediately when in final state, memory is lazily cleared only after the parent is notified.
• Bootstrap structures initialization into dependency-ordered, memoized phases. The trust boundary — the moment the user gives authorization consent — is a key inflection point: security-sensitive subsystems (telemetry, secret environment variables) cannot be activated before trust is established. Multiple entry modes (CLI, server, SDK) share the same Bootstrap path, different entry points.

In Claude Code: Use

/update-config

to configure Hook (before/after tool execution, prompt submission).

• All-or-nothing Hook trust is simple but crude — one untrusted Hook disables the entire extension system.
• Disk-backed task output keeps memory constant but increases I/O latency proportional to concurrent work units.

1. Concurrency classification is per call, not per tool type. The same tool is safe for some inputs and unsafe for others. Do not assume that the concurrency behavior of a tool is static — the runtime decides per call.
2. Permission evaluation has side effects. The permission checker tracks rejection counts, transitions modes, updates state. Do not treat it as a pure query function.
3. Most asynchronous work skips the "pending" state. In practice, work units are directly registered as "running". Do not build UIs that assume every work unit starts from pending.
4. Fork children cannot fork. Recursion protection maintains the single-layer invariant. The Fork tool remains in the child tool pool (for prompt cache sharing) but is blocked when called.
5. Context builders are memoized but manually invalidated. If you add a context source without adding a corresponding invalidation point, the model will see stale data for the entire session.
6. Memory indexes have hard caps. Entries exceeding the cap are silently truncated. If not cleaned up regularly, new entries become invisible.
7. Skill list budget is very tight. Descriptions are concatenated and limited by characters per entry. Put the most distinctive trigger language first — the rest will be truncated.
8. Hook trust is all-or-nothing. When the workspace is untrusted, the entire Hook system is disabled, not just individual suspicious Hooks.
9. The default permission for tools is "allow". Tools that do not implement custom permission logic are fully delegated to the rule-based system. Only override when tool-specific gating (path ACL, quota, etc.) is required.
10. Reclamation requires notification. Final state work units can only be GCed after the parent receives the completion signal. Reclamation before notification creates a race condition, and the parent will never read the result.

• Prompt engineering or system prompt design
• Model selection or fine-tuning
• General software architecture (MVC, microservices)
• Chat UI or conversational interfaces
• LLM API integration basics