Recursive subagents: spawning, depth, and family scope

Calling await rlm(...) asks the runtime to admit a child session and returns a handle once that work has been accepted. The handle identifies or controls the admitted child; it is not the child's completed response.

This split lets the parent continue coordinating work while the child runs with its own context, history, and kernel. Consumers should treat admission and completion as separate events.

A child reports its result through an agent message or a file rather than through the value returned by rlm(...). The parent must watch the appropriate communication path and integrate the result when it arrives.

For substantial output, a durable file can keep the message concise. For a short conclusion or steering update, a family-scoped message preserves the relationship between the child and its parent.

Multiple admitted children can make progress concurrently. This is useful for independent research or implementation branches, because each child gets a separate session and kernel rather than sharing one mutable interpreter namespace.

Concurrency also multiplies active model, memory, and process use. Tasks that depend on one another still need explicit ordering, and the parent remains responsible for reconciling conflicting results.

The default maximum recursion depth is one: a root agent can create direct children, but deeper nesting requires configuration. The bound prevents recursive delegation from expanding without an explicit operator choice.

Raising the limit creates full additional sessions at each level, so depth should be chosen as a cost and coordination budget rather than as a proxy for answer quality.

Direct routing is limited to a nuclear family: an agent can communicate with its parent, its direct children, and its siblings. A grandchild or cousin is outside that immediate routing scope.

Messages that need to cross that boundary must be relayed by an intermediate family member. The restriction keeps routing local and makes the chain of coordination visible instead of creating an unrestricted session-wide message bus.

A child is a real session with its own history and kernel, not a disposable function invocation. Retaining the child preserves a place for follow-up work and keeps its prior context available within the session tree.

That retention has a resource cost. Keep children when continued dialogue or recovery matters; do not assume that every small delegation needs a long-lived worker.