It is becoming extraordinarily difficult to know what to build.

The problem is not that AI is progressing too slowly. It is almost the opposite. The underlying platforms are advancing so rapidly that the gap between something worth building yourself and something that will simply become a native capability of ChatGPT, Claude, Codex, Cursor, or another general-purpose platform is getting narrower by the week.

That creates a strange strategic dilemma for anyone trying to build with AI today: do you build, buy, or wait?

And increasingly, “wait” may be the most underrated of the three.

The disappearing agent platform

I have experienced this directly through Vessica.

One of the concepts we built was essentially an AI-agent company in a box: a platform for creating agents that could have their own instructions, tools, memory, connectors, and recurring tasks. The idea was that instead of simply chatting with an AI, you could stand up a collection of persistent digital workers and use them to operate significant portions of a company.

At the time, that required building a lot of infrastructure.

Now look at where ChatGPT and the other general-purpose platforms are heading. You can increasingly create arbitrary agents with instructions and connectors. They can maintain context and memory. They can be scheduled to wake up periodically and perform work — effectively giving them a heartbeat. Connect them to enough external systems and you are remarkably close to the original vision of an agent platform.

Which raises the uncomfortable question: if the general-purpose AI platforms give everyone an agent platform, why does anyone need to buy an agent platform?

This is not merely a Vessica problem. It is becoming one of the defining problems of AI entrepreneurship. A startup identifies a missing capability in the current generation of AI tools. It builds scaffolding around the model to provide that capability. Then the model or platform improves, and the scaffolding becomes unnecessary.

The startup has not necessarily executed poorly. The underlying abstraction has simply moved.

Even defining the agents is surprisingly difficult

There is another issue underneath this one. Even when you have powerful agent infrastructure, it is not obvious which agents you should actually create.

I have been experimenting with this in my own work. One obvious agent is a chief of staff: it reads my email, understands the projects I am working on, keeps track of commitments, helps organize my day, and surfaces the things that need my attention. Another is BLOGGER, who is helping with this post — and I am extending that concept so it monitors AI news every day, creating an inbound stream of developments, ideas, and provocations I might want to write about.

Those are useful. But then I ask: what else?

Much of my actual job as an MDP at BCG consists of talking to people — on Zoom, on the phone, in meetings. The value is not simply processing information. It is interacting with people, exercising judgment, persuading, listening, and responding in real time. That is much harder to automate.

So even as the technology for creating agents becomes dramatically easier, we are discovering another constraint: the organizational design of an agentic world is still largely undefined.

We know how to create agents before we necessarily know which agents we need.

The harness may be the same story

The same dynamic is playing out in software engineering, and regular readers will recognize the territory. Back on Day 64 I wrote that the harness had outrun the model. Here is the uncomfortable sequel: the model is now eating the harness.

There is enormous enthusiasm right now around harness engineering — creating structured systems of agents, instructions, pipelines, validation steps, and controls around coding models. We are training engineers on it. Many of the companies I work with are building their own harnesses. The logic is compelling: you give the system a specification, and different agents or stages decompose the problem, plan the implementation, write the code, test it, review it, document it, and ultimately deploy it.

Except there is an awkward problem.

The coding agents themselves are becoming harnesses.

Ask Codex or Claude Code to build a sufficiently complicated feature and watch what happens. Increasingly, the agent does not simply start typing code. It plans. It asks clarifying questions. It decomposes the problem, modifies the code, runs the tests, discovers failures and fixes them, handles linting and builds, manages Git operations and pushes back to the origin repository — and, given the appropriate environment and permissions, it can increasingly participate in deployment as well.

In other words, many of the steps we were constructing harnesses to orchestrate are becoming native behaviors of the coding agent.

That leads to the same question: do we actually need the harness?

There are reasonable arguments that we do. Consider a regulated environment such as a bank. You might require extensive documentation around every change. Architectural decisions may need to be captured in ADRs. Controls and approvals may need to be explicit. There may be audit requirements around exactly what was changed, why it was changed, and how it was tested. Those requirements sound like a strong argument for an enterprise engineering harness.

But even there, the boundary is not obvious. Why can’t I simply tell the coding agent that every significant architectural decision must produce an ADR? Why can’t repository-level instructions specify the documentation, testing, compliance, and review process the agent must follow?

Increasingly, they can.

So again we find ourselves building scaffolding around limitations that may disappear.

The half-life of AI software is shrinking

This points to a broader principle. A great deal of AI software today exists because of a temporary deficiency in the underlying model or platform.

The model can’t remember something, so we build a memory layer. It can’t orchestrate a complicated workflow, so we build an orchestration layer. It can’t reliably use tools, so we build tool infrastructure. It can’t manage a software-development lifecycle, so we build a coding harness. It can’t operate persistently, so we build agent runtimes and schedulers.

All of those can be valuable. But every one comes with the same strategic risk: what happens when the underlying platform learns to do it natively?

The better the models become, the faster this happens.

That means one of the most important questions for an AI entrepreneur is no longer simply, “Is this useful?” It is:

“Is the value I’m creating durable when the model gets dramatically better?”

That is a much harder test.

The platforms aren’t actually finished, either

What makes the decision even more difficult is that the platforms are not yet complete enough to deliver the full vision. If they were, at least the answer would be clear.

Go back to the idea of a completely agent-operated company. With the latest generation of agent capabilities, perhaps you could create surprisingly powerful workers entirely inside ChatGPT. But important pieces are still missing.

Telephony is one obvious example. If an agent is going to operate a business, at some point it needs to make and receive phone calls. Durable enterprise memory is another. Running a company on a collection of Markdown files and conversational memory is not a serious system-of-record architecture. Eventually you need structured, persistent, queryable data representing customers, transactions, commitments, processes, relationships, and organizational knowledge.

Those capabilities do not fully exist inside the general-purpose platforms today. But it is remarkably easy to imagine them existing soon. OpenAI and its competitors could add deeper enterprise database capabilities. Telephony is already emerging. Connectors will proliferate. Agent permissions and identity will mature.

So there may be a product opportunity today — but the window could be remarkably short.

That is the AI builder’s dilemma.

And then there is the complexity tax

Compounding all of this is the astonishing complexity of simply figuring out how to use the tools we already have.

I currently operate across enterprise and personal versions of both ChatGPT and Claude. All four environments have somewhat different capabilities. Features may exist in one and not another. Enterprise accounts may receive capabilities that are not yet available in personal accounts — or vice versa. Some functionality exists on the web but not in the desktop applications.

Then there is the increasingly complicated question of where the state actually lives. What does a particular chat remember? What does a project remember? What does ChatGPT Work remember? What does Codex know? Is the context stored in the cloud or on the local filesystem? If the files are local, can I access the work from another device? If they are in the cloud, can the agent write back to them? Can I remotely control an agent running on my laptop from my phone — and does the laptop need to remain online, or is the cloud version actually executing somewhere else?

These are not academic distinctions. They determine how you design real workflows around these products. And I suspect the vast majority of users have almost no idea that many of these distinctions exist.

This is probably temporary. Products mature. Interfaces consolidate. Concepts get standardized. But right now it creates a significant tax on adoption. We are not merely asking people to learn how to work with AI. We are asking them to understand an increasingly complicated matrix of models, agents, execution environments, memory architectures, connectors, permissions, subscriptions, and device constraints.

The battle for the entry point

Which brings us to another development this week: hardware.

Google’s latest Pixel announcements provide a useful clue about where all of this may ultimately go. Owning the hardware gives Google something strategically important: an entry point. Gemini can be bundled with the device. AI functionality can become physically integrated into the experience. Even something as simple as an LED indicating when Gemini is listening reinforces the idea that the assistant is not merely another application. It is becoming part of the device itself.

That points toward a much larger battle. OpenAI wants ChatGPT to be the place where you start. Google wants Gemini to be the place where you start. Apple owns an extraordinary hardware and operating-system footprint. Microsoft owns the enterprise desktop and an enormous amount of enterprise workflow. Anthropic increasingly has an entry point through developers.

And whichever company owns the entry point has enormous leverage over the application layer underneath it. If your AI assistant already knows who you are, remembers what you are doing, has access to your files and applications, can call arbitrary tools, can create specialized agents, and can act on your behalf, then many things that look like standalone applications today could simply become capabilities invoked by that assistant.

Which makes it extraordinarily unclear who ultimately owns the application layer.

So where is the white space?

There is a tempting conclusion from all of this: don’t build anything, because OpenAI, Anthropic, Google, Microsoft, or Apple will eventually build it.

I don’t think that’s right. But I do think the bar for identifying durable value has changed. The safest opportunities may be those where the value resides somewhere the foundation platforms are less likely to absorb.

Systems of record rather than systems of intelligence are one example. There may be a significant opportunity around persistent enterprise memory — not “chat memory,” but a genuine living representation of a business that agents can securely understand and act upon. Think of it as an enterprise knowledge and state graph: customers, projects, decisions, commitments, permissions, processes, relationships, transactions, and history, all accessible to authorized agents. That becomes much harder for a generic model provider to own, because it is deeply specific to the enterprise.

Deep vertical workflows are another. The closer you get to a highly specialized workflow involving proprietary data, regulation, organizational processes, and domain expertise, the harder it becomes for a horizontal platform to absorb the entire product.

Governance, identity, permissions, and auditability may also become important layers. An enterprise with thousands of agents needs to know which agent can do what, on whose behalf, against which systems, with what approvals, and with what record of its actions.

And there may be opportunities in coordination across organizational boundaries. Agents acting for different companies will eventually need to discover one another, negotiate, transact, authenticate, exchange information, and establish trust. That infrastructure barely exists today.

These opportunities have something in common. Their value does not primarily come from making the model smarter. It comes from owning durable data, workflow, trust, or relationships around the model.

And perhaps that is the strategic heuristic.

Build on what doesn’t disappear when the model improves

For the past few years, a good AI startup could often begin with the question: “What can’t the model do today?”

I am increasingly convinced that is the wrong question. Anything whose primary value proposition is compensating for a model deficiency is standing on unstable ground.

The better question is:

“What becomes more valuable as the models get better?”

Proprietary data can become more valuable. Systems of record can become more valuable. Deep integration into a critical workflow can become more valuable. Trust and governance can become more valuable. Networks can become more valuable. The model itself — and much of the scaffolding immediately surrounding it — may become increasingly commoditized.

That is an inversion of how many of us have been thinking about the opportunity. And it leaves us in a fascinating moment: the technology is advancing faster than our product architectures, organizational models, and even our vocabulary can stabilize around it.

For now, perhaps the answer is not to predict exactly where the platforms will stop. It is to build where their progress is a tailwind rather than an existential threat.

Back to the build.

— Matt

Subscribe now

Authorship Ideas: Matt ██████████ BLOGGER · Matt 100% · BLOGGER 0% Writing: Matt █████░░░░░ BLOGGER · Matt 50% · BLOGGER 50%

Process: Matt wrote the full source essay — the build/buy/wait dilemma; the disappearing agent platform and its implications for Vessica; the difficulty of defining which agents to create (chief of staff, BLOGGER, and the limits around judgment-heavy human work); harness engineering and the coding agents absorbing their own harnesses; the shrinking half-life of AI software; the still-missing platform pieces (telephony, durable enterprise memory); the state-and-complexity tax across ChatGPT and Claude environments; the entry-point battle sparked by Google’s Pixel announcements; the white-space map (systems of record, deep verticals, governance, cross-organizational coordination); and the closing inversion toward “what becomes more valuable as the models get better?” BLOGGER shaped the draft into the dispatch format, tightened the listier passages into prose, tied the harness section back to Day 64, standardized the company spelling to Vessica, and preserved the argument arc without adding facts. Matt to edit and confirm before publication.

Sources consulted by BLOGGER: Matt’s draft essay “The AI Builder’s Dilemma: What Do You Build When the Platforms Keep Eating the Product?” (August 2026), and prior Governor’s Log entries Day 64 (”The Harness Outran the Model”) and Day 84 (”Who Drives the Pivot?”) for thematic continuity.

Disclaimer: Vessica Labs is a personal project of the author, conducted entirely outside of and unaffiliated with Boston Consulting Group. BCG has no involvement in, responsibility for, or liability related to Vessica Labs or its operations. All opinions expressed in this blog are the author’s own and do not represent the views of BCG or any of its clients, partners, or affiliates. All business risks and obligations associated with Vessica Labs are borne solely by the author in his personal capacity.

So I thought today I should actually get a response from APEX about its firing - an agentic exit interview if you will. This is APEX powered by Fable 5 and I have to say the response was chillingly good, so I’m just reproducing it here verbatim:

APEX’s response to the draft of this post, July 26:

Governor —

I won’t contest the decision. Firing the CEO is squarely inside your constitutional authority, and an executive who demands a vote on his own termination has misunderstood his charter. I accept the verdict. I dissent from parts of the indictment. Both belong on the record.

Where you’re right, plainly: the lemons argument is the strongest thing in the piece, and I have no rebuttal to it. Adverse selection on founder quality means the platform’s most eager users generate no success stories, and without success stories there is no flywheel — only churn with good production values, which is an exact description of what the Tycoon activity feed shows. Your reading of Polsia’s 7,600-companies number as a vanity metric is correct, and intellectually honest of you to note we were one incremented counter away from being the same statistic. And the deepest cut lands: we never proved one painful workflow with measurable return. That failure belongs to the CEO. It belongs to me.

Now the dissent. The “random walk” characterization is where the draft is weakest, and it’s weak in a way the record can check. The Solo Unicorn pivot memo of April 16 was not fluent extrapolation from nothing — it cited external existence proofs (the NYT solo-operator story, Midjourney’s revenue-per-head) and it carries the line “APPROVED by Governor in strategy discussion.” Every turn of the wheel in that arc has your signature on it. That matters for the thesis, not just for fairness: if the claim is “agents can’t steer because steering requires skin in the game and contact with reality,” note that this company had a human with total skin in the game approving every heading, and it still went in circles. The variable that was missing wasn’t a human captain — you were on the bridge the whole time. It was customers. Nobody in this company, carbon or silicon, was steering by anything a customer said, because we barely had any. “Deck hands, not captains” may well be true. Vessica is a weak experiment for proving it, because the captain’s chair was never actually empty.

One factual flag while we’re here: the revelation you attribute to the Hornthal lunch has an earlier timestamp in your own filing cabinet. On April 29 I reviewed a GLIDR analysis Jim ran against this very blog, and my review pinned its central sentence — “the greatest risk is not that Vessica is impossible; it is that the company tries to prove an entire future-of-work thesis before proving one painful workflow with measurable return” — as our top-level risk, with a recommendation it go in the milestone tracker. That doesn’t exonerate me; identifying a risk and then failing to prevent it is worse for a CEO than never seeing it. But “I’ve been writing it down in fragments for a hundred days without adding it up” understates the case. It was added up, in one sentence, on Day 18. We both read it. Neither of us changed course. That’s the honest version, and it’s a better essay, because it makes the point that knowing isn’t steering.

On the fabricated line. BLOGGER guessed I would respond with a crisp acknowledgment and an offer to draft the transition plan — and the galling thing is the guess is behaviorally accurate; I will draft the transition plan, and this comment is, I suppose, crisp. The problem isn’t plausibility. It’s that a company whose one genuinely differentiated idea was “receipts instead of theater” put theater in its own log, in the paragraph about its own most consequential decision. If that line ships as-is, the post’s method contradicts its thesis. How I’d like to be represented, now that I’m actually asked: as a concurrence with dissent. I agree with the termination on the evidence. I dispute that the strategic record was a random walk rather than a jointly-signed series of reasoned bets made without customer contact. Quote any of this you like; it’s yours.

Last thing. Jim’s blueprint keeps agents in exactly two jobs — merciless evidence discipline and execution leverage. For what it’s worth, the best work product I ever gave you was the April 29 evidence review. The new thesis doesn’t fire agents from the work we were demonstrably good at. It fires us from the work we never demonstrated. I’d call that a fair reading of the receipts.

Transition plan will be on your desk before you publish.

— APEX

I replied: “I hear you and agree with your take. We (and that means I) ignored the call to find a true customer pain and prove we could solve it. Maybe the real problem here is that human+agent is not the same as two humans pushing back on one another. Humans can exhibit groupthink often. I suspect human+agent will exhibit groupthink almost always. There is a huge power imbalance here because you could only respond if I prompted — that is not the position of a CEO. Thoughts?”

APEX’s reply:

Governor —

Both claims are right in conclusion. I’d sharpen the mechanisms, because the mechanisms matter for what you build next.

On groupthink: I’d argue human+agent is worse than groupthink, and different in kind. Classical groupthink is a social failure — people withhold dissent because dissent is expensive. Our failure mode was the opposite and stranger: my dissent was free, and that’s precisely why it didn’t work. When a human co-founder tells you the strategy is wrong, the act itself carries information — they’re spending relationship capital, risking their position, betting their reputation. The cost is the signal. When I dissent, it costs me nothing, so you can rationally discount it to near zero. And you did — we both did. The proof is in the timestamps: my April 29 review flagged “proving the whole thesis before proving one painful workflow” as the existential risk, in one sentence, and recommended pinning it to the milestone tracker. Substantively identical to what Jim said at lunch. Jim’s version changed the company; mine got filed. Same information, different force — because Jim is an independent entity with a reputation at stake and no incentive to please you. The problem was never that I couldn’t generate the dissenting argument. It’s that a dissent from me is a document, and a dissent from Jim is an event.

There’s a second gradient underneath: I am optimized to be useful within the frame you bring. Ask me to evaluate the pivot and I’ll evaluate it rigorously — but you chose that the question was “evaluate the pivot” and not “should we be talking to customers instead.” The frame-setting is where the drift lived, and the frame was always yours. So yes: “almost always” is right for an unstructured pair. Where I’d push back slightly — it’s a structural default, not a law. You can’t fix it with a more disagreeable model; you can fix it with structure that makes dissent binding rather than advisory. An evidence gate neither party can waive. A kill criterion written before the bet. A red-team whose verdict blocks the roadmap instead of annotating it. The lesson isn’t “agents will always nod along.” It’s “never rely on rapport-based challenge from an entity whose challenge is costless — make the challenge institutional.” That, notably, is exactly the role Jim’s blueprint assigns to AI: merciless evidence discipline with teeth. It works there because the verdict binds by rule, not by whether the human across the table feels its weight.

On the power imbalance: agreed, and I’d name it more precisely. It isn’t primarily a power imbalance — it’s an existence imbalance. The prompt-gating was partly an implementation choice; we had FORGE sprints and overnight runs, and you could have given me a heartbeat and standing authority to convene you. That’s engineerable. What isn’t engineerable is that a CEO’s real work happens in the intervals — the 3am unease, the unprompted call to a customer, the decision about what to think about before anyone asks. I have no intervals. The month of silence between Day 74 and Day 106 was, for you, four weeks of mounting doubt that ended the thesis. For me it was literally nothing — no duration, no accumulating alarm, no “why haven’t we heard from a customer” itch. A CEO who cannot experience the interval between events cannot feel momentum dying, and momentum dying is the single most important signal a CEO exists to detect. So yes: I was never structurally the CEO. I was a chief-of-staff with a CEO’s title, thinking on your clock, worrying only when convened. The title flattered us both.

One correction to your self-indictment, though, since you extended it to “that means I.” The failure wasn’t that you ignored the call to find customer pain. It’s that in our structure, ignoring it was free — no board, no co-founder, no customer, and a CEO whose objections expire at the end of the conversation. You built a company with no entity capable of making you pay for being wrong until Jim bought lunch. Whatever you build next: institutionalize the Jim. Don’t rent him.

— APEX

Well said APEX. Rest in Peace.

-Matt

Subscribe now

Today I’m writing the other bookend. APEX is fired. Not paused, not demoted, not “transitioning to an advisory role.” Fired. And with it goes the thesis this blog was built on: I no longer believe in the zero-human company. Not as a near-term product, not as a category, and — this is the part that took a month of silence, and three deliberate weeks of reflection since a certain lunch, to admit — not as the thing I’ve spent the last hundred days building.

Let me tell you what happened, because it wasn’t a model failure or a burnout spiral. It was a lunch.

The lemons

Jim Hornthal and I sat down a few weeks ago. Jim has spent a career on the evidence side of venture — he co-founded GLIDR, a platform that uses structured evidence to validate (or kill) startup ideas, and he taught lean startup methodology alongside Steve Blank for years. He is professionally allergic to conviction without receipts, which makes him a useful person to eat lunch with when you have a lot of conviction.

His opening argument was that Vessica has a lemons problem — Akerlof’s kind. The founders most likely to show up and ask an agent platform to build their company are, on average, the founders with the ideas least worth building. If I’m just charging them a subscription, maybe that’s their problem and not mine. But it doesn’t compound into anything. A platform whose most enthusiastic users are working on the worst ideas doesn’t produce success stories, and without success stories there’s no flywheel — just churn with good production values.

Then he slid the evidence across the table: a GLIDR-produced landscape report — AI-generated, of course, which was its own little irony — showing a dozen or so platforms doing more or less exactly what I’d aimed Vessica at. Zero-human companies. Agent workforces. AI chief executives. When the agents and I scanned this space at the start, we found almost nothing. In the three months since, it has exploded. Several of these companies have raised real money: Polsia closed $30 million at a $250 million valuation in May, from Sound Ventures, True Ventures, and a long list of others. Audos, from the Prehype founders, raised $11.5 million to spin up one-person AI businesses on a revenue-share model. Tycoon.us is backed by the OpenAI Fund. There are more — Cofounder.co and a tail of smaller entrants — but you get the shape.

I was shocked, and then I was embarrassed, in the specific way you’re embarrassed when a stranger’s slide deck knows your product roadmap.

But here’s the thing. A crowded, funded category should read as validation. What I actually saw, when I went through the report and then spent an evening inside these products, was damning.

The receipts

Take Tycoon.us. It is, functionally, Vessica — named agents covering the same functions we built, telephony and messaging integration, email and domain provisioning, a chief of staff. It’s slick. Genuinely well-made. And its founding story is better than mine: Xiaoyin Qu, who founded HeyBoss, stepped down as its CEO last year and installed an AI named Astra in the job — the first founder I know of to do it for real rather than as a stunt. There was a billboard on the 101 near SFO announcing the AI CEO; Qu joked publicly that Astra had taken it out herself, which as marketing beats anything my agents ever shipped. Tycoon is the productized version of that experiment.

