user agrees.
A permanent child agent lives in ``agent/children/NAME/`` with the same
-files as the root. Create its directory and ``config.json`` by hand
-before startup. Use the root config fields with a separate random ID,
-set ``name`` to ``NAME``, and add ``parent`` with the root name and
-``responsibility`` with the child's area. The daemon opens all children
-at startup. A missing or invalid child config stops startup. Only one
-level of children is supported.
+files as the root. The root's ``agent_create(name, responsibility)``
+tool creates and starts it with the root's model, effort, and working
+directory, and a separate random ID. A name describes the area, such as
+``House`` or ``Calendar``. It is one word of 2 to 32 ASCII letters,
+starts with a capital letter, and cannot name the root, an existing
+child, or a subagent. The daemon opens all children at startup. A
+missing or invalid child config stops startup. Only one level of
+children is supported. Remove a child by hand while the daemon is
+stopped. The root's turn state lists each child and its responsibility.
+The root passes area messages from mixed chats with sender, date, and
+words, and asks the user before it sends a child's draft to WhatsApp.
Each child has its own memory, model client, usage file, subagents,
schedules, and turn loop. Its prompt limits work to its area, asks for
their recipient finishes its turn. A daemon stop preserves queued
messages and reports for the next start without a second log entry. An
interrupted turn can repeat its model calls and tools after restart.
-Backups lock this queue with the agent files. No tools send messages
-between parent and child agents yet.
+Backups lock this queue with the agent files, including children made
+during the daemon run. The root uses ``tell`` for both children and
+subagents. ``zoom("Name")`` gives a child's view or a subagent's whole
+log. ``spawn`` starts short-lived subagents, not permanent children.
**************
User service