docs: llm-node builtin availability — user__/todo__ now require explicit tools: opt-in (breaking), other builtin families stay implicit

Graph-Agents.md

@@ -697,6 +697,28 @@ whitelist is enforced against global tools, agent custom tools, and MCP
 alike. Each entry is validated at startup against the active agent's tool
 list; an unknown entry is a startup error.
 
+### Built-in functions inside `llm` nodes
+
+Coyote's built-in function families are not all governed by the `tools:`
+whitelist the same way:
+
+- **`user__*` and `todo__*` require explicit opt-in.** Inside an `llm` node
+  these interactive/turn-control builtins are only offered to the model if
+  the node's `tools:` list names them (e.g. `tools: [user__select]`). A node
+  that doesn't list them never sees them. This is deliberate: graph nodes
+  usually run headless, and a structured-output node calling `user__select`
+  ("Ready to finalize?") suspends the node as an escalation instead of
+  producing its output. The graph validator warns when a node with an
+  `output_schema` explicitly opts into `user__*` tools. Approval gates are
+  unaffected — use a [`approval` node](#approval) for human sign-off, not an
+  `llm` node with user tools.
+- **`agent__*`, `memory__*`, `job__*`, `skill__*`, and RAG builtins stay
+  implicitly available** (subject to their usual gates: `can_spawn_agents`
+  for spawning, the skill policy for skills, and so on) regardless of the
+  node's `tools:` list. Orchestrator graphs spawning sub-agents from `llm`
+  nodes, teammate fan-out messaging, node-scoped background jobs, memory,
+  and graph RAG all depend on this.
+
 ### The `mcp_tools` field (per-server tool patterns)
 
 Where `tools:` selects *which servers* a node may use, an optional