Flowness
Work persists. Agents assemble.
Flowness is a work-centered runtime for agentic software engineering.
It keeps engineering work alive across changing agents, sessions, contexts, and plans, then compiles the next execution from the current state of the world.
Humans define the goals, rules, judgments, and irreversible boundaries. Agents organize and act within them.
Flow is primary. Work gives it an address. Agents are temporary forms of execution.
A session may end. The work keeps its name, its history, and its next question.
简体中文 · Run the public proof · Flow Engineering · Architecture · Failure Atlas
Public status: today’s Open Alpha ships a runnable, deterministic Assurance Kernel for execution → independent review → targeted rework → fresh acceptance. The broader work-centered Flow runtime is present as a substantial inspectable mechanism set and private dogfood system, but its new public hero demo and a complete organic public end-to-end run are not shipped yet. See What is actually available.
The next unit of software engineering is not the session
Interactive coding agents are getting stronger. The bottleneck is moving.
A serious engineering task may outlive:
- the agent that started it;
- the context window that explained it;
- the first plan that organized it;
- the graph that routed it;
- the pull request that materialized one part of it.
Most agent systems still organize around one of those temporary containers. Flowness organizes around the flow.
session-centered: choose and supervise the next agent session
graph-centered: choose the next node or transition
flow-centered: read the work's current state,
determine what it now needs,
and assemble the next execution around it
Agent does not own the flow. The flow temporarily assembles an agent.
From Harness to Flow
These engineering ideas are not competitors. They expand the object being engineered.
| Engineering focus | What it makes explicit |
|---|---|
| Prompt Engineering | The instruction given to a model |
| Context Engineering | The local world the model can see now |
| Harness Engineering | The environment, tools, rules, and feedback that let one agent act |
| Loop Engineering | How action observes, corrects, retries, and improves over time |
| Graph Engineering | How multiple execution units connect, branch, merge, and coordinate |
| Flow Engineering | How work itself moves through changing execution structures and keeps finding a valid next step |
A useful shorthand:
A loop is one execution unit unfolding through time.
A graph is many execution units organized in space.
A flow is work moving through a succession of graphs—and sometimes changing the graph itself.
The 30-second runtime model
flowchart TD
E[World event or human intent] --> T[Persistent work state and truth]
T --> P[Project the current world]
P --> C[Compile the next execution]
C --> A[Agent + context + tools + graph + gates]
A --> X[Action / finding / effect]
X --> V[Verify, commit, activate, or reject]
V --> T
T -->|conditions not ready| W[Wait without losing the work]
W --> T
T -->|upstream assumption invalid| R[Reflow the affected slice]
R --> P
Flow is not messages moving between agents. It is work moving through changing execution assemblies.
A healthy flow must do more than “keep running.” It must:
- continue instead of silently dying;
- preserve identity and interpretation instead of drifting while appearing green;
- adapt when the world invalidates an assumption;
- commit outputs into the system that actually consumes them;
- close in reality, not merely in an agent’s final message;
- compound judgment so the same structural failure becomes less likely next time.
Six differences that matter
1. Flow first, agents second
The Flow is primary; Work is its addressable projection — it can split, merge, or be superseded, and the underlying facts live across Objects, Events, Obligations, Judgments, Evidence, and History. Work is the interface for finding that state, not a god object that holds it. Executors remain replaceable attempts, not the source of truth.
2. Graphs are projections, not prisons
A graph represents the work’s structure at a particular state and evidence cutoff. A finding, superseded concept, new dependency, or owner decision may invalidate part of that graph and require a new one.
3. Context is compiled from the current world
A Context Capsule is not a handoff summary. It is a bounded execution view assembled from authoritative state, active concepts, obligations, evidence, scope, and the action being attempted.
4. Reflow is deeper than retry
re_execute → repair → replan → re_engineer → redesign → re_interview
The system should return to the nearest layer that must actually change. Repeating the last node is not a substitute for locating the broken assumption.
5. Human control is infrastructural, not conversational
Humans do not need to watch every transcript. They define the system’s constitution:
- goals and anti-goals;
- concepts and judgment cases;
- obligations and red lines;
- authority and irreversible boundaries;
- acceptance criteria and promotion rules.
The system may self-organize within that field. It may not silently invent the field.
Human out of the session, never out of the constitution.
6. “Done” has multiple reality states
Built ≠ Integrated ≠ Activated ≠ Accepted
Code can exist without being wired. A path can be wired without receiving organic use. Organic use can occur without the responsible owner accepting the result.
Flowness treats those as different states, with different evidence.
Run the public proof
The current Open Alpha ships a deterministic Assurance Kernel Demo. It demonstrates one narrow but load-bearing part of a trustworthy Flow:
- three isolated producers;
- a content-bound candidate;
- independent judges separated from producers;
- a mandatory finding that survives rework;
- targeted repair rather than full rerun;
- a fresh verdict over the successor candidate;
- an independently inspectable trace.
No model account is required.
git clone https://github.com/Towow-ai/Flowness.git
cd Flowness
python3.12 -m venv .venv
.venv/bin/python -m pip install -e ./oss/flowness-oss-harness
.venv/bin/flowness-oss open-alpha-demo \
--output /tmp/flowness-open-alpha-demo
.venv/bin/flowness-oss open-alpha-demo-inspect \
--run-root /tmp/flowness-open-alpha-demo
A successful inspection ends with:
{"state":"verified","producer_agents":3,"round_1":"blocked","targeted_rework":"verified","round_2":"accepted"}
This proves the acceptance kernel, not the entire Flow Engineering thesis. The new “Work Outlives Agents” hero demo is specified in docs/demos/HERO_DEMO_SPEC.md and remains [DESIGNED] until it is implemented and bound to a release artifact.
What is actually available
Flowness uses evidence-status labels so architecture, dogfood, design, and shipped behavior are not blurred together.
| Status | Meaning |
|---|---|
[RUNNABLE] |
Reproducible from the public repository |
[INSPECTABLE] |
Public code, tests, or contracts exist, but not a complete public path |
[DOGFOOD] |
Used or observed in sustained private work; public evidence may be sanitized or incomplete |
[DESIGNED] |
Specified, or present as a pure component, but not connected into a complete runtime loop |
[OPEN QUESTION] |
A research target, not a capability claim |
Public surface today
| Capability | Status | Public evidence |
|---|---|---|
| Execution → review → targeted rework → fresh acceptance | [RUNNABLE] |
Open Alpha demo and inspector |
| Append-only events, projections, envelopes, gates, selected orchestration and closure mechanisms | [INSPECTABLE] |
harness/src/towow/, public core, tests and conformance code |
| Design and engineering-spec objects, gates, CLI, and partial forward/reflow routes | [DOGFOOD] / [INSPECTABLE] |
selected public schemas/docs; private runtime is partial |
| Full organic goal → accepted outcome on a new public target | [OPEN QUESTION] |
not yet demonstrated publicly |
| WorkView CLI and “Work Outlives Agents” demo | [DESIGNED] |
public specifications in this documentation set |
| General cross-domain Flow runtime | [OPEN QUESTION] |
software engineering is the first proving ground |
See the claims and evidence register · Versioning tracks
The software-engineering Flow profile
Flowness’s first high-assurance domain profile progressively turns vague intent into falsifiable engineering work:
goal
→ investigation / interview
→ problem and requirements
→ design alternatives and decisions
→ engineering specification
→ stable engineering consensus
→ dependency-aware plan
→ isolated execution
→ independent validation
→ targeted reflow
→ evidence-backed closure
This is a Flow profile, not the definition of every Flow. Small, reversible work should take a shorter route. High-impact work earns deeper design, engineering, authority, and acceptance gates.
What the runtime is made of
1. Human Constitution
goals · ontology · judgments · obligations · policies · red lines
2. Persisten