From a context graph to Arc

Six months ago we announced Viable Systems. It was a flag rather than a product: we knew the intersection we wanted to work at, and not much more.

The intersection was that people and AI are going to work side by side in the same organisation, on the same work. What does that workplace look like, and how is it structured? Which parts of it are digital? Which tasks belong to a person, which to a model, and how do the two hand work back and forth? Then take all of that and scale it to a team, a department, a company.

That was the whole brief. This post is what we learned trying to answer it, and what we built as a result.

The zero-to-80 demo

Around us, the industry was getting carried away with a particular kind of demo. Prompt a model and get a deck. Prompt it again and get a report. Zero to 80 percent in a sentence. It created an illusion that enterprise work had become effortless: whatever the job was, it was only a prompt away.

Real businesses are messy.

Work does not happen in a clean chat window. It crosses teams, systems, spreadsheets and frantic message threads. It depends on tribal knowledge, client-specific rules nobody wrote down, and hard noes learned through painful experience. Written out in full, a single production workflow can run to thirty or forty pages.

Hand all of that to a model and it gets confused. It will still produce an answer, because producing an answer is what it does, but whether it is the right answer is a different question. Give a model a small task with a handful of instructions and it follows them beautifully. Give it a long-running job with hundreds of instructions, some of which contradict each other, and it does not. That gap is the one most people had not yet run into.

The first product

Our first product was a context graph^{1Context graphs — the term, and where it came from}: a record of how decisions actually get made inside an organisation, captured from the work as it happens and fed into the next run. It wrapped whatever agent a company had already built, watched it work, and learned from what went right and what went wrong.

The analogy landed every time: when a new employee joins a company, access to the systems does not make them effective. They spend months learning how the company actually works. A context graph promised to solve that for software.

We signed design partners. The conversations were intellectually energetic and commercially inert.

Nobody moved. The idea was understood, but it was never urgent. People had brief responses taking four days and campaign checks taking eight hours. The context problem was present in every one of those jobs, but it was not the job they were trying to get done. Nobody wakes up in the morning thinking they need a context layer.

The space also got crowded fast. Within a few months everyone was a context graph, and the term stopped meaning anything in particular.

We had started with a mechanism and asked people to find a use for it. We needed to start with the work.

What we changed

We stopped selling the abstraction.

Organisations do not need another generic platform promising to solve everything from thirty thousand feet. They need software that embeds directly into their most demanding, high-friction workflows and completes the work.

To do that, we built Arc.

Arc is a composable platform. It provides the operational primitives needed to run complex jobs:

• Workflows that manage multi-step chains and asynchronous logic.
• Agents assigned to bounded operational tasks.
• Sessions that maintain persistent working state between people and machines.
• Editable artifacts for structured plans, documents, and decks.
• Purpose-built applications where people review, intervene, and sign off.

Underneath, Arc sits on a custom ontology: a hand-authored model of the customer's business, defining their objects, relationships, rules, and naming conventions. The context graph did not go away; it moved underneath. Every time work runs through Arc, the context graph records what happened, what changed, and what was approved. The ontology defines what things are. The context graph records how they behave.

Crucially, we do not sell the ontology, the context graph, or the platform in a box. We sell completed work.

We take one important, complicated workflow and turn it into software that runs the whole job, from incoming brief to final deliverable: finding the information, applying the rules, asking people for the decisions only they can make, producing the output, coordinating review, updating the right systems, and preserving what happened for next time. If a messy human step is necessary, it stays. The approvals, the client exceptions, and the integrations into their existing stack are not edge cases left for the customer to wire up. They are the work.

Why a prompt does not scale

This is the part people find hardest to see, so it is worth being precise.

Claude and a prompt gets a person a long way. It does not get an organisation anywhere, because it does not scale. One person prompts the model one way; another prompts it differently. One run forgets to check an internal system; another forgets that a metric is defined differently on this team. Each conversation remains an isolated silo without shared lineage or institutional memory.

Production means turning that individual practice into a shared system, where the same rules are applied whoever starts the job, and where the system can stop, ask for missing information and resume, rather than filling the gap with something plausible.

The arithmetic is worse. A model can write fluent prose about a spreadsheet while getting the calculations completely wrong. On DABStep, a benchmark of real-world multi-step enterprise analysis, leading models score just 16% on the hard split^{2DABStep — 16% on the hard split}. On TableBench, numerical reasoning over tables, models manage 51% against 86% for human analysts^{3TableBench — 51% against 86% for people}. On Spider 2.0, enterprise text-to-SQL tasks hover near 21%^{4Spider 2.0 — around 21%}.

When models make mistakes, they cannot reliably catch them alone. But given the exact location of an error, they correct it consistently^{5Tyen et al. — LLMs cannot find reasoning errors, but can correct them given the error location}.

So in Arc, the model never calculates the final metrics directly. Instead, it writes a computational plan: declaring every filter, join, and aggregation as a distinct node with expected outputs. A deterministic runner executes that plan against raw source data.

Where the results match, the number ships with an immutable audit trail back to the source row. Where they disagree, the runner flags the exact node, returns it to the model, and loops until the results converge.

Nothing leaves unverified.

What we believe now

AI is incredibly powerful, and you can build systems with it that were never possible before. You still need good engineering principles and hard constraints around it before a mid-sized or large organisation can actually use it. That is what Arc is: a platform, and engineers deployed alongside it to build the workflows.

The underlying platform is general, but our focus today is in media operations.

We are working alongside publishers, media agencies, brand teams, and ad tech companies. We are deploying Arc on their most critical, high-friction production work: brief responses, RFP submissions, audience packs, media plans, and campaign reporting.

If your team has a workflow like that, bring us the job.

Dennis Yurkevich
Founder & CEO, Viable Systems LTD