When we started building the first version of Viktor last year, we wanted to find the answer to one question: what will an AGI harness look like? The harness is everything around the model: the tools it can call, how it's prompted, when it wakes up, what it remembers, and what it's allowed to do.
We are promised a utopian future where AI does all the work and everything is abundant. But if models just keep getting more and more powerful, is that alone enough to actually do most human work? We don't think so. A model that could do the work of a great analyst is still trapped if it can only respond when someone types at it, forgets everything between conversations, and has to squeeze every action through a handful of rigid tools. ChatGPT's harness doesn't get most of the value out of the underlying models, and the same is true of today's coding harnesses like Claude Code and Codex.
The most useful answer we found is a test. Before any change to Viktor's harness ships, it has to answer one question:
Will this harness change still be useful for Fable 10? If yes, we build it. If no, we don't, no matter how much it would help this quarter.
The test sounds obvious until you hold the last two years of agent products up against it. Most of what got shipped fails.
Harness code expires
Last year, many agent products carried a drawer of tricks. Rerun the agent at the end and keep the better result. Re-trigger it on its last turn so it double-checks its work. Inject reminders mid-task when it stalls. Wrap everything in retries because the model quits early.
Then Opus 4.5 arrived, and most of that drawer stopped mattering. The failure modes it existed to patch had shrunk to noise.
This keeps happening, because most harness code is a workaround for a model weakness, and a workaround expires when the weakness does. A retry heuristic survives maybe one model generation, a tuned re-prompting trick maybe two. A shared filesystem survives all of them: no amount of intelligence makes "nowhere to save your work" a good idea.
Everything you could build sorts into two piles. Workarounds compensate for what the model can't do yet. They depreciate, and their expiry date is the next release. Capabilities extend what any competent actor can do. They appreciate, because each generation uses them better than the last. Most agent codebases sit mostly in pile one, because teams optimize against the model in front of them, and the model in front of them is always the weakest one they'll ever integrate.
The Fable 10 test forces the sorting early. If a model five generations out would still want the thing, it's a capability. Build it. If that model would ignore it or trip over it, it's a workaround, and we skip it.
What the test admits: primitives, not workflows
Ask what Fable 10 wants to live in, and a pattern shows up fast. It doesn't want workflows, the meeting-summarizer and invoice-chaser features agent products usually ship. A workflow is a ceiling: the product can never be better than the flow you designed, no matter how smart the model gets. A primitive is a floor: every model generation stands on it and reaches higher than the one before did.
Viktor is an AI coworker that lives in Slack and Microsoft Teams and does its work by writing and running code in a workspace it shares with the whole company. Here's what we built, and the constraint behind each piece.
A shared filesystem. A single, isolated chat thread is too constraining an abstraction, because everything the model learns or builds evaporates when the conversation ends. So it gets a workspace where scripts and data persist across every session and thread. The payoff is accumulation: a script the agent writes in March to pull data from three integrations is still there in June, and by then other work depends on it.
A heartbeat. Crons and event triggers only cover work you saw coming. Nobody wires up a trigger for "notice this project is drifting." Viktor instead wakes on a cycle with no assignment, reads the state of the company, and asks what needs it. That loop is most of what people actually mean by "proactive."
Waits, and crons it configures itself. Real work isn't one continuous push. You send the reminder, and the correct next action is nothing for three days. We made waiting a first-class action, from minutes to weeks, alongside fully configurable crons, including conditional ones where a cheap script runs first and decides whether the model needs to wake at all. "Check back Thursday, escalate if unpaid" becomes one line the agent writes for itself.
Everything available as code. The harness must not cap how fast or efficiently something can be done, and fixed tools with fixed workflows put our imagination between the model and the task. Every capability is exposed as code instead, with most arguments surfaced: structured output, image generation, transcription, speech, web search, browser, file conversion, bulk readers across integrations. The model decides how to combine them, and when the best solution is plain software with no LLM in the loop, it writes that.
Subagents, and cheaper models under an orchestrator. Some jobs are one decision made four hundred times, and one context window shouldn't carry all four hundred. The agent fans batches out to copies of itself and hands simple search or implementation work to cheaper models. Even Fable 10 won't want to spend frontier attention on grunt lookups.
Skills, not a fat prompt. A model that can do everything can't carry the manual for everything in its head at once. Capabilities live in skill files loaded when relevant, including the new tools the agent creates itself. The main prompt stays small, and the library grows without a token tax on every request.
Seams for people. Nobody hands real work to an agent they can't supervise. That's why there's an approval system for consequential actions, a way for the agent to propose work it could take over, and quick UI apps for when a chat thread is the wrong interface.
One task, end to end: the heartbeat pulls up overdue invoices, a script saved months ago fans the list out to subagents, drafts wait behind an approval, a conditional cron re-checks in three days, and the agent stays silent if nothing is due. Six primitives. We never wrote an invoice-chasing feature.
Nothing on this list gets less useful as the models get smarter.
What the test rejects, and why refusing is hard
The pull toward workarounds is real: a model weakness hurts today, a patch fixes it today, and the primitive that would make the patch unnecessary takes longer to build. But stack enough patches and you end up with a product made of compensations, one that nobody can reason about and whose value shrinks with every model release.
So when today's model needs help, we put the help where deleting it is cheap. A model that under-searches, stops early, checks in too little, or writes in the wrong register gets a model-specific system prompt section, iterated against our benchmarks before we roll it out and on failures we see in production, then removed the day the next generation doesn't need it.
Complexity rises much more in harness space than in prompt space. The model's behaviour together with its prompt is already a complex system, and harness machinery multiplies with it, which makes debugging very difficult: when something breaks, you can't tell anymore whether it was the model, the prompt, or the machinery.
Two things we own that might expire
Two of our pieces are harder to sort. They're real capabilities today, but whether they stay useful depends on where the labs take the models, so we re-check them every generation:
- Memory summary files. High-quality Markdown files that present the full state of the company, instead of re-reading tens of thousands of noisy Slack messages. Continual learning inside the models would make them pointless. The labs aren't heading there yet.
- Compaction checklists. Deliberate choices about what carries into the next session. Very large context windows shrink the problem, and something more native, like provider-side token compression, might remove it.
The bet
Under all of this is one assumption: the models keep getting better. If that stops, we've built a harness that's too simple, and simplicity is cheap to fix. If it holds, every primitive we've built appreciates on someone else's R&D budget. Each new generation shows up already knowing how to use the filesystem and the crons, and uses them better than the one before. The drawer of tricks stays empty.
We build Viktor for the models that are coming, not the ones we have. The test is how we hold ourselves to that.
TL;DR
- Most harness code is a workaround for a model weakness, and workarounds expire with every release.
- We sort with one test: will this still be useful for Fable 10? Capabilities pass. Workarounds don't.
- What passes is primitives: a shared filesystem, a heartbeat, waits and crons, everything as code, subagents, skills, seams for people. A workflow is a ceiling; a primitive is a floor.
- When today's models fall short, the fix goes into prompt space, where deleting it is cheap.
- Everything that passes the test compounds with every model release, all the way to AGI.