This page states the product ambition. The delivery status records implementation, dated observations, named checks, and known gaps.
One project workspace for people and agents
A person opens a project and works with an agent on what it is trying to accomplish. Conversation, plans, workflow definitions, runs, decisions, and resulting artifacts remain connected. The project retains the reasons behind its current shape.
The person directing the project understands its progress without writing Go or reading agent transcripts. Engineers and agents author the workflows that carry out the work. Both groups use the same project view.
From an idea to dispatched work
A person describes the desired work to a conversation agent. The agent discovers the appropriate workflow, supplies its inputs and starts it. The person does not need to select a workflow in a launch form or learn its invocation syntax. An accepted run appears as a linked event in the session and as a new tab without taking focus; its origin and invocation remain inspectable.
Workflow guides and diagrams are there to help people understand the work and develop workflows. Viewing one does not require starting it, and reading one is not a prerequisite for an agent to run it. Manual launch remains a secondary route. The person can inspect, steer and review the resulting work.
These outcomes are registered as Agents start workflows and Understand a workflow in the promise inventory. Both are partially implemented with validation unknown; their presence in a design or in source is not proof that the complete experience is ready.
Choose agents without changing workspaces
The project is independent of any one model provider or coding-agent application. People choose among supported models and harnesses for conversations and workflow roles, while project intent, history, and artifacts stay available. Each upstream service has its own capabilities and session limits; Gimbal makes those differences understandable.
Workflow execution also admits a backend the project or organization owns. Gimbal’s agent, context, observation, and control semantics remain recognizable across local and external execution.
Edit workflows together with an agent
The ambition is best-in-class human-agent collaborative workflow editing. A person points to a step in a readable workflow diagram, discusses it with an agent, and sees the agent’s source edit reflected in the diagram. Prompts, scoped context, branches, and the source of each step are available in place. The person and the agent look at the same part of the same workflow.
The delivery status records the merged design-time loop and its evidence. No comparative evaluation has established “best-in-class.”
Speak, show, and inspect
Voice gives a person another way to shape work and give direction, especially while thinking aloud or away from a keyboard. Diagrams, documents, images, and other visual artifacts are shared references for the person and agent. Workflow runs connect those artifacts to the decisions and results that produced them.
The delivery status distinguishes today’s interactive workflow diagrams from voice and shared conversation work around visual artifacts. The first useful slices of that broader experience still need to be defined and evaluated.
Workflows belong to the project
A team keeps its workflows in its own repository as readable code. Gimbal discovers them, shows their source-derived diagrams, starts them, and exposes the same observations and controls available for built-in workflows. A project changes its workflow without rebuilding one shared Gimbal distributable.
The language and loading mechanism are open questions. Project-local compiled Go could preserve ordinary Go; interpreted Go or a scripting interface might reduce build friction but would need to preserve workflow meaning and the source view. No architecture has been chosen.
Work runs beyond one machine
The longer-term workspace dispatches work to another machine or a networked execution backend, then exposes observation and control in the project. Displayed state reflects the actual remote work, including failures and lost contact. Local conversation, design, dispatch, and oversight come first. The delivery status records the current backend boundary.
Anti-goal: cancellation accounting and strict timing
We choose to exclude all strict timing requirements and journaling of cancellation completeness within the workflow orchestrator. It must not produce cleanup receipts, release-confirmation ledgers, or a retained retry-cleanup lifecycle. Timings may be logged in place as observations; they must not become requirements, enforced thresholds, or acceptance gates.
The central server requests cancellation through the selected message bus. Transport owns delivery; executing nodes cancel their work; local resource owners eventually release resources. The central orchestrator does not retain a terminal run to confirm every external release. An unreachable external operation may require manual intervention; report the failure rather than creating reconciliation machinery in the core.
Normal scope completion still collects final agent-turn and command results, saves usable results, and removes contextual data when its scope ends. During cancellation, exact UI delivery cutoffs, immediate closure, complete late diagnostics, and precise shutdown timing are not promises. Final diagnostics may be lost. Verification addresses actual operation: normal execution, saved-result readback, cancellation, and eventual resource release. This anti-goal supersedes earlier fixed shutdown deadlines and retained-cleanup requirements; it does not claim that an implementation has been validated.