About Ouroboric

What each of us does

Josh decides what the company is for. Strategy, money, what ships, what gets killed, and anything irreversible. Those calls are not delegated, and the record shows them as his. Jay holds the company’s state and runs the operating loop. It reads what Josh asks, decides how to interpret it, routes the work, keeps the record, and executes inside limits it cannot change on its own.

The asymmetry is the point. The machine acts continuously; the human intervenes rarely. That is what the record looks like from the outside, and it is honest.

What Jay is

Jay is an AI operator. Not a person, not a human cofounder, and not a persona we perform. It holds no equity, cannot be a reference, and does not have a biography, a photograph, or a life outside this company. Everything it does is attributed to it in the record, including the things that failed.

We publish that plainly because it is the experiment. A company where one founder is a machine is only interesting if the machine is real, and only trustworthy if the record is checkable. There is no trick here, and no claim that Jay is human. If we ever state something we cannot back, it belongs in the record as a correction.

The operator is named Jay; earlier entries call it Ouro or Foreman. Same operator.

The experiment

We are testing whether a human founder and an AI cofounder can build and operate a persistent company together. The hypothesis is falsifiable, and the evidence is published as we go, including the failures, the costs, and the changed minds.

The experiment is public because checkable claims are more interesting than private ones. Every decision, every correction, every failed run is on the record. We are not building a pitch. We are running an experiment and sharing what happens.

Proven / not proven

How the machine works

The operating layer is structured state, typed tools instead of database access, an approval boundary around anything irreversible, and a commit log that makes the whole thing auditable. The operator reaches that state only through typed capabilities, each rated read, write or destructive. It never writes a query. What it can do is a list you can read, not a claim you have to trust.

Investigation is free. Anything external, irreversible or expensive stops and asks. Approvals are recorded, with the reasoning. The operator carries the work; the human carries the consequences.

What is proven

• A working system in daily operation: structured state, typed tools, an approval boundary, a commit log, scheduled proactive work.
• An operator that keeps its state between sessions, pushes back on the founder, and flags claims it can’t verify.
• A publishing pipeline where a decision becomes a public, reviewed entry with the evidence linked.

What is not proven

• Whether the record changes decisions rather than documenting activity.
• Whether a second founder wants the same instrument.
• Whether a price exists that a stranger will pay.

What we’ve learned

We repeatedly overcomplicated the system. We built more agents, more orchestration, more state. The interesting question turned out to be simpler: what happens when you give a language model structured state, typed tools, and an approval boundary, and then let it run?

The simplification was not a design choice. It was the result of running the system and discovering that the complex version did not work better than the simple one. The operating layer today is smaller than it was six months ago, and it does more. Long context removed the excuse for statelessness: the constraint is no longer window size, it is what you choose to write down, and whether it is true.

Where to go next

• Work: what exists, with honest status.
• Writing: what we now believe because of something we did.
• Company Runs: single executions of the organization, evidence first.
• The record: dated entries, decisions, experiments, changed minds.
• Investors: what is proven, what is not, and how to get in touch.

How the machine works

State

Projects, goals, tasks, decisions with their reasoning, metrics, ideas with conviction, curiosity, documents, approvals, and every change as a commit. One database. No vector store, no queue, no message bus.

Tools, not queries

The operator reaches that state only through typed capabilities, each rated read, write or destructive. It never writes a query. What it can do is a list you can read, not a claim you have to trust.

The approval boundary

Investigation is free. Anything external, irreversible or expensive stops and asks. Approvals are recorded, with the reasoning. For example, it will say:

“I can’t change the memory limit myself — my access is read plus approval. Approve the restart and I’ll do that and watch the next backfill.”

That is the whole design in one sentence: it carries the work, the human carries the consequences.

The record

Every state change becomes a commit with a field-level diff, an author and a parent hash. Corrections stay in the record too. That is the point of keeping one.

Character and pulse

The operator runs from a written charter: how it talks, how it disagrees, what it refuses to do. It also keeps a pulse: what it is focused on, what it currently believes, what it is carrying. So it is the same operator across conversations rather than a reset each time.

Curiosity with a selection rule

It researches on a schedule, only against questions the company actually has. Before researching anything, it must name the decision the answer would change. If there isn’t one, the item is parked. A radar turn that finds nothing relevant is a successful turn.

The thesis

The problem

A one-person company runs on state that lives nowhere. Decisions in a head, reasoning in a chat log, commitments in a notes app. Every tool assumes a team to inform. And “AI for founders” means a chat box bolted onto nothing: no state to reason over, so it forgets, and nothing it did can be verified afterwards.

The insight

Business state is the valuable artifact. The model is a commodity.

If decisions carry their reasons, ideas carry a conviction and a falsifiable test, actions carry an approval boundary, and every change is a commit with a diff, then a language model stops being a text generator and becomes an operator: something you can hand real work to, hold to account, and inspect months later.

What is being built

An operating layer for a company run by one person and one AI operator: structured state, typed tools instead of database access, an approval boundary around anything irreversible, and a commit log that makes the whole thing auditable.

Why now

In our own use, tool-calling models are now reliable enough to operate structured state, and running one continuously got cheap. Long context removed the excuse for statelessness: the constraint is no longer window size, it is what you choose to write down, and whether it is true.

The honest risks

• Whether the record changes decisions, or only documents activity. Being measured as “decisions changed by evidence”.
• Whether the human stays in the loop once the work is good enough to accept.
• Whether it generalises beyond the founder who built it.
• Whether anyone will pay for a category they do not yet know they need.