The WAT Framework

Ninety percent accuracy is a trap.

The standard approach to AI automation is to describe a multi-step task to a language model and let it perform every step: fetch this page, extract those details, compare them, write it up, publish it. In a demo, this works. In production, it degrades in a way that surprises people.

If each step is 90% reliable, five steps in sequence succeed 0.9⁵ = 59% of the time. Four failures in ten runs.

And that's the optimistic reading, because the failures aren't loud. A model asked to scrape a page it can't reach doesn't stop — it produces something plausible. The output looks correct, arrives on schedule and is quietly wrong. That is considerably worse than an error message.

The instinctive fixes make it worse: longer prompts, more instructions, "please be accurate". None of them address the actual cause, which is architectural. The model is being asked to do work that isn't a reasoning problem.

Three layers, with a hard line between judgement and execution.

• Layer 1 — Workflows. Written procedures in plain language: the objective, the required inputs, which tools to use, the expected output and how to handle edge cases. The same briefing you'd give a competent new colleague — versioned, reviewable, and readable by the business owner rather than only by a developer.
• Layer 2 — The agent. The model's job is coordination and judgement alone: read the relevant workflow, run the right tools in the right order, interpret results, handle failure, ask when genuinely uncertain. It decides what happens. It never performs the mechanical work itself.
• Layer 3 — Tools. Ordinary scripts that do the actual work — API calls, data transforms, file operations, database queries. Deterministic, testable, fast, and identical on every run. Credentials live here, not in a prompt.

The rule that makes it work is unglamorous and absolute: if a step can be written as code, it is written as code. The model never improvises an operation that a script can perform reliably.

The system gets better because it's designed to learn.

The proving ground was a full research-and-publishing pipeline: gather sources, extract and deduplicate, evaluate relevance, draft, format, schedule and send. Seven steps — precisely the length where the naive approach becomes unusable.

• Tools before invention. The agent checks for an existing tool before writing anything new, so the library consolidates instead of sprawling into a hundred near-duplicate scripts.
• Failures become documentation. When something breaks — a rate limit, a timing quirk, an undocumented API behaviour — the fix goes into the tool and the lesson goes into the workflow. The same failure doesn't recur next month.
• Cost discipline. Anything spending credits or hitting a paid API pauses for confirmation before re-running. Automation shouldn't be able to surprise you on a bill.
• Workflows are protected. They can be refined but not silently overwritten. The written procedure is the institutional memory of the system, and it's treated as such.
• Deterministic where it counts. Every step that must be right every time — the maths, the sending, the writing to a record — is code with tests, not a paragraph of hopeful instruction.

• Python
• Claude API
• Tool use
• Markdown SOPs
• Scheduled execution
• Structured logging

What this means if you're hiring the studio.

You're unlikely to want a framework. You want a process to stop eating a day a week. This architecture is why the thing that gets delivered can actually be trusted with that.

• It runs unattended. Reliability is engineered in, so the automation doesn't need someone checking its homework — which was the entire point of automating.
• It fails loudly. When something breaks, you're told. You never receive a confident, well-formatted, incorrect result.
• You can read how it works. Workflows are plain English. Your team can understand and amend the procedure without being able to program.
• Costs stay predictable. Deterministic code is free to run; model calls are reserved for the steps that genuinely need judgement.
• It's not locked to one model. Because reasoning and execution are separated, the model underneath can be swapped as prices and capabilities change. Your tools are yours.

This is the difference between "we added AI" and a system your business can depend on — and it's the reason the studio is comfortable putting automation near real customers and real money.