Status: parked
We're consolidating on code mode — an agent whose one tool is execute({ source }), writing confined JS against petname-bound capability globals — as the primary agent surface. The JSON tool layer (makeTool / makeGitTool / makeGitRemoteTool / makeHttpTool / makeWorkspaceTools wrappers an LLM drives by emitting JSON) is being parked here as future work. This parks only the JSON tool wrappers; the underlying git / fs / mount capabilities they sit on are shared infrastructure that code mode depends on and are unaffected.
Why we're parking it
- Capabilities crossing the tool boundary are hard. Passing a live cap in as a tool argument, or getting one back out as a result, is footgun-prone and needs a lot of additional machinery and case-by-case massaging (see the gist for the full boundary analysis).
- Code mode looks easier and more effective. Our thesis is that letting an agent write code is a better path than a growing JSON tool surface: fewer tool calls / turns, better composition, and fewer tokens.
- A shorter, more interesting, likely more capable path.
To be explicit about what this is not: it is not a trust or competency judgment about models, and code mode is not a "power-user only" surface — execute can itself be exposed over MCP. We're choosing the more promising lane, not retreating from a hard one.
Already designed (mostly)
- Capability arguments as petnames — a live cap crosses the tool-call wire as a petname string, resolved fail-closed against the guest's own petstore. Rejected alternatives (opaque handle registry; forgeable passable entries) and the full tradeoff analysis: https://gist.github.com/0xpatrickdev/747d4ec20600f2f9646ebf91eb73d90c
designs/endo-agent-tools.md — the makeTool / makeGitTool ToolRecord surface and the schema⟷guard divergence gate.
designs/daemon-agent-tools.md — reconciliation map for the tool surface over the mount / git / git-remote / http capabilities.
designs/agentry-git-verb-gaps.md — the JSON makeGitHistoryTool slice.
designs/endopi-edit-tool.md — the oldText/newText JSON edit tool.
Blockers / open questions (for when this is picked up)
- Adoption is uncertain. Even fully built, will agents / MCP clients reach for the JSON tool surface over code mode, and what's the migration path for anything already wired to tools? Worth answering before re-investing.
- Result-out half is unimplemented.* Tools that return a live cap (e.g.
Git.filesystemAt(ref) → live Filesystem) have no landed tool-mode story — the main open frontier.
- One name, one case.* The "camelCase everywhere, no transform" convention is decided but only partly installed (base is partly kebab-native).
- Naming discipline for derived views. Unbounded derived views (every ref, path, status row) must stay plain-data-relative-to-a-grant, not each consume a petname; the promote-to-named-thing boundary needs a firm rule.
- Divergence-gate coverage must extend to every new capref / cap-out method.
* Also open for code mode / execute, not unique to the JSON tool layer: handing a returned cap back to a code-mode session and settling on a resultName, and the single-name/single-case convention, both cut across both modes.
Parked code — preserved on branches
Snapshot branches pin this work independently of the PRs, so it survives rebase / branch deletion.
Status: parked
We're consolidating on code mode — an agent whose one tool is
execute({ source }), writing confined JS against petname-bound capability globals — as the primary agent surface. The JSON tool layer (makeTool/makeGitTool/makeGitRemoteTool/makeHttpTool/makeWorkspaceToolswrappers an LLM drives by emitting JSON) is being parked here as future work. This parks only the JSON tool wrappers; the underlying git / fs / mount capabilities they sit on are shared infrastructure that code mode depends on and are unaffected.Why we're parking it
To be explicit about what this is not: it is not a trust or competency judgment about models, and code mode is not a "power-user only" surface —
executecan itself be exposed over MCP. We're choosing the more promising lane, not retreating from a hard one.Already designed (mostly)
designs/endo-agent-tools.md— themakeTool/makeGitToolToolRecordsurface and the schema⟷guard divergence gate.designs/daemon-agent-tools.md— reconciliation map for the tool surface over the mount / git / git-remote / http capabilities.designs/agentry-git-verb-gaps.md— the JSONmakeGitHistoryToolslice.designs/endopi-edit-tool.md— theoldText/newTextJSON edit tool.Blockers / open questions (for when this is picked up)
Git.filesystemAt(ref)→ liveFilesystem) have no landed tool-mode story — the main open frontier.* Also open for code mode /
execute, not unique to the JSON tool layer: handing a returned cap back to a code-mode session and settling on aresultName, and the single-name/single-case convention, both cut across both modes.Parked code — preserved on branches
Snapshot branches pin this work independently of the PRs, so it survives rebase / branch deletion.
makeToolinvoke boundarypackages/agent-tools/src/tool.jsmakeGitRemoteTool(fetch/pull/push)packages/agent-tools/src/git-remote-tool.jsGitRemotecapability is kept.makeHttpToolpackages/agent-tools/src/http-tool.jsprovideHttpClientdaemon infra is kept.makeWorkspaceTools(catalog provisioning + worked loop)packages/agent-tools/src/workspace.jspackages/agent-tools/src/git-tool.js(delta)agentry/src/execute/git.js) is code-mode and kept.packages/agent-tools/src/git-mount-tool.js(delta)checkoutConflictverb is kept.