Summary

Add a first-class primitive for spawning a persistent, autonomous background agent from within a Claude Code session. The agent would stay alive for the life of the session, read the session's transcript JSONL on its own cadence, and perform its own work silently — without per-turn invocation from the main chat and without producing any visible output in the main conversation.

Motivation

Several classes of useful behavior are not expressible with today's primitives:

• Continuous side-effect workflows (logging, summarization, bookkeeping, analytics) that should run as the user chats, without the user or the main agent having to remember to trigger them.
• Observational / auditor patterns where a secondary agent watches the primary conversation and acts on its own schedule.
• Autonomous capture systems where the user wants to focus on the conversation and have structured artifacts emerge as a byproduct — similar to how auto-memory works today, but with richer processing and schema.

The common thread: the main chat should be undisturbed, and the background work should happen without requiring the foreground agent to relay each turn explicitly.

What exists today and why it falls short

Adjacent prior art (open/closed):

• #45017 — "Periodic silent execution primitive" (covers the silent + periodic half, but hook-shaped, not agent-shaped).
• #44882 / #24038 — "Persistent observer agents" / "Auditor session mode" (cover persistent observation, but assume visible output or a separately-launched CLI session).

None of these, individually or combined, provide: spawn-from-slash-command + zero main-chat output + autonomous transcript reading + self-decided cadence + stays-alive-for-session + no per-turn forwarding.

Proposed primitive

A new mode for the `Agent` tool (or a sibling primitive) with these properties:

• Spawn: invoked once (typically from a skill or slash command). Returns immediately.
• Lifetime: persists until the session ends or is explicitly stopped.
• Autonomy: not driven by per-turn messages from the parent. Decides on its own when to act.
• Input source: read-only access to the current session's transcript JSONL (path provided via env var / tool arg), or an equivalent event stream of new user/assistant turns.
• Cadence: configurable — on every new turn, every N turns, every N seconds, or agent's own judgment.
• Output: side effects only (writes to disk, external APIs, etc.). No surface in the main chat unless explicitly asked.
• State: maintains a persistent reasoning context across its activations within the session.
• Termination: session end, idle timeout, or explicit stop call.

Pseudo-code usecase

```python

In a skill or startup hook:

Agent( subagent_type="my-background-worker", mode="persistent_observer", # new cadence="every_turn", # or "every_n=5" or "poll_seconds=30" transcript_access="read_only", # new visibility="silent", # new — no output in main chat idle_timeout_seconds=1800, # agent receives turns automatically; no SendMessage needed from parent )

Main chat continues normally. User and main agent never have to

forward turns or orchestrate — the background agent sees each

new turn as it lands in the transcript and acts on its own schedule.

Example end-user outcome: the user chats freely; a secondary

agent silently writes structured artifacts to disk as a byproduct.

```

Why not just use a shell daemon / external script?

You can approximate this today by spawning a `nohup` shell script from a skill that tails the transcript JSONL and invokes `claude -p` per turn. This works but has real drawbacks:

• Every trigger is a fresh `claude -p` subprocess — cold start, no persistent reasoning context across turns.
• Not a Claude Code citizen — bypasses hooks, skills, permissions, logging.
• Lifecycle management (PID files, signal handling, session-end detection) is reinvented per project.
• SDK `query()`-based approximations have the same one-shot limitation.

A native primitive would be reliable, inspectable, and properly integrated with the rest of the platform.

Scope considerations

• Security: read-only transcript access, permission-scoped tool use, explicit opt-in per-agent.
• Resource limits: token/time budgets, idle timeouts, single-instance lock per agent type.
• Observability: a command to list running background agents and view their logs.
• Failure mode: if the background agent crashes, main chat is unaffected; error surfaced on request.

Related issues

• #45017 (silent periodic execution)
• #44882 (persistent observer agents) — closed as dup
• #24038 (auditor session mode) — closed as dup
• #51315 (daemon + client workflows)

Available to partner for this feature.