Agent Tooling Splits Three Ways: IDEs, Inboxes, and Runtimes

The pitches are not competing for the same buyer. Hyperlane describes itself as an IDE and ADE that runs AI agents in parallel and merges their worktrees with native tooling. Pizza Bot, published on GitHub by pizza-bot-app, is a local-first inbox for long-running agents built with DeepAgents and LangGraph. Soma, documented at docs.trysoma.ai, is an open-source, self-hostable agent and workflow runtime that ships as a single binary.

All three are developer-facing. None is a hosted service in the way the current enterprise agent news cycle assumes.

What each one actually claims

Pizza Bot's README is the most specific of the three. It says the tool was developed at Amazon and released under the Apache 2.0 license. The runtime is a stateful DeepAgents and LangGraph stack that serves the same React front end in Electron and in the browser. The desktop app, web app and terminal CLI all talk to an api-server over HTTP and server-sent events.

Agents keep working when the user navigates away or disconnects, the README states, and only the api-server process must remain running. Completed work lands in an Unread queue and approval requests land in Action. Runs are checkpointed and survive client disconnects, and cron or webhook triggers can start work without an open conversation.

On models, Pizza Bot supports Amazon Bedrock, Anthropic, Google Gemini, OpenAI, OpenRouter and Ollama. Bedrock accepts an AWS profile, AWS access keys or a Bedrock API key, with an optional region override; otherwise AWS_REGION or us-west-2 is used. The desktop protects entered secrets with Electron safeStorage, and server configuration persists only environment-variable references.

Local access is opt-in. Administrators add individual read-only or writable folders under Settings, Files, and the README states Pizza Bot receives no default home-directory access. The api-server binds to 127.0.0.1, and non-loopback binding requires authentication. Installers are attached to every release with a SHA256SUMS file; macOS builds are signed and notarized, Windows ships a setup executable, and the Linux .deb and .rpm packages are not signed.

Soma goes lower in the stack

Soma's documentation frames the project as the bottom of the pyramid: core building blocks plus developer experience, with the agent logic left to the user. Agents and MCP functions are defined in regular code, with TypeScript supported and Python listed as coming soon. Users can bring their own frameworks, and the docs name LangChain and the Vercel AI SDK as examples.

The runtime claims fault tolerance and resumability: execution can crash or be suspended at any point and resume where it left off. It also generates A2A (Agent2Agent) endpoints and says OpenAI streaming-compatible endpoints are coming soon, with fine-grained API key access management to restrict access to a given agent.

Governance is the differentiator Soma leans on hardest. The docs list an MCP server pre-integrated with third-party SaaS providers that handles credential encryption and rotation, an outbound AI gateway to intercept agent requests to model providers, and local, AWS or forthcoming GCP KMS encryption for MCP credentials, API keys and agent secrets.

Platform support is uneven. TypeScript is marked available on macOS x86 and ARM, Linux GNU x86 and ARM, with Windows unsupported. Python carries the same four green platforms. Rust is not yet available on any listed platform, and the documentation attributes the gap to the project's use of Unix domain sockets in Rust.

Hyperlane sells the worktree

The Hyperlane listing on hyperlaneide.com positions the product as a complete IDE that runs AI agents in parallel, merging agent worktrees with native tooling. That is the whole of the substantive claim the page text supports; the rest of the fetched content is rendering noise rather than readable documentation.

Worktree isolation is the natural response to a real problem: two agents editing the same repository at the same time produce conflicts that are hard to attribute. Running each agent in its own worktree and merging the results keeps the main branch clean until a human decides what to accept. It is a coding-centric answer, and it assumes the buyer already lives inside an IDE.

Pizza Bot takes the opposite stance. Its inbox metaphor assumes the user does not want to watch the agent work at all. The README's pitch is to start or schedule a task, walk away, and come back to finished work. Skills become tool-scoped subagents whose progress appears in an Activity panel, and human-in-the-loop approvals, long-term memory, file attachments and desktop notifications are built into the workflow.

Soma sits underneath both. It does not care whether a human is watching, because its job is to keep execution alive and observable across crashes, and to keep credentials and model calls inside a controlled boundary.

The governance question the tools raise

Self-hosting is the common thread. All three are positioned as software an organisation runs on its own infrastructure rather than a subscription. Pizza Bot ships Docker Compose and a Dockerfile. Soma ships as a single binary. Artifact Keeper, a separate Show HN project, makes the same argument for artifact registries: a self-hosted replacement for JFrog Artifactory and Sonatype Nexus with no open-core split, 45 or more package formats, GPG and PGP signing, OIDC, LDAP and SAML 2.0 authentication, and OpenTelemetry tracing. It is not an agent tool, but it is the same buyer making the same calculation.

That calculation is where the agent tooling market is currently fracturing. The news cycle around enterprise agents is dominated by control planes and runtime governance, but the artefacts developers are actually publishing are smaller and more opinionated: an inbox, a runtime, an IDE.

None of the three publishes adoption numbers. Pizza Bot's README lists an architecture and a roadmap but no user counts. Soma's docs list platform availability without download figures. Hyperlane's page offers no metrics at all in the text that renders. For a category that the surrounding headlines value in the tens of millions of dollars, the public evidence here is still engineering detail rather than traction.

There is also an unresolved tension in the local-first pitch. An inbox that runs long tasks in the background is only useful if the runtime stays up, and Pizza Bot says exactly that: only the api-server process must remain running. A laptop that sleeps, or a desktop app that is quit, breaks the promise unless the backend is moved somewhere persistent. The same README documents a standalone backend path for remote Electron, browsers, containers and Linux services, which is where most enterprise deployments would end up anyway.

Soma's KMS options point at the same reality. Local encryption is convenient for a single developer; AWS KMS, with GCP described as coming soon, is what an organisation with an audit obligation will ask for. The gap between the demo and the deployment is where these projects will be judged.

For now, the useful signal is what the authors chose to build first. One picked parallel worktrees. One picked an inbox. One picked a governance plane around a single binary. Those are three different bets about where agent work actually breaks, and only usage will settle which one was right.