The fence — tools, agents, and fan-out guards

The tool fence

allowed_tools is a hard whitelist — only listed tools ever reach the LLM; an out-of-fence call is refused by the runtime, not merely discouraged. Omit it and the loop runtime applies its own fail-closed default fence.

The full loop-tool catalog (fence vocabulary): read_file, write_file, edit_file, list_files, search_files, delete_file, web_search, web_fetch, load_skill, memory, knowledge, skill_manage, recall, recall_history, delegate, local_agent, registry_search, registry_lookup, call_agent, invoke_workflow, run_python, ask_user, platform_action, task_complete.

Fence design rules:

• Always include task_complete — it is how a run ends cleanly.
• Smallest set that can achieve the goal. A verification mission needs web_search, web_fetch, task_complete — not the file tools.
• ask_user keeps human-question continuations available on every surface; include it when the goal may need clarification mid-run.
• Two loop runtimes exist: the default full-surface runtime (all 24 tools; in unattended runs — the engine/bot default — platform_action is stripped from that default fence, which is why a scheduled mission can behave differently from the same mission run interactively) and universal-agent (thin default fence: the registry triad registry_search + registry_lookup + call_agent, plus research + load_skill + ask_user + task_complete — an unfenced universal-agent mission CAN call registry agents) — select with agent: on the harness task. An explicit allowed_tools always wins over either default.

The agent fence and money-class protection

call_agent lets the loop invoke registry agents. allowed_agents: [a, b] limits it to those; 'all' opens the catalog minus denied_agents. Payment/blockchain-class agents stay deny-unless-explicitly-named even under 'all' — naming them is the only way a mission can touch money, and permissions: {call_agent: ask} adds a human gate on top. This is a trust fence: surface refusals, never work around them.

Recursion and fan-out guards

• delegate spawns parallel child agents; children get a minimal default tool set and ALWAYS have delegate, invoke_workflow, and memory stripped — no fan-out explosions, no child memory writes.
• Orchestrator depth is propagated (depth → children send depth+1) and hard-capped (default max depth 3); a too-deep dispatch is refused.
• max_parallel caps one delegate call's width by refusal, never by serializing — silent batching would multiply wall clock.