Flowtrace turns an agent session into a graph of files you can re-run
Run a task with AI as a flow of steps you keep, reuse, and refine, not a one-off chat.
At a glance
- What is it?
- Flowtrace is an MIT-licensed TypeScript CLI that runs an agent task as a trace: ordered steps, each writing its output to disk, with per-step re-runs and git history. The idea is sound and the on-ramp is broad, but the README states the mechanism more clearly than it states the operational cost.
- Who is it for?
- Adopt Flowtrace if your agent work is repeated rather than one-off: a recurring research note, a security gate, a memo whose inputs change but whose method does not, and you are willing to keep the trace directory under version control. Do not adopt it for exploratory prompting or a single question, where the step scaffolding costs more than it returns.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 98 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Flowtrace is aimed at: agent work that you have to check or repeat
The README frames the target precisely. A skill run does the whole task in one pass. A chat session grows turn by turn. Both produce a wall of messages, and the README lists four consequences: the thread is too long to follow, a confident wrong answer looks like a right one, one bad assumption forces you to redo everything, and the session disappears into scrollback. It is explicit that this is acceptable for a quick question and a problem for anything you would need to verify or run again, naming buy or sell calls, due diligence memos, and security gates. That is a narrow audience stated honestly. If your agent use is exploratory, the pitch does not apply to you, and the README says so.
How a trace differs from a transcript: steps, files, and a dependency graph
A trace is a flow of steps the agent moves through one at a time, and each step leaves its output on disk. The README's example is a buy or sell decision: frame the thesis, research four angles in parallel, fold them into a valuation, deliver a one-page brief. The parallel branch is the part worth noting, since it implies the step graph is not strictly linear. The reading model is stated directly: the trace is exposed as a graph of files, and the agent loads a step's contract, inputs, and outputs only while working on that step, following explicit dependencies instead of carrying the whole history. The README claims this bounds working context and reduces drift. That is a design argument, not a measured result, and no numbers are given to support it. The grounding claim is more concrete: results point back to the files they came from. The example cards shown are a finance result (price, RSI, MACD, drawdown charts with a passing trend-and-momentum check) and a clinical result (survival benefit HR 0.62 with a Kaplan-Meier curve citing km_curve.png). Both carry the same shape: the finding, its charts, the checks that pass, and the source files.
Steering, resuming, and the evolving trace
The README's steering claim is specific: fix one step and only what depends on it re-runs. That is the payoff of the dependency graph, and it is the single most important behaviour to verify before adopting, because the size of the re-run set is exactly what determines whether editing a mid-flow step is cheap or expensive. Related claims: the run is files and git, so it survives closing the tab, supports stop and resume, and can be handed to a teammate. A screenshot caption describes picking a step in a node map, opening its version history, and travelling back to an older commit to see its state then, with v2 gradient-boost AUC 0.84 against v1 logistic 0.78 used as the illustration. Treat that as a picture of the interface, not as a benchmark. The evolving claim is the most interesting and the least specified: when a step misses its bar, the next version switches to a method that clears it, and the version that passes sticks. The README does not say who defines the bar, how a check is expressed, or what happens when no version passes. Those are the questions I would want answered from the docs directory before trusting the mechanism.
Getting it running, and what the README does not give you
This is where the supplied material runs thin. The README has a Get started section in its table of contents, but the text provided does not include it, and no releases were retrieved. So I cannot give you an install command, a binary name, or a config key from this material, and I will not invent one. What the README does state is the integration surface: it works with the agent you already use, naming Claude Code, Codex, and Cursor. The repository topics list cli, claude-code, claude-skills, codex, cursor, agent-skills, and developer-tools, and the primary language is TypeScript, which together suggest a Node-distributed CLI that installs into or alongside those agents. The on-ramps are documented as four conversions: a skill, a long session, a plan, or a finished run, each turned into a trace. The docs live under docs/trace/README.md. Anyone evaluating this should read that file first, because the root README is a product argument and the trace docs are where the step contract and the run commands would have to live.
The costs the README does not price: files, commits, and re-runs
Every step writing its output to disk means a trace produces a directory of artifacts, and the traceability claim depends on that directory being committed to git. That is the same property that makes the run durable and the property that makes it expensive. Intermediate files accumulate, diffs get noisy, and a trace that runs frequently will produce history you have to manage deliberately. The README does not discuss artifact size, retention, or what belongs in the repository versus what does not. There is a second cost in the same place: the re-run claim is only as good as the dependency declarations. If a step's dependencies are declared loosely, an edit cascades; if they are declared too tightly, a stale output is reused. Neither failure mode is discussed. The README also does not state what happens when a step's output file is edited by hand, which is a natural thing to try and an obvious way to desynchronise the graph from the artifacts.
Where Flowtrace is the wrong tool, and what it is being compared against
The README concedes the first case itself: a quick question. The second is any workflow whose value is in the conversation rather than the artifact, where you are thinking alongside the model and the back-and-forth is the work. The third is a task you will run exactly once, where building the step graph costs more than the run returns. For a comparison, the nearest thing is the plain skill or slash command these agents already support, which the README treats as the starting point rather than the rival: a skill does the whole task in one pass. Flowtrace's difference is that the skill's written steps become a flow of real, checkable steps, each with its own output file and its own re-run boundary. That is a genuine architectural difference, not a wrapper. The trade is that you take on a step graph, a directory of artifacts, and a git history in exchange for the ability to fix one step without redoing the rest. A general-purpose workflow engine such as a DAG orchestrator sits at the other extreme: it gives you scheduling and dependency semantics but knows nothing about agent steps, contracts, or the files an LLM step produces. Flowtrace's bet is that the agent-shaped parts of that problem are the parts worth encoding.
Licence and maintenance
The licence is MIT, stated in the README badge and in the repository metadata, with the licence file at ./LICENSE. MIT is permissive: it allows commercial use, modification, and redistribution, and it disclaims warranty. That is the whole of what I can say from the material, and it is not legal advice; if you are embedding Flowtrace in a product, read LICENSE and your own counsel's view. On maintenance, the last push is dated 2026-06-09, the repository is not archived, and no releases were retrieved, which means there is no published version history in this material to reason about. The homepage is morphmind.ai, and the README links a Discord and an X account, so there is an active project surface. The README explicitly asks readers to star the repository and says stars are how the team decides what to keep building in the open. That is a candid statement about prioritisation, and it is also a reason to check the commit cadence yourself rather than inferring stability from the repository's presentation.
Editorial conclusion
Adopt Flowtrace if your agent work is repeated rather than one-off: a recurring research note, a security gate, a memo whose inputs change but whose method does not, and you are willing to keep the trace directory under version control. Do not adopt it for exploratory prompting or a single question, where the step scaffolding costs more than it returns. Before committing, verify three things against the repository itself: how a step's contract is declared, how the tool decides which downstream steps to re-run after an edit, and what the trace directory looks like in git after ten runs.
Community notes