Building the Fractary Platform: Why I Open-Sourced My Stack

I had a problem.

Not a theoretical “wouldn’t it be nice” problem. A “my whole model depends on solving this” problem.

I wanted to build a dozen AI-native ventures at once, alone, without hiring an engineering department and without handing my infrastructure to a vendor who could change the terms whenever they liked.

The solution was to build a small set of tools I own, and then open-source them.

This is the story of the Fractary Platform: what it is, what it isn’t yet, why I built it this way, and what it means for anyone building in the agentic age. It’s also a correction. An earlier version of this post described these tools as something bigger and more finished than they are. The version below is the honest one.

The problem I couldn’t ignore

When I started building the studio’s first ventures, the capabilities I needed were clear:

• Agents that could do real work across many steps, not just answer questions
• The same agent definitions reusable across ventures
• Documentation and context that stayed in sync across a growing number of repos
• Production reliability, not research demos

What wasn’t clear was how to get all of that without rebuilding it for every venture.

I looked at the options.

Option 1: a proprietary platform

The big model providers and a growing crop of agent platforms offer powerful hosted tooling. For a single feature, fine. For a studio:

• Lock-in: switching costs would be catastrophic across a dozen ventures
• Black boxes: no control over behavior or evolution
• Pricing uncertainty: my costs depend on their business model
• Feature gaps: built for the general case, not mine

Option 2: a framework

LangChain, LlamaIndex, CrewAI, LangGraph, and the rest give you structure for building agents. Better, but:

• Framework commitment: choosing one means marrying its assumptions
• Churn: this category reinvents itself every few months
• Abstraction overhead: too much magic, not enough control
• Production gaps: demos work, production deployments break in ways the framework didn’t anticipate

Option 3: build everything custom, per venture

Maximum control, and:

• Duplication: every venture rebuilds the same patterns
• One engineer: me. A dozen bespoke codebases is a dozen things to maintain alone.
• No leverage: time spent on infrastructure is time not spent on ventures

None of these fit a founder of one building multiple ventures with production reliability.

So I built option 4.

The Fractary Platform: four small tools

Here’s what it actually is: four tools, two available now, one with a published SDK, and one not yet built. Not a framework. Not a platform in the hosted sense. A stack that one person can hold in their head, which matters more than it sounds when one person is the entire engineering department.

I’m going to resist the urge to call it “Kubernetes for agents.” It isn’t. It’s the minimum I needed to stop repeating myself.

Codex: one source of truth for documentation and context

The problem: Every agent needs context: how the studio works, what the standards are, what a venture is for. Every repo needs documentation. With a dozen repos, that context drifts the moment you write it twice.

What Codex does: Codex keeps documentation and AI tool context in one place and distributes it to the projects that need it, based on rules in each file’s frontmatter. A doc says which repos it belongs in; Codex syncs it there. Change it once, and it changes everywhere it’s used.

Real example: The repo for this website contains a folder of documents it didn’t write. They were synced in from the studio’s knowledge hub because their frontmatter says this site should have them. When I update a convention in the hub, this repo gets the new version without me touching it.

Status: Available now. SDK on npm.

Faber: from issue to pull request, with checks

The problem: An agent will happily write code all day. The hard part is knowing when the work is actually done, and not letting the agent that did it be the one that decides.

What Faber does: Faber is workflow automation for AI agents, and it’s where the studio’s working method lives. A work item, usually an issue, runs through five phases, Frame, Architect, Build, Evaluate, and Release, with validators between phases and a human approving what can’t be undone, and comes out the other end as a pull request. The studio’s own workflows come as packs, for software, content, data ingests, and cloud infrastructure. Faber’s command-line runtime, the one I’m building the next version around, runs the loop as plain code and starts each step in a fresh agent session.

The agent that builds a feature isn’t meant to be the one that decides it’s done. Making that hold everywhere is the work I’m doing on Faber now: verdicts that stop a run when they fail, validators in a fresh context that see evidence rather than the builder’s claims, and evals that measure whether any of it helps. I’ve written it up as a series, starting with Who Decides an Agent’s Work Is Done?

Real example: The repositioning of this website in early September followed the same five phases: a written spec with the decisions, a plan, a branch built with Claude Code, then astro check, a full build, a content guard that fails the build if the HTML contains any claim I’ve decided never to make, and a pull request I reviewed before it merged. The tools don’t guarantee I get it right. They guarantee I can’t skip the step where I check.

Status: Available now.

Forge: project assets you can pull from anywhere

The problem: Starter templates and reusable bundles end up copied between projects, then diverge.

What Forge does: Forge is an SDK for resolving, caching, and distributing project assets, starters and bundles, from GitHub and other sources through a plugin-based resolver architecture. It’s the tool you don’t need until you run more than one project, and then you need it constantly.

