All roads led to Markdown
A startup-builder loop through CEOgenerator, Framepath, Paperclip governance, Paxlings, and the awkward realization that Build Right was the markdown harness.
I have always worked in startups. My role has often been some version of this: arrive when things are messy, build foundations, figure out the hard parts, make the system less fragile, then keep it that way.
But on the side, the real hustle was always building cool products.
The idea pile
Having ADHD gives the whole process a very specific texture. I do not struggle to come up with ideas. That would be convenient. I come up with too many, too quickly, and with enough detail to make each one feel briefly inevitable.
My brain is good at the first 30%. It sees patterns, wedges, systems, missing tools, bad abstractions, better abstractions, and sometimes the tool that should exist underneath the better abstraction.
idea 1 -.
idea 2 -|
idea 3 -+--> all plausible
idea 4 -| |
idea 5 -' v
weekend prototype
|
v
more interesting adjacent problem
The annoying part is that the ideas are often not bad. If they were obviously stupid, I could close the tab and move on. But they tend to be plausible. Sometimes good. Good enough for a weekend, then a prototype.
But soon enough, my brain finds a more interesting problem next to the initial problem.
After repeating this enough times, I decided the real issue was not any single startup idea. I needed a system that could evaluate my pile of ideas for me: research the market, estimate execution difficulty, compare impact, revenue potential, distribution, competition, and all the other things I know I should do.
The first escape hatch
So I started building CEOgenerator.
CEOgenerator was meant to triage startup ideas before I emotionally invested in them. Not find product-market fit by magic, but make the first pass less impulsive: gather evidence, compare opportunities, and decide which hypotheses were worth testing in the real world.
In a more honest phrasing, it was supposed to protect me from myself while still allowing me to have ideas.
too many startup ideas
|
v
CEOgenerator
|
v
market research
execution difficulty
impact
revenue potential
distribution
urgency
competition
|
v
"which idea is actually worth building?"
Having already figured it out in my head, my next insight was that I needed an app factory to build stuff for me.
I kept calling this laziness, but that was only half true. The stronger impulse was leverage: if I could turn repeated work into a system, I could move faster without dragging my attention through the same setup steps every time.
So I moved one level down.
CEOgenerator answers:
"What should I build?"
|
v
new problem:
"Who builds it?"
|
v
app factory / execution system
The control plane detour (Framepath)
I started building what I thought of as a control plane for AI workloads. That project was Framepath.
The idea was to coordinate AI work more reliably: governed agents, tasks, scripts, artifacts, review steps, etc. I wanted something inspectable, something that treated AI execution like real work rather than a sequence of hopeful messages.
AI work, unmanaged:
prompt -> output -> hope
prompt -> output -> hope
prompt -> output -> hope
AI work, with a control plane:
task
|
v
script / model call
|
v
artifact
|
v
review step
|
v
next bounded action
For about a month, this felt correct. Not obviously a distraction. That is the problem with these detours: they are usually defensible. Each abstraction solves a real limitation in the previous layer.
Then I started thinking about launching it.
A public release would need positioning, documentation, examples, growth experiments, content, maybe community, maybe developer relations.
Framepath (control plane)
|
v
needs launch
|
+--> positioning
+--> documentation
+--> examples
+--> growth experiments
+--> content
+--> community
+--> developer relations
|
v
"this is also too much manual work"
This was no longer just product engineering. It was the company-shaped work around the product: explaining it, distributing it, proving it, supporting it, and keeping the story coherent while the thing itself was still changing.
Again, the leverage instinct kicked in. The next conclusion arrived: I needed agents to help me run the company around the thing.
Governance all the way down
That led me to Paperclip.
Paperclip was my attempt to make company operations executable by agents: research, planning, content, follow-up, review, and the recurring operational work that surrounds a product. That was exactly what I needed. The problem was that unconstrained agents create their own work. They do things, some of which are useful, some are plausible but wrong, while some are complete in the narrow sense and useless in the broader sense.
So I started building a governance layer on top of Paperclip.
The governance layer would define roles, outcomes, review gates, issue templates, approval points, and the right configuration for tasks. I did not want agents wandering around trying to be clever. I wanted them inside workflows, producing artifacts a human could review.
Paperclip agents
|
v
governance layer
|
+--> roles
+--> outcomes
+--> review gates
+--> issue templates
+--> approval points
+--> task configuration
|
v
bounded work
|
v
reviewable artifacts
Again, this made sense. If agents are going to do real work, governance matters.
But then the next problem surfaced: building this specifically for Paperclip felt limiting. The useful idea was more general. It wanted to be Paxlings: an AI workers platform that was more extensible, more consumer-ready, and inspired by Paperclip.
Framepath, the control plane for AI, was infrastructure for coordinating work. Paxlings, the AI workers platform, was the productized version: reusable workers, packaged workflows, and a way for someone else to run the work without understanding the machinery underneath. That direction was inspired by aiworkers.so.
So I started moving toward that. By then the loop was fully alive.
I had started with too many startup ideas, built a system to decide which one to build, put that one aside, started building Framepath as a control plane to run AI work, realized I needed agents to help launch Framepath, started adding governance to the Paperclip agents, realized the governance should be portable, and began turning it into Paxlings.
Written out, it sounds insane. From the inside, it felt like a chain of reasonable decisions.
too many ideas
|
v
CEOgenerator
|
v
needs execution
|
v
Framepath (control plane)
|
v
needs launch support
|
v
Paperclip / company agents
|
v
agents need governance
|
v
portable governance
|
v
Paxlings (AI workers)
The markdown layer (Build Right)
At some point I realized I did not actually want to babysit agents step by step. I wanted fast execution loops with a real harness. I wanted to define an outcome, have the model or agent run a bounded process, produce the right artifact, stop at the right moment, and let me review the result.
So I started extracting the repeated parts of my own work into repo skills and scripts. That became Build Right.
Build Right came from old project starters, scaffolds, agent interactions, and startup workflows I had already run too many times manually: idea triage, market research, product requirements, GitHub issue breakdowns, acceptance criteria, launch plans, human review checklists, critique loops.
old project starters -.
scaffolds -----------|
agent interactions --+--> Build Right skills
startup workflows ---|
manual processes ----'
Build Right skills:
idea triage
market research
product requirements
GitHub issue breakdowns
acceptance criteria
launch plans
human review checklists
critique loops
etc
Then the absurd part became clear: the Build Right skills were the useful part of almost every layer I had been building.
They had some of what I wanted from CEOgenerator, without needing CEOgenerator to be a whole product yet. They had the spirit of Framepath, the control plane, without the complexity. They had the governance I wanted around agents, without tying me to Paperclip. They had the practical value I wanted from Paxlings, without requiring me to build the platform first. And they were mostly markdown.
After all the architecture, I had landed on instructions. Not vague prompts like "act as a senior product manager" and hope for the best. Build Right was a set of markdown repo skills with workflows, inputs, outputs, constraints, review points, definitions of done. Small pieces of operational judgment written clearly enough that a capable model can follow them and a human can inspect them.
A good Build Right skill can take a vague product idea and turn it into a scoped task, acceptance criteria, verification plan, and review checkpoint. That is not a company. It is not a platform. But it is enough shape to make the next unit of work real.
The full circle was almost too neat.
I was building Build Right skills that could help build Paxlings, which could help launch Framepath, which could help build CEOgenerator, which could help me decide what to build, which I could then build using the same skills.
+-----------------------------+
| |
v |
Build Right skills |
| |
v |
Paxlings (AI workers) |
| |
v |
Framepath (control plane) |
| |
v |
CEOgenerator |
| |
v |
decide what to build |
| |
v |
build the thing ----------------------+
At some point, an architecture diagram becomes a confession.
The product was the harness
The easy summary is that I overcomplicated everything. That is partly true. But the more useful conclusion is that I kept looking for the product at the wrong layer. The thing I needed first was not a better platform around the model: it was a better harness around the work.
Today's LLMs are already good enough for a surprising amount of product engineering work if used correctly. Not perfectly, not without review, but good enough to follow instructions if written well.
How it fits together
The cleaner model is this: Build Right is the agent discipline, Framepath is the repo-local control plane, and Paxlings is the customer product. Build Right tells an agent how to work: ground the request, separate evidence from assumptions, plan, execute one bounded task, and verify. Framepath gives that work a controlled environment: repo state, policy, adapters, validation, artifacts, and traces. Paxlings is what a customer uses: bounded AI workers for business workflows, with approvals, side-effect control, and auditability.
That is why these projects kept feeling related without being the same thing. They are all responses to the same failure mode: AI work that looks complete because a model said so, but has no explicit goal, authority, validation, or evidence. Build Right attacks that at the method layer. Framepath attacks it at the control-plane layer. Paxlings applies it at the product layer.
The mistake would be to collapse them. Build Right can help build Paxlings without becoming Paxlings. Framepath can govern repo work without being the SaaS. Paxlings can borrow the same principles without becoming a general agent framework. The through-line is not one product swallowing the others; it is the same operating belief showing up at three different layers.
Please let me know what you think.