Postmortem · 5 min read
What We Learned Building Darkmatter Agents
It began as a client project and became a product we tried to sell. What we got wrong about workflows and agents, and where the attention goes now.
Darkmatter Agents started as a client project. It was never meant to be a product.
We needed to automate a specific set of work for a client, so we built the thing that did it. It worked. That client still runs on it today and will keep running on it for now. Along the way it also became what we use for our own company-wide automation, and it has stayed that way. Most of what happens quietly inside Darkmatter happens through Agents.
At some point we decided to open it up. The reasoning was ordinary. We had built something useful, other people had the same problems, and a B2B SaaS around it looked like it could be a business. So we put a signup on it and started selling.
Workflows are good. They are not agents.
Early in 2026 the ground moved under us.
The industry was still arguing about definitions at the time. What counts as an agent, what counts as a workflow, whether the distinction is real. We looked at what we had actually shipped and answered our own question. We had built workflows.
Workflows are good. When the steps are known in advance, a visual graph of blocks and connections makes the logic legible and repeatable, and that is worth having. But a workflow decides everything up front. An agent does not. It runs in a loop, reads context, picks a tool, looks at what came back, changes its approach, and keeps going until it reaches an outcome or needs a person. We had made the workflow the primary object. The agent should have been the primary object, with workflows available where determinism was wanted.
Five research providers, twenty blocks, and every branch drawn before anything runs. An agent would work out which sources were worth the trouble. This asks all of them, always, because we decided in advance that it would.
Trying to have both made it worse
We did the obvious thing and put the agent on the canvas. An agent in the loop, as a block, inside the same visual arrangement as everything else, so both models could live in one picture.
The agent, offered as one more block among the others. Everything after this had to make sense for two models at once.
It got convoluted quickly. Two mental models sharing one surface meant every feature had to answer for both. The product became harder to explain, harder to maintain, and harder to keep organised.
That was the real signal, and it was not a metric. We were spending our attention holding the thing together instead of making it better.
Inbound is not traction
Interest was never the problem. We had plenty of inbound. What we did not have was enough of it turning into people who stayed.
Six of a hundred and forty-five agents ever used, and a third of all runs failed. Both numbers are the section title.
The breadth we thought was the product. Every tile is a surface to maintain, and none of them is the reason anyone stayed.
The market we had walked into is full, and it is full of good tools. We are happy to say that plainly.
We are not stopping because catching up would be hard. Building this kind of software is fast now. We could rebuild what we have in about a week, and so could most people, which is a large part of why the market looks the way it does. What it costs is focus. A general purpose agentic SaaS wants the whole company aimed at it, every day, and we want ours aimed somewhere else.
Meanwhile the work we were most interested in was the work we kept postponing. Putting AI into the physical world, into hardware, into problems where the hard part is not another integration.
What we actually built
Agents was never only a browser product, and this is the part we are most pleased with.
The same system ran three ways. There was the visual editor, which is the part people saw. There was an MCP server, so other agents could drive it as a tool. And there was a CLI, a normal program you could run on a plain Linux machine with no browser involved at all.
There is an instance still running on a machine we are not going to tell you about.
What it taught us
The durable lesson is about visual language for programming.
Agents are hard to trust when their work arrives as a paragraph of text or disappears into a log. Through the canvas, the execution states and the connections between blocks, we spent a long time on how to show what a system is doing: which tool it reached for, where data went, when a person needed to step in.
We were wrong about forcing the agent into a fixed graph. We do not think we were wrong about the interface. Dynamic software still needs to be legible, and a picture can carry plans, tool calls, dependencies and approval boundaries better than a terminal or a chat window. That thinking goes into what we build next.
The second lesson is cheaper to state and more expensive to learn. Build the thing you need, and be honest about whether that is the same as a thing to sell.
What happens now
We are not taking new users for Darkmatter Agents. The product pages are gone and this postmortem is what sits in their place. Existing users can still sign in.
It keeps running for the client it was built for and for our own automation, which is the arrangement it was good at from the beginning. We keep it because it is useful and because it keeps that work under our control.
We are putting the attention somewhere more specific instead. The technical work behind Agents carries over: tool use, permission boundaries, observability, and visual ways of showing what a machine is doing. As with everything at Darkmatter, we built it carefully, and the parts that were wrong were worth being wrong about.
