I'm building Spine

Coding harnesses like Claude Code and OpenCode are great for building software. But I’ve found them less suited to building complex, reusable applications that require multiple agents working together.

I’ve experimented with building multi-agent systems using these tools. While they work well for one-off tasks, things become harder to control as the number of agents, dependencies, and execution steps increases.

I want more control over how agents interact, how data flows between them, and how their execution is orchestrated, without having to build a custom runtime for every application.

That’s why I’m building Spine, an agentic application platform based on composable workflows and sandboxed agent execution.

The core idea is simple: an agentic application should be something you can build, inspect, compose, and distribute, much like traditional software.

###What’s an agentic application, anyway?

I think of an agentic application as a program that uses one or more AI agents to accomplish a task, while retaining the properties we expect from traditional software: reusability, maintainability, deployability, and a well-defined interface, whether that’s a UI, an API, or something else.

A few examples of what I have in mind:

• A marketing assistant that analyzes a website, researches its competitors, and generates a presentation.
• A code review system that analyzes a repository, runs specialized reviews, and produces actionable feedback.
• A communications assistant that coordinates interactions across email, messaging platforms, and other channels.
• A research application that processes large documents, extracts relevant information, and generates structured reports.
• A coding harness itself, orchestrating tools and specialized agents to complete development tasks.

These applications share an important characteristic: they involve more than a single prompt. They require orchestration, state management, tool execution, I/O, and coordination between multiple operations. This is the distinction between running an agent with a prompt and building an application around it.

###The problem with existing approaches

In my experience, there are two common approaches to building these systems, each with its trade-offs.

1. Delegate everything to an agent.

Give an agent a set of instructions, tools, and access to subagents, then let it coordinate the execution. This approach is flexible and easy to prototype. But as complexity grows, execution becomes harder to predict, debug, and control.

2. Build a specialized orchestration system.

Implement the execution logic yourself, explicitly defining how agents, tools, and application state interact. This provides greater control, but introduces a significant amount of infrastructure work. Much of that infrastructure may need to be adapted or rebuilt for the next application.

Neither approach is inherently wrong. But I think there’s room for a better abstraction between the flexibility of agents and the predictability of traditional software.

###The vision

My approach with Spine is to represent agentic applications as composable workflows.

A workflow is a collection of operations that together accomplish a task. In its declarative form, it’s represented as a graph: each operation is a node that consumes inputs and produces outputs, while edges connect nodes and define how data flows between them.

This is not a new concept. Visual workflow builders and orchestration engines have used similar abstractions for years. What interests me is applying this model to agentic execution. Rather than delegating the entire orchestration to an agent, the workflow defines the structure of the application, while agents handle the operations that require reasoning and autonomy.

Agents operate with explicitly configured tools, environments, and instructions, while sharing resources and identities within the same workflow execution. This gives us a way to combine deterministic execution with agentic behavior while retaining control over the application as a whole.

Agents share a workflow’s trust domain, but retain their own execution configuration.

###The execution model

One of Spine’s main design goals is to provide agents with powerful execution environments while retaining control over how they operate and interact with the surrounding system.

The architecture is built around a few key concepts:

• Workflow isolation: Each workflow runs inside an unprivileged podman¹ container, defining a shared trust domain where agents can cooperate, exchange data, and access common resources.
• Agentic Runs: Each agent execution runs in its own bwrap² sandboxed process, with a configurable toolchain, toolset, instructions, skills, and working directory.
• Declarative execution environments: Nix³ makes it possible to compose reproducible toolchains and dependencies for each agent without maintaining custom container images.
• Local and shared tools: Agents can execute tools locally or interact with workflow-level services, such as LSP servers and MCP clients, shared across multiple runs.
• The runtime interface: An RPC-like syscall API lets agents request inference, invoke tools, and spawn other agents or workflows through the Spine service.
• Identities and permissions: All agents within a workflow share a common identity, while the Spine service authenticates and authorizes their requests against the workflow’s capabilities.

This design is a deliberate trade-off between isolation, resource efficiency, and ease of cooperation. Rather than isolating every agent as an independent security principal, Spine treats the workflow as the trust boundary.

There’s a lot more to unpack here, particularly around sandboxing, resource management, and the runtime interface. I’ll explore those architectural decisions in dedicated articles.

###What’s next?

I’m building Spine because I want agentic applications to feel more like traditional software: something you can reason about, inspect, reuse, and distribute.

I don’t think the answer to every problem is to give an agent more autonomy, more tools, even whole computers, and slap a guardrail model on top. Sometimes the right solution is to let an agent make decisions. Other times, it’s to explicitly define the execution flow, isolate resources, and control how components interact.

Spine is my attempt to bring these two approaches together.

Workflows provide the structure. Agents provide the reasoning. The runtime provides the isolation, capabilities, and infrastructure needed to make the whole thing work.

There’s still plenty to explore, and so much more I haven’t touched upon here. I’m looking forward to exploring and sharing more soon.

Thank you for reading this far!