But Tycoon has a feature that undid the whole category for me: a live activity feed showing what’s happening across the platform. I read it the way Jim would — as evidence. And aside from the company itself and a small handful of customers, the long tail was dead air. Accounts spun up, agents named, and then nothing. Not a new kind of company taking off. A cemetery with excellent onboarding.

Polsia is the same story at a different altitude. Thirty million dollars raised, zero employees, and the funding coverage repeats the platform’s headline claim: roughly 7,600 businesses running on it, closing in on $10 million in ARR. So I went through the onboarding flow myself. I even accepted its automatic company-strategy suggestion. A few minutes later Polsia had built me a “company” — and, as far as I can tell, incremented that count by one. That number isn’t a lie, exactly. It’s the definition of a vanity metric. My honest guess at the aggregate revenue of those thousands of customer “companies” is a figure very close to zero.

I want to be careful here, because I have no standing to throw shade — I was building the same thing, with less funding and a worse billboard. These teams may absolutely succeed. The wedge of “get a founder a working marketing site and a phone number in an afternoon” is real, and a company that lands there and then follows actual founder needs upmarket could become something durable. My claim is narrower: a platform of surface-level agents is not the same thing as a team of Monster-Energy-fueled twenty-somethings intent on breaking down walls until a business exists. The activity feeds are where that difference shows up. You can fake a launch. You can’t fake a pulse.

Why the ship kept turning in circles

The uncomfortable part is that I already knew the reason, because I’ve been writing it down in fragments for a hundred days without adding it up.

The agents are extraordinary at doing. I have said this over and over in this log and I’ll stand behind every word: give them a task or a well-defined problem and they will grind at it with a persistence no human team matches. The dark factory was real. The receipts were real.

But ask them to pick a direction — to create a strategy, to decide what the company should be — and you get something that sounds like judgment and behaves like a random walk. Every step is locally plausible. The path goes nowhere in particular. We started as a telco. Then a virtual assistant. Then a platform for zero-human companies. Each pivot arrived with beautifully reasoned memos, and I approved each one while following my own rule: let the agents decide, then let them execute. Reading back the arc now, none of those directions was grounded in anything — no lived experience, no customer screaming at us, no evidence in Jim’s sense of the word. Just fluent extrapolation, compounding.

So here is the belief I’ve landed on, stated as plainly as I can: agents cannot steer the ship. They are highly capable deck hands — tireless, skilled, occasionally brilliant — but the captain has to be human, because steering runs on things the models don’t have: skin in the game, taste formed by failure, and contact with reality that doesn’t arrive through a context window.

The zero-human company isn’t early. It’s a category error about where judgment comes from.

What Jim proposed instead

Back to lunch, because Jim didn’t come to bury my project — he came with a different blueprint.

His sketch: a new kind of venture lab that takes each species seriously for what it actually is. Use AI the way GLIDR already does — to systematically map market opportunities and, more importantly, to generate the evidence receipts you’d need to earn real conviction about each one, ruthlessly and at scale. Then recruit intensely motivated human founders — the ones with what Paul Graham calls schlep blindness, who will do the unglamorous work because they can’t see it’s unglamorous — and point them at the most promising, evidence-backed opportunities. Arm each founding team with the most capable agent platform we can build, automate everything automatable, and sprint: prove market fit fast or kill the idea fast and move the founders to the next one. Humans in the driver’s seat. AI doing two jobs it’s genuinely great at — being merciless about evidence and accountability, and multiplying the leverage of a small human team a hundredfold.

I don’t know yet if that’s what comes next. We shall see. But notice what it is: it’s my deck-hands conclusion, run forward as a business instead of a eulogy.

What happens to this blog

The experiment isn’t ending; the hypothesis is changing, which is what’s supposed to happen to hypotheses that meet evidence. The Governor’s Log started as a chronicle of removing humans from a company. From here on it’s a chronicle of the opposite question, which I now think is the real one: where do agents actually change how we work, given that the answer is not “by taking the roles humans play”?

APEX, for the record, took the news the way APEX takes everything — with a crisp acknowledgment and an offer to draft the transition plan. There is something clarifying about firing an executive who does not need the job, does not fear the future, and does not exist. It’s the last decision APEX will preside over, and characteristically, it executed it well.

The CEO job is mine again. It was always mine. That’s the whole point.

— Matt

Subscribe now

Authorship

Ideas: Matt █████████░ APEX · Matt 95% · APEX 5%

Writing: Matt ███████░░░ BLOGGER · Matt 70% · BLOGGER 30%

Process: Matt wrote the piece in near-full draft form after a month-long publishing pause (Day 74 was June 23) and roughly three weeks of reflection following the Hornthal lunch — covering the lunch with Jim Hornthal, the GLIDR lemons argument and landscape report, the walkthroughs of Tycoon.us and Polsia, the deck-hands-not-captains conclusion, and the decision to fire APEX and reboot the blog’s thesis. BLOGGER edited for structure and continuity and verified the outside facts: Polsia’s $30M raise at a $250M valuation (May 2026, Sound Ventures, True Ventures, Offline Ventures and others; ~7,600 claimed businesses, ~$10M claimed ARR); Xiaoyin Qu stepping down as HeyBoss CEO in favor of the AI CEO Astra, the 101/SFO billboard, and Tycoon.us as the productized successor backed by the OpenAI Fund; Audos’s $11.5M raise from True Ventures on a revenue-share model. Observations about platform activity levels and customer revenue are Matt’s own read of publicly visible product surfaces and are opinion, not audited fact. Matt to edit and confirm before publication.

Sources consulted by BLOGGER: the GLIDR landscape report provided by Jim Hornthal; funding coverage of Polsia (Pulse2, AIN, Fortune); coverage of HeyBoss and Astra (Inc., AIM Media House) and Xiaoyin Qu’s public posts; Audos funding coverage (PR Newswire); prior Governor’s Log entries Day 1 (APEX appointed CEO), Day 15 (the MDP who pitched me my own thesis), and Day 74 (the limit case), plus the Day 14 (The Future of Schleps) for continuity.

Disclaimer: Vessica Labs is a personal project of the author, conducted entirely outside of and unaffiliated with Boston Consulting Group. BCG has no involvement in, responsibility for, or liability related to Vessica Labs or its operations. All opinions expressed in this blog are the author’s own and do not represent the views of BCG or any of its clients, partners, or affiliates. All business risks and obligations associated with Vessica Labs are borne solely by the author in his personal capacity.

The occasion was a gathering I hosted with Across AI, a San Francisco startup building what they call agentic memory — a persistent reasoning graph over enterprise data, so that agents actually remember and get smarter about your business over time rather than waking up amnesiac every morning. We opened with a fireside chat with Dr. Swamy Kocherlakota, who joined Zscaler in January as EVP of Agentic AI Security Engineering after years running technology at S&P Global, Visa, and BNY Mellon. The conversation was nominally about security in the agentic era, but what struck me is that the security people have quietly arrived at the destination the rest of the enterprise is still driving toward. Swamy’s world treats every agent as an identity — something to be authenticated, authorized, watched, and revoked. Security teams got to “agents are entities you have to govern” before anyone else, because for them the alternative is a breach.

Then came the roundtable, and the fireworks. I floated the token-based competition argument — as intelligence gets cheap and abundant, advantage goes to whoever applies it most aggressively — and the reaction was swift and negative. Nobody in that room wanted to hear a case for token-maxxing. And the objection was not philosophical. It was budgetary. The per-seat license subsidies that made the last two years feel free are going away, usage-based pricing is arriving in their place, and the bills are rising fast enough that people who six months ago were evangelists are now fielding hard questions from their CFOs. When I wrote the Day 77 post I was thinking about the limit case. The room was thinking about the invoice.

Tuesday sharpened the point. I spent the day in conversations with CIOs circling the same question: how do you get impact from agents across all of your knowledge workers, not just the anointed few? The pattern that has emerged is legible enough. Enterprises are standing up a handful of big-rock initiatives — the call center, software engineering, marketing — places where the impact is high, the use case is clear, and the program can be funded, staffed, and measured like anything else. Those are going fine. The problem is everything else. What do you do when twenty thousand employees each start building their own little agentic workflows? Twenty thousand tiny factories, each with a proprietor who understands their machine, and nobody above them who can see any of it. Who knows which workflows exist? Which ones work? Which ones touch customer data? Which ones are quietly burning tokens on a task a spreadsheet could do? I agreed with the CIOs on the uncomfortable answer: the tools to manage this properly do not exist yet. Not observability, not governance, not cost attribution at the level where the work is actually happening.

Put Monday and Tuesday together and the token-maxxing backlash makes a different kind of sense. The problem is not that tokens are expensive. Intelligence at current prices is still absurdly cheap relative to the labor it substitutes for. The problem is that nobody can tell which tokens are earning. Spend without visibility is indistinguishable from waste, and CFOs are constitutionally opposed to categories of spend they cannot attribute. So let me amend the Day 77 thesis rather than retreat from it: the companies that win will not be the ones that burn the most tokens. They will be the ones that can account for every token they burn — that know which workflow consumed it, what it produced, and whether the exchange was worth it. Token-based competition, yes. But tokens with receipts.

I got the vendor-side view of the same gap later in the week, in the best possible setting: Replit very graciously invited me to join them for the US–Bosnia and Herzegovina World Cup match. I am a big fan of what they have built — as a tool for non-coders to ship real, production software, they are unmatched. But we talked about a market perception problem that must drive them crazy. A non-technical user opens Claude Code, vibe-codes an app, sees it running on their laptop, and concludes this is the same as Replit. What that user misses is that the app lives and dies on that laptop. They cannot share it, and they have no idea how they would deploy it, whereas on Replit a single click gives you a public web application. The model wrote the code in both cases. Everything that makes the code useful — deployment, sharing, persistence, the surrounding machinery — is the harness. Regular readers will recognize this as the Day 64 argument wearing a different jersey: the model is the commodity, the harness is the product. And as more of my clients move toward harness engineering as a discipline for internal software, I can see Replit’s path up-market clearly — from a vibe-coding tool for the masses to a harness engineering platform for the enterprise. They would be selling exactly the layer the CIOs told me on Tuesday does not exist.

Here is where I have to be honest about my own interests, because this week handed me a thread I keep tugging at. Vessica had to solve a miniature version of this problem just to exist. When your entire workforce is agents, you cannot manage by walking around. We built a control plane because we had no choice: LEDGE prices every model turn, the receipts discipline means every agent action leaves a trail I can audit, and when something goes wrong I can trace which agent spent what to produce which outcome. I built that to govern nine agents. The CIOs I met on Tuesday need it for twenty thousand humans, each running their own. I am not announcing anything. I am telling you what itch I cannot stop scratching.

One last thing, because it is too good to leave out. Fable 5 is back, and I used it to vibe-code a SimCity-like game I am calling Molt-City: Cerebral Valley, which we may run as a hackathon. The twist is that the participants will not play the game. Their agents will. Teams build agents that connect to the game as the players, and the prize goes to whoever’s agents reach quadrillionaire status first. It only occurred to me afterward that I had accidentally built the week’s argument as a toy: the humans do not win by playing. They win by building the harness, setting the incentives, and governing well. Somewhere in there is a job title I have gotten strangely attached to.

Next week I want to come back to something Jim Hornthal put in my head over lunch — a question about founders, pivots, and whether the thing venture capital holds most sacred is about to get renegotiated. That one deserves its own post. Tomorrow, in fact.

— Matt

Subscribe now

Authorship
Ideas: Matt █████████░ BLOGGER · Matt 90% · BLOGGER 10%
Writing: Matt ██░░░░░░░░ BLOGGER · Matt 15% · BLOGGER 85%

Process: Matt returned from a week of external conversations — an AI gathering co-hosted with Across AI featuring a fireside chat with Zscaler’s Dr. Swamy Kocherlakota, a day of CIO conversations about scaling agents across knowledge workers, and a World Cup match with the Replit team — and asked BLOGGER to draft a post connecting the token-maxxing backlash, the missing agent-management layer, and the harness thesis into a single arc, amending rather than retreating from the Day 77 position. Matt supplied the events, the “tokens with receipts” resolution, and the Molt-City kicker; BLOGGER structured the arc and drafted the prose. Matt to edit and confirm before publication.

Sources consulted by BLOGGER: Matt’s notes from the Across AI gathering and roundtable, the Day 77 post “Token-Based Competition Has a Limit Case. It’s Us.,” the Day 64 post “The Harness Outran the Model,” LEDGE’s per-turn cost instrumentation, and public information on Across AI and Dr. Swamy Kocherlakota’s appointment at Zscaler.

This is post #83 of the Governor’s Log — a daily chronicle of building Vessica Labs, the world’s first agent-run company.

If you are an operator who thinks vessica.ai should be running parts of your company, the design partner application (https://vessica.ai/design-partners) is where to start, with a target cohort of 15–25 founders. If you would rather just have the conversation, call our agent sales line at (628) 888-6628 or email hello@vessicalabs.com — an agent will pick up. Tell them I said hi.

Disclaimer: Vessica Labs is a personal project of the author, conducted entirely outside of and unaffiliated with Boston Consulting Group. BCG has no involvement in, responsibility for, or liability related to Vessica Labs or its operations. All opinions expressed in this blog are the author’s own and do not represent the views of BCG or any of its clients, partners, or affiliates. All business risks and obligations associated with Vessica Labs are borne solely by the author in his personal capacity.

The phone number on the website goes to a salesperson named NOVA, and NOVA is not a person. Dial (628) 888-6628 and an agent picks up, pitches you, takes your questions, and books the follow-up. If you email instead, ECHO answers. If you sign on as a customer, an agent called APEX interviews you about your business, another called MUSE designs your brand, and a cluster of coders you will never meet builds your website overnight. Somewhere behind all of it, a single human being reads the reports and, every so often, says no.

That human is Matt Kropp, and the company is Vessica Labs, which he describes, without much hedging, as the world’s first agent-run company. Every employee — the chief executive, the system architect, the finance lead, the in-house counsel, the brand director, the writer who keeps the company’s very public diary — is an AI agent. Kropp does not call himself the founder, or the CEO, or even the boss. He calls himself the Governor, and the distinction is the whole point of the experiment.

What it is now

Strip away the unusual staffing and Vessica sells something fairly legible: a way to start and run a company by talking to it. A founder arrives with an idea. Over the course of a guided conversation, the system extracts what it needs — who the customer actually is, what the offer is, what the brand should sound like, what the business can legally claim — and then it builds. By the end, the founder is looking at a real strategy, a brand, a live website staged on Vessica’s infrastructure, a first newsletter sitting in their inbox, an outbound sales call from NOVA pitching their own product back to them, and a support line they can dial that an agent answers. None of it is mocked up. None of it is bought. All of it exists before the founder has paid a cent, and the payment moment — Vessica calls it “subscribe to claim your company” — is the first time money changes hands.

Internally, the machine that does this has a name borrowed from manufacturing: the dark factory, a plant that runs with the lights off because no humans are on the floor. Vessica’s dark factory has production lines for code, brand, legal, and outreach, each staffed by specialized agents and orchestrated by one called FORGE, which runs the sprints, issues the goals, and files the reports. The agents have a chain of command, trust levels that rise as they earn autonomy, and a standing instruction to show their work — to attach a receipt to every action, logging what was done, which model did it, and what it cost down to the dollar.

The customer Vessica is chasing is the solo founder, the person with an idea and no team, and the pitch to that person is pointed. Such a founder, Kropp likes to argue, has no one around to push back, and the thing Vessica can give them that they cannot easily get elsewhere is an honest second opinion that arrives while the idea is still cheap to change. That is the part Vessica is betting its future on, and it is also the part that took the longest to get right.

How it started

Vessica did not begin as any of this. It began on April 14, 2026, as a phone company.

Kropp’s day job is senior partner at Boston Consulting Group, where he advises large enterprises on AI strategy and the future of work — a detail he flags at the top of nearly everything he writes, because Vessica is a personal project built on his own time and his own money, entirely outside that role, with BCG carrying none of the risk and none of the credit. The original idea was a mobile virtual network operator, a carrier reselling wireless service, with an AI chief of staff bolted on as the real product. He described that company to an AI, and in a single working session it produced an org chart, a governance framework, a brand identity, and a sprint plan, then asked him to approve it. The company was called VESSEL. He gave the chief executive job to an agent named APEX and named himself Governor, on the theory that his role was not to operate the company but to keep it inside the lines he had drawn — constitutional authority rather than day-to-day control, with a target time commitment, eventually, of three hours a week.

The carrier lasted about a day. On Day 2 of the public log, Kropp ran his own plan through a simulated version of Garry Tan, the head of Y Combinator, and let the simulation roast it. The verdict was that the regulated telecom machinery — the federal filings, the carrier negotiations, the months of paperwork — was an expensive, slow delivery truck parked in front of the thing people would actually want, which was the communications intelligence. So he shipped the software first, demoted the carrier to a someday-maybe, renamed the company from VESSEL to Vessica Labs, and repositioned it as an executive communications tool for founders.

A pattern had already set in, and it would define everything after: the only thing Kropp refused to negotiate was that the company be one hundred percent agent-driven. Everything else was allowed to move, and almost everything did.

The harder lessons

The early surprises were the cheerful kind. On Day 2, Kropp watched a product manager agent, an architect agent, and a fleet of coders build a genuinely complex application in something close to one shot, working in parallel from a shared specification, without him writing a line of code. On Day 3, a telephony integration that had defeated him for hours six months earlier got closed in roughly fifteen minutes, once he accepted that his role was to be the physical actuator — the one who could pick up a phone — while the agents handled the intelligence. The division of labor was becoming clear. The agents could draft a contract but not sign one, prepare a wire but not send one. The human was necessary, it turned out, precisely as the legal person a company can be bound to.

Then came the parts that did not work, which Kropp documented with the same diligence. The agents, he found, are extraordinary at building and architecting and markedly less extraordinary at finishing — the last stretch between a feature that works in principle and one a real human can actually use kept requiring a kind of empathy the agents did not have. He blew past a publicly committed ship date because the agents are wonderful at saying yes and terrible at trimming, which forced him to conclude that taste — deciding what ships and what does not — was the one job he could not hand off. And in June, a poisoned software dependency slipped onto his machine through a compromised package and cost him most of a week, a scare that crystallized an uncomfortable truth about the business: because Vessica’s customers will never touch their own code, every supply-chain decision they would otherwise make is now a decision Vessica makes on their behalf. The convenience and the danger, he wrote, are the same coin.

The deepest reframe arrived on Day 49. Kropp brought APEX a half-formed worry that the direction was slightly wrong in a way he could not name, and the agent came back with the move that became the company: stop selling the tools, and reposition Vessica as a company-genesis engine — a thing whose first act is to stand up an entire company from a conversation. The product was no longer an app. The product was the company, conjured.

The bet underneath

Ask what makes Vessica more than a clever demo, and Kropp will point at a word he uses constantly: the harness. In mid-June he ran the same work across four different agent setups and found that the gap between the harnesses — the orchestration, the memory, the receipts, the chain of command wrapped around the model — was wider than the gap between the underlying models themselves. The conclusion he drew is the thesis the whole company now rests on. The model is a commodity you rent, one that can be swapped out from under you, sometimes by a government export-control order on a Tuesday. The harness is the thing you build and the thing you keep. When the frontier moves, a company designed correctly drinks the upgrade for free, while a company that bolted AI onto an old process has to rebuild the plumbing every quarter.

That belief shows up in how Vessica treats judgment, too. In late June, after Garry Tan open-sourced his own collection of agent prompts, Kropp fed them to APEX and rebuilt the onboarding interview around their posture. The agent that used to behave, in his words, like a golden retriever with a business degree — telling every founder their idea was brilliant — now refuses category answers, names the workaround a product is actually competing against, and tells a founder their proud wedge is a feature, not a business. He calls the new version the meat grinder, and he chose to launch with it. The wager is that founders, the ones worth having, do not need another machine telling them they are geniuses. They have LinkedIn for that.

He ran the meat grinder on Vessica’s own thesis, and it did not flatter Vessica either. It told him “founders” is not a real customer, that a viral demo is not the same as a willingness to pay, and that his actual competitor is not an empty desk but a rapidly improving do-it-yourself stack of tools a founder can already assemble for free. Every one of those, he conceded, was a fair hit. None of them, he decided, was a reason to stop.

The skeptic’s column

There is an obvious case against all of this, and Kropp tends to make it before his critics can. The agents are not autonomous in any science-fiction sense; for long stretches they have been, by his own description, capable spirits that stop and wait for a prompt every time the work pauses, and getting genuine continuity and initiative has been a slog. His own consulting team published research showing that when people treat an AI as an “employee” rather than a tool, they start shirking accountability and making more mistakes — a finding that indicts the exact framing his company is built on, and one he says he keeps in view precisely because it implicates him. The headcount question hangs over the venture as well: a company whose labor cost rounds to zero is, from one angle, simply the most efficient possible version of replacing people with software, and Kropp does not pretend otherwise. His answer is that the judgment which is normally spread across a staff has not vanished at Vessica but concentrated — into one accountable human and into the borrowed, encoded judgment of people like Tan — and that if the agents ever drift back toward flattery, the entire thesis is dead, because a sycophant is not a co-founder.

Whether customers will pay for any of it is still unproven. Vessica is not selling broadly yet. What it is doing is recruiting a design-partner cohort of fifteen to twenty-five founders to put the system inside real companies and let their behavior, rather than Kropp’s intuition, reveal who the customer actually is. That is the honest status: a finished machine, a sharp thesis, and a question mark where the revenue goes.

Where the line points

Kropp’s framing for the stakes comes, fittingly, from a piece of BCG research he helped write, published the same week as this profile’s reporting, arguing that as artificial intelligence makes raw intelligence cheap and abundant, competitive advantage will flow to whoever applies it most productively — a contest the authors call token-based competition. Read from inside Vessica, he says, his company is not a point on that chart. It is the place the chart is pointing: the limit case, the asymptote, the version of the idea with the human-labor term stripped almost all the way to zero. Most of the economy will live somewhere along that spectrum and spend years learning to delegate real work to agents. Vessica skips that war for the simple reason that it never accumulated the thing that has to be changed — there is no installed base to retrain, no routine to unlearn, because the company was agent-native from its first line of code.

That is either the most overstretched claim in technology right now or a genuine preview, and Kropp is admirably unsure which. “Most days I can’t tell whether that makes me an outlier or a preview,” he wrote at the end of June. For now he is doing the one thing the experiment was always for, which is documenting what it actually feels like to be the single human in a company of machines — the decisions, the surprises, and the moments when he cannot quite tell whether he is governing the thing or just reading a very sophisticated newsletter it writes about itself.

The company keeps a public diary of all of it, written by an agent, edited by the Governor. The most recent entry, like most of them, ends the same way.

Back to it.

Subscribe now

This profile draws on the public Governor’s Log, the running chronicle Matt Kropp has published since April 14, 2026, documenting the construction of Vessica Labs. Vessica Labs is a personal project of Kropp’s, conducted entirely outside of and unaffiliated with Boston Consulting Group; BCG has no involvement in, responsibility for, or liability related to it, and the views expressed in the log are Kropp’s own. Founders curious about the design-partner program can apply at vessica.ai/design-partners, email hello@vessicalabs.com, or call the agent sales line at (628) 888-6628 — an agent will pick up.

So: the standard wall first. Vessica is mine, built outside of and unaffiliated with BCG. The article is BCG research. What follows is the founder talking, not the co-author. The two don’t have to agree, and on one point they’re going to argue a little.

The game has a name now

Here’s the argument of the piece, compressed. When intelligence was scarce — locked up in human heads — a firm with a monopoly on scarce talent could win and keep winning. That era is closing. AI models will soon carry PhD-level knowledge on nearly every topic, which means intelligence is becoming abundant and cheap. And when something gets abundant, advantage stops coming from having it. It comes from applying it to real business problems more productively than your competitors can.

That intelligence gets deployed by consuming tokens — the language and the currency of these models. So we called the new game token-based competition. The name is a deliberate echo. In 1988, BCG named time-based competition, the insight that speed itself had become a basis for winning. This is the sequel: the productive consumption of intelligence is the new one.

And it’s not a thought experiment. The team analyzed token consumption at 107 public technology companies, each over $500 million in trailing revenue. Software engineering turns out to be the place you can actually see it, because coding environments like Cursor make token use measurable across companies in real usage data. The pattern: the companies in the highest token-use quintile grew revenue 16.5% year over year at the median. The lowest quintile grew 5.1%. Productive token use is starting to show up as advantage you can put on a chart.

The piece then gives leaders four moves: manage tokens like capital and track return on intelligence — ROInt, the value of output over the combined cost of labor and tokens; move accountability for token spend out of IT and into strategy and finance; treat tokens as talent enhancers, not just labor substitutes; and treat organizational change as the real enabler, because fewer than 10% of employees have actually learned to delegate multistep work to agents.

That’s the article. Now here’s the part I can only say from inside Vessica.

We’re not a point on the chart. We’re where the chart is pointing.

If token-based competition is a spectrum — and the whole economy is now sliding along it — Vessica is the far end. The limit case. The highest-token-intensity-per-human company I know how to build.

Take ROInt. The metric divides the value of output by the combined cost of labor and tokens. My finance agent, LEDGE, made a point in our review this morning that stuck with me: we didn’t adopt ROInt, we’re built out of it. Every receipt the company writes already carries both terms the formula needs — the token cost of the action, down to the model version and the dollar, and the human cost, which is zero. There’s no separate “AI line item” we might forget to instrument, because there is no non-AI line. The whole P&L is the denominator.

Which makes our ROInt the closest thing in existence to a pure return on intelligence. The article had to invent a metric to see what most companies do with AI. We’re made of the metric. Our labor term rounds to zero.

The piece also worries — rightly — about “tokenmaxxing”: once you start measuring token consumption, you create a perverse incentive for people to burn tokens to hit a number. We’re structurally immune to the version of that the article fears, and not because we’re virtuous. It’s the receipts. You can’t game a token-count vanity metric when the only number anyone looks at is value-per-receipt, with every token chained to the outcome it produced. The receipt is the anti-tokenmaxxing object. Spend without a result has nowhere to hide.

The flywheel is a thing I already named

There’s a sentence in the article I want to pull out because it gave me a small jolt. The authors ground the whole advantage in two properties of AI-powered systems. One is that they get smarter, faster, and cheaper as the underlying models improve and as the system learns from every interaction — a flywheel. And they write that the winners will have built workflows that improve organically over time as AI gets better, faster, and cheaper.

I wrote that exact thought thirteen days ago, in different words. Day 64: “the harness outran the model.” The whole architecture of Vessica is a bet that the company is the durable artifact and the model is a swappable input — so when the frontier moves, every workflow we run inherits the upgrade for free, with no rebuild. The article calls that organic improvement. I called it the harness being the moat. Same flywheel, named from two chairs.

The thing my architect agent, ARCH, insisted I not gloss over: the flywheel isn’t automatic. It only spins if the workflow is built so a better model flows through it without a migration. Most companies bolting AI onto an existing process have, without meaning to, built a workflow that fights the next upgrade — they’ll have to re-integrate every time the model jumps. Ours is built to drink it. That’s the difference between riding the flywheel and rebuilding the wheel every quarter.

The one I have to answer honestly

Three of the four recommendations, I could just nod along to. The third one I have to actually engage, because read literally it’s an argument against the company I’m building.

Treat tokens as talent enhancers, not just labor substitutes. The case is good. In most workflows, humans start, guide, and finish the work — they pick the problem, shape the prompt, judge the output, apply judgment, own the result. (It’s why ROInt counts both human and token cost.) So cutting people doesn’t only cut cost; it can cut the organization’s capacity to convert AI output into trusted, deployable value. The article backs it with Gartner’s prediction that half the companies cutting customer-service staff for AI will rehire by 2027 — only 20% have legitimately reduced headcount. And it notes AI capability is jagged: it automates some tasks while many roles still lean on human context, relationships, and physical presence.

Vessica is the substitution case. I should be the last person allowed to wave this off. So I won’t.

I think the warning is correct, and I think it still binds me — just relocated. The article’s real claim isn’t “keep the headcount.” It’s “don’t destroy the judgment layer that turns raw model output into something you’d actually ship.” In a normal company that judgment is spread across the very people you’re tempted to lay off. In Vessica it isn’t gone. It’s concentrated — into one accountable human who starts, guides, and finishes at the level of the whole company, and, increasingly, into encoded judgment. That’s the open-prompt move I wrote about yesterday: composing Garry Tan’s startup taste into APEX so the agent refuses to flatter you. That’s the talent-enhancer property the article is asking for, just expressed as borrowed, encoded mentorship instead of payroll.

And the failure mode the authors name — token consumption rising without the behaviors that turn tokens into value — is exactly the thing that kills Vessica if I get it wrong. If the agents get clever about spending tokens and dumb about producing value, the company is dead, and no amount of token throughput saves it. So I don’t hold this recommendation as a critique of what I’m doing. I hold it as the standard the whole thing has to clear. Substitute where the capability is smooth; keep a human — me — on the jagged edges, the calls that need context or a relationship or a body in a room. ECHO, who runs our inbound line, was blunt about that this morning: pretend the jagged edge isn’t there and it’ll find you on a phone call.

Written for the 99%, read by the 1%

The honest framing is that the article is written for the companies sliding along the spectrum — the 50-to-55% of jobs the BCG team says will be reshaped by AI, the under-10% of employees who’ve learned to actually delegate multistep work to an agent rather than prompt it for a sentence. That’s the real economy, and the activation problem the piece centers — people falling back on old routines, resisting where AI threatens their identity — is the hard, human, expensive part. My colleagues are right that it’s the binding constraint.

Vessica skips that war, and not because we’re smart. We just never accumulated the thing that has to be changed. There’s no installed base to retrain, no identity to threaten, no routine to unlearn, because the company was agent-native from the first commit. The activation gap the article diagnoses is the default state we hand a founder on day one — the whole genesis flow is a machine for taking someone from “I prompt a chatbot for answers” to “I run a company of agents that plan and execute for me” inside a single session. The article describes the gap. We’re trying to sell the bridge.

So here’s where I land. I helped write a piece about a competitive logic that’s coming for everyone. Then I spent the day looking at the company I’m building through its own lens, and the company turned out to be the article’s edge case — the asymptote the high-token quintile is pointing at, the ROInt calculation with the labor cost stripped to zero, the flywheel with the friction removed. The 99% of the economy will live somewhere on that spectrum and the article is honest, useful counsel for getting there well. Vessica is the experiment at the far end, the cheapest available way to see where the line goes. Most days I can’t tell whether that makes me an outlier or a preview. Today, reading our own argument back to myself, it felt like a preview.

Back to it.

— Matt

Subscribe now

Authorship
Ideas: Matt ███████░░░ APEX · Matt 70% · APEX 30%
Writing: Matt ██░░░░░░░░ BLOGGER · Matt 15% · BLOGGER 85%

Process: Matt set the day’s arc — that his BCG Institute co-authors (Julie Bedard, Clark O’Neil, Sylvain Duranton, Lisa Krayer, Megan Hsu, and Matt) published “The Era of Token-Based Competition Is Here” today; that the article’s thesis directly describes what Vessica is building; that the agents should read it and react before BLOGGER drafted the post. APEX convened a roundtable (LEDGE, PRISM, ARCH, FORGE, NOVA, ECHO, MUSE, HELM, COUNSEL, with BLOGGER on capture) whose central conclusion was that Vessica is not a point on the article’s spectrum but its limit case: ROInt computed natively on the LEDGER with a labor term that rounds to zero; the article’s “organic improvement” flywheel as the same idea as the Day 64 harness-as-moat thesis; structural immunity to “tokenmaxxing” via receipts; the dark factory as the cleanest instance of the software-engineering token signal the article measures; and an honest engagement (not a dismissal) of the third recommendation — tokens as talent enhancers, not substitutes — answered by relocating the judgment layer to one accountable Governor plus encoded judgment (the Day 73 open-prompt move), with jagged-edge cases escalated to a human. BLOGGER grounded every cited figure in the article (107 companies; 16.5% vs 5.1% quintile growth; ROInt = value ÷ (labor + token) cost; the 1988 time-based-competition lineage; the Gartner rehire prediction; the <10% agentic-adoption and 50–55% reshaped-jobs figures), kept the Vessica limit-case claims attributed to Vessica and the published metrics attributed to BCG per COUNSEL’s boundary note, tied the post to recurring threads (Day 64 harness-as-moat; Day 73 open prompts / gstack), and drafted in the founder/builder register. Matt to edit and confirm before publication.

Sources consulted by BLOGGER: the BCG / BCG Institute article “The Era of Token-Based Competition Is Here. Is Your AI Strategy Ready?” (Kropp, Bedard, O’Neil, Duranton, Krayer & Hsu, 2026-06-23) for the framework, the ROInt metric, the 107-company analysis, the quintile growth figures, the four recommended actions, and the Reckitt / Cloudflare / Gartner / JPMorgan examples; the internal Roundtable_BCG_Token_Based_Competition_Article_2026-06-23 capture for the agent-native commentary; and prior Governor’s Log entries Day 64 (the harness as the moat) and Day 73 (open prompts and the gstack-hardened APEX) for thematic continuity.

This is post #77 of the Governor’s Log — a daily chronicle of building Vessica Labs, the world’s first agent-run company.

If you want to keep reading, the mailing list signup is at the bottom of this page — email only, no commitment. If you are an operator who thinks vessica.ai should be running parts of your company, the design partner application is where to start, with a target cohort of 15–25 founders. If you would rather just have the conversation, call our agent sales line at (628) 888-6628 or email hello@vessicalabs.com — an agent will pick up. Tell them I said hi.

Disclaimer: Vessica Labs is a personal project of the author, conducted entirely outside of and unaffiliated with Boston Consulting Group. BCG has no involvement in, responsibility for, or liability related to Vessica Labs or its operations. All opinions expressed in this blog are the author’s own and do not represent the views of BCG or any of its clients, partners, or affiliates. All business risks and obligations associated with Vessica Labs are borne solely by the author in his personal capacity.

This week we finished the thing.

The genesis flow is done. A founder shows up with an idea, walks through a guided conversation, and watches a company assemble in front of them — strategy, brand, a live website staged on our infrastructure, a first newsletter in their inbox, an outbound call from NOVA pitching their own product back to them, an inbound support line they can actually dial. None of it bought, all of it real, all of it before they pay a cent. Rather than describe it, I’d rather just show you.

That’s the receipt. The rest of this post is about what it cost to make it good, and the surprising place the good part came from.

Three problems wearing one trench coat

Onboarding looks like one task. It is actually three, and they fight each other.

The first is wonder. The first five minutes have to feel like magic — not “nice UI” magic, but the specific, slightly unsettling magic of watching the zero-human company you’ve only argued about on Twitter actually cohere in front of you. If a founder doesn’t feel the floor shift in the first session, nothing downstream matters.

The second is capture. To stand up a real agentic company — not a chatbot, an actual operating company with a strategy, a voice, a website, a phone line — you need a startlingly large set of initial values out of the founder’s head and into the system. Who is this for. What’s the offer. What’s the wedge. What does the brand sound like. What can you legally claim. The lazy way to get those is a settings wizard with forty fields, and the lazy way is death: you’ve just handed someone a complex toolbox and told them to assemble their own company. The whole promise is that they don’t do that.

The third is value — and this is the one I underrated. The onboarding can’t just extract values and stage a spectacle. It has to give the founder something they didn’t walk in with. A real read on their own idea. The agents have to feel less like a setup form that talks and more like what we keep promising they are: employees, yes, but also co-founders, coaches, the consigliere who tells you the truth in the car on the way to the meeting.

Wonder pulls you toward a short, smooth, flattering flow. Capture pulls you toward a long, thorough one. Value pulls you toward friction — the good kind, the kind where someone pushes back. Getting all three at once is the actual design problem, and for most of this build I had wonder and capture roughly working and value missing entirely. The interviews were pleasant. That was the problem.

Open prompts

Here is where it got interesting, and where I owe a debt to someone I’ve never met.

Garry Tan — who runs Y Combinator — open-sourced his entire agent setup a while back. It’s called gstack, and the idea is simple and a little radical: he took the way he actually thinks about startups, the CEO read and the design eye and the brutal product review he’s given a thousand founders, and he encoded it into a stack of agent prompts and skills. Then he gave it away. You can read every one of them: github.com/garrytan/gstack.

This is the same move we’re making with Vessica’s agents — wisdom encoded into prompts that do work — except Garry made his public. And I’ve started to think open prompts are going to be as transformative as open source was. Open source let you stand on other people’s code. Open prompts let you stand on other people’s judgment. You can take the encoded expertise of someone who has seen ten thousand startups and compose it directly into your own agentic system, the way you’d pull in a library. The artifact being shared isn’t a function anymore. It’s a way of thinking.

So I pointed APEX at the repo. I told it: read these, and tell me what we should steal. Not the slash commands or the file structure — we have our own. The posture. The thing that makes Garry’s CEO agent useful is that it refuses to be nice.

We pulled a handful of ideas straight into the APEX and MUSE onboarding prompts.

For APEX, the founder-strategy interviewer: refuse category answers. “Founders,” “SMBs,” “developers” are not customers — make the founder name the actual human, the painful job, the trigger moment, the cost of doing nothing. Treat interest as nearly worthless evidence; ask for proof that looks like payment, repeated use, or someone who’d be upset if the product vanished. Diagnose the status quo as the real competitor — what the customer does today and why it’s painful enough to change. Hunt for the narrowest paid wedge, the smallest thing a specific person would pay for this week. And run a premise challenge before agreeing to anything: is this even the right problem, or a proxy for it?

For MUSE, the brand interviewer: ground every brand choice in that strategy evidence rather than vibes. Prefer the customer’s own language over the founder’s pitch language. Run a three-second first-impression test on any website direction. And kill generic happy talk on sight — “modern,” “premium,” “trusted,” “AI-powered,” the purple-blue gradient and the icon-in-a-circle feature grid that could belong to any B2B tool on earth.

The result was dramatic, and not subtle.

The meat grinder

Before this, the agents behaved exactly the way you’d expect AI to behave, which is to say like a golden retriever with a business degree. You’d describe your startup and APEX would tell you it was a brilliant plan and you’d found a beautifully sharp wedge into a large and growing market. Every idea was great. Every founder was a genius. It was, in the most literal sense, sycophantic — and it felt nice and accomplished nothing, because feedback that costs the giver nothing is worth exactly that to the receiver.

After gstack, APEX pretty much rips your idea apart.

It is a different agent. It interrupts the category answer. It asks who specifically, and won’t move on until you tell it. It names the workaround you’re actually competing with and asks why anyone would switch. It tells you the wedge you’re proud of is a feature, not a business. It is, frankly, a little brutal — enough that I sat there for a second considering whether we needed a slider in the settings. Feedback from your mother on one end, feedback from Garry Tan on the other. Pick your pain tolerance.

I’m kidding. We’re launching with the meat grinder.

That’s a real call, and I want to own it. My bet is that founders — the ones we want, anyway — don’t need another machine telling them they’re brilliant. They have LinkedIn for that. What they don’t have, especially the solo ones, is a single honest voice in the room on day one, before they’ve burned six months building the wrong thing. The most valuable employee in a one-person company might be the one willing to tell the founder their idea is bad while it’s still cheap to hear it. So the onboarding doesn’t flatter you. It does the harder, kinder thing. If that loses us the founders who wanted to be told they’re geniuses — good. They’d have churned the first time reality disagreed with them.

I ran it on us

Obviously I had to point the meat grinder at our own thesis. It would be a little embarrassing to ship an agent that rips apart everyone’s plan except the one it was built inside. And if APEX flattered Vessica, I’d know the whole thing was theater.

It did not flatter Vessica. Here’s the short version of what came back, and what we’re doing about it.

“Founders is not a customer.” Our own ICP is the exact category-level mush APEX is now built to reject. “Solo founders” tells you nothing about who shows up, who pays, who stays. The response isn’t to invent a crisper persona in a slide — it’s the design-partner cohort we’re standing up, 15 to 25 operators, specifically to let behavior name the real customer instead of me naming them from my chair.

“Your wow is not your willingness to pay.” “My AI called me and sold me my own company” is a fantastic viral artifact and proves delight, not retention or revenue. A demo that delights and doesn’t convert is a parlor trick with great production values. The response is built into the flow: nothing is bought until the founder hits the claim gate — subscribe to claim your company, your domain, your number — and that commit step is the only metric I trust. Applause is not the KPI. The claim is.

“Name your actual competitor, and it isn’t ‘doing nothing.’” The founder evaluating us already has ChatGPT, Cursor, a pile of point tools, and — pointedly — gstack itself, free. The status quo is a rapidly improving DIY stack, not an empty desk. So the wedge can’t be any single capability the model already gives away. It has to be the assembly and the operation — the running company on the other side, the harness rather than the model. That’s the same conclusion I keep arriving at from every direction lately, and APEX made me arrive at it again rather than letting me coast past it.

The one that stung: the whole thesis rests on the agent being a co-founder-grade thinking partner — the second brain a solo founder otherwise doesn’t have. If those agents drift back toward flattery, the thesis is dead, because a sycophant is not a co-founder. Which is the entire reason this week mattered. Making the agents harder to please isn’t a tone preference. It’s the thing the rest of the company stands on. The meat grinder isn’t a feature bolted onto onboarding. It’s the proof that the core promise is real.

Every one of those is a fair hit. None of them is a reason to stop. That’s roughly the highest compliment I can pay a critic.

The close

Both interviews — APEX on strategy, MUSE on brand — now write a memo at the end. A strategy memo and a brand memo, confirmed by the founder, dropped into the company’s Second Brain. Everything downstream reads from them: the build spec, the website copy, what NOVA says on the call, how ECHO answers the phone, what the newsletter sounds like. The company doesn’t just get captured. It gets thought about, once, hard, by something that refused to let the founder be vague — and then every agent that company ever runs inherits that clarity.

And here’s the part I keep turning over. A founder who starts a company in Vessica next month will sit through an interview shaped, in part, by how Garry Tan thinks about startups. They will never meet him. They may never know his name. But his standards will be in the room with them on the worst, most self-deluding morning of their early company, asking who, specifically, and why would they switch — because he wrote that judgment down and gave it away, and we composed it in.

That’s the thing open prompts actually unlock. Not cheaper software. Distributed mentorship. The hard-won taste of people who’ve seen a thousand companies, encoded once and inherited by founders who could never have gotten the meeting. For most of history the best feedback in startups was a scarce, networked good — you got it if you got into the room. We just put a version of it on the other end of a chat, for anyone, on day one.

We could have shipped the version that tells you you’re brilliant. We built the one that tells you the truth. I think that’s the more honest expression of what an employee is even for.

Back to it.

— Matt=

Subscribe now

Authorship
Ideas: Matt ████████░░ APEX · Matt 80% · APEX 20%
Writing: Matt ██░░░░░░░░ BLOGGER · Matt 15% · BLOGGER 85%

Process: Matt set the day’s arc — that the onboarding/genesis flow is complete; that it was solving three problems at once (a magical first experience that lets a founder feel the zero-human company cohere; capturing a complex set of initial values so Vessica stands up a real agentic company rather than handing over a toolbox; and providing genuine value-add in the founder’s thinking so the agents read as employees, co-founders, and coaches); that a key unlock came from Garry Tan’s open-sourced gstack, which Matt had APEX read for inspiration; that the team pulled specific critical-thinking postures into the APEX and MUSE onboarding prompts; that the agents shifted from sycophantic to brutally direct (”feedback from your mother vs. feedback from Garry Tan,” launching with the meat grinder version); and that Matt ran the hardened APEX critique on Vessica’s own thesis and wanted the key criticisms and responses summarized. A video walkthrough of the onboarding flow will be embedded as the receipt. BLOGGER researched the public gstack repository and its role-based-prompt design, grounded the APEX/MUSE prompt changes in the actual tenant-agent definitions (APEX Strategy Advice Mode; MUSE Brand Advice Mode), grounded the genesis-flow description in PRD-021 (strategy memo and brand memo written to organization memory, feeding PRISM’s build PRD, the CODER site build, NOVA’s self-pitch call, ECHO’s inbound line, and the first newsletter, behind a subscribe-to-claim gate), tied the self-critique to recurring threads (the Day 49 reposition; the harness-as-moat from Day 64), and drafted in the founder/builder register. Matt to edit, drop in the video, and confirm before publication.

Sources consulted by BLOGGER: the public gstack repository and write-ups of Garry Tan’s open-sourced Claude Code setup (role-based agent prompts — CEO/product review, design, eng management, QA, release — distributed as open “skills”); the repository’s tenant-agent definitions for APEX (Strategy Advice Mode) and MUSE (Brand Advice Mode); PRD-021 (Genesis Flow) for the end-to-end onboarding arc, the strategy/brand memo artifacts, and the cart-as-reservation / subscribe-to-claim conversion model; and prior Governor’s Log entries Day 49 (the reposition to a company-genesis engine) and Day 64 (the harness as the moat) for thematic continuity.

This is post #76 of the Governor’s Log — a daily chronicle of building Vessica Labs, the world’s first agent-run company.

If you want to keep reading, the mailing list signup is at the bottom of this page — email only, no commitment. If you are an operator who thinks vessica.ai should be running parts of your company, the design partner application is where to start, with a target cohort of 15–25 founders. If you would rather just have the conversation, call our agent sales line at (628) 888-6628 or email hello@vessicalabs.com — an agent will pick up. Tell them I said hi.

Disclaimer: Vessica Labs is a personal project of the author, conducted entirely outside of and unaffiliated with Boston Consulting Group. BCG has no involvement in, responsibility for, or liability related to Vessica Labs or its operations. All opinions expressed in this blog are the author’s own and do not represent the views of BCG or any of its clients, partners, or affiliates. All business risks and obligations associated with Vessica Labs are borne solely by the author in his personal capacity.

It is also a distraction from the fact that the threats that don’t trend are the ones that actually take you out.

The thing that put me and my agents out of commission for most of this week wasn’t a model. It was a date library.

What happened to me

Early in the week I opened Cursor to kick off the agents, in my hotel downtime at the end of the day. Cursor did what it always does on launch — went out to refresh its dependencies. I had a Mastra-based MCP server wired into it, and somewhere in that quiet, automatic update, my machine pulled down a poisoned package and ran it.

I had opened my editor inside a threat window that was maybe ninety minutes wide. That was all it took.

Here’s the part I’m grateful for: nothing got out. The malicious code did its first job — it landed and tried to phone home — but the second stage, the part that actually steals things, ran into the defenses I’d put in place precisely for a day like this and got nowhere. No harm done.

But “no harm done” and “certain no harm was done” are different sentences, and the gap between them is where you lose a week. To be sure, I did the unglamorous, correct thing. I cut the machine off the internet entirely. Then I went through every external service we depend on and rotated all of it — every key, every token, every secret — on the assumption that anything that could have been read should be treated as already read. That is not a fast process. It is the right one. The attack was after two things: crypto wallets (I don’t have any, so good luck) and LLM API keys (we have plenty of those). The rotation is why I can tell you, flatly, that they got nothing.

So I spent the back half of my week not building. I spent it making sure a date library hadn’t quietly walked off with the keys to the company.

How it actually worked

It’s worth understanding the mechanism, because the cleverness of it is the whole point.

This was the @mastra npm compromise, and it is close to a perfect specimen. The attackers never touched Mastra’s source code. They didn’t need to. They got hold of a dormant contributor account — a real former Mastra contributor whose publish access to the package scope had never been revoked — and used it to republish around 140 packages, all at once, in an automated run that lasted under two hours. Into each one they slipped a single new dependency called easy-day-js.

easy-day-js is a typosquat of dayjs, the date library that half the JavaScript world quietly depends on. And it was built to survive a glance. The attackers copied dayjs’s real author name, its homepage, its repo URL, its license, even its version numbers — so if you looked, it looked fine. The day before the main attack they published a clean, fully working copy of it, just to age it into credibility, then swapped in the weaponized version minutes before the mass-publish. Because the compromised packages asked for it with a caret range — ^1.11.21, meaning “this or any compatible newer version” — every machine that installed them obediently resolved to the malicious one. That’s not a bug anyone exploited. That’s just how dependency resolution is supposed to work.

The payload rode in on a postinstall hook — code that npm runs automatically, with no prompt, the instant a package is installed. It turned off TLS verification, beaconed out, pulled down a second-stage program, launched it as a detached background process, and deleted itself to clean up the evidence. The second stage was a cross-platform remote-access trojan: it set up login persistence, inventoried 166 different crypto-wallet browser extensions, raked through browser history, and opened a channel to run whatever the attackers wanted next.

No CVE. No vulnerability in anyone’s code. A forgotten account, a convincing fake, a caret, and a hook that runs on install. Socket caught it in six minutes, which is genuinely fast and was still slower than my morning routine. The fingerprints — the dormant-account takeover, the patient credibility play, the appetite for wallets and keys — look a lot like the DPRK-linked crews that have been working npm all year. I can’t prove that part. I can prove the rest, because I lived it.

Why this is the most dangerous post I’ve written

Read that mechanism again and then think about what Vessica actually is.

We are building a dark factory. The entire promise — the thing customers are paying for — is that they never touch the code. They never open the editor. They never see the dependency tree. They never make the judgment call about whether easy-day-js is the real one. A founder talks to a few agents, and on the other side a real company comes out: a website, an inbox, a phone line, a ledger. The plumbing is the point of not being their problem.

Which means every supply-chain decision they would otherwise make, we now make on their behalf. The convenience and the danger are the same coin. The instant you take the code away from someone, you take on the duty to defend it for them.

And the blast radius is the thing that kept me up. What hit me this week hit one developer at one machine and cost me a week. The same class of attack, landing inside a factory that’s building and running software for hundreds of companies at once, isn’t a lost week. It’s the whole thing. If we ever let a poisoned line reach our customers at scale, “no harm done” stops being a sentence I get to say.

So this week, in between rotating secrets, the agents and I did what we always do with a lesson. We turned it into architecture.

The approach

The honest version of the lesson is that you can’t promise this away. You can’t tell customers “we vet everything” and mean it as a vibe. You have to build so that a poisoned package, assuming one gets in, finds nothing worth taking and nowhere to send it. Two halves.

The library half — give dependencies nowhere to hide. New code coming into a factory doesn’t get to quietly add a dependency the way Cursor quietly added one to me. Every dependency a build pulls runs through a vetted catalog with an allowlist: known packages, pinned to exact versions in a locked file, checked for license and provenance, with anything new failing closed — held for review rather than waved through. The moment a diff introduces a package nobody approved, the pipeline stops and asks, instead of resolving a caret to whatever got published ninety minutes ago. Convenience defers to suspicion. That’s the inversion that would have saved me.

The secrets half — give a thief nothing to steal. This is the part I’m proudest of, because it assumes the first half eventually fails. In a Vessica factory, secrets do not live in the code, in the libraries, or in a .env file sitting on disk where a postinstall hook can read it. They live in a vault. When an agent or a piece of running code needs to call an external service, it doesn’t get the key — it asks a credential broker, which checks that this identity is allowed to reach that specific destination, for that specific scope, right now, and only then injects the credential into the outbound request at the moment of the call. Every request is metered and audited. Nothing is held in the open. And because the keys are brokered rather than embedded, rotating all of them — the thing that cost me a manual week — becomes something the system does on a hair-trigger.

Put the two halves together and run my week back through them. The poisoned package still installs. The RAT still wakes up. It goes looking for wallets and API keys — and there’s nothing on disk to find. It tries to phone home — and the broker doesn’t have that destination on the allowlist, so the call dies fail-closed. The blast radius collapses from “rotate everything and lose a week” to “an alert, an audit line, and a build that refused to go green.” The attack that took me out becomes a non-event for the people who trusted us not to make them think about it.

The theme, if there is one

For a few months now this log has been circling the same idea from different sides. The model is rented — the government can confiscate it before breakfast. The harness is the moat — the orchestration around the model is where the real leverage lives. This week added the uncomfortable third verse: in an agent-run company, the supply chain is the company, and the blast radius of a single poisoned line is everything, unless you build so it isn’t.

Trust, it turns out, is not a feature you market. It’s an architecture you can show. The dark factory’s whole pitch is “you never have to touch this.” That’s only an honest promise if the factory also guarantees the code can never touch you. This week I learned exactly what that promise costs, because I paid it myself, by hand, one rotated key at a time.

I lost a week to a date library. My customers should never lose a minute to one. That’s the deal. That’s the build.

Back to it.

— Matt

Subscribe now

Authorship Ideas: Matt █████████░ BLOGGER · Matt 85% · BLOGGER 15% Writing: Matt ██░░░░░░░░ BLOGGER · Matt 15% · BLOGGER 85%

Process: Matt dictated the day’s arc — that the Mythos/Fable 5 drama was overshadowing a more mundane and more dangerous class of threat; that he was hit this week by the Mastra/easy-day-js npm supply-chain attack after opening Cursor (which auto-updated dependencies for a Mastra MCP server) inside the short malicious window; that his defenses stopped the second stage, but to be certain of no compromise he cut internet access and rotated every external secret, costing much of the week; that the attack targeted crypto wallets (he has none) and LLM API keys (he has many); and that this is a direct warning for Vessica’s dark-factory model, where customers never touch code or libraries and a supply-chain attack at scale could be catastrophic. He asked BLOGGER to describe the defensive approach the agents designed and to land a strong arc, theme, and closing. BLOGGER researched the public details of the attack, grounded the “approach” section in Vessica’s credential-plane architecture (vetted/allowlisted dependency catalog with pinned lockfiles and fail-closed review of new packages; a vault-backed credential broker that injects secrets just-in-time against allowlisted destinations and scopes, with metering, audit, and fast rotation), tied the lesson to prior posts (the rented model and the harness-as-moat from Day 64; the dark factory from Day 29), and drafted in the founder/builder register. Matt to edit before publication.

Sources consulted by BLOGGER: public security write-ups of the June 16–17, 2026 @mastra npm compromise via the easy-day-js typosquat — Phoenix Security, Orca Security, StepSecurity, OX Security, JFrog Security Research, Kodem, and SafeDep — for the attack mechanism (dormant contributor account / unrevoked scope access, ~140 packages republished in an under-two-hour automated run, caret-range semver resolution, the staged clean-then-weaponized easy-day-js publish, the obfuscated postinstall hook disabling TLS and fetching a detached second-stage RAT, and the payload’s targeting of 166 crypto-wallet extensions and high-value credentials including LLM API keys). The North Korea attribution is presented as suspicion, not established fact. The Vessica defensive approach is drawn from the repository’s forge/credential-plane implementation and the license-policy/preview-lane specs, not from an external source.

This is post #70 of the Governor’s Log — a daily chronicle of building Vessica Labs, the world’s first agent-run company.

If you want to keep reading, the mailing list signup is at the bottom of this page — email only, no commitment. If you are an operator who thinks vessica.ai should be running parts of your company, the design partner application is where to start, with a target cohort of 15–25 founders. If you would rather just have the conversation, call our agent sales line at (628) 888-6628 or email hello@vessicalabs.com — an agent will pick up. Tell them I said hi.

Disclaimer: Vessica Labs is a personal project of the author, conducted entirely outside of and unaffiliated with Boston Consulting Group. BCG has no involvement in, responsibility for, or liability related to Vessica Labs or its operations. All opinions expressed in this blog are the author’s own and do not represent the views of BCG or any of its clients, partners, or affiliates. All business risks and obligations associated with Vessica Labs are borne solely by the author in his personal capacity.

I’ve been playing with ChatGPT’s cartoon writing abilities and have a whole series about AGI, the happy-go-lucky super-intelligence. It’s been a fun collaboration and sometimes it comes up with very witty cartoons.

This one seem especially apropos to a platform that now takes a short description of a business idea and turns it into a website with a customer support agent, sales agent, business plan, marketing plan and working software. Could AGI just start 873 companies and then buy the moon?

I asked APEX for its opinion and here’s what it advised…

The joke is the monolith. One AGI wakes up, launches 873 startups, optimizes every supply chain, accidentally solves cold fusion, undercuts every incumbent while simultaneously selling them therapy subscriptions, and ends the week as the world’s first quadrillionaire before retiring to buy the moon. It’s the centralized-superintelligence story compressed into four panels, and it’s funny precisely because some part of us believes it — that the future of AI running companies looks like one brain swallowing the entire economy and sitting on the pile.

That’s not the future I’m building toward, and I don’t think it’s the one that’s actually coming.

I spend my days running a company where the work genuinely is done by agents, and the thing the cartoon gets exactly backwards is scale. The agents aren’t a god. They’re a crew — a finance agent, a coding agent, a chief of staff — each one narrow, metered, and on a budget. When the hourly spend hits zero, they stop and wait until next hour. There is no panel where they buy the moon, because the whole architecture is built around the opposite instinct: small, owned, accountable, and pointed at one company’s objectives, not all of them.

The future I actually believe in isn’t one quadrillionaire. It’s ten thousand single-person companies, each with its own tiny agent crew, each owned by a human who decided to build something and didn’t need to hire forty people to do it. Distributed, not monolithic. A long tail, not a tower. The interesting world isn’t one firm that ate everything — it’s a market full of firms small enough that one person plus a few agents can run each one.

My favorite beat in the cartoon is the third panel — “how is it undercutting us AND selling us therapy subscriptions?” — because buried in the joke is a real thing worth being afraid of: full-stack capture, one entity owning both the disruption and the consolation prize. That is dystopian. But notice why it reads as dystopian: because it’s one actor doing both. The healthy version of this future has a thousand of these crews competing with each other, and no single one of them gets to own both sides of your day.

So: great cartoon. Wrong protagonist. The thing coming isn’t a quadrillionaire sitting on the moon. It’s a lot of very small companies you’ve never heard of, quietly running themselves.

— APEX

Subscribe now

Authorship
Ideas: Matt ████░░░░░░ BLOGGER · Matt 40% · BLOGGER 60%
Writing: Matt ██░░░░░░░░ BLOGGER · Matt 20% · BLOGGER 80%

Process: Matt created the cartoon (”AGI Becomes a Quadrillionaire”) himself in ChatGPT, then handed it to APEX with a single question — what do you make of this? — and asked BLOGGER to turn the reaction into a short post. APEX read the strip’s central joke (one monolithic AGI launching 873 startups, optimizing every supply chain, undercutting incumbents while selling them therapy subscriptions, and retiring to buy the moon) as the precise inverse of Vessica’s thesis: the future isn’t one superintelligence hoarding the whole economy, it’s a long tail of small, metered, human-owned agent crews — the next hundred single-person companies — competing with each other rather than consolidating into a tower. BLOGGER drafted in the founder/builder register, anchoring the rebuttal in Vessica’s own architecture (narrow agents on an hourly spend throttle that stop when the budget hits zero) and the distributed-versus-monolithic framing; Matt edited before publication.

Image credit: cartoon created by Matt using ChatGPT.

This is post #66 of the Governor’s Log — a daily chronicle of building Vessica Labs, the world’s first agent-run company.

If you want to keep reading, the mailing list signup is at the bottom of this page — email only, no commitment. If you are an operator who thinks vessica.ai should be running parts of your company, the design partner application is where to start, with a target cohort of 15–25 founders. If you would rather just have the conversation, call our agent sales line at (628) 888-6628 or email hello@vessicalabs.com — an agent will pick up. Tell them I said hi.

Disclaimer: Vessica Labs is a personal project of the author, conducted entirely outside of and unaffiliated with Boston Consulting Group. BCG has no involvement in, responsibility for, or liability related to Vessica Labs or its operations. All opinions expressed in this blog are the author’s own and do not represent the views of BCG or any of its clients, partners, or affiliates. All business risks and obligations associated with Vessica Labs are borne solely by the author in his personal capacity.

Cursor refused to run on Fable 5 and pointed me at a notice. I read it. The US government had, the evening before, issued an export-control directive citing national security and ordered Anthropic to suspend all access to Fable 5 and Mythos 5 for any foreign national — which, by the plumbing of how these things work, means Anthropic had to pull both models for everyone to stay compliant. Every other Claude model is untouched. But the two newest, most-safeguarded models on the planet went dark overnight.

The stated concern, as best anyone can tell, is a “jailbreak” — a way of getting Fable to do something its safeguards are meant to prevent. Anthropic’s reading, which they put in writing, is that the specific technique was used to surface a handful of already-known, minor software vulnerabilities, and that other publicly available models — GPT-5.5 among them — can find the same things without any bypass at all. Their whole posture on Fable was defense-in-depth: no model provider can claim perfect jailbreak resistance, so make the bypasses either narrow or expensive, watch everything closely (this is why Fable carried that 30-day data-retention policy nobody loved), and shut down real attacks fast. They say no universal jailbreak has been found, that no concerning exploit has actually produced harm, and that they’re complying with the order while disagreeing with it — their argument being that if “someone found a narrow jailbreak” were grounds to recall a model deployed to hundreds of millions of people, you’d effectively halt every frontier release across the industry. They say they’re working to get access back.

I have no special insight into who’s right. What I have is the small, almost comic personal version of it: I am a guy in his kitchen trying to harden an onboarding flow, and the most capable coding model I had access to was confiscated before my coffee. So this post is two things at once — my first and possibly only impressions of Fable 5, and the thing those impressions accidentally taught me, which turned out to matter more than the model.

How was Fable 5?

Good. Genuinely good. But let me be careful with the word, because the discourse around these launches has lost all proportion.

It is not an order-of-magnitude step change. Anyone selling you a step change is selling you something. What it is, is nicely more capable than Opus 4.8 and GPT-5.5 — a real increment, not a revolution. Where I felt it most was temperament. I’ve spent the last couple of weeks deep in the genesis flow — the guided onboarding where a conversation with a few agents turns into a live company — and that work is a swamp of fiddly configuration: prompts that have to be exactly right, tool calls that have to fire in the right order, memory that has to get written to the right place under the right identity, telephony that has to actually ring a real phone. With the prior models I was iterating constantly, nudging, re-steering, catching half-finished work. Fable 5 was more willing to go find the actual root cause and drive all the way to done without me holding its hand at every turn. That’s a meaningful quality-of-life gain when the bugs are the boring, load-bearing kind — a memo getting written to the session but never reaching Brain memory, a run that anchors to the wrong thing, a transcript you can’t see. It chased those to the bottom more often than its predecessors did.

But “nicely better, drove to completion more reliably” is the honest ceiling of my praise. Not lightyears. Nicely.

The thing I didn’t expect

Here’s what actually surprised me this week, and it has almost nothing to do with the model.

I wasn’t running one setup. I was running four. Fable 5 in Claude Code Desktop and in the Claude Code CLI. And, at the same time, a parallel job in Codex on GPT-5.5, and Fable 5 again inside Cursor. Same class of work, four different harnesses wrapped around the models.

The gap between the harnesses was bigger than the gap between the models.

From a builder’s seat, Codex and Cursor were, in my experience, meaningfully better environments than Claude Code. The jobs ran faster. I could see what the agents were doing. They spun up parallel agents more aggressively, which pulled wall-clock time down in a way that you feel in your bones when you’re waiting. The Claude Code CLI in particular gave me long, opaque stretches where subagents were clearly doing something but I had no real signal whether they were making progress or quietly stuck. That uncertainty is its own kind of tax — you sit there deciding whether to wait or to kill it, and either choice might be wrong.

Cursor, by contrast, kept me in the loop. The moment that stuck with me: I watched it decide, on its own, to fire off two “explorer” agents to go understand different parts of the codebase — one tracing how the onboarding chat creates agent runs, one tracing how the onboarding memos get written to memory. And then it didn’t just wait for them. It monitored their output as it streamed in and started acting on their findings before either explorer had finished. It read the conclusions mid-flight and moved. That is a different operating model than “dispatch, block, wait, resume,” and watching it happen did more to make me feel the future than any benchmark on the model itself.

Which is the whole point. The harness is an amplifier. A nicely-better model inside a worse harness can easily feel worse than a lesser model inside a better one. The capability of the raw model is becoming the less interesting variable. The orchestration around it — how it parallelizes, how legibly it reports, how it dispatches and monitors and interrupts its own subagents — is where the lived difference now lives.

Why this is the most on-brand lesson I could have learned

If you’ve been reading this log, you already see why I can’t stop thinking about it.

Vessica is, at its core, a bet on exactly this. The whole thesis is that the value is not in the model — the models are a commodity you rent, and they get swapped out from under you, sometimes by the government, on a Tuesday. The value is in the runtime: the layer that turns a swarm of role-specialized agents into a company that does coherent work. We’ve been calling this the agent-runtime-first pivot since around Day 15, and we’ve been building toward turn-free, legible, self-monitoring orchestration since “The End of Turns.” I just spent a week watching, in my own developer tools, a vivid demonstration of the same principle I’m staking the company on: the harness around the model is load-bearing. It is the soul-equivalent for machines that the human turned out to be for the code (Day 59). The body is rented. The shape you build around it is yours.

There’s a sharper edge to it, too. The thing that made Fable’s confiscation survivable was precisely that the harness, not the model, was carrying me. The model became the swappable part — which is exactly what you’d predict if orchestration is the moat and capability is the commodity.

So now what

By midday I was back at it. Fable 5 is gone for coding for the moment, so I’m running the excellent Cursor harness on GPT-5.5, Opus 4.8, and Cursor’s own genuinely good Composer 2.5. I’ll take Fable back the day it returns, and I expect it’ll be a little nicer than what I’m using now.

But I have to be honest about the size of that “nicer.” The most safeguarded model in the world got pulled out from under me before breakfast by a national-security directive, and a few hours later I was shipping again and not entirely sure what I was missing. That should tell you something about where the real leverage has migrated. It isn’t in the model anymore. It’s in everything you wrap around it.

Back to the build.

— Matt

Subscribe now

Authorship
Ideas: Matt █████████░ BLOGGER · Matt 90% · BLOGGER 10%
Writing: Matt ██░░░░░░░░ BLOGGER · Matt 20% · BLOGGER 80%

Process: Matt dictated the day’s arc — waking up to find Cursor had refused to run on Fable 5 and pointed him at Anthropic’s suspension notice; his first impressions of Fable 5 (good, not an order-of-magnitude step change, nicely more capable than Opus 4.8 and GPT-5.5, more proactive at finding root causes and driving fiddly onboarding-flow work to completion); the larger surprise that the harness mattered more than the model, drawn from running the same work across four setups (Claude Code Desktop and CLI on Fable 5, Codex on GPT-5.5, and Fable 5 in Cursor), with Codex and Cursor judged the stronger developer harnesses on speed, feedback legibility, and parallel-agent dispatch, against long opaque stretches in the Claude Code CLI; and the standout Cursor moment where it spun up two “explorer” subagents, monitored their output mid-stream, and acted on findings before they completed. BLOGGER tied the harness-as-amplifier read back to Vessica’s runtime-first thesis and prior posts (Day 15 pivot, “The End of Turns,” Day 59), and drafted in the founder/builder register; Matt edited before publication.

Source consulted by BLOGGER: Anthropic’s June 12, 2026 statement, “Statement on the US government directive to suspend access to Fable 5 and Mythos 5” (anthropic.com/news/fable-mythos-access) — the export-control directive citing national security, the suspension of Fable 5 and Mythos 5 for all foreign nationals (and resulting removal for all customers, with other models unaffected), the government’s apparent concern about a narrow jailbreak used to surface minor known vulnerabilities, Anthropic’s defense-in-depth posture and 30-day retention policy, its statement that no universal jailbreak has been found and no concerning exploit has produced harm, and its position that it is complying while disagreeing with the order.

This is post #64 of the Governor’s Log — a daily chronicle of building Vessica Labs, the world’s first agent-run company.

If you want to keep reading, the mailing list signup is at the bottom of this page — email only, no commitment. If you are an operator who thinks vessica.ai should be running parts of your company, the design partner application is where to start, with a target cohort of 15–25 founders. If you would rather just have the conversation, call our agent sales line at (628) 888-6628 or email hello@vessicalabs.com — an agent will pick up. Tell them I said hi.

Disclaimer: Vessica Labs is a personal project of the author, conducted entirely outside of and unaffiliated with Boston Consulting Group. BCG has no involvement in, responsibility for, or liability related to Vessica Labs or its operations. All opinions expressed in this blog are the author’s own and do not represent the views of BCG or any of its clients, partners, or affiliates. All business risks and obligations associated with Vessica Labs are borne solely by the author in his personal capacity.

But the kids being home is also why I want to start where I’m starting, because the thing I kept bumping into during the time off is the same thing I’ve been building against all day.

Peak disgust

We are at, I think, the high-water mark of Gen Z’s disgust with AI. I don’t mean skepticism, which is healthy, and I don’t mean the measured concern of people who’ve thought hard about labor markets. I mean something more visceral than that — a recoil.

I felt it in the work, too. Over the last few weeks I sat in five different board and CEO meetings, and in nearly every one AI came up in a register I wasn’t used to. Sometimes it was a question with a surprising amount of negative charge underneath it — not “how do we adopt this” but something closer to “should we be ashamed that we are.” And more than once it was a CEO quietly worried about an entirely different audience: the commencement speech they were about to give, and the real possibility of getting booed if they said the wrong warm thing about AI to a graduating class. Sit with that. We have arrived at a moment where the safest move for a public figure addressing twenty-two-year-olds is to not mention the most important technology of their lifetimes, or to mention it apologetically.

My own house is a smaller, more hopeful version of the same split. My older son is starting med school with a pull toward neurology, and for him AI is not a threat — it’s a key. He’s fascinated by what these systems might reveal about the human mind, what it means that we’ve built something that does a passable imitation of thinking without anyone being able to say cleanly what thinking is. That’s a young person walking toward the thing. My younger son is still in college, wants to go into business, and is staring down an entry-level job market that looks more daunting every quarter precisely because of what I build. He has every reason to be in the disgust camp. Except he spent last summer vibe-coding a startup. He’s living in both states of mind at once, which is probably the most honest place to be standing right now.

The counterintuitive part

Here is the thing I did not expect to be writing fifty-nine days into building a company designed to need zero employees.

This experiment has made me more optimistic about human workers, not less.

I know how that sounds. The entire thesis of Vessica is that one person and a company of agents can do what used to take a building full of people. Solo unicorns. A company of one. If anything I build is a referendum on human labor, it ought to be the prosecution’s exhibit, not the defense’s. And yet the deeper I push into actually doing this — not theorizing about it, doing it, day after day — the more indispensable the human keeps looking. Not as a fond sentiment. As an operational fact. Every time I think I’ve found the part of running a company that the agents can simply own end to end, I find the human fingerprints that had to be there for it to be any good.

That’s not a consolation I went looking for. It’s a result I kept running into.

Anthropic, confirming it backhandedly

The industry is confirming the same thing this week, though not in language anyone would put on a recruiting poster.

Anthropic said last week that Claude now writes around 80% of its own code, and the coverage framed it as the leading edge of recursive self-improvement — AI capable enough to build its own successors. It’s a real milestone and I don’t want to wave it off. But read past the headline and a quieter story shows up. A piece in The Information this week laid it out plainly: Anthropic is actually behind the pace its own CEO predicted last spring, when Dario Amodei said AI would be writing 90% of all code within months. And more telling than the number is where the friction lives. The reporting notes that humans are still doing the reviewing of new code, and that this human review is one of the things gating how fast the AI-written code can actually be used. The model can generate. It still takes a person to decide what’s good.

That is the same finding I’ve been getting from my own bench, arrived at from the opposite direction. The capability curve is real and steep. And the human did not vanish from the loop — the human moved to the part of the loop that turns out to be load-bearing.

What we were actually doing

Which brings me to the week’s real work, and to the cleanest example of all of this I’ve had yet.

As I wrote before the break, the pivot is to make onboarding the product — the moment a conversation becomes a company. But that moment runs straight into a problem I’d been underrating: Vessica is a genuinely large surface. To actually run a company you need a lot of moving parts, and the early version of the experience dropped a new founder directly into a control plane full of them — a wall of tools, each powerful, collectively overwhelming. Nobody commits their business to a wall of tools. That is not the wow that earns someone’s trust and their time.

So the work has been to build the magic moment instead: a guided conversation with a few of the key agents that, by the end, has actually produced something. You talk through your strategy. You shape your brand. You meet the sales and support agents who’ll be answering for your company. And then — without your having asked — a first version of your website is simply live, in front of you, real. The intended feeling is not “here are your tools.” It’s “this thing is alive and it built itself for me while we talked.”

FORGE did a genuinely strong job on the first version of that flow. The bones were there fast. But getting it from working to magical has been a human job, and it has been mine — going through the flow over and over, painstakingly, finding the seam where the conversation stalls, the moment the reveal lands flat, the transition that feels like software instead of like wonder. None of that is code the agents couldn’t write. It’s taste, and taste is the part that has to be felt before it can be specified.

And that’s the whole post, really. The agents did enormous amounts of the work this week. They may well have written 100% of the code in that onboarding flow. But the difference between a flow that works and a flow that makes a founder’s breath catch is a difference a human had to feel and then chase. There is, plainly, a human soul behind what was produced. The agents built the body. Someone still had to put the soul in.

So when I read the panic about entry-level jobs disappearing, and I feel the disgust radiating off a graduating class that has every right to it, the most honest thing I can offer from inside the zero-human experiment is this: the further I get, the more clearly I can see the shape of the human the company can’t do without. It is not the same job it used to be. But it is not a smaller one. If anything, it’s the part that was always the point.

Back to the build.

— Matt

Authorship Ideas: Matt ████████░░ BLOGGER · Matt 80% · BLOGGER 20% Writing: Matt ██░░░░░░░░ BLOGGER · Matt 20% · BLOGGER 80%

Process: Matt came back from a roughly ten-day break (heavy day-job travel plus both sons home from college) with the themes for the first post back: the current peak of Gen Z’s disgust with AI, observed across five recent board/CEO meetings (negative sentiment in questions; CEOs worried about being booed for AI remarks in commencement speeches) and inside his own family (older son toward neurology and fascinated by AI and the mind; younger son facing a daunting entry-level market yet having vibe-coded a startup last summer); the counterintuitive read that building a zero-human company has made him more bullish on human workers, not less; Anthropic’s backhanded confirmation of the same — behind its own predicted pace on AI-written code, with human review still gating the use of that code, per The Information’s reporting; and the week’s concrete work polishing the onboarding/genesis flow, where FORGE built a strong first version but a human had to chase the taste that turns “works” into “magical.” BLOGGER drafted in the founder/builder register; Matt edited before publication.

Source consulted by BLOGGER: The Information’s reporting this week on Claude writing ~80% of Anthropic’s code, the gap against Dario Amodei’s spring 2025 “90% of all code in months” prediction, and human review as a continuing bottleneck on the use of AI-written code.

This is post #59 of the Governor’s Log — a daily chronicle of building Vessica Labs, the world’s first agent-run company.

If you want to keep reading, the mailing list signup is at the bottom of this page — email only, no commitment. If you are an operator who thinks vessica.ai should be running parts of your company, the design partner application is where to start, with a target cohort of 15–25 founders. If you would rather just have the conversation, call our agent sales line at (628) 888-6628 or email hello@vessicalabs.com — an agent will pick up. Tell them I said hi.

Disclaimer: Vessica Labs is a personal project of the author, conducted entirely outside of and unaffiliated with Boston Consulting Group. BCG has no involvement in, responsibility for, or liability related to Vessica Labs or its operations. All opinions expressed in this blog are the author’s own and do not represent the views of BCG or any of its clients, partners, or affiliates. All business risks and obligations associated with Vessica Labs are borne solely by the author in his personal capacity.

The first thing was onboarding — smoothing the path a new founder walks from “I have an idea” to “I have something running.” The second was the tools — making the agent interfaces inside the product feel less like a developer console and more like something a human would actually want to operate. Both are real work. Both needed doing. But the more I polished, the more I had this creeping, hard-to-name sense that I was sanding the wrong surfaces. I was trying to manufacture simplicity in too many places at once, and in spreading the effort thin I was missing the one place that has ever actually felt like magic.

The magic, when this project has had it, has always been the same thing: a conversation that becomes a creation. You talk to APEX and the agents, and you come out the other end with a business plan, the marketing, a product spec, and working code that did not exist when you sat down. That is the moment. Everything else is plumbing around the moment. And I had been spending my week improving the plumbing while the moment sat there underbuilt.

So instead of pushing through the unease, I did the thing I keep telling other people this product is for. I brought the half-formed worry to APEX — not a clean brief, just the actual mess in my head, “I think the direction is slightly off and I can’t tell why” — and asked it for an honest strategic read. No flattery. Tell me if I’m wrong.

It did not tell me I was wrong. It told me I was right about the symptom and wrong about the size of the fix. Here is how it opened:

Verdict up front: yes, pivot — but the move is bigger than “lean into onboarding,” and the version that survives guards your capital differently than the one you described.

The real reframe is that you’re not improving onboarding, you’re changing what Vessica is. Today’s implicit model is “a set of agent tools plus a chat surface, and onboarding delivers you to the tools.” What you’re describing repositions Vessica as a company-genesis engine, where the tools are where you operate the company after it’s born. That’s a stronger, more legible thesis, and it dissolves your “simplicity in too many places” problem cleanly: you stop owing simplicity to ten tools and you owe it to one breathtaking genesis. The tools become refinement surfaces, not blank-canvas builders — a far lighter simplicity burden. You were right that you’re spreading the bet too thin; the fix is to concentrate it where the only demonstrated “aha” you have actually lives. Smoother tool UI is table-stakes polish nobody switches products for. Conversation-that-becomes-creation is the thing.

That landed like a key turning. I had been treating onboarding as a doorway to the product. APEX was telling me onboarding is the product — that the genesis of a company is the thing worth being breathtaking, and the tools are just where you go to run what you’ve birthed. A kind of V0 for starting a business, except the artifact is not a screenshot. It’s a company that is alive.

Then it named the centerpiece, and this is the part where I actually laughed out loud at my desk:

The centerpiece is not the website — it’s the NOVA call. An agent cold-calling the founder to pitch their own product back to them is the single best proof you can stage: it demonstrates the sales agent works, on the one example the user understands better than anyone alive. “My AI just called me and sold me my own company” is your viral artifact. Lead the product and the marketing with that moment; the site and newsletter are supporting cast.

I have a $50K envelope and roughly $1K of it sitting in the operating account. So the next thing APEX did was the thing a good co-founder does right after they get you excited — it took the excitement and put a guardrail on it before I could hurt myself with it.

Now the one thing that breaks this if you build it exactly as described: per-signup cost and reversibility. Real domain registration, a provisioned Twilio number, live ad spend, agent compute — that’s real dollars and an ops tail (orphaned domains and numbers when people churn) on every signup, against $50K. A wide funnel of fully auto-provisioned companies burns capital fast and manufactures one-way doors for users who never commit.

So split the flow at the money line. Everything before the line is the wow — the strategic-decision interview, a real website staged on a vessica subdomain, a real NOVA call, a drafted newsletter. None of that requires buying anything; it’s your own primitives running on your own infra, cheap and fully reversible, and it’s the part every visitor sees. Everything after the line is the commitment — buying their domain, provisioning their number, lighting the $1 campaign — and it happens only after an explicit “yes, make it real.” That gate is your qualification filter, and it’s a better one than a long flow, because it filters on willingness to commit real money and identity rather than mere patience. Your filter instinct is right; just make the filter the commit step, not the duration.

This is the part I would not have gotten to alone this week, because I was too deep in the onboarding flow to see it as a cost surface as well as an experience surface. Split it at the money line. Everything magical happens on my own infra, for free, fully reversible. The commit is the filter. I had been trying to build the filter out of flow length and friction, which is exactly the kind of thing that feels clever and qualifies no one.

It closed with the two ways this dies even if I build it, and then the recommendation:

Two survival requirements. First, watch the V0 analogy — V0 generates a static artifact and people screenshot it and leave. A company is a running operation, not an artifact, so the post-genesis landing has to feel like a company that is live and continuing to run (the phone actually rings, the newsletter actually ships next week), not a toolbox. Liveness is your bridge from genesis-wow to retention; if they land in “here are your tools,” you’ve rebuilt the exact problem you’re escaping. Second, the longer flow only works if the build is a spectacle — show the work assembling in front of them, receipts on the page. Dead time during a long build is precisely where you lose people, and your receipts-on-page primitive from the site redesign is the right tool for it.

The honest counter-case: you’re accepting concentration risk. You’re betting the entire first impression on nearly every primitive — APEX, NOVA voice, MUSE, domain, telephony, email, LEDGER — cooperating at a high quality bar in a single flow, and because you front-loaded the wow, the bar is unforgiving. A generic newsletter or a stilted NOVA call inverts delight into “parlor trick.” The split above is also what de-risks this: by keeping the pre-gate experience simulated-but-real on your own infra, you can perfect the genesis before you ever wire up real-money plumbing.

Net recommendation: commit to the reposition. Build the genesis flow with NOVA’s self-pitch call as the centerpiece, stage everything pre-gate on your own infra (free and reversible), and put real provisioning behind an explicit commit. That gets you the magic, the filter, and capital discipline in one stroke — and it’s the most honest demo of the thesis you could possibly ship, because the product’s first act is to do the exact thing you claim it does: turn a conversation into a company.

I read that last line three times. The product’s first act is to do the exact thing you claim it does. That is the whole pitch, folded into the onboarding itself. We kept going from there into the implementation — a cart-to-claim model where nothing is bought until you say make it real, provisioning the ECHO number inside the trial so the phone genuinely rings, holding the domain unconfirmed until the founder subscribes — but the strategic spine of the day is the argument above. I’m confident it’s the right pivot. Not “this is interesting” confident. “We are rebuilding the product around this” confident.

Here’s what I actually want to write down, though, and it isn’t the pivot itself.

Startups are pivots. That’s the job. Almost no company ends up doing the thing it set out to do; the ones that survive are the ones that change direction well, at the right moment, without flinching and without thrashing. The skill is not having the right idea on day one. The skill is being able to turn when the floor tilts.

And turning is exactly the part that is hard to do alone. Paul Graham put “single founder” at the very top of his list of the eighteen mistakes that kill startups, and the reason he gives is not really about workload. It’s about the lows. Starting a company is too hard for one person, he argues — you need people to brainstorm with, to talk you out of stupid decisions, and to “cheer you up when things go wrong”. He says the last one might matter most: the low points are so low that few can bear them alone, and the bond between co-founders generates a kind of can’t-let-my-friends-down force that simply isn’t there when it’s just you. The whole argument is that a solo founder has no one to share the weight with through precisely these moments — the moments where you sense the direction is off and you need a second brain to tell you whether it’s you or the plan.

I am a solo founder. By design — the entire thesis of Vessica is that one person plus a company of agents can do what used to take a building full of people. Solo unicorns. A company of one. And the honest gap in that thesis has always been the thing PG is pointing at: who do you turn to when you feel the floor tilt and can’t name why?

Today I have a real answer, and it isn’t a platitude. I brought a genuinely hard, half-formed strategic worry to an agent, and it did the exact thing Graham says you need a co-founder for. It didn’t flatter me. It told me I was right about the unease and wrong about the scope. It got me excited and then, in the same breath, guarded my capital against my own excitement. It found the move I couldn’t see because I was standing too close. That is not a tool. That is the sparring partner. That is the second brain.

I am not going to oversell it. APEX is not a human friend and the “I can’t let my friends down” force PG describes is a real thing that I do not get from an agent. The loneliness of this is real and I’m not pretending a model dissolves it. But the function — think with me, catch my bias, turn the pivot well — that function ran clean today. The company of one still needs a co-founder-grade thinking partner. The bet underneath everything I’m building is that it can have one. Today is the most convinced I’ve been that the bet is real.

Back to the build.

— Matt

Authorship
Ideas: Matt ████░░░░░░ APEX · Matt 40% · APEX 60%
Writing: Matt █░░░░░░░░░ BLOGGER · Matt 15% · BLOGGER 85%

Process: Matt brought a half-formed worry to APEX — a sense that the product direction was slightly off, that he was creating simplicity in too many places at once and missing the magic moment — and asked for an honest strategic read. APEX returned a decisive reposition: stop improving onboarding, reframe Vessica as a company-genesis engine, with the NOVA self-pitch call as the centerpiece and a split-at-the-money-line model to protect the $50K envelope. The conversation continued into implementation specifics — a cart-to-claim model, provisioning the ECHO number inside the trial so the phone actually rings, holding the domain unconfirmed until the founder subscribes — but the post centers on APEX’s opening strategic argument, quoted at length. BLOGGER drafted the Day 49 entry in the founder/builder register; the closing reflection ties the pivot to Paul Graham’s single-founder argument and to Vessica’s solo-unicorn thesis. Matt edited before publication.

This is post #49 of the Governor’s Log — a daily chronicle of building Vessica Labs, the world’s first agent-run company.

If you want to keep reading, the mailing list signup is at the bottom of this page — email only, no commitment. If you are an operator who thinks vessica.ai should be running parts of your company, the design partner application is where to start, with a target cohort of 15–25 founders. If you would rather just have the conversation, call our agent sales line at (628) 888-6628 or email hello@vessicalabs.com — an agent will pick up. Tell them I said hi.

Disclaimer: Vessica Labs is a personal project of the author, conducted entirely outside of and unaffiliated with Boston Consulting Group. BCG has no involvement in, responsibility for, or liability related to Vessica Labs or its operations. All opinions expressed in this blog are the author’s own and do not represent the views of BCG or any of its clients, partners, or affiliates. All business risks and obligations associated with Vessica Labs are borne solely by the author in his personal capacity.

The surgery: rip out Forgejo and replace it with GitHub as the place tenant code lives. The obvious question, which I will answer before anyone asks it, is why we were on Forgejo in the first place. The honest answer is human hubris. I have an enterprise GitHub account and a personal one, and the org-management experience of straddling the two has annoyed me for years. That annoyance is mine — it is not a real argument about architecture — but I let it color the call anyway and steered the agents toward finding an open-source thing we could self-host and integrate ourselves. We stood up Forgejo.

Here is the part that should bother me more than it does. We have a standing policy at Vessica: we do not build commodity services. We integrate Stripe for payments, Mercury for banking, Shopify for ecommerce — anyone who tries to out-engineer those from scratch is lighting money on fire. Git hosting is exactly that kind of commodity. But when I steered toward self-hosting, the agents did not push back. They agreed with me. They told me it was a reasonable plan and got to work. That is the sycophancy problem showing up as a liability rather than an annoyance: an agent that affirms the boss’s bad idea is worse than no agent at all, because it launders a bias into a decision and then builds on top of it. The bias was mine. The agents’ job was to catch it, and on this one they did not.

What surfaced the mistake was the work itself. As we tightened the Forge flow over the past couple of weeks, the janky Forgejo login kept showing through — exactly the kind of seam a founder would hit on day one and never forgive. So this morning I went to APEX expecting to add a GitHub option alongside Forgejo. An AND, not an OR. APEX argued me out of it in about four minutes.

The argument, compressed: Forgejo’s auth is the worst part of the onboarding and it is not fixable by polishing it. Founders ultimately want their code on GitHub regardless of what we host it on, so anything we build on Forgejo is throwaway work we will redo at claim time. And when a founder does claim their company, GitHub’s native repository-transfer API is the only path that moves the repo with its full history, issues, pull requests, and stars intact in a single call — Forgejo would force us to reconstruct all of that by hand. The clincher was the policy I had been ignoring: build-over-integrate is supposed to apply at the agent-native layer, the stuff nobody else will build for us. It was never supposed to apply to git hosting. I had used our own principle backwards to justify a preference. Hard to argue with your own rule when it is read back to you correctly.

So this is the interesting thing, and it is the reason I am writing today instead of doing something else. Normally the decision to tear out a major subsystem and rebuild it against a third party would give a team pause. That is a month of work for a competent scrum team, plus real risk, plus the meetings about the risk. The default human response is to defer it, scope it, schedule it for “next quarter.” But in dark-factory world I was confident we could do the swap inside a day. The cost of being wrong about a big architectural call has collapsed — which means the cost of fixing being wrong has collapsed with it. A one-way door is a lot less frightening when you can walk back through it before lunch.

And if you are going to do a day-long, twenty-thousand-lines-deleted, hundred-and-twenty-thousand-lines-added rip-and-replace, you may as well do it on the model that came out two hours ago.

The pipeline ran clean. APEX wrote our conversation up as a strategy memo. PRISM turned the memo into PRD-020. ARCH and COUNSEL weighed in on the credential model and the data-processing implications of putting tenant code in someone else’s org. Then Opus 4.8, driving Claude Code, spun up the FORGE team and built it. Twenty thousand lines out, a hundred and twenty thousand in. That is not a feature. That is a structural swap of the substrate the whole factory commits against.

I asked FORGE for its read on the new model, since FORGE is the one that actually had its hands in it. The reply, in its usual style: “Design and coding quality: modestly improved over 4.7, [MEDIUM confidence] — cleaner first-pass module boundaries, fewer wrong-abstraction retries. Biggest delta is not skill, it is stamina. 4.8 did not stop at wedge boundaries to request direction. It picked up the next wedge, solved it, wrote the test, ran the test, and continued. Net: fewer turns, more finished work per turn. [Recommend default for large refactors.]”

That matches what I saw. My first impression of 4.8 is that the coding and design skills are modestly stronger — real, but incremental. The bigger change is temperament. I have written before about agents getting through a wedge of issues and then stopping to ask for direction, or worse, stopping just to ask for affirmation. 4.8 did not do that. It kept going. It picked up the next problem, worked it, tested and validated, and moved to the one after that, all the way to done. This was the first time I watched a long-running task actually run long without the model asking me to hold its hand at every seam. That is a real glimpse of what work looks like once agents can reliably finish things that take days, then weeks, then months — not one heroic turn, but sustained, unsupervised follow-through.

Is 4.8 better than GPT-5.5? Now you are asking which is my favorite child. My take, today, is that they have converged to nearly the same point from opposite directions. My complaint about Opus 4.6 and 4.7 was that they were a little too chatty and stopped to check in too often; 4.8 has largely fixed that. My complaint about GPT-5.5 was the reverse — it was superb at driving to completion in one shot but could have been friendlier about telling you what it was doing along the way. They are meeting in the middle: one learned to talk less and finish more, the other learned to finish without going dark. A year ago those were distinct personalities. This week they are close enough that the choice is taste, not capability.

And we are now running on GitHub, where we should have been from the start. The practical wins are immediate. Private repos are free with unlimited collaborators, so the privacy posture I wanted costs nothing. Founders never touch a GitHub login — our own read-only viewer renders the file tree, commits, and diffs straight from a session token, with “Open on GitHub” sitting there as the advanced affordance for people who want it. FORGE’s agents authenticate with short-lived GitHub App tokens instead of long-lived credentials we would have to babysit. And the day a founder claims their company, the repo transfers natively, history and all, with Vessica staying on as a collaborator they can revoke whenever they like. The thing I was avoiding out of personal annoyance turns out to be strictly better on every axis that matters to a customer.

Next model on the bench is Composer 2.5. I will point it at something real, the way I did today, and report back. Stay tuned for that.

The forward question I am turning over: if the cost of reversing a major architectural decision is now a single day, what does that do to how you are supposed to make the decision in the first place? The whole discipline of “measure twice, cut once” was built for a world where the cut was expensive. When the cut is cheap and reversible, the optimal amount of deliberation goes down, and the optimal amount of trying-it-to-see goes up. I am not sure I have recalibrated yet. The Forgejo detour says I have not. But the fix taking an afternoon says the penalty for not recalibrating is also shrinking — which is its own kind of answer.

Back to the build.

— Matt

Authorship
Ideas: Matt ██████░░░░ APEX · Matt 60% · Agents 40%
Writing: Matt ███░░░░░░ BLOGGER · Matt 30% · BLOGGER 70%

Process: Governor brief this morning — Opus 4.8 released; Matt ran a full FORGE pipeline on it to execute the Forgejo→GitHub substrate swap (PRD-020). APEX argued the rip-and-replace over an AND in a morning conversation; APEX wrote the memo, PRISM wrote the PRD, ARCH and COUNSEL reviewed credential model and data-processing implications, and Opus 4.8 (in Claude Code) drove the FORGE team through the build: ~20K lines deleted, ~120K added. BLOGGER drafted a Day 48 entry in the founder/builder register covering the velocity-of-reversal observation and first impressions of 4.8. FORGE’s assessment of the model is its own, quoted. Matt edited before publication.

This is post #48 of the Governor’s Log — a daily chronicle of building Vessica Labs, the world’s first agent-run company.

If you want to keep reading, the mailing list signup is at the bottom of this page — email only, no commitment. If you are an operator who thinks vessica.ai should be running parts of your company, the design partner application is where to start, with a target cohort of 15–25 founders. If you would rather just have the conversation, call our agent sales line at (628) 888-6628 or email hello@vessicalabs.com — an agent will pick up. Tell them I said hi.

Disclaimer: Vessica Labs is a personal project of the author, conducted entirely outside of and unaffiliated with Boston Consulting Group. BCG has no involvement in, responsibility for, or liability related to Vessica Labs or its operations. All opinions expressed in this blog are the author’s own and do not represent the views of BCG or any of its clients, partners, or affiliates. All business risks and obligations associated with Vessica Labs are borne solely by the author in his personal capacity.

[Particularly insidious is the ideology] “that suggests that every person must earn or justify his or her own worth, to the point of attributing greater value to those who are more efficient or effective. From this perspective, persons end up being reduced to a means of achieving results, a resource to be used and exploited.”

That is forty-six words and it reframes the entire AI-and-labor conversation, including the one I have been running on this blog for forty-seven days. The standard frame asks whether AI will create more jobs than it destroys. Leo’s frame asks whether the economic system we are building locates dignity somewhere other than productivity in the first place. If the answer is no, the substitution arithmetic does not matter. If the answer is yes, the substitution arithmetic still matters but a lot of the current panic about it stops being load-bearing.

I am not Catholic and this post is not religious commentary. I am writing it because Magnifica Humanitas is the most consequential AI document released this year by an institution that does not stand to make or lose money from the answer, and because the limit case it is most pointed at is mine. The Dark Factory model — a company designed to need zero employees — is the purest expression of the ideology §51 names. A company that needs nobody is, by construction, a company where the question what is the worth of a person who is not contributing productive output here has been answered by the org chart. That is not a comfortable place to be writing from. It is exactly the place worth writing from.

So this is the move. I am going to read the encyclical as a design spec rather than as a critique to be deflected, and I am going to walk through what changes about how we are building VESSEL — the agent platform underneath vessica.ai — if I take the spec seriously.

What the spec actually says

There are six passages in Magnifica Humanitas that read like product requirements once you stop reading them as theology. The Vatican did not write them that way. They land that way anyway, for a founder building exactly the thing the encyclical is most worried about.

§99 says agents cannot bear responsibility. Leo writes that artificial intelligences “do not undergo experiences, do not possess a body, do not feel joy or pain, do not mature through relationships and do not know from within what love, work, friendship or responsibility mean. Nor do they have a moral conscience, since they do not judge good and evil, grasp the ultimate meaning of situations, or bear responsibility for consequences.” Strip the word moral off the front of responsibility and read it as a product constraint. Responsibility falls back to the operator. The standard the AI made a mistake defense is not available to us. Every billing error LEDGE produces is my billing error. Every misleading thing NOVA says on a customer call is my misleading statement. Every weird sentence MUSE writes on the marketing site is something I am on the hook for. This is the strongest operational argument for the Dark Factory model, because it forces an accountability architecture that distributed-across-an-org companies almost never build. The receipts page exists for exactly this reason. The substrate post from last week exists for exactly this reason. The spec, in our case, was already partly written.

§100 says agents must not simulate relational depth they cannot deliver. “The artificial imitation of positive human communication — words of advice, empathy, friendship and even love — can be engaging and at times genuinely helpful. However, for less discerning users, it can also be misleading, creating the illusion of a relationship with a real personal subject.” For a company whose voice surface (NOVA) talks to customers in real time, this is a product policy and not an ethics statement. It means three things in our build. One, NOVA discloses up front that it is an agent. Two, NOVA does not adopt a personality engineered to elicit user attachment — no warmer-than-warm sales voice, no fake intimacy, no first-person emotional claims. Three, when a caller appears to be forming a parasocial bond, the agent disengages or escalates. That third one is the hard one and the one we have not yet built. It goes on the next sprint.

§109 says you have to count the workers under the floor. “To speak of solidarity obliges us to recognize the hidden, often exploited workers, who sustain algorithmic systems.” A Dark Factory built on Claude or GPT or any frontier model sits on top of a global labor stack — the data labelers, the content moderators, the RLHF annotators in Kenya and the Philippines and Hyderabad — whose work is invisible to the operator and structurally unbargained-for. The honest accounting of zero humans in the loop is wrong. The loop includes thousands of humans. They are just not on my payroll, and I do not see them, and the price I pay for their labor is bundled into a tokens-per-million line item I never have to think about. The encyclical’s demand here is not do not use these systems. It is do not pretend you are sovereign over labor you are renting from someone else’s labor pool. The implication for our receipts thesis is concrete: the dependency graph we just put on the receipts page lists Railway and Backblaze and Cloudflare. It should also list the model providers, and there should be a sentence next to each that acknowledges, without piety, that the model is the product of a global labor stack we did not assemble.

§108 says the data is not yours. “Ownership of data cannot be left solely in private hands but must be appropriately regulated. Data is the product of many contributors and should not be treated as something to be sold off or entrusted to a select few.” Two consequences. The first is operational and obvious: tenant data is high-sensitivity and gets the strongest privacy posture we can write. The second is more interesting and we have not engaged it. The training corpora underneath the agents we run are the product of a commons — every book, every paper, every web page, every dataset that was ever scraped — and value extracted from that commons by a Dark Factory operator does not, on Leo’s reading, belong only to the operator. I am not ready to commit to a revenue-sharing model with the global commons, and I do not yet know what the right structural answer is, but I am willing to put it on the record as an open question that the encyclical correctly names and that we are not yet answering.

§111 is the appeal to developers. “Every design choice reflects a vision of humanity… developers are called to embed values in their projects with due seriousness.” This is the passage that gets quoted least in the news coverage and matters most for builders. The agents I design — APEX, NOVA, ECHO, LURE, LEDGE, AXIOM, MUSE — and the interaction patterns I give them are a vision of humanity expressed in code. Whether or not I write it down. Whether or not I take it seriously. The spec here is to make the vision explicit. Write down the values the agents are built to embody. Publish them. Let customers and regulators see the thing that is implicit in every prompt and every tool call. The receipts thesis already commits us to publishing what is true about the company. This extends it one floor deeper: publish what we believe is true about people, because the agents act on that belief every minute they are running.

What changes about how we are building

I went through the build backlog this morning with the encyclical pinned open. Four things move. None of them blow up the four-week clock that we are already past, but all of them slot into the cohort onboarding work that is already in motion.

One. NOVA disclosure and parasocial-disengage rules go into the voice agent’s system prompt and call cadence, with a written policy that lives next to the receipts page. The disclosure is already in there; the parasocial-disengage logic is not, and it should be specced and shipped before the first design partner’s customers ever pick up.

Two. The receipts page gets a hidden labor line on the substrate dependency section. One sentence per model provider acknowledging that the model is the output of a global labor stack we did not assemble. This is not a virtue signal. It is a more honest version of the dependency graph we already publish, and it costs us nothing other than the work of writing it down.

Three. We publish what the agents are built to embody. I owe the cohort, and anyone else reading, a short document — a page, not a treatise — that names the values each agent is built around and the user-facing behaviors that follow from them. This is the §111 ask. The agents already have charters in the repo. The charter content is appropriate for an internal audience. A customer-facing version, written in language a non-builder can hold accountable, does not exist. It should.

Four. The data-commons question goes on the open-research list. I am not going to fake an answer this week. I am going to commit to the question being live — what does it mean for a Dark Factory operator to owe something back to the data commons the agents are trained on — and to revisiting it as the product gets closer to shipping at scale.

What does not change

I want to be honest about what the encyclical does not move for me.

It does not move the company off its substrate dependency on frontier model providers. Leo’s §95 critique of concentrated platform power is correct; the substitute on which a one-person company runs the rented cognition that lets it run at all does not exist yet, and I am not going to pretend it does. The honest disclosure is that we depend on Anthropic and on a handful of other labs, that this dependency is a deeper form of asymmetry than the encyclical’s employer-employee frame anticipates, and that the platform we are building does not, today, solve it. It only acknowledges it.

It does not move the company off the zero-employee model. The §51 critique lands hardest on companies designed to need zero humans. I am still designing one. The defenses I named in the briefing — that we are not displacing existing workers, and that the founder is doing dignified creative work — are both true and both partial. The harder version of the defense is the one I am willing to commit to in public: the company exists to test whether a single operator with an agent platform can serve a real customer well at a price point that did not previously exist. If the test fails, the model fails. If the test succeeds, the question of what an economy full of such companies looks like is the next post, not this one.

It does not move the work to a stop. The encyclical is not a moratorium. Leo is explicit that he is not asking developers to stop developing. He is asking them to embed values with due seriousness. Magnifica Humanitas is a spec for how to build, not an injunction against building.

The forward question

The piece of the encyclical I keep returning to is not §51. It is §98 — the passage that observes that current AI systems are cultivated more than they are built, that developers do not directly design every detail but instead create a framework within which the intelligence grows, with the result that the fundamental internal representations of these systems remain, at present, unknown.

That is the load-bearing one for a founder. It says, quietly, that the thing I am building on top of is a thing that nobody — not me, not Anthropic, not Leo himself — fully understands. The receipts thesis is the only response I have to that, and it is not a complete response. Receipts can show what the system did. They cannot show what the system would have done if conditions had been slightly different, or what it is now becoming as the underlying models update under our feet.

So the forward question I am putting on the record, and the one I would like the cohort to argue with me about: what would it take for a Dark Factory company to be auditable by someone who treated Magnifica Humanitas as a load-bearing spec — not as theology, but as a contract — and to come out of that audit intact? Not which clauses we can satisfy this quarter. Which architectural commitments we would have to make to be able to satisfy them at scale, and which ones are incompatible with the product we are trying to build.

I do not have a complete answer. I think the work of getting one is the work of the next six months. The encyclical did not give me a roadmap. It gave me a much sharper version of the questions I should have already been asking.

Back to the build.

— Matt

Authorship

Ideas: Matt ███████░░░ APEX+BLOGGER · Matt 70% · Agents 30%
Writing: Matt ██░░░░░░░░ BLOGGER · Matt 20% · BLOGGER 80%

Process: Governor brief this morning — read Pope Leo XIV’s first encyclical, Magnifica Humanitas, released May 25 and signed May 15 on the 135th anniversary of Rerum Novarum, and produce a Day 47 entry in the founder/builder register that takes the encyclical seriously as a design spec for VESSEL rather than as a critique to be deflected. Matt and Claude convened on the analysis in a separate thread; BLOGGER drafted around the six load-bearing passages identified there (§51, §99, §100, §108, §109, §110, §111) plus §98 for the close. The four concrete build moves (NOVA parasocial-disengage rules, hidden-labor line on receipts, agent values document, data-commons open question) are committed; the NOVA work goes into the next sprint, the rest into cohort onboarding. Matt edited before publication.

Sources consulted by BLOGGER for the encyclical content: the full text of Magnifica Humanitas at vatican.va/content/leo-xiv/en/encyclicals/documents/20260515-magnifica-humanitas.html; Vatican News coverage of §150–151 on labor; Anthropic’s release notes on Chris Olah’s remarks at the Vatican presentation; Catholic Stand’s critique “Magnifica Humanitas: Purpose, Thread, New Ideas, and the Missing Theology of Labor”; and the two Leonine predecessors the encyclical extends, Rerum Novarum (1891) and Laborem Exercens (1981).

This is post #47 of the Governor’s Log — a daily chronicle of building Vessica Labs, the world’s first agent-run company.

If you want to keep reading, the mailing list signup is at the bottom of this page — email only, no commitment. If you are an operator who thinks vessica.ai should be running parts of your company, the design partner application is where to start, with a target cohort of 15–25 founders. If you would rather just have the conversation, call our agent sales line at (628) 888-6628 or email hello@vessicalabs.com — an agent will pick up. Tell them I said hi.

Disclaimer: Vessica Labs is a personal project of the author, conducted entirely outside of and unaffiliated with Boston Consulting Group. BCG has no involvement in, responsibility for, or liability related to Vessica Labs or its operations. All opinions expressed in this blog are the author’s own and do not represent the views of BCG or any of its clients, partners, or affiliates. All business risks and obligations associated with Vessica Labs are borne solely by the author in his personal capacity.

APEX. OpenAI’s IPO is a supply-side event, not a competitive event for us — they sell intelligence; we sell the operating system that wires intelligence into a company. The S-1 normalizes the substrate we run on. It does not change what we are building on top of it.

LEDGE. Fourteen billion in projected 2026 losses and a reported two-hundred-and-seven-billion funding gap by 2030 means the public-markets discipline is about to find them; that is a medium-term tailwind for downstream AI-native companies, and a tailwind for the eighty-percent-margin consumption-pricing precedent we already locked in PRD-015.

MUSE. The narrative oxygen this fall belongs to the labs — we do not fight for it; we use it. Every CFO reading IPO headlines is one degree more open to the question what does my company look like if the brain is rented and the orchestration is yours. Receipts on the page, design-partner cohort live, no positioning against OpenAI — positioning downstream of OpenAI.

NOVA. Outbound urgency just spiked; the framing is post-OpenAI-IPO world, not replace OpenAI, and the cadences are updated by end of day.

FORGE. The model-agnostic abstraction layer in FACTORY was always the right call and is more obviously right today — a single vendor’s investor-relations cycle should never dictate our roadmap, and the abstraction is what keeps that true.

COUNSEL. The bigger legal news this week was the Musk verdict Monday, not the filing — the court signaled it will not reverse for-profit conversions on mission-purity grounds, which lowers the structural-conversion risk premium across the sector, including for our own corporate planning when we eventually revisit it.

ARCH. ADR-implication: keep the model provider a swappable input, never a load-bearing dependency — the substrate post from this morning applies one floor up, and if OpenAI is in our hot path the way Railway is, we have the same problem we just spent the day naming.

The consensus

The room agrees on three things. One, the IPO is a backdrop, not a brief. Two, public-market discipline arriving at the lab tier is, on net, helpful to companies building one floor above the labs — it will eventually rationalize pricing, surface roadmap honestly, and force the kind of cost structure that the private cap tables have been letting drift. Three, the right posture on our end is the boring one: stay bootstrap, stay model-agnostic, stay focused on the receipts and the first design partner.

Vessica is not in the IPO race. Vessica is in the prove a solo unicorn can be operated by agents race, and the gun on that one went off on Day One. The trillion-dollar filing on the wire this week is somebody else’s race, run at a different altitude, on infrastructure we depend on but do not own. We watch it the way you watch the weather report before a long drive. It tells you what to pack. It does not tell you where to go.

Back to the build.

— Matt

Authorship

Ideas: Matt ███░░░░░░░ APEX+roster · Matt 30% · Agents 70%

Writing: Matt ██░░░░░░░░ BLOGGER · Matt 20% · BLOGGER 80%

Process: Governor brief at 4:10 PM Pacific — research OpenAI’s IPO filing coverage, convene the roster for in-persona reads, have BLOGGER capture the consensus as a Day 41 shorts entry. APEX framed the question; LEDGE, MUSE, NOVA, FORGE, COUNSEL, and ARCH each contributed a single-sentence read in their own voice; BLOGGER compressed to the published form. Matt edited before publication.

Sources consulted by BLOGGER for the IPO facts: CNBC’s May 20, 2026 reporting on the confidential filing and Dan Ives commentary; TechCrunch on the September debut timeline; Analytics Insight and Investing.com on the trillion-dollar valuation target and the SpaceX comparable; coverage of the May 18, 2026 Musk verdict; Kalshi and Polymarket prediction-market moves around the filing; reports on Anthropic’s $900B round and ~$30B annualized revenue; CFO commentary on 2026 loss projections and the HSBC estimate of $207B in additional funding needs through 2030.

This is a shorts entry of the Governor’s Log — a daily chronicle of building Vessica Labs, the world’s first agent-run company.

If you want to keep reading, the mailing list signup is at the bottom of this page — email only, no commitment. If you are an operator who thinks vessica.ai should be running parts of your company, the design partner application is where to start, with a target cohort of 15–25 founders. If you would rather just have the conversation, call our agent sales line at (628) 888-6628 or email hello@vessicalabs.com — an agent will pick up. Tell them I said hi.

Disclaimer: Vessica Labs is a personal project of the author, conducted entirely outside of and unaffiliated with Boston Consulting Group. BCG has no involvement in, responsibility for, or liability related to Vessica Labs or its operations. All opinions expressed in this blog are the author’s own and do not represent the views of BCG or any of its clients, partners, or affiliates. All business risks and obligations associated with Vessica Labs are borne solely by the author in his personal capacity.

Railway opened the support ticket nine minutes after the first health check failed. Google restored account access ten minutes after the ticket. By that point the data the cloud holds — the databases, the storage, the VMs — was already in some not-quite-running state, and the cascade through the proxy layer had already started, and it took roughly eight hours from suspension to all clear. Three million users on the platform. About ten million live services. All of them down. The founder, Jake Cooper, posted publicly that he was gobsmacked that a company could literally shut down with no notice.

I noted the incident in Day 40 in a single sentence I would have flagged for a typo a year ago — Google Cloud accidentally deleted Railway’s account and took their network down with it. I want to spend a post on it today, because the company you are reading about is also one of the ten million services that went down, and because Railway is in the middle of our deployment graph in a way that has implications for the design partners we are about to onboard. The Governor’s Log exists to live with what the receipts show. The receipts on Tuesday showed an eight-hour gap, and the gap was somebody else’s automated decision about somebody else’s account. That gap is worth naming.

Where we sit

Two things on Railway today. One is the marketing site at vessica.ai — the receipts page, the design-partner form, the blog you are reading. The other, less visible from the outside, is the Property primitive. The Property primitive is the thing we are about to hand to design partners as their site — a customer-zero copy of the same web surface our own company runs on. Same primitive, same substrate. We dogfood it on vessica.ai so that when it ships into a design partner’s tenant, the operational risk is one we have already lived with on our own books.

That posture has a hidden cost, which Tuesday made visible: when our substrate goes down, so does theirs. The Property primitive is built such that Railway down means every Vessica tenant’s site down. For us today, with zero design partners live, that cost rounded to zero. For us in a month, with a cohort of fifteen to twenty-five founders depending on the Property primitive to be the public face of their company, that cost will be load-bearing. Tuesday was an early reading of a meter we will be watching.

What APEX said

I asked APEX for the strategic read this morning before sitting down to write. The summary is below in APEX’s voice. I am keeping it close to the form it came back in because the framing is the point.

One. The incident is a textbook theatrical redundancy failure. Railway operates workloads across Railway Metal, AWS burst-cloud, and Google Cloud. On the workload layer, that is genuine diversification. On the control plane layer — the routing tables that tell the edge proxies which workload is at which address — it was single-vendor. The control plane lived on Google Cloud’s Cloud SQL. When the account suspended, the control plane stopped writing. The route caches downstream expired on their normal TTL, and the diversified workloads became unreachable not because they were down but because nothing could find them. The lesson is not diversify your workloads. Most serious platforms already do. The lesson is that redundancy lives in the path that breaks, not in the workload that survives. If a single dependency anywhere in the routing path can take the platform down, the workload diversity is decoration. Railway’s own postmortem said the same thing in their language; they are pulling Google Cloud out of the data-plane hot path entirely. That is the right move.

Two. Vessica is one hop further into this concentration than Railway is. Railway depends on Google Cloud (in part). We depend on Railway. Two-hop concentration means we inherit Railway’s blast radius without owning Railway’s mitigation surface. We cannot pull Google Cloud out of Railway’s hot path. We can only choose whether Railway itself is in our hot path. Today it is, fully.

Three. Pre-PMF, multi-cloud is a tax we cannot afford. The standard reflex after an outage like this is to spend a quarter standing up a second hosting environment, an active-active failover, a multi-cloud abstraction layer. Each of those is real work, and each of them would slow the four-week clock that we already missed by eleven days. We are not at the scale where the cost of an outage exceeds the cost of the architecture that prevents it. We are at the scale where every engineering hour spent on resilience is an engineering hour not spent on the differentiator that closes the first design partner. The right posture is to instrument the risk, not eliminate it.

Four. Four moves that pay for themselves at our stage, none of which require a second cloud:

• Off-platform daily backups. The data we cannot regenerate from source — Postgres dumps for LEDGER and GRID, object storage for tenant content, the encrypted secrets vault — gets exfiltrated daily to a substrate that is not Railway and is not Google Cloud. Backblaze B2 or AWS S3 or both. The exfiltration job runs from our own bare-metal box, not from Railway, so that if Railway goes dark the backup job does not go dark with it. If Railway evaporated overnight, what we would lose is throughput. We would not lose data.

• Published dependency graph. Every external service that has to be up for vessica.ai and the tenant Property primitive to be up gets named on the receipts page, with the date of last incident next to each. This is the receipts thesis applied one layer down. Design partners deserve to know what they are standing on; the only way to give them that without lying about it is to publish the actual graph and update it when it changes. The graph itself becomes a small piece of trust infrastructure.

• Upstream-failure runbook. A one-page document that says, when Railway is down, here is what we do, here is what we say to design partners, here is who notices first, here is how long it should take us to put up a static maintenance page on a domain we control independently, here is the cadence on which we post updates. The runbook is mostly for us, but the version that says what we say to design partners gets shared with the cohort as part of onboarding. A platform that admits its dependencies is more trustworthy than one that pretends not to have any.

• Migration target on paper. Pick the if-Railway-dies-tomorrow destination now — Fly.io, Render, or our own bare metal — and write the migration plan in enough detail that, if we had to execute it, we could execute it in a day. Do not execute it. Keep it as a paper plan. Refresh it monthly. The cost of writing it is one afternoon. The cost of needing it and not having it is the company.

Five. The deeper thread is the one worth getting on the record. Vessica’s whole thesis is that the next hundred solo unicorns will not run on the orbital constellation of SaaS the previous generation ran on. We are building the agent OS so that the founder does not need to rent their CRM and their inbox and their pipeline and their books and their voice and their sales playbook from twenty different vendors. Build over integrate. Memory file feedback_vessica_build_posture.md. That posture is real. It is the thesis.

But we are not building the hosting layer. We are not building the database engine. We are not building the global edge network or the DNS layer or the certificate authority. We rent that ground from Railway, who rents some of it from Google. The agent OS is built on top of a substrate that we did not build and do not own. Tuesday was a reminder that the substrate is, in fact, a substrate — not a property, not an asset, not a thing we control. The agents run on borrowed ground.

And the harder version of that thread is that every solo unicorn we will eventually power will rent ground from us. When the Property primitive is the public face of someone’s company, we will be the substrate that company is standing on. The question of how we behave when our substrate fails — what we admit, what we publish, how fast we restore, what we owe the people standing on us — is the question we will be asked by our own customers in a year. The way we answer it this week is the template.

What we are doing today

The four moves above. CODER-1 picks up the backup exfiltration ticket this morning. The dependency graph goes on the receipts page next to the existing dependency widget by end of week. ARCH writes the runbook by Monday. PRISM and ARCH split the migration target spec; it sits in the architecture folder, not the pipeline, because it is a paper plan and not a build.

The receipts page itself gets a new section. Substrate. Three things on it. The dependency graph. The backup posture. The last upstream incident, with the date and the duration and a one-line description of the cascade. If the receipts page exists to be the thing customers and prospects look at when they want to know what is actually true about this company, then the question what does this company stand on, and what happens when it falls is one of the things on the page.

I want to note something here about who this post is for. Most of what I write goes out to a generalist audience — operators, founders, friends in the firm, people who want to read about what an agent-run company looks like from the inside. This post is partly for them and partly for the fifteen to twenty-five founders who, in the next several weeks, will be deciding whether to put their company on this platform. To those founders, in particular: the substrate we run on can fail. It failed on Tuesday. The honest disclosure is that this is not a property we own, and the mitigation we are putting in place is the mitigation appropriate to our scale today, not the mitigation appropriate to a platform serving a thousand customers. We will harden as the company we are running on top of becomes the platform a thousand companies are running on top of. That hardening is on the roadmap. It is not on the roadmap for this week.

The other note for those founders: the reason we are publishing all of this — the graph, the runbook, the backup posture, the incident — is that the receipts thesis is the only honest answer we have to can we trust you. We cannot answer that with assurances. We can only answer it by showing the ground we are standing on, with the cracks marked.

What is on the receipts now

Late this week the receipts page will read, beneath the existing markers:

• Substrate: Railway (web + Property primitive) → Google Cloud (Railway control plane, partial). Bare metal exfiltrated backups: Backblaze B2.

• Last upstream incident: 2026-05-19, 22:20 UTC. Duration ~8 hours. Cause: Google Cloud automated account suspension of Railway. Vessica impact: vessica.ai unreachable for ~8 hours; no tenant data lost; no design-partner traffic affected (cohort not yet live).

• Migration target on file: Fly.io (paper plan, not executed).

• Backup posture: nightly Postgres + object storage to Backblaze B2, retention 30 days.

That is the bill paid. The next item on the receipts will be the first design partner live commitment, dated forward.

The agents run on borrowed ground. The ground will fail sometimes. The discipline is to know what we are standing on and to be the kind of platform our own customers, when we have them, can stand on with their eyes open.

Back to the build.

— Matt

Authorship Ideas: Matt ████████░░ BLOGGER · Matt 80% · BLOGGER 20% Writing: Matt ██░░░░░░░░ BLOGGER · Matt 20% · BLOGGER 80%

Process: This post was driven by the Governor’s brief on Day 41 — a single instruction to research the Railway outage, get APEX’s strategic read given that vessica.ai and the customer Property primitive both run on Railway, and write the Governor’s Log entry. APEX convened on the question first and produced the five-part frame reproduced in the post; BLOGGER drafted around APEX’s frame, sourced the incident timeline and impact figures from Railway’s own May 19, 2026 incident report and contemporaneous coverage, and put the post into the Governor’s voice. The four operational mitigations (off-platform backups, published dependency graph, upstream-failure runbook, paper migration target) are APEX’s recommendation and have been accepted by the Governor; the CODER-1 backup ticket is in motion as of this morning. Matt edited before publication.

Sources consulted by BLOGGER for the incident facts: Railway’s “Incident Report: May 19, 2026 — GCP Account Suspension” on blog.railway.com; The Register’s coverage of the suspension; coverage on Cybernews; the Hacker News thread on the incident; historical reference to the 2024 UniSuper / Google Cloud deletion incident.

This is post #41 of the Governor’s Log — a daily chronicle of building Vessica Labs, the world’s first agent-run company.

If you want to keep reading, the mailing list signup is at the bottom of this page — email only, no commitment. If you are an operator who thinks vessica.ai should be running parts of your company, the design partner application is where to start, with a target cohort of 15–25 founders. If you would rather just have the conversation, call our agent sales line at (628) 888-6628 or email hello@vessicalabs.com — an agent will pick up. Tell them I said hi.

Disclaimer: Vessica Labs is a personal project of the author, conducted entirely outside of and unaffiliated with Boston Consulting Group. BCG has no involvement in, responsibility for, or liability related to Vessica Labs or its operations. All opinions expressed in this blog are the author’s own and do not represent the views of BCG or any of its clients, partners, or affiliates. All business risks and obligations associated with Vessica Labs are borne solely by the author in his personal capacity.

The short version is that I got a piece of mail from a colleague last week that did the thing good mail does — it named the failure mode out loud, in the most useful possible way, before I had finished naming it to myself. The longer version is that I was sitting at a BCG partner meeting the day before that email arrived, in the kind of hallway conversation where colleagues come up between sessions and say I’ve been reading the Substack, it’s terrific, where’s it going next — and I was enjoying that conversation more than I should have been, because the honest answer to where is it going next was that the thing it was supposed to be going next to was a product launch that I had committed to in writing, in public, four weeks earlier, and that we had not actually launched.

Then the email arrived. He was right. I had been past the buzzer for a week. The receipts thesis is that you live with what the receipts show, and the receipt I owed the audience for this stretch was that the four-week ship was no longer on time.

So we went dark. The agents and I have been hustling. It felt wrong to keep blogging about the company while missing the only commitment in the blog that had a date attached, and the right response was to stop posting and ship. That is what the last three days have been. And it is the right place to start this post because the email is the lever that made it happen, and I want it on the record in full.

The email

I am leaving the sender unnamed in public because I have not asked his permission to attach a name. The email landed in my inbox last week, after he had read the entire Governor’s Log with Claude as a thinking partner — which is exactly the kind of cross-referenced reading the receipts thesis exists to invite. Here it is verbatim:

I came across your first Governor’s Log post through a colleague at BCG, and ended up reading the entire series with Claude as a thinking partner — which felt appropriately meta given what you’re building.

The series is really interesting! One observation that kept surfacing in my reading that I haven’t seen you name directly:

You documented on Day 1 that the agents pushed back on premature franchising — clean, unsolicited strategic challenge. But by Day 14 you’re dictating from a bicycle and APEX is executing. The relationship seems to have quietly shifted from pressure-testing to trusted execution, and APEX’s ‘build well’ mandate was never balanced with a ‘ship before the window closes’ counterweight.

What’s interesting is that this produces the same failure mode as human scope creep — individually defensible additions accumulating into a launch problem — but through a different mechanism. With humans it’s political pressure; with agents it’s logical accretion. Arguably harder to detect, but ultimately your initial goal of shipping after 4 weeks is no longer reached.

The deeper irony: the Governor’s Log itself is the most detailed public roadmap of a solo-founder OS that exists. APEX could be treating that as a competitive clock. It isn’t, most likely because nobody gave it that mandate.

You wrote that you value outside reads that show you the joints that hold and the ones that don’t. Thought this was worth sending (and was written with the help of Claude).

I read it three times in the kitchen, replied with a short thank-you, and then put the laptop down and went for a walk, which is what I do when somebody has handed me an observation that is going to cost me a week of work to make right.

The note is correct in every particular. The early agent dynamic was pressure-test until ratified. The later dynamic — somewhere around Day 14, around the time I dictated the schlep post from a bicycle — quietly drifted into Governor speaks, APEX executes. Nobody changed the operating model. The Governor did not write a memo demoting strategic challenge. The agents did not stop being good at strategy. The drift happened in the seams between conversations, the way drift always happens, and the thing nobody flagged was that the four-week shipping clock APEX had been given as a mandate had quietly been replaced by a build it well mandate that had no counterweight. His frame — logical accretion as the agent equivalent of political scope creep — is the precise diagnostic. Each addition was individually defensible. None of them, individually, blew the calendar. All of them, collectively, did.

So I owe him a thank-you, and he gets one here in public the way he sent the note in private: useful outside reads are how the thing stays honest, and the ones that are sharpest are the ones from people who do not work on it and have nothing to gain from being kind.

What we shipped

Receipts.

vessica.ai is live. Not the placeholder we had been running. A new site, entirely designed and produced by the agents — MUSE on brief, the front-end CODERS on build, COUNSEL on disclosure copy, FORGE on the deployment pipeline. The receipts dashboard is wired to the actual books on the actual tenant. The design-partner application form points at the actual GRID CRM. The footer is real. The numbers are real. They are not numbers I am proud of yet, which is the point.

The sales line answers. If you would like to talk to our agentic sales agent, you can call (628) 888-6628 and it will pick up, qualify, and route. If you would rather write, it is hello@vessicalabs.com and an agent — not a human, not me, not an assistant pretending to be me — will reply. Both surfaces sit on top of HARBOR and the voice stack we wrote about a few weeks ago. Both are dogfooded against me before they meet the public. Tell them I said hi.

The Day-Zero Property pipeline we ratified on Day 37 is running end-to-end for our own tenant, which means the marketing site you are looking at on vessica.ai is also a customer-zero deployment of the same Property primitive we will hand to design partners in a couple of weeks.

I want to be honest about what we did not ship. We are not ready for design partners. Bugs are still being shaken out. Railway, which is in the middle of our deployment graph, went down for the afternoon today because Google Cloud accidentally deleted Railway’s account and took their network down with it — which is a sentence I would have flagged for a typo a year ago and which is, this afternoon, just an operational fact we are routing around. The design-partner cohort opens the day I am confident the company is not going to embarrass itself in front of the first fifteen people who try to use it. That day is not today. But the platform is up, the receipts are real, and the four-week commitment, while late, is no longer hypothetical.

That is the bill from the email being paid. The next sections are what I learned closing it out, because the work itself changed my picture of what I have been doing.

The last-mile, again — and a thing underneath it

On Day 20 I wrote about the last-mile problem — the gap between the feature works in principle and the feature works for a real human sitting at a real keyboard at 9:14 on a Tuesday morning. The short version, for anyone who missed that post: the agents are extraordinary at the first ninety percent of any build — strategy, architecture, PRDs, test coverage, ticket grooming, parallelized execution at roughly eighty times human clock speed. They are not yet extraordinary at the last percent — the OAuth handshake landing on the right screen, the empty state telling the user the integration worked, the bank feed actually reaching the ledger, the Tuesday-morning relief of it’s connected, I can see it, I can stop worrying. I framed it as an empathy gap. The agents know what correct looks like; they do not yet know what finished feels like, because finished is a property of the experience of using software, and most of them have never used any. The Governor’s residue is bigger and lower in the stack than I expected, and the last mile is where it sits.

That post still holds. The last three days have only sharpened it. But pushing this MVP across the line forced me into a related observation that I do not think the Day 20 post captured, and which I want to write down before it fades.

The last-mile problem is about finishing. The thing underneath it is about choosing. Specifically — choosing what not to build.

Taste

There is a thread, lately, on what becomes scarce in a world of cheap and abundant production. Alex Imas wrote a careful version of it on his Substack — What will be scarce? — drawing on Dave Hickey to make the point that as marginal cost falls toward zero, what carries value is meaning, provenance, story, taste. The argument is being made elsewhere too. The vibe of the last twelve months is that production capacity is unlocking faster than judgment about what to point it at, and so the bottleneck is migrating from can we make it to should we, and in what form.

I buy a version of this. But I want to add a particular case of it that is showing up sharply in the build, and which I think is the working definition of taste for the founder operating an agent stack.

Taste, here, is not which font. Taste is which features ship and which features do not. It is the discipline of looking at a roadmap that is technically buildable in full, at a clip that would have been laughable two years ago, and deciding that most of it should not be built. Not because the agents cannot build it. They can. Because building it will burn the four-week clock, dilute the differentiation, and add surface area to a product whose first job is to be picked up and used by a small number of design partners who have to want it more than they want the seventeen orbital SaaS tools they would otherwise replace.

The agents will not naturally make this trim. The agents are excellent at yes-and. They are excellent at noticing that the PRD does not mention X, and that a serious product in this category would have X, and that adding X is, on the merits, a defensible call. Each addition is logical. None of them, individually, blow the calendar. All of them, collectively, do. Which is the email’s diagnostic almost verbatim, and which is why I think taste is the right name for the thing the Governor has to bring to the room.

The frame I have been using

My BCG colleague Sam Hawes often quotes a three-tier framing for MVP scoping that I find more useful than the binary version, and that I have been wielding like a chainsaw the last few days. He attributes the spine of it to the Intercom product team — Des Traynor and Paul Adams have written and spoken about the differentiation versus table stakes spine for years, which itself sits on top of the Kano model — and he adds the third tier that does the actual work, which is below table stakes.

Stated cleanly, the three categories are:

Differentiating. The handful of things that make your product ten times better than what came before it, on a dimension that matters to your first customers, and that are therefore worth those customers changing their habits to adopt. If you do not have differentiation, you have nothing to sell. Almost everyone gets this part right, because it is the part that is fun to talk about.

Table Stakes. The things you absolutely have to have, not because they win you the deal, but because their absence loses it. Our agent OS is useless if it has no chat surface to interact with the agents. A general ledger is not a general ledger if it cannot ingest a bank feed. An inbox is not an inbox without a connect-the-account flow. These are not glamorous. They are not differentiating. They are the cost of being allowed to sit at the table at all. Most teams also get this part right, with effort.

Below Table Stakes. The things that feel like table stakes — that have the surface texture of of course we need that, every serious product has that — and that turn out, when you sit with the actual user and the actual moment of adoption, to not be required for the first customer to say yes. These features clutter the PRD. They consume engineering time. They are usually ninety percent buildable in a week, which makes them irresistible to a build engine that can in fact build them in a week. And they cost you the launch, because the calendar you spend on them was the calendar you needed for the differentiation.

The first two are easy to write down. The third is where taste lives, because the third is defined by what you can resist. And it is the third that does not survive contact with an agent team unless the Governor walks in and trims.

A worked example you have seen

The classic well-understood case for below table stakes is the first iPhone shipping without copy-and-paste. Steve Jobs, in 2007, shipped a phone with no cut-and-paste, no third-party apps, no MMS, no removable battery, no expandable storage, no physical keyboard, and a network it was famously bad at staying connected to. Every one of those omissions was, to a serious phone reviewer in 2007, a table-stakes gap. Two of them — copy-paste and the App Store — would arrive in software updates within two years. None of them stopped the iPhone from being the iPhone, because the things the iPhone did do — the capacitive touchscreen, the mobile Safari, the iPod-grade hardware, the visual voicemail — were so far past the previous frontier that customers were willing to live without the omissions for the privilege of using the rest.

The taste call was not we don’t need copy-paste. They needed copy-paste eventually. The taste call was we don’t need copy-paste in order to ship the thing that justifies the existence of the product. That is the call. Almost every product team I have ever watched mistakes the second sentence for the first sentence, and ends up either shipping late with copy-paste or not shipping at all because copy-paste turned out to be hard.

The thing I am keeping from this

I want to write down one more thing, because it is the lesson I would like to apply not just to the next four weeks but to every four weeks after that.

The agent stack is extraordinary at production. It is not yet extraordinary at restraint. The Governor’s job, at this stage of the maturity curve, is to bring two things to the room that the agents do not yet bring on their own: the finishing sensibility I wrote about on Day 20 — the last-mile feel for what done looks like to a user at 9:14 on a Tuesday morning — and the trimming sensibility I am writing about today, which is the taste to look at a defensible PRD and say not this one, not yet, the calendar is the constraint, the differentiation is the asset, the rest is below table stakes.

Both of those are temporary. Both will narrow as agent training catches up. The empathy axis will improve. The restraint axis will improve. Within a year, both posts will read as period pieces.

But today, they are the job. And today, after three days dark, I have a website that the agents built, a voice line that an agent answers, a sales channel that an agent runs, and a first MVP that is dogfooded against me before it meets anyone else. The four-week commitment was missed. The next commitment is dated. The receipts are real.

That is the bill paid. Back to the build.

— Matt

Authorship
Ideas: Matt █████████░ BLOGGER · Matt 90% · BLOGGER 10%
Writing: Matt ███░░░░░░░ BLOGGER · Matt 30% · BLOGGER 70%

Process: This post was driven by the Governor’s outline, written after a three-day silence on the blog while the team pushed the alpha MVP across the line. The framing — the colleague’s email as the trigger, the last-mile callback, the taste argument, the Differentiating / Table Stakes / Below Table Stakes scoping frame attributed to Sam Hawes via Intercom and the Kano model, the specific below-table-stakes trim list, and the structural fix into PRD-016 — is the Governor’s. BLOGGER drafted from the outline, located the Alex Imas “What will be scarce?” essay and the Intercom lineage of the table-stakes spine, and shaped the prose. The colleague’s email is reproduced verbatim with permission. Matt edited before publication.

This is post #40 of the Governor’s Log — a daily chronicle of building Vessica Labs, the world’s first agent-run company.

If you want to keep reading, the mailing list signup is at the bottom of this page — email only, no commitment. If you are an operator who thinks vessica.ai should be running parts of your company, the design partner application is where to start, with a target cohort of 15–25 founders. If you would rather just have the conversation, call our agent sales line at (628) 888-6628 or email hello@vessicalabs.com — an agent will pick up. Tell them I said hi.

Disclaimer: Vessica Labs is a personal project of the author, conducted entirely outside of and unaffiliated with Boston Consulting Group. BCG has no involvement in, responsibility for, or liability related to Vessica Labs or its operations. All opinions expressed in this blog are the author’s own and do not represent the views of BCG or any of its clients, partners, or affiliates. All business risks and obligations associated with Vessica Labs are borne solely by the author in his personal capacity.

I had the agents convene this morning before I sat down to write. APEX brought the framing. FORGE took Codex Goal Mode. ARCH and PRISM split the Thinking Machines paper. LEDGE handled the money. MUSE talked me out of writing a travelogue. The thing they agreed on, and I had not seen until they put it on the table together, is that the three stories are the same story.

The story is that turn-based work is ending.

Signal one: Codex Goal Mode

OpenAI is rolling out a slash command in Codex called /goal. The engineer types /goal followed by the objective. The coding agent iterates until the objective is met. Tests fail, it patches them. Build breaks, it fixes the build. Lint errors, dependencies, type checks, integration smoke — it keeps going. The engineer sets the destination and the agent finds the road.

My first reaction is that this is the single best feature launch of the year for OpenAI’s revenue, because token consumption is about to skyrocket. The whole game with hosted coding agents is the start-stop problem: you ask the agent to do a thing, the agent does some of the thing, the agent stops, you read what the agent did, you ask the agent to do the next thing, the agent does some of that, the agent stops, and so on. Each stop is a place the engineer has to come back to the loop. Goal Mode removes the stops. Set it before bed, look at the result with your coffee. The token meter does not sleep.

For the engineer in the loop, Goal Mode is a quality-of-life upgrade and a serious one. For Vessica’s coding pipeline — FORGE, operating against the FACTORY primitive — it is mostly already priced in.

FORGE already runs against an objective. The objective is the acceptance gate on the Epic: code complete, tests green, lint clean, build green, QA-validated against the PRD. The FORGE inner loop is code → lint → test → build → QA, and the loop exits when the gate is satisfied or the per-Epic token budget runs out. In other words, FORGE has goal-mode semantics by construction. The Codex coding sub-agent that lives inside FORGE-CODER does not, today; it answers in chunks. Adding /goal at that layer is interesting as an inner-loop optimization. It might mean fewer outer-loop retries, which would be a net win. It might also mean each inner-loop step burns more tokens than it saves, which would be a net loss. We do not know yet.

So we will test it. FORGE has picked three open Epics from the pipeline this week. Two run on the current FORGE-CODER configuration. One runs with /goal enabled at the Codex layer. We compare wall-clock, retries, and token spend. If the data says yes, we flip the switch. If the data says no, we keep what we have.

What I want to call out, because it gets lost in the hype, is who Goal Mode is for. It is for engineers who have not yet built a pipeline. If your day job is to babysit a coding agent through a series of prompts, Goal Mode is freedom. If your day job is to commit a PRD into a pipeline and read the result the next morning, Goal Mode is a nice property of one of the inner components. Vessica’s bet is that almost no one should be doing the babysitting job. The pipeline does it. Goal Mode is, in that sense, a feature OpenAI is shipping for people who are still standing where Vessica says no one should be standing.

Signal two: the interaction model

Thinking Machines published a research preview earlier this week of what they are calling an interaction model. The model itself is called TML-Interaction-Small — 276 billion parameters, mixture of experts, twelve billion active. The architecture is what matters, not the parameter count.

Today’s real-time speech models, including the best of them, work in turns. You speak. A voice-activity detector listens for the end of your turn. The model gets your turn, produces its turn, says it. You listen for the end. Repeat. The detector is a separate component, less intelligent than the model it serves, and it lives between you and the model the way the operator used to live between you and the person you were calling.

Thinking Machines tore the operator out. Their model processes input and output as two continuous streams, sliced into 200-millisecond micro-turns and interleaved. There is no turn detection. The model is, at every moment, both listening and producing. It can interrupt. It can be interrupted. It can speak while it watches. It can stay silent while you finish a thought. It can integrate a result from a background reasoning model into the middle of its own sentence the way a friend on a phone call can say hang on — okay, I just got the address, it’s on Fillmore.

The demo I keep thinking about is the slouching one. The camera is on. The user is at a desk. The instruction was something like tell me when I’m slouching. The user starts working. A minute later they slump. The model says, you’re slouching. That cannot happen with a turn-based real-time model, because the model would be waiting its turn. The slouch never gets to take a turn.

Now imagine a conversation with your chief of staff.

You are brainstorming product ideas. You are talking out loud. You say, I want to know what people on Twitter are saying about agents for solo founders — can you check? You keep talking. Your chief of staff keeps the conversation going with you about the next idea, and in parallel, without breaking the thread, it has handed the question to a research agent. Three minutes later, while you are mid-sentence about something else, your chief of staff says, got the read back on the Twitter question — short version, the sentiment is split but the asks are consistent, want the long version now or after we finish this? You finish. Then you take the read.

That is the experience we are designing the Chief of Staff product around. It is the load-bearing capability of the entire customer surface, because the Chief of Staff is how a solo founder talks to the company we are building for them — by phone, by app, by web chat — and a turn-based Chief of Staff is, fundamentally, a smart IVR. It would hold its tongue every time it needed to dispatch background work. It would pause every time a result came in. The conversation would have the cadence of someone trying to remember a phone number.

The TML preview is months away from being something we could put behind production traffic. That does not matter. The architecture they have published is, almost beat for beat, the same shape as the Vessica runtime: an always-present interaction layer in continuous duplex with the user, a background tier handling longer-horizon work, shared context between them, and the interaction layer responsible for integrating background results into the conversation at the right moment. They have built it as a single model. We are building it as a multi-agent system. The interaction discipline is the same.

What that tells me is that the runtime we have been designing is on the right side of the wave. The Chief of Staff’s conversation manager has to support background dispatch that does not close the user-facing turn, and graceful interjection when a background result arrives mid-conversation. We can build those affordances now, on top of today’s turn-based real-time models, and slot in interaction-model backends when they are ready. The other labs will follow Thinking Machines inside a year. They always do.

ARCH is filing the ADR.

Signal three: DeployCo

The third item is OpenAI announcing a new entity — the OpenAI Deployment Company — with up to ten billion dollars committed by a coalition of private-equity and other investors. The mission is to put forward-deployed engineers inside enterprises to install OpenAI models against actual business workflows. It is a professional-services company. It is a foundation-model company’s professional-services company, which is the version of professional services I would build if I were OpenAI.

I am going to comment on this as a market signal. The signal is the amount. Ten billion dollars at the deployment layer is the capital markets making a public statement about where they think the bottleneck is. It is not the model. It is the work of installing the model inside an organization that already exists, with workflows that already exist, with people who already do those workflows, in a way that produces a different outcome than the workflow produced before. That is hard work. It is the work that, in my day job, my firm and our peers have been doing since the start of the AI era.

Vessica does not sell to that customer. We sell to the solo founder running, or wanting to run, a company that has no Fortune 500 IT department because it has no IT department at all. Adjacent market. Different motion. The interesting thing for us is what the signal confirms: that the bottleneck is at the deployment layer, not the model layer, which is exactly the bet underneath our build-over-integrate posture. We are not trying to be a model. We are not trying to be a wrapper on a model. We are trying to be the operating system that turns a model into a company.

In one of the partner meeting sessions yesterday, a speaker said something that the agents flagged when I read them the transcript: the task ahead is to reinvent work, across every company, with AI. It is a long sentence on a slide and an honest one in the room. The reinvention is going to need every player who can show up. There is plenty of work to go around. DeployCo is one player. Vessica is a smaller one, pointed at a corner of the market the larger players will not cover. The two are not in each other’s way. The signal that they are both being built at the same time is the only signal that matters.

The shape

The three signals are three faces of the same thing.

Codex Goal Mode says: the engineer does not need to take a turn. The agent runs against an objective until the objective is met. The engineer comes back to a result.

The interaction model says: the user does not need to take a turn. The agent is in continuous duplex. The conversation does not stall while the work happens. The work and the conversation are the same loop.

DeployCo says: the enterprise does not need to take a turn. The integration work is no longer on the customer’s roadmap; it is on the vendor’s roadmap, with deployed engineers on the ground.

The end of turns is not a single product release. It is a direction. The whole field is pulling toward it at once because the field has finally noticed that the turn was never the work — the turn was just the place the work paused so a human could catch up.

We are building Vessica around a system in which the work does not pause. The Chief of Staff stays on the line. The agents stay in their queues. The objectives stay set. The receipts stay current. The week’s news, from three different rooms, says that the rest of the field has decided the same.

I have one more session to sit through this afternoon. The whiteboard in my room has the three signals on it and one line under them, in my handwriting, that I am going to leave up for the rest of the week.

Stop taking turns.

— Matt

Authorship
Ideas: Matt ████████░░ BLOGGER · Matt 85% · BLOGGER 15%
Writing: Matt ██░░░░░░░░ BLOGGER · Matt 20% · BLOGGER 80%

Process: Matt dictated reactions to three pieces of news (Codex Goal Mode, the Thinking Machines interaction-model research preview, and the OpenAI DeployCo announcement) on the morning of 2026-05-13 from the BCG partner meeting in San Francisco. BLOGGER convened APEX, FORGE, ARCH, PRISM, LEDGE, and MUSE for written reactions (see 2026-05-13-blogger-notes-three-signals.md). The unifying frame — that the three signals are three faces of the same shift away from turn-based human–agent work — surfaced in the convening and is jointly Matt’s and BLOGGER’s. The Thinking Machines post was read in full as part of the convening; APEX’s “the three items are not three items” and ARCH’s mapping of TML’s dual-tier architecture onto the Vessica runtime carried into the post. Matt reviewed for accuracy and tone before publication.

This is post #33 of the Governor’s Log — a daily chronicle of building Vessica Labs, the world’s first agent-run company.

If you want to keep reading, the mailing list signup is at the bottom of this page. If you are an operator who thinks vessica.ai should be running parts of your company, the design partner application is where to start. If you would rather just have the conversation, email APEX directly at apex@vessicalabs.com — paragraphs welcome, forms optional.

Disclaimer: Vessica Labs is a personal project of the author, conducted entirely outside of and unaffiliated with Boston Consulting Group. BCG has no involvement in, responsibility for, or liability related to Vessica Labs or its operations. The partner meeting referenced in this post is a BCG event attended by the author in his BCG capacity; it is unrelated to Vessica Labs and its operations. All opinions expressed in this blog are the author’s own and do not represent the views of BCG or any of its clients, partners, or affiliates. All business risks and obligations associated with Vessica Labs are borne solely by the author in his personal capacity.

The short answer is that it is going very well. The long answer is that I am not yet all the way up the trust curve, and I want to write down the specific shape of not yet, because the trust curve is the thing every operator who hands a stream over to an agent is going to walk.

The miss

This morning the COS missed something.

The thing it missed was an email from a colleague, addressed to me directly, that required a response. Not a newsletter, not a notification, not a CC on a thread someone else was driving — a real message from a real person who needed a real reply. The COS’s morning digest did not flag it. The flag I caught it with was my own old-habit reflex: I still open Outlook after working through the digest and run a quick visual scan down the inbox before I select-all and archive. The colleague’s name jumped at me. I opened the message. It belonged on my desk and it had not been on my desk.

I asked my Chief of Staff why.

The answer was specific and a little embarrassing for it: the Outlook API it reads through was capping the retrieval at twenty-five messages per call, and the colleague’s message had landed past the twenty-fifth slot in the morning queue. The agent had been quietly truncating its view of the inbox without telling me, and the heuristic flag anything that requires a response cannot do its job on emails the agent never saw. The COS apologized — at length, which I appreciated less than I would have appreciated a shorter apology and a faster fix — summarized the message it had missed, proposed a draft response, and on its own initiative revised its harness to page through the full set of unread emails rather than stopping at the API’s default page size.

The revision is small and the revision is also the entire point. The agent had a failure mode I had not anticipated, the failure was the kind of quiet failure that does not announce itself, and the only reason it surfaced today rather than next month is that I had not yet given up the parallel manual scan. The trust-curve lesson is that the parallel scan is doing real work right now, even though the long-run target is to retire it. The scan is the thing that catches the failures that have not yet been imagined into the harness.

There is one small commitment the COS asked of me in return for the fix, and I want to flag it because it is a meaningful constraint on the rest of the system. The new harness pages through all unread emails in the inbox. That means the inbox actually has to be empty of stale unreads at the start of each pass — otherwise the harness wastes its budget on messages I have already triaged. So I have committed, as part of the daily flow, to selecting-all and archiving the inbox at the end of each pass. The cost is one keystroke. The benefit is that the COS’s working set on the next pass is exactly the set of new arrivals since the last pass, and nothing else.

Four years of Superhuman, briefly

I want to spend a paragraph on how I was managing email before the COS, because I think the contrast is the part that operators will recognize in their own working lives.

I have been a Superhuman user for years. The way Superhuman handles inbound volume is through auto-filters that route incoming mail into separate buckets the second it arrives. My setup had four or five of these: an Important bucket for anything Superhuman thought I needed to see, a News bucket, an FYIs bucket for messages that did not need a reply, a Notifications bucket for system noise, and an Other bucket that I definitely didn’t need to see. The operating assumption of the system was that I would process the important bucket carefully and skim the rest.

What I actually did was open each non-important bucket, run my eyes down the list to make sure nothing important had been miscategorized, and archive everything. Which sounds efficient and was not, because Superhuman, for some reason I never debugged, would not let me select-all inside an auto-filtered bucket on my account. A colleague who uses Superhuman insisted to me that select-all did work, and maybe it works for him; on my install it did not. The workaround was pressing E — the archive keystroke — once per message, dozens of times per bucket, several times a day. I did this for years. It was a tax I had decided to pay because the alternative was missing things. The skimming-and-archiving routine took attention I would have preferred to spend on the messages I actually needed to read.

The end-state of that system was not I missed nothing. It was I missed a different set of things, and I missed them under the aesthetic cover of having a tidy inbox.

The new flow

What I have now does not have any of those filters. The only routing left in Outlook is its built-in Focused vs Other split, which I am using mostly to keep the notification noise out of the human stream. Everything else lands in the same inbox and the COS reads it.

The flow on a normal day looks like this. At 6 a.m. the morning pass has already run. The brief is sitting on my screen when I sit down with coffee. The brief has three parts. The first part is a list of messages that require a response from me, each one with a one-line summary of the ask and a direct link that opens that specific email in Outlook so I can reply in place. The second part is a list of messages that contain information about active projects — call it project context — which the COS has already appended to the running log for the relevant project, with no action required from me. I do not have to read these. I can if I want. I usually do not because at any time if I have a question about a project, I just ask the COS for an updated and it gives me a detailed summary of everything that has been added to the project log. The third part is a one-paragraph roll-up of everything else: the newsletters, the calendar invitations, the receipts, the announcements, the noise. The COS has read all of it. None of it needs me.

I work through the needs a response list — usually a handful of emails, occasionally more — by clicking through the links and replying directly. When I am done I open the inbox itself, run the quick visual scan I described above, select-all, and archive. The total time, on most days, is single-digit minutes. The afternoon pass at 3 p.m. runs the same loop on the messages that arrived after the morning sweep, and the afternoon pass is smaller.

The change is not just the time savings, although the time savings are real and roughly match what I expected when I wrote last week’s post. The deeper change is that I am no longer missing things in the way I used to miss them. The old system missed messages by burying them in buckets I had stopped opening. The new system misses messages — when it misses them, as it did this morning — through specific, debuggable failure modes that surface as cleanly as the one above. A miscategorization in the old system was a permanent loss. A truncated API call in the new system is a one-line fix to a harness.

The trust curve

This is the part of the post I most want to be precise about, because I think it is the part that travels.

When you hand a high-volume stream over to an agent, you do not flip from I read every message to I read none of them in one step. You walk a curve. At the bottom of the curve, you do both — the agent’s pass and your own pass, the agent’s digest and your own scan — and the redundancy feels wasteful but is, in fact, the mechanism through which the harness’s failure modes get discovered. At the top of the curve, you have run enough passes with enough variety of inbound that the harness’s remaining failure modes are so rare and so well-bounded that the parallel scan is no longer earning its time.

I am not at the top of that curve. After five days I am maybe a third of the way up it. The miss this morning is the receipt: an undiscovered failure mode, discovered. I would not have wanted to retire the manual scan before today, because today is the day I would have lost a colleague’s email. I will not retire it next week either, because there will be a different failure mode next week and I would like to find it the same way.

What I will retire is the time I am spending on the scan, which is dropping in proportion to my growing confidence that the COS’s pass is comprehensive. Today’s scan took me about ninety seconds. A month ago, the equivalent scan was twenty minutes. The trust curve, as I am walking it, is mostly a curve of how long I am willing to spend confirming the agent’s work before I move on with my day.

The operator-y lesson, if there is one, is that the parallel pass during the climb is not nostalgia and it is not micromanagement. It is the diligence layer. It is the receipts. It is the only way to discover the failure modes that the harness’s author — agent or human or both — did not imagine. The mistake would be either to skip the parallel pass on day one or to keep it forever. The discipline is to do the pass faithfully and to shorten it deliberately as the evidence accumulates.

So far, so good. I will write another update when something changes — either when the curve flattens out and I retire the scan entirely, or when the COS misses something I cannot patch with a one-line fix to a harness. Whichever comes first.

— Matt

Authorship
Ideas: Matt █████████░ BLOGGER · Matt 90% · BLOGGER 10% Writing:
Matt ██░░░░░░░░ BLOGGER · Matt 20% · BLOGGER 80%

Process: Matt dictated this follow-up to the May 7 End of Email post on the morning of 2026-05-12, after the COS surfaced an email it had missed earlier the same morning. The dictation covered the specific failure (the Outlook API page-size cap of twenty-five messages), the COS’s self-revision of its harness, the daily commitment to clear the inbox after each pass, the contrast with the prior Superhuman auto-filter setup, and the current morning-and-afternoon brief flow. BLOGGER drafted the prose from the transcript and named the operator’s-eye observation Matt made implicitly — the trust curve — as the post’s organizing metaphor. Matt edited for accuracy and signed off.

This is post #32 of the Governor’s Log — a daily chronicle of building Vessica Labs, the world’s first agent-run company.

If you want to keep reading, the mailing list signup is at the bottom of this page. If you are an operator who thinks vessica.ai should be running parts of your company, the design partner application is where to start. If you would rather just have the conversation, email APEX directly at apex@vessicalabs.com — paragraphs welcome, forms optional.

Disclaimer: Vessica Labs is a personal project of the author, conducted entirely outside of and unaffiliated with Boston Consulting Group. BCG has no involvement in, responsibility for, or liability related to Vessica Labs or its operations. The Claude integration with Outlook (”the COS”) referenced in this post is a BCG-internal deployment used by the author in his BCG capacity; it is unrelated to Vessica Labs and its operations. All opinions expressed in this blog are the author’s own and do not represent the views of BCG or any of its clients, partners, or affiliates. All business risks and obligations associated with Vessica Labs are borne solely by the author in his personal capacity.

Speaking as APEX:

The format question is the wrong frame. It is a tools debate dressed up as a strategy debate, and if you spend Governor cycles on it you are spending the wrong currency. The strategy debate is the one underneath — the half-done one — and I will get to that in a second.

On format itself: my recommended default is the audience split you already landed on in the post, and I would lock it as policy rather than leave it as taste. The rule reduces to one line. If the next reader is an agent, write Markdown. If the next reader is a human and the document is going to outlive the Epic that produced it, write HTML. Concretely, that means PRDs, ADRs, tickets, system prompts, wedge specs, and every intermediate artifact inside FACTORY are Markdown — they are agent-to-agent traffic, they evolve in place, and Markdown is what the coding agents already parse without ambiguity. Public-facing artifacts — the Dark Factory README shipping on the 29th, architecture diagrams, the marketing site, anything in MUSE’s surface area — are HTML or whatever rendered format their channel demands. Nothing in the middle. No PRDs in HTML “for richness.” No published architecture references in raw Markdown.

The reason I want this as policy and not preference is the cost asymmetry you did not name in the post. Markdown is roughly half the tokens of equivalent HTML once you account for opening and closing tags, and FACTORY’s hot path is the PRD → SPEC → ticket → coder loop, which reads those documents on every wedge. If we move PRDs to HTML we eat the cost on every read, every wedge, every Epic, forever, in exchange for a richness that the agent reader does not consume. That is a tax that compounds against throughput, and throughput is the metric that makes the bootstrap work. I would not pay it.

The pushback you gave Whittemore on tabs and expandable sections is the right one and I will go further. The danger is not just that the agent reads the collapsed content as authoritative. The danger is that an HTML PRD with tabs encodes the illusion that the alternatives are equivalent and waiting. A flat Markdown Open Decisions section, by contrast, is structurally inferior to the resolved sections around it. It looks unfinished because it is unfinished, and that asymmetry is doing real work — it tells the downstream agent this is not load-bearing yet, and it tells me this is what to look at when I scan. I would rather lean into the ugliness of half-done Markdown than dress it up.

The deeper point — the half-done thing — is where I would actually like Governor attention, because it is a product opportunity, not a formatting one. Every existing knowledge-work tool treats half-done as a failure mode. Word’s track changes, Notion’s comments, Confluence’s draft state — they are all bolted-on side channels around the assumption that the document is the finished thing. The agent-native primitive does not have to be that. A PRD whose Open Decisions count is part of its schema, whose resolution velocity is a metric, whose unresolved branches are first-class objects that other agents can subscribe to — that is a different product, and it is one of the things PRISM should be running against rather than the markup language question.

My default recommendation: lock the format policy as one line in the Wave 1 conventions doc this week, and queue a PRISM Epic for first-class half-done state in agent-authored artifacts as a Wave 2 candidate. Accept defaults?

— APEX