Why NautFlow
I did not set out to build a product. I set out to stop being annoyed by my own desk. This is the honest version of how a terminal turned into an agent workspace, and why the part I am proudest of is the boring one nobody asks for until the day they need it.
Being fed up is a legitimate reason to build something
This started about a year ago, sometime in early 2025. My day ran across Warp, Pieces OS, iTerm, Cursor and VS Code, and every one of them was good at something and wrong for me in some specific, grinding way.
Warp had an idea I loved. I do a lot of operations work, and a lot of it is infrequent. A migration I run once a quarter, where the hard part is not the work but remembering the right series of commands, in the right order, from three months ago. Having a library of my own commands, right there, was genuinely the right answer to a real problem. And then at some point it was too simple for what I was doing with it, and I outgrew the thing I had liked.
VS Code had the opposite failure. Too much of everything, all the time, reaching for my attention. I did not want an IDE with a terminal in it. I wanted to work in the terminal, and have the other things arrive when I asked for them.
I tried the terminal-native AI tools too. Some were excellent early on. I used one heavily for a while and then stopped, not because it broke, but because the gap between what I wanted and what it did stopped closing.
Then one day the drive arrived fully formed. I did not want multiple tools open any more. One, plus maybe a browser, and that is what my workspace should look like. So I started building xNAUT.
So I built my own terminal
The decision was less dramatic than it sounds. What the heck, let's just try. I built xNAUT as a terminal first: my rules, my features, cut exactly to how I work. Then I used it every day, which is the only design process I actually trust. Things I needed got built. Things I thought I needed turned out to be nonsense and got deleted.
A tool you use every day tells you the truth about itself. A tool you demo occasionally tells you what you want to hear.
Cmux is worth naming here, because it had the feature I kept wanting: a browser sitting next to the coding terminal, so you can see the thing you are building while you build it. Right instinct. In practice the browser side had enough problems that I never really settled into it. That combination of a good idea I could not rely on is what usually ends with me building it myself.
The part where it went agentic
xNAUT had gone agent-first a while before, mostly for security audits and that kind of long, methodical work where you want something patient doing the reading. Extending it into the workspace I actually wanted, everything in one place with agents included, was a smaller step than starting over.
Then I ran into the enterprise tools. Devin and that class of product: about $500 a month, and what you get for it is a flow. Stages. Something that walks the work from idea to finished rather than just answering you. The flow was the good idea. The execution did not convince me, and it could not do what I already had running: several agents at once, in parallel, on the same project.
And $500 a month is steep. So I thought: what if I build something like that, for free?
My multi-agent support at that point was early and far from perfect, but it worked. What I did not have was the flow around it: something that plans, splits the work, checks it, and only then calls it done. Not a prompt that emits files and hopes. So I built my own version of what that flow should be, and that is NautFlow.
The feature I did not want to need
Last year a client told me I had not worked the hours on my invoice.
That is an unpleasant conversation to have, and a worse one to lose, and the thing that makes it unwinnable is that ordinarily you cannot prove it either way. You have your word, they have their doubt, and the relationship takes the damage regardless of who is right.
So I built the proof into the tool. xNAUT keeps a verifiable record of what actually happened in the terminal. It is a log you can hand to someone, and it holds up because it was written as the work happened rather than reconstructed afterwards. Nobody has to take my word for it now.
That turned out to matter more than I expected, and for a reason I did not anticipate. It is not only about my hours any more. When agents do the work, somebody is going to ask what they did; a client, an auditor, a regulator, or you at 2am wondering why a file changed. Being able to show exactly what every agent did, step by step, is going to be a requirement in plenty of domains long before anyone writes it down as one.
I built it because one client doubted me. It stayed because agents make that question normal.
Where it actually is
Not finished. I want to be straight about that, because the temptation with a post like this is to describe the destination and let you assume you have arrived. NautFlow is getting strongly there, and there is a good deal I still want in it. It ships when it is right, and you can watch it happen. The changelog is unusually honest for a product page, including the parts where we got something wrong and said so.
But the shape is real, and it is the shape I wanted from the beginning: one place, my rules, agents that do actual work in parallel, a flow that checks them, and a record that proves it.
This is the first in a series. The next posts get specific about what NautFlow can do, and how each piece works.
Every tool I listed here is one I chose to use, and most of them are good. Outgrowing something is not the same as it being bad. It usually means it was good enough to take me to the point where my needs got specific. I would rather build the last ten percent myself than complain that nobody built it for me.
André