Project · active · 2026–

Omegi

AI agents build this system for writing novels and audio serials while I direct them. It reads classic novels into maps of their stories and writes new stories from what it learns. The first serial is live on PocketFM.

Afterschool.Games taught me what agents can build when I already know what right looks like. Ba Noi taught me what happens when I let them build before I’ve decided what the system is.

Omegi is the harder test. Can AI write long fiction that people want to keep reading? No test passes or fails it and there is no answer key. You find out only when a reader keeps going or stops.

I don’t write the code or the prose. Claude Code and Codex write both. They also design and run the experiments. My job is to set the direction, choose between approaches, and say when something isn’t good enough.

The work falls into three parts: the system that reads and writes, the way that system gets built, and the tools underneath.

Part 1: The novel system

Reading a book

The reader takes a novel from before 1931 and maps its story: who is in each scene, what each person knows or wrongly believes, what the reader wants to find out, and where the book answers it. Because every book is mapped the same way, any two can be set side by side.

A frozen set of these books is called a library. The first one holds 64 novels that run from Adam Bede to Wuthering Heights. Anyone can read those novels with their maps beside them at ClassicNovels.org.

Writing a book

The writer turns a premise into a plan and the plan into pages. The planner works from the top down through the premise, the cast, the seasons, and each scene. Claude and Codex review every level before the next one is built on it. The writer then drafts each scene from its plan and from what has happened so far. An editor reads whole sections against the story and either passes them on or sends them back with notes.

Each book runs as its own pipeline on Hatchet. Every step is tracked. When a draft fails too many times the run stops and waits for a person.

The first serial is Low Tide at Brannock’s on PocketFM. A woman comes home to Maine to sell her late father’s boatyard until an eight-year-old girl stops the sale.

It falls short in ways a reader notices. Much of the prose still reads like AI wrote it. The same themes come back again and again. Complications stay open long after a better writer would have closed them and moved on. Those three problems are what the next version of the writer has to fix before the second serial goes to a PocketFM contest in December.

The console

A private console shows the whole system on one screen: each book in production, what needs a person, what failed and why, and every experiment, decision, and lesson. Ba Noi had nothing like it. I think that is a big part of why it failed.

Part 2: Building the system

The roadmap

The novel system has version numbers. Each version fixes one library, planner, writer, editor, and publisher. Any published page can be traced back to exactly what wrote it. Nothing changes in a released version. The roadmap decides what goes into the next one.

Experiments

Most ideas get tested on their own before they reach the roadmap. Before an experiment runs we write down the question it answers and the bar it has to clear. If it clears the bar it can propose a change to the roadmap. If it misses it is dropped and the reason is kept as a lesson. Most of them miss.

Roughly 70% of the effort goes to the roadmap and 30% to experiments. An experiment that can’t say which roadmap question it helps answer gets set aside.

The software factory

Every change follows the same path. An experiment or a request becomes a written plan. The plan feeds the roadmap. The roadmap is broken into small tasks called beads. Agent Flywheel runs many coding agents at once on a server. Each one works through its own beads. Whatever passes review and tests goes live.

I sit at the top of that chain and make the calls. The agents do the rest.

Part 3: What it runs on

No single model does the job. Cheap tools go first. The expensive ones get only what the cheap ones can’t settle.

  • Plain code for anything a rule can decide.
  • Classic NLP (BookNLP, spaCy, WordNet) to find the people, places, speech, and events in the text.
  • Jev from TypeSafe AI for questions with a short list of answers, such as whether two names belong to the same person. Jev picks. It never judges.
  • Claude and Codex for judgment and for the prose.
  • Gemini and Mercury in experiments that check whether a different model changes the answer.
  • Gemma 4 31B trained with LoRA on Modal to test whether a smaller model can learn to write from the library.
  • Hatchet to run one pipeline per book.
  • Quarto for omegi.com.

What I’ve learned so far

Famous books are no good for testing a model’s judgment. We changed every name in a chapter of a classic. Both models still named the book every time and guessed far more of the next chapter than they did for obscure books from the same years. They weren’t reading. They were remembering. (The lesson)

The maps are useful and often wrong. In early hand checks they caught about three of every four people in a scene. About three in five of their readings of what a scene does to the reader held up. The system flagged 131 places where a book seemed to break its own rules. Every one was the system’s mistake. I publish the maps on ClassicNovels.org anyway. Reading a book through its map is how I find what’s wrong.

What I’m writing up next

Most of my writing for the next few months will come from this project. The lab keeps its record at omegi.com/labs/lessons: one plain claim per lesson with the tests behind it. Each piece here tells how we arrived at a few of those lessons and links to them. The first three:

  • It starts easy and grows layers. The first version of a system like this takes days. Then each fix adds a layer until a month later there are dozens.
  • An agent or a runner. I wrote books both ways: an agent with tools and skills that decides what to do next, and a Hatchet pipeline with fixed steps. Each one is good at different work.
  • Training our own writer. We tuned Gemma 4 31B with LoRA. It opened scenes well and then drifted. Before we reached preference training (DPO) I realized we had been training it on the wrong things. (The lesson)

Why I am doing it

Most of the problems worth solving with AI at work look like this one. There’s no clean answer key and a lot rides on getting it right. Omegi shows me where each kind of tool works, where it breaks, and how they fit together. It also shows how much agents can build once I’ve done the part that is still mine: deciding what the system is.

Log

Moved the reading of classic novels out to its own product, ClassicNovels.org.
Split the work into two tracks: the roadmap and the experiments. About 1,550 commits, 107 decisions, and 213 lessons in.
Froze the first library of 64 public-domain novels. Started training our own writer on Gemma 4 31B.
The console went up behind a sign-in. One place to see what is running, what failed and what needs me.
omegi.com went live.
Moved the writer onto Hatchet. First story atlas. A novel shown paragraph by paragraph beside a map of its story.
Picked audio serials for PocketFM as the first outlet. Wrote down what the platform rewards.
First commit. A small language for the shape of a story. Tried first on Persuasion.