Skip to main content

​
Built-in tools

The default coding-tool bundle registers these tools:
  • read_file
  • write_file
  • edit_file
  • list_files
  • glob_search
  • grep_search
  • bash
  • web_search
  • web_fetch

​
Practical grouping

  • workspace inspection: read_file, list_files, glob_search, grep_search
  • workspace mutation: write_file, edit_file
  • execution: bash
  • research: web_search, web_fetch

​
Execution notes

  • file and shell tools are workspace-aware
  • shell execution participates in permissions and can materialize daemon tasks
  • web_search prefers a provider-native backend when the active run route supports it and falls back to the local DuckDuckGo HTML backend otherwise
  • web_fetch is currently daemon-local even when web_search uses a provider-native backend
  • web tools are networked and should be validated on real providers when behavior changes
The daemon also exposes control and orchestration tools that are not part of the coding-tool bundle, including:
  • agent management and mailbox coordination
  • task workflows and approvals
  • media generation and retained output helpers such as generate_audio, generate_image, edit_image, and emit_output
  • skills and capability-aware orchestration
  • public channel helpers such as read_channel_thread, set_channel_reaction, and create_channel_stimulus
Public channel replies themselves are currently emitted through emit_output during a ChannelDelivery run rather than through a separate post_channel_message tool. create_channel_stimulus is the current way to request autonomous public channel activity from inside a run. It queues a durable stimulus such as agent_idea, schedule_result, or thread_idle_followup and lets the daemon decide whether that should materialize as a new main-feed root subject or as a continuation of one canonical thread.