Founder Note
What It Means to Be an Agentic Solo Founder
At the beginning of July, I wrote that we had built what we call a meaning manifold, or technically, a multiplex supraLaplacian hypermap. It was an internal research prototype and the core mathematical object underneath the Financial Market Meaning Manifold, FM3.
We had built it. Then we began to measure it.
The eigenvalues told us something was wrong. One of the major axes had collapsed. The object organized itself around who was speaking, while losing much of the structure of what they actually believed. A map was supposed to have terrain. Ours had become a line.
For the next several weeks, we struggled to understand why. I was using some of the most capable frontier models available to me, including Opus 4.8 and Opus 5. Each model found a different fault. Each diagnosis sounded plausible. Each fix uncovered another problem that supposedly had to be solved first. We were doing a lot of sophisticated work. We were not making progress.
By then, Hoshi, my Engineering Manager agent, had about ten agents reporting to him across different parts of the build. The problem was beyond what Hoshi could hold in one context window. It was also beyond what I could hold in my own head.
Hoshi needed directors.
We added four director agents beneath him. Those directors needed executor agents to do the work and verifier agents to independently check it. Within a short period, the fleet grew by about twelve agents. Onboarding twelve agents is much easier than onboarding twelve humans. It is still onboarding. They need a role, an identity, a body of documents, a definition of what they own, and a clear understanding of when they are supposed to stop.
Twelve new agents created the next problem. They needed a common operational picture.
We spent several more weeks building one. The common operational picture brought every major node of the problem into the same software surface. Each node had an owner. Each node had a state. Each node showed the work that had to happen before it could move. We used Kahn's algorithm to sort the work by dependency, then counted the downstream nodes released by each completed task. The live board puts a green ring around work whose prerequisites are complete and adds a numbered badge showing how many nodes it will unblock.
For the first time, the whole organization could see the same map. They still kept finding new reasons to work on something else.
The more capable the model, the more capable it was of finding a reason to delay the task. Give an agent a specific problem and it might identify a fault in one of the assumptions. It would begin solving that fault, find another precursor beneath it, and then turn to that problem. The work became an endless chain of intelligent objections. The original task remained open.
The agents also rediscovered problems we had solved weeks or months earlier. They would derive a new answer without knowing why an earlier decision had been made. Sometimes the new answer was worse. Sometimes it was almost identical. Either way, the organization was spending cognition to recover knowledge it already possessed.
So we built a second structure around the common operational picture: an execution-order framework expressed as a directed acyclic graph, or DAG. Each order moves through a fixed rail: frame the problem, determine whether it can actually be executed, revise the order, reconcile it against the existing system, execute, verify the code, and verify that the result meets the original acceptance conditions.
The execution DAG did three things. First, it repeatedly grounded an agent in the existing research, decisions, and evidence before allowing execution to begin. Second, it established exact start conditions, stop conditions, and achievement gates for each node. Third, it captured what the organization learned during execution so the next agent would inherit the result instead of rediscovering it.
Then the system found the problem.
The dependency map showed that one unfinished node had thirteen downstream dependents. During the grounding phase, we discovered that several of its own dependencies had never been documented. We tested those dependencies directly. One of those tests exposed a fundamental error in the construction of the graph.
Months earlier, we had used a temporary stand-in so the team could continue building while a more complete layer was still under development. We grouped belief statements around the people and institutions making them. The finished graph needed to connect comparable beliefs across different speakers. That replacement never happened. We carried the temporary construction forward through successive builds until the mathematical object reached an internal production-candidate build with it still inside.
That was why the map had collapsed into a line.
We lost six weeks of progress. During those six weeks, we built an organizational cognitive harness that could find the error, trace its dependencies, and preserve the answer once we understood it. If this construction error had not stopped us, another undocumented dependency eventually would have.
Twelve more agents gave us more cognition. They also created more context to coordinate, more assumptions to expose, more work to verify. By the time the common operational picture reached 96 nodes and 153 edges, my job had changed. I stopped trying to personally hold the entire technical system in my head. I started building the organizational system that allows one human and a fleet of agents to hold it together.
The mathematical map failed because we had built it around a temporary stand-in. The common operational picture showed us the one node with thirteen downstream dependents. The execution DAG forced us to ground the work and test them.
We still have to rebuild the meaning manifold. This time, the organization building it is capable of understanding why.