Why it exists
A multi-agent process is a program. It has lifetimes, ownership, concurrency, cancellation, and failure, and it needs someone to be able to read it six weeks later. Frameworks that express the process as configuration or a graph DSL give up the one tool that already handles all of that well: a programming language.
Gimbal keeps the process in Go and supplies only what Go does not have: agent sessions with owned lifetimes, context that reaches the agents in a scope, planner-directed loops, supervision of a live turn, and a record and a live view of all of it.
What it refuses to do
- No named tactics. There is no
BakeOff, noCritiqueRound, no retry policy. Those are a few lines of Go in the workflow that needs them, where they can be read and changed. - No prompt assembly. A prompt is a constant or an embedded file. Data reaches the agent as scoped context.
- No models in workflows. Workflows name roles. Runs bind them.
- Harness behavior stays with its adapter. External harnesses retain their tools, sandboxes, and sign-in. The Pi adapter runs its engine inside Gimbal and uses a Router key.
- Consumer-owned infrastructure. The local runtime and console can run on loopback. Consumers choose their own orchestration and deployment; Temporal is one demonstrated target, not a mandatory dependency.
Workflow and infrastructure
Ordinary authored Go remains authoritative for control flow. Gimbal supplies shared agent behavior, scoped context and lifecycle semantics, and source/event meaning for observation and control. Consumers own their compiler, emitted orchestration, worker placement, storage and deployment policy.
A simple CLI workflow should run without required Docker or network infrastructure. Individual tools can declare their own service dependencies. A multitier host has additional obligations: isolate concurrent stacks, route each app to its database, separate workspaces and data, and handle startup failure, cancellation and cleanup. See the local and multitier requirements.
One design candidate is a team-defined profile such as web app plus Postgres. A workflow selects it and receives explicit app/database handles to place commands and agents. This is not an implemented universal API. Plain processes, systemd, Docker networks and Kubernetes remain infrastructure choices.
A bounded same-build replay result does not establish arbitrary workflow-version migration or restoration of live agent sessions. A consumer must retain a compatible generated build for its active runs or drain them before replacement, and state its own restart and update policy.
Five terms
- Run
- One execution of a workflow and its record on disk.
- Scope
- A named piece of a run. It ends when its function returns.
- Session
- One agent conversation, on one harness, in one working directory.
- Role
- A kind of cognitive work. A run binds each role to a harness, model, and effort.
- Group
- A named set of concurrent child scopes.
Waitjoins them.
Not an Attractor implementation
Gimbal is a reaction to the work around Attractor, not an implementation of it. It does not adopt Attractor as its architecture, product plan, or vocabulary. The lesson kept is simple: keep the workflow in code a person can read, and make the agent work observable.
Status
Gimbal is young and moves quickly. Seven built-in workflows and five harness adapters ship in the reviewed revision. The public shared compiler support has a bounded consumer example; broader target independence and visual quality still need representative evaluation. The October 8 product assessment records current checks, live console observations, and known outcome gaps. Authoring a new built-in CLI workflow happens inside the Gimbal checkout; the library itself is usable from any Go module. The programming contract is the Godoc: go doc -all github.com/tylergannon/gimbal.