Purpose
The Harness layer provides a default set of built-in tools sufficient to complete a full closed loop: reading and writing files, searching memory and sessions, delegating subagents, and optionally running a shell. No manual registration is needed —HarnessAgent.build() and SubagentsHook wire everything up together.
Registration Path
- Direct registration:
FilesystemTool/MemorySearchTool/MemoryGetTool/SessionSearchToolare always registered;ShellExecuteToolis only registered whenbackend instanceof AbstractSandboxFilesystem. - Indirect registration:
AgentSpawnToolandTaskToolare returned bySubagentsHook.tools()and only appear when non-leaf andmodelis configured; in session mode,agent_*tools are renamed tosessions_*.
Filesystem — FilesystemTool
Wraps AbstractFilesystem; paths are the backend’s local paths.
Memory — MemorySearchTool / MemoryGetTool
Parameter names are camelCase (startLine/endLine), inconsistent with the snake_case used by filesystem tools.
Session — SessionSearchTool
All parameter names are camelCase.session_searchreturns the “first 10 hits” across allagents/<agentId>/sessions/*.jsonl, not ranked by relevance.
Subagent — AgentSpawnTool
sessions_spawn / sessions_send / sessions_list.
Background Tasks — TaskTool
Shell — ShellExecuteTool (Conditional)
Only registered when the backend is AbstractSandboxFilesystem (which includes LocalFilesystemWithShell). If you use a pure LocalFilesystem or RemoteFilesystem, this tool does not appear.
Note:@Toolhas no explicitnameset, so the tool name defaults to the method name, meaning the LLM seesexecute. A future rename toshell_executeis a small refactor — see roadmap.
Related Pages
- Filesystem — backend implementations and sandbox interface
- Memory — FTS5 and the two-layer memory behind
memory_search/memory_get - Session —
WorkspaceSession/SessionTreedual-track behindsession_*tools - Subagent — scheduling and lifecycle of
agent_spawn/agent_send/task_*