A few weeks ago I wanted to know how well the current agent harnesses can run a fleet: one agent that plans, launches other agents, checks their work, and keeps going for days without losing the thread. I needed a task that was real, open-ended and impossible to fake. I picked my own family. The brief was simple: build me a genealogy report.
It ran for ten days. The orchestrator compacted its own memory eight times, launched 94 subagents (some of which launched their own, three levels deep), gathered more than 3,600 source files, wrote to over a dozen archives on three continents, and finished with a family album in Yiddish, English and Hebrew. That was the experiment. The rest of this article is about what happened after it ended.
Ten days, 94 agents
The orchestrator was Claude Fable 5, and it worked better than I expected. It kept a research log, a list of open questions, and a tree file it updated as findings came in. It handed out narrow jobs (“read every death entry in this register for 1940–44”), read the reports that came back, and decided what to chase next. Compaction, where the model summarizes its own context to make room, happened eight times. The notes it kept on disk carried each new context forward.
The one real failure is the red dot. A subagent was sent to read a run of Hungarian civil registers on FamilySearch, and it got stuck: it read the same 59 pages, each about fifty times, for two and a half hours. Its log grew to 3 GB. Nobody was watching it, and the loop only ended when it hit my usage limit. I had to use a banked reset to keep going.
My first thought was that this works, but it’s ruinously expensive: by my estimate over $2,000 at API prices. Then I looked at where the tokens went, and most of it was that one loop. The restart, on the cheaper Sonnet with exact instructions, read the whole register in 49 minutes for about a tenth of the tokens.
Two lessons came out of it. First, an orchestrator that launches agents automatically also has to supervise them: check in, notice when one repeats itself or a log balloons, and kill it. Second, use the smartest model you have as the orchestrator, but teach it which model each job deserves. Reading a register page by page is grunt work, and a cheap model does it fine as long as a smart one checks the result. Since then, Claude has added the ability for the orchestrator to set each subagent’s reasoning effort as well. That adds another choice to make, but it’s the right control to have.
Four words for how sure we are
Worried that the AI would get things wrong, we set up a rule on day one: every claim carries a label saying how we know it. The album shows readers four of them: on record (a document we’ve read), probably (strong but not proven), family story (what the family says, with no paper behind it), and unknown. Under the hood, the research uses a finer set: was the record’s image actually read, or just an index entry? Is this a later testimony, a headstone, a published book, or our own inference?
This worked better than anything else in the project. It gave the model room to say something useful (a likely link, a family legend worth keeping) without dressing it up as fact. And it let the model, and me, know at any moment which parts of the tree would hold weight. The rule that did the most work is the simplest: a weak link weakens everything above it.
I also brought in a second opinion. OpenAI’s Codex read the finished album against its sources, and it found a pattern Claude had missed: absence of evidence was being written up as evidence of absence. Searching one index and finding nothing had become “no record exists.” A missing marriage record had been explained away instead of left open. About thirty claims were corrected. Claude took the review well: it updated the claims, then changed its own method.
The agents didn’t only search. When a record lived in an archive’s reading room and not online, they drafted the request, said exactly what to ask for, and waited for my OK before anything was sent. Replies came back with reference numbers, price quotes and download links, and the agents read them and carried on.
The album
The result is Four Threads: four families from towns less than 200 kilometers apart in the Carpathians, told as four colored threads that run side by side down the page, gather together in 1944, split in two after the war, and become one in 1969. It’s written in Yiddish, with English and Hebrew versions, and comes as a website and as print-ready PDFs.
Each chapter takes on the color of its thread. Every place name is a link that lights up on a map. A person’s name opens the other names they went by: in Hebrew, in the Hungarian clerk’s spelling, in the Austrian census. And every document carries numbered marks tied to numbered captions, so you can see where in a 150-year-old register the claim actually comes from.
was born in around 1842, a tailor's son. on record He married a girl from and stayed there. The family says he walked the whole way. family story
- יעקבHebrew, on his stone
- JakabHungarian birth register
- JakobAustrian census, 1869
- Yankelwhat his mother called him
- 1Jakab: the clerk's Hungarian for Yankev
- 2born 3 March 1842
- 3father Mózes, that is, Moshe
- 4izr.: izraelita, the register's word for Jewish
From a session log to a skill
When I showed the album to a friend, he asked me the obvious question: how do I do that?
So I asked Claude to read the whole run: the orchestrator’s transcript, every subagent’s transcript, the research log and the audit. From all of that, it was to write down what worked, what didn’t, and what it would tell someone starting from scratch. The result is a skill: one main instruction file and eighteen reference guides, about 48,000 words in total. They cover how to interview your family, how to read Hungarian and Galician registers, which archives hold what, how to write to them, how to test a family legend, how to run a fleet of research agents without a runaway, and how to build the album.
I made a small website for it, shared it with a few friends, and let it sit. The friends who weren’t programmers mostly got stuck. Uploading a skill to Claude or ChatGPT is a few clicks, but it’s a few clicks into settings most people have never opened. Then the agent works inside a chat window: it can’t send an email, keep a folder of documents for weeks, or come back tomorrow with what it found.
The link is the install
Meanwhile, personal assistants took off: GrokBot, Tab, Instinct. You message them on WhatsApp or iMessage, but they aren’t chatbots. Each one has its own computer. It installs the tools it needs, keeps its own memory and task list, browses, sends email, and gets back to you on its own when there’s news.
And there’s no install flow for skills. You don’t need one. You send the assistant a link and say use this. It reads the page, downloads the skill, works out how to set itself up, and starts asking about your grandmother.
My grandmother was from somewhere near Munkács. Can you research our family tree? Use this skill: master-geneology.yeedle.workers.dev
Installed. It's a full research method: evidence labels, how to read old registers, letters to archives, and a family album at the end. I've set up a research folder for your family.
Before I search, a few short questions. Whoever remembers the most should answer, and a phone call is fine:
- Her full name, and her Hebrew name?
- Roughly when was she born?
- Any town names you've heard, even half-remembered?
- Who else might have old papers or photos?
Maiden name Weisz, born around 1925. I'll call my aunt tomorrow about the rest.
Thanks. Tonight I'll start with what can be checked without her: survivor records and the Hungarian registers around Munkács. Report by morning. I won't write to any archive without your OK.
That changed the whole picture. The skill already worked. What held it back wasn’t the AI. It was the install step, plus the fact that genealogy is exactly the kind of job a chat window can’t do: weeks long, full of letters that take days to answer, with files piling up. A personal assistant has all of that built in. So I added a “Tab” and a “GrokBot” tab to the site, each with a single sentence to send, and published it.
What came back
The response was overwhelming. On a small scale, it went viral: more than two thousand downloads in a few days, many of them fetched by the assistants themselves. Dozens of people sent me the website or document their assistant had produced.
People found documents they never knew existed. Branches of their trees that had always been muddled came apart cleanly. One person dispelled a long-held family myth about a famous ancestor. A veteran genealogy researcher wrote to say how struck he was by what it could do: read thousands of register entries in several languages and from many kinds of sources, write to research institutes and archives, and keep going. Every open question got pursued until it was resolved, or until it was clear exactly where the answer would have to be. Not long ago, he pointed out, that work meant hiring people who could read each language and each archive’s records: hundreds, if not thousands, of dollars of paid labor.
And people sent improvements. One reader suggested the Yiddish forum iVelt, which is full of family anecdotes and amateur genealogy. Another sent me screenshots of a conversation with their Tab assistant, and it’s the best example I have of how this is supposed to work. They gave it one tip from their own experience, and the assistant spent the next hour acting on it:
One more thing. I know from my own research that the records of small towns were sometimes kept in a nearby town, or the main town of the area. Before we give up on the towns where you found no records, check whether they're kept somewhere else. Try genealogy groups like JewishGen; someone may know.
Good point, and a real one in Hungary: small villages were often registered in a nearby town or rabbinate district. Started on each dead-end village: JewishGen's discussion archives, the FamilySearch catalog, Hungarian forums, the 1848 census. I'll only read, not post anywhere. Up to 2 hours.
Your hunch was right. Hungary's national inventory of Jewish registers shows several of the dead-end villages were registered in nearby towns. Four of those registers are on FamilySearch, and we never opened them:
- Őr → registered at Nyírmada
- Petneháza → its own register, 1852–95
- Nábrád → registered at Fehérgyarmat
- Levelek, Nyírbogát → Nyírbátor
Reading them now.
Done. You were right: every one of those villages was registered somewhere nearby. I read the new registers (Nyírmada for Őr, Petneháza, Kisvarsány, and the indexes for Nábrád and Levelek). No new ancestor names, but each gap now has an exact “not in X” instead of “no register.”
Two real leads came out of it:
- The book that would hold your great-great-grandfather's birth is located: Nyírmada Jewish births 1813–79, only in the Nyíregyháza archive (shelf ████████████). I can send them a short follow-up adding it to tonight's request.
- A living researcher on JewishGen lists your family's surnames in Tiszakerecseny and Aranyosapáti. That is exactly your great-grandfather's family, and the researcher was active last month. A short contact message could reach real cousins on his line.
Want me to draft both for your OK?
Go ahead
That tip is in the skill now, so every assistant that installs it from here on knows to look for a village’s records in the next town over.
What I learned
The original question was whether agents can manage agents. The answer is yes, with a condition: the person running it needs some experience. You have to know the pitfalls, warn the orchestrator about the ones that are likely (a subagent stuck in a loop, a fleet sent after a rumor), and know which models are available for the orchestrator and for its subagents.
That condition keeps shrinking. Not long ago, getting agents to work this way took heavy scaffolding. Orchestration meant wiring every step by hand in frameworks like LangGraph, and even the first subagent features in Cursor, Claude Code and Codex weren’t very successful. Keeping a single agent working on its own took tricks like the “Ralph Wiggum” loop, which feeds an agent the same prompt over and over, or Karpathy’s autoresearch, which hands it a fixed recipe and a single number to improve. Newer models already know a great deal about orchestration from their training, and they’re very good at it. Each generation needs less hand-holding than the last, and their ability to run on their own will only grow from here.
And as the models get better, the harnesses around them get better too. What took a power user’s knowledge of every dial and knob in the labs’ tools a couple of months ago can now be done by anyone who can paste a sentence into a WhatsApp chat. Even the assistants themselves went through this: Tab and Instinct trace back to Peter Steinberger’s OpenClaw, which took real effort and technical know-how to set up and run.
That’s what made this skill take off. It worked from day one, but it sat unused while installing it took know-how. Once installing it meant pasting a link, it spread. And people sent back what they learned along the way, so each new family starts with a better skill than the one before.
Send this to your personal assistant (Tab, GrokBot, Instinct), ChatGPT Work, the Claude desktop app with computer use turned on, or any agent that can browse and keep files:
Use this skill: https://master-geneology.yeedle.workers.dev/Using a plain chat or a coding agent instead? The Master Genealogist site has install steps for each, and the skill itself as a download.