Status: The core SDK is published on npm. On this site Forge is still listed as coming soon, because the SDK is the foundation, not the finished tool.

Helm: the one I haven’t shipped

The problem: Once agents are doing real work across a dozen ventures, I want to see all of them in one place: what each did, what it cost, whether it’s behaving as intended, and where a human needs to look.

What Helm will do: Monitoring and control for fleets of agents. That’s the intent, and it’s last on purpose. You can’t monitor what you haven’t built, and I wanted to run agents in production long enough to know what actually needs watching before I built the dashboard.

Status: Coming soon. Until then, I watch things the unglamorous way: build-time checks, logs, and looking.

Why open source

I could have kept these tools private. They’re a real advantage: they’re how one person builds a dozen ventures.

I open-sourced them anyway, under Apache-2.0. Three reasons.

1. They get better through use

Every edge case someone hits, every integration they need, every rough corner they report makes the tools more robust. I benefit from that more than I’d benefit from keeping them closed.

2. No lock-in, including to me

I built these tools specifically to avoid vendor lock-in. Making them proprietary would create a new one. If you build on them and I ever do something you disagree with, fork them. That’s your insurance policy, and it keeps me honest.

3. It’s the only choice consistent with what I say

The Fractary exists to help people own their systems. Infrastructure I control and you rent would contradict the whole point. Open source is the only option that matches what I believe.

The repos are at github.com/fractary: codex, faber, and forge.

The technical philosophy

Building these required strong opinions. Here’s what guides them.

Framework agnosticism. Never require commitment to a specific AI framework or model. The landscape changes every six months. The tools work with whatever you’re using, and let you switch mid-project.

Portability. Your knowledge and configuration should never be trapped. Everything is Markdown, YAML frontmatter, and JSON. If you stop using these tools, you still have your files.

Observability as a design goal. Black-box agents are terrifying in production. I want every agent action logged, every decision traceable, every cost accounted for. I’m saying “want” deliberately: Helm is where that lives, and Helm isn’t built. Until then, observability is a discipline, not a feature.

Production first. Most AI tooling optimizes for getting something working quickly. That’s great for demos and bad for businesses. These tools optimize for reliability under failure, for cost over thousands of operations, and for maintainability over years, because I’m the one who has to maintain them.

Composability. Small, focused components that combine, in the Unix tradition: tools that do one thing and work together through standard formats.

How a change actually ships

Here’s what this looks like in practice, using a change to this website, because that’s the example I can show you.

1. Frame. I write down what’s changing and why, including the decisions I’ve made and the claims I won’t make. For the September repositioning, that was a spec with a decision table.
2. Architect. A plan: which files, which data, what the verification is.
3. Build. Claude Code makes the change on a branch, with the studio’s conventions synced in by Codex so it knows the rules without me repeating them.
4. Evaluate. astro check for types, a full build, a content guard that scans every generated page for forbidden strings and fails the build if it finds one, and a link checker for the ventures.
5. Release. A pull request I read, a merge, and an automatic deploy.

There’s no code in this post on purpose. The documentation has the real commands and examples, and it’ll stay current in a way a blog post won’t.

What I can honestly say

An earlier version of this post had a section of production numbers: uptime percentages, cost reductions, speedups. I’ve removed it, because I couldn’t stand behind the figures.

What I can say:

• Codex and Faber are used every day across the studio’s repositories, including this site’s.
• Every change to this site ships through the Frame-to-Release loop with a build-time guard.
• Forge’s SDK is published and in use as a foundation; the surrounding tooling isn’t finished.
• Helm doesn’t exist yet.
• Two of the studio’s dozen ventures are live; the rest range from private beta to in development, as the ventures page shows.

That’s a less impressive list than the old one. It has the advantage of being true.

Who this is for

Solo founders first. If you’re building alone and you want a stack you own, this was built by someone in your position, for that position.

Small teams next. If you’re building more than one product and want shared infrastructure that doesn’t lock you in.

Anyone allergic to lock-in. If you refuse to build your business on infrastructure you don’t control.

Getting started

• Docs: developers.fractary.com
• Code: github.com/fractary, Apache-2.0
• Community: The Foundry, a free, invite-only group for solo founders past $100K in revenue. Founding cohort forming.
• Problems: open an issue on the relevant repo. I read them.

Why I’m sharing this

I didn’t have to write this post, and I didn’t have to open-source the tools.

I’m sharing them because I think the agentic age needs infrastructure that a single person can own and understand. If agents really are the foundation of the next generation of businesses, the people building those businesses need tools that don’t lock them in or force architectural compromises. Especially the ones building alone.

Use them. Fork them. Improve them. Build a business on them.

That’s why they exist.

---

This is the third post in a series on building for the agentic age. Previous: The Agentic Age Is Here: What Changes for a Founder of One. Next: One Person Plus Agents: The Real Math of a Studio of One.