When I started building the previous version of Viktor last year, I wanted to find the answer to one question: what will an AGI harness look like?

Some quick context. Viktor is an AI coworker: it lives in Slack and Microsoft Teams, works inside a company's tools, and does its work by writing and running code in a persistent workspace it shares with the whole company. The *harness* is everything we build around the model to make that possible: the tools it can call, how it is prompted, when it wakes up, what it remembers, and what it is 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 express every action through a handful of rigid tools. ChatGPT's harness doesn't unlock most of the value sitting in the underlying models. The same is true of today's coding harnesses like Claude Code and Codex.

That gap, between what models can do and what the software around them lets them do, is in our view one of the largest unclaimed opportunities in AI right now. And it changes what you should optimize for: a harness designed around the weaknesses of today's models will be obsolete in months, while a harness designed for the models that are coming gets stronger with every release.

So instead of asking what today's models need, we asked a different question. What kind of harness does a model like Fable 10 or GPT-11 want to live and act in? What primitives does it need to do anything in the world?

Early thoughts (from back then)

• A single, isolated thread is too constraining an abstraction. The model needs a way to interact with other threads, share information, and build up its own useful tools that it can reuse in any session. → A shared filesystem where it can save scripts and data for reuse across sessions.
• Proactivity today means either a cron firing at fixed times or an event-based trigger. Humans run a loop: pull new work, check on the status of ongoing work. AIs need the same loop to actually do human work. → A heartbeat, plus additional crons for fine-grained status checks.
• Real-world work isn't always a task you work on until it's done. Sometimes you check in every few days, or repeat something on a cycle. → The ability to create crons, and to wait anywhere from minutes to weeks.
• The harness shouldn't limit how fast or efficiently something can be done. Everything the agent can do should exist as code primitives, as configurable as possible, so a smart model can optimize how it works, and even write plain software (no LLMs involved) to solve problems. → Make everything available as code and expose most arguments to the model.
• It needs to be always on, jumping into action when needed. → It has to run in the cloud, not as local software.

The core principle

That's the core goal: a harness that lets an AGI-level model (imagine Fable 10) automate all work. From it comes the single question behind every harness decision:

Will this harness change still be useful for Fable 10? If yes, let's add it. If no, let's not.

Decisions that follow directly from this principle

Code-first, minimal harness

• Every tool is available as code, with lots of arguments surfaced to the model.
• Keep the harness itself minimal.
• System prompt sections explain how the harness works and the key filesystem structure.
• Progressive disclosure: capabilities live in skill files, including the new tools the agent creates itself. Fable 10 doesn't want every tool and workflow description crammed into the main agent prompt.

Autonomy and scheduling

• Fully configurable crons, including conditional crons, where a script runs first to decide whether the model should run at all.
• Wait functions.
• An event-trigger system the agent can fully configure itself.

Scale and delegation

• Subagents: any large batch of items needs a fan-out pattern.
• Orchestrator/advisor patterns: even Fable 10 might want to outsource simple implementation or search work to cheaper models.

Capabilities

• A ton of useful tools: structured LLM output, image generation, transcription, speech, web search, browser.
• Utility functions to convert between file types and turn any file into a readable Markdown document.
• Utility readers, like fetching the latest messages across all Slack channels.
• A way to quickly generate UI apps for the user.
• Tools for interacting with its own settings.

Working with people

• An approval system.
• A way to interact with a company and proactively propose work it can take over.

Self-improvement

• Useful error messages from all of our systems.
• A catalogue of best practices, useful tools, and scripts for specific roles, jobs, and tasks.

Much of that catalogue is knowledge earned through trial and error, by interacting with our tools and with users. Knowing that a daily brief should set a certain focus is not in any base model. And a mature script that queries all the needed integrations at once beats recreating it from scratch every session and repeating the same mistakes until it works.

Why this compounds

Every improvement we make in this category compounds with every new model, every month. It also means we automatically unlock more of each frontier model's capabilities. These investments scale all the way to AGI.

Bets tied to the current shape of LLMs

Some decisions follow the labs' current direction, and might change if the shape of the LLMs they ship changes fundamentally (it hasn't, really, in the last year):

• Memory summary files. Up-to-date, high-quality Markdown files that present the full state of the company, instead of reading tens of thousands of noisy Slack messages. If the labs build continual learning into the models themselves this might become unnecessary, but right now the lab direction doesn't point that way.
• Compaction checklists. Carefully deciding what carries over into the next session. Even with very large context windows you'll likely still need compaction. It might fall away at some point, or be replaced by something more native (e.g. token compression in token space on the provider side).

Bridging the gap to Fable 10

There's still a gap between what current models can do and what Fable 10 will be able to do. How do we deal with it without accumulating short-term fixes or needing to rebuild our harness every month? In this order:

1. Model-specific system prompt changes. When a specific model shows behaviour we don't want (too little searching, not finishing tasks fully, too little checking in with users, a suboptimal writing or communication style), we iterate on model-specific prompt sections: against our benchmarks before we roll a new model out, and after rollout on failures we see in production. This work is necessary anyway: models differ in behaviour, and we want to abstract those differences away from our customers.

1. Harness adaptations and hacks (no longer necessary). Pre-Opus 4.5, models had major reliability issues, and you could eke out performance by rerunning agents at the end, injecting additional context based on heuristics, or re-triggering the model on its last turn to double-check its work. There are still places where you could patch model behaviour this way, like keeping a model family from quitting tasks too early, which is far less of a problem with the latest generation (Fable 5, GPT-5.6). We don't need these anymore, and we avoid adding them to the Viktor harness. They complicate the architecture, make failure cases harder to reason about, and add moving pieces. If a model needs a final validation step, a model-specific system prompt section covers it, and we can simply drop that section for the next model generation that doesn't. Complexity rises much more in harness space than in prompt space.

TL;DR

• We build Viktor for the models that are coming, not the ones we have.
• Every harness decision gets one test: will this still be useful for Fable 10? If yes, we build it.
• We give the model open-ended code primitives (tools available as code, a shared filesystem, crons, waits, subagents) and let it decide how to use them.
• Where today's models fall short, we compensate with model-specific system prompt sections that we can drop when the next generation doesn't need them.
• Everything that passes the test compounds with every new model release, all the way to AGI.