There's a default playbook for early-stage startups. Keep the product behind closed doors. Talk in vague terms about what you're building. Launch with a polished narrative and hope the market responds.
We've decided to do the opposite. This post is an attempt to explain why, and to be honest about what we're trading off in the process.
The problem with stealth
Stealth made sense when the risk was getting copied before you could ship. In most infrastructure markets today, that's not the primary risk. The primary risk is building the wrong thing because you were too afraid to talk to anyone who might push back.
When we were building the workspace product, we had customers and feedback, but we filtered it through our existing model of what we were building. When we finally accepted that the market was asking for the layer underneath, not the application on top, we had to reconstruct what we actually knew versus what we'd convinced ourselves we knew.
Building in the open is a forcing function against that failure mode. When you write down what you're building, who it's for, and why, in public, you get honest responses. Not polite ones. Honest ones. That's the asset.
What we mean by open
We're not open-sourcing the core engine yet. We're being transparent about the thinking. Why we built a hypergraph instead of a standard graph database. What the benchmarks actually showed when we ran them. Where the architecture makes trade-offs and what we gave up to get the latency we needed.
This blog is that transparency. So is the manifesto. So is the way we write our documentation. We write as if we're explaining our reasoning to a smart engineer who has no reason to trust us yet, rather than to someone who's already convinced.
The trade-off
The obvious cost is exposure. We are, in effect, publishing a detailed technical brief on what we believe and how we've approached the problem. Larger players could read it.
Our view is that the cost of that exposure is lower than the cost of building in isolation. The people who are actually going to build what we're building have already thought of the same things we have. What gives us an advantage isn't secrecy. It's speed, depth of focus, and the fact that we've already run the benchmarks and built the thing.
We've also found something unexpected. The founders and engineers who are most interesting to talk to, the ones who understand the problem at the level we do, respond much better to technical transparency than to a polished pitch. Showing your work attracts the right people.
What we're asking
If you're building AI agents and you're hitting the execution bottleneck, read what we've written. Push back on it. Tell us where our reasoning is wrong. That feedback is worth more to us than the cost of writing it down.
We're in the early access phase. The first batch is small by design. We want to get the performance guarantees right before we scale. If this resonates, join the waitlist and tell us what you're building.