Flowplane
A workflow engine for AI-assisted software development with isolated execution, durable work tracking, and persistent knowledge.
- Audience
- AI-assisted developers and technical teams
- Role
- Architect and principal builder
Autonomous development needed stronger boundaries and memory.
Long-running coding work required more than a prompt loop. Teams needed explicit workflows, isolated execution, durable plans, and knowledge that could distinguish decisions, patterns, lessons, and superseded context.
A workflow engine joined orchestration, isolation, and knowledge.
I built a substantial Go system combining an agent runtime, pluggable workflow engine, durable work and knowledge tracking, Git worktrees, container isolation, and a terminal interface. Decisions and lessons could be searched, related, and superseded as the work evolved, while central persistence made progress visible across workstreams.
What this case can and cannot prove.
Public evidence is classified so a private implementation, deployed system, measured result, and advisory artifact are never presented as equivalents.
- Context
- Several coding-agent efforts collided in one local development environment, and work could not be inspected or resumed once a session ended.
- Clifford's role
- Architect and principal builder.
- Evidence
- Implemented private system, alongside a sanitized architecture snapshot captured August 13, 2026. The snapshot shows the central operating view, the workflow control, the persistent decision graph, approval state, isolated project sandboxes, and GitHub as the authoritative repository, without exposing source code, repository details, or private work data.
- What changed
- Moving persistence out of the local environment and into a central database made parallel workstreams legible beyond one session. Progress, dependencies, decisions, and approval points became reviewable across roles, and a long implementation loop can be inspected and resumed after disconnecting. Worktrees and containers isolate each effort, and GitHub remains the authoritative source-code repository.
- Not claimed
- Public adoption, measured productivity improvement, financial impact, and public source availability are not claimed.
- Implemented private system
- A working Go implementation confirms the agent runtime, workflow controls, durable work tracking, isolated workspaces, knowledge system, and terminal operating surface.
- Public artifact
- Sanitized architecture snapshot captured August 13, 2026. Documents the operating relationships without exposing source code, private work data, or repository details.
The control plane connects oversight to isolated work.
This sanitized view records the implemented relationships without exposing source code, private work data, or repository details.
Captured August 13, 2026
Workstreams, progress, dependencies, and approval state
Research · Plan · Implement · Verify
Evidence, constraints, prior choices, dependencies, and work state move forward together.
- Engineer
Review · approve · continue
- Designer
Review · approve · continue
- Leader
Review · approve · continue
Worktrees and containers separate concurrent implementation.
Central persistence made parallel agent work visible and resumable.
These outcomes describe what the implementation made possible. They are not generic product promises.
Created an end-to-end operating surface for AI-assisted development workflows.
Isolated execution from the host environment while preserving work state.
Retained decisions, patterns, learnings, context, and plans for future sessions.
Central state made isolated work legible across roles.
The system was organized around an operating sequence people could understand, govern, and improve.
Orchestrate
Coordinate work as explicit, durable workflows.
Isolate
Run implementation inside controlled container boundaries.
Track
Keep plans and work state visible through execution.
Learn
Preserve and evolve the knowledge produced by the work.
The decisions, reversals, and evidence behind the result.
Each movement records how the work changed as evidence replaced the starting assumptions.
Outcome
The intended outcome was a controlled development environment where coding agents could work with meaningful autonomy while execution, work state, workflow, and durable knowledge remained connected. A central requirement was preserving the decision trees and graphs agents worked through across research, planning, implementation, and verification. Later phases needed the reasoning, constraints, and prior choices that shaped the implementation, not only a summary of the next task. This outcome was selected over raw code-generation speed because faster execution without decision continuity would still leave agents rediscovering context and making inconsistent choices across phases.
Diagnose
The presenting problem appeared to be coordinating several coding-agent work efforts. In practice, those efforts overlapped and collided in the same local development environment. This was before isolated worktrees had become a standard part of agent-assisted development, so the local workspace remained the source of truth while multiple efforts competed to change it. The collisions exposed a broader operating problem. The environment needed to be centralized for remote access, long implementation loops after the user disconnected, and resumption with the same work state and decision context.
Design
One option was to continue combining a coding-agent command-line tool, terminal multiplexing, remote-access tooling, and an external task tracker around a shared local workspace. That approach was rejected because it was clumsy to operate and provided no unified view of the work moving through the system. The fragmented toolchain also allowed users and agents to circumvent RPIV. Keeping the separate tools would have preserved file collisions and fragmented state while making the operating method optional precisely when long-running or parallel work required it most.
Decide
The initial persistence decision favored a database contained within the local development environment. That fit the early model of one environment serving as the source of truth, but it limited visibility once Flowplane needed to coordinate several workstreams. The decision changed in favor of a central database. Central management and leadership needed one place to inspect workstreams, progress, dependencies, and operating state across development environments. The reversal was driven by the need to make parallel work legible and governable beyond the individual agent session or local workspace.
Execute
Flowplane deliberately did not replace GitHub, the coding model, or the developer's repository. GitHub remained the authoritative source-code repository, while Flowplane governed how coding agents researched, planned, implemented, and verified changes against it. Worktrees and containers isolated individual work efforts. Each project or workstream received a sandbox so its implementation loop could proceed without overlapping another effort or changing the main workspace directly.
Transfer
Flowplane transferred more than a task description between stages. As work moved through Research, Plan, Implement, and Verify, the system carried forward the decision graph, supporting evidence, constraints, dependencies, work state, and implementation history. The same durable context supported handoffs between people and agents, and between different agents or developers. A leader could disconnect during a long implementation loop, inspect progress centrally, and resume without reconstructing the session.
Measure
The unexpected result was the degree of operational and business control the workflow created. Flowplane was initially expected to coordinate coding-agent work, but its more consequential value was making large specification efforts visible and governable across roles. That result changed the product direction. The centralized operating view and workflow controls expanded so engineers, designers, and leaders could review, approve, and manage substantial specification work together.
I built Flowplane as infrastructure for responsible autonomy.
The architecture reflects a consistent principle in my work: give agents enough structure to move quickly while keeping execution, evidence, and decisions understandable to people.
Working through a similar decision?
Bring the desired outcome, the systems already in place, and the constraint keeping the work from moving. The first conversation will test whether the problem is architecture, ownership, data, capability, or execution.