Agent scaffolding matters more than model. The proof is eight lines in a system prompt.

Section 1

Eight overrides in twenty-three lines

ChatPrompts.swift line 97 opens the routing table with 'Tool routing:' and the first bullet. The block ends at line 115 with the close of the tools tag. Inside that span, there are eight rules in NEVER, ALWAYS, MUST, or CRITICAL form. Eight is not a target the team set. It is the count of distinct things the same model kept doing wrong on this stack until somebody patched the prompt.

1. Screenshots route to capture_screenshot, never browser_take_screenshot. The latter only sees the browser viewport. The user almost always means the whole desktop, including the Excel window behind the chat bar.
2. WhatsApp follows a four-step contract. search, open_chat, verify get_active_chat, then send_message. The verify step is what stops a wrong send when search returned two contacts with overlapping names.
3. Telegram never goes through Playwright. The bundled telegram skill runs Python telethon via Bash. It is two orders of magnitude faster, dodges captchas, and does not spend an entire context window on the web Telegram DOM.
4. Native Mac apps go through mcp__macos-use__*, not Playwright. Finder is not a webpage. Treating it like one was a category error the model made often enough to earn a line.
5. CRITICAL: never type reasoning into the user's open application. The exact text in the prompt: 'Typing your chain-of-thought into a user's document (Word, Notes, etc.) is a critical failure.' This rule was written because it had happened.
6. browser_navigate vs the macOS open command. If the user explicitly wants the agent to interact with a page, use Playwright. If the user just wants a URL opened in their own browser to look at, use 'open'. Mixing these wastes a turn loading the extension and produces a tab the user did not ask for.
7. Tab hygiene: list before navigate. browser_tabs list is the first call, match by domain, switch with browser_tabs select if found, otherwise reuse the current tab. Close anything you opened. Without this rule the agent ends a five-minute task with eleven new tabs the user has to clean up.
8. NEVER run find on the home root. The exact phrasing: 'NEVER run find ~ or any recursive search on the entire home directory, it scans millions of files and hangs for minutes.' This is a small rule and a large outcome.

Outside the routing block, two more rules carry the same kind of weight. The ask_followup rule on line 113 says the call must be the absolute last tool call of the turn and that no text or tool call may follow it, because the floating-bar UI has nothing to do with the trailing content if it does. And the onboarding chat, on line 228, opens with 'ABSOLUTE LENGTH RULE: every message you send MUST be 1 sentence, MAX 20 words. No exceptions. Never write 2 sentences in one message. This is the number one rule.' That line is uppercase, repeated, and wrapped in 'no exceptions' for a reason. The model still tries to write paragraphs. The harness still has to override it.

Section 2

When the prompt fails, the runtime catches it

A system prompt is best-effort. The model reads it, attends to most of it, and still occasionally does something the prompt forbade. For one specific class of failure, Fazm has the runtime catch the model in the act. The file is acp-bridge/src/fazm-tools-stdio.ts and the relevant block is lines 587 through 687, where the execute_sql tool intercepts every write query before it reaches SQLite.

The model, when running in a chat observer session, has access to execute_sql against the user's local fazm.db. The system prompt tells it to use save_observer_card for the common case of saving an observation. The model sometimes ignores that and writes raw SQL anyway, often against a table the model invented from the shape of the schema (memories, user_facts, observations, the usual culprits). Without a guardrail, the INSERT silently fails against a non-existent table, the model believes the save succeeded, and the user observation is gone.

Line 617 of fazm-tools-stdio.ts declares the allowlist:

const KNOWN_TABLES = new Set([
  "observer_activity", "ai_user_profiles", "chat_messages",
  "indexed_files", "local_kg_nodes", "local_kg_edges", "grdb_migrations",
]);

On every write, the bridge regex-matches the target table from the INSERT INTO or UPDATE clause, lowercases it, and checks membership. If the table is not in the set, the call is rejected with a string the model will read on its next turn:

Blocked: table "X" does not exist in the app database. To save observations, use your file tools to write memory files or use save_observer_card instead, do NOT write raw SQL.

The error message is part of the harness too. It is in the form the model can act on: 'do this instead, here is the name of the tool.' The next turn picks save_observer_card and the work moves on. Without that one block of code, every model in the family would lose user data on the same failure path.

Section 3

One concrete request, end to end

Pick the simplest example: the user asks Fazm to message someone on Telegram. The model, by default, will reach for whatever web automation tool is nearest. The harness intervenes at three distinct layers before the model ever picks a tool.

The harness made three decisions the model did not. It picked which tools were even in the menu (Playwright was excluded from the Telegram path by the routing rule). It enforced that ask_followup must be the absolute last call of the turn (not a model-side preference, a UI contract). And it length-capped the reply through the response_style block on lines 76 to 91. None of those are model improvements. None of those move when the model upgrades.

Section 4

What the model does, what the harness enforces

Five concrete rows. Left column is what the same model does on a stack without these rules. Right column is what the harness forces. The model does not know which column it is in. The user only sees the result.

Counterargument

But surely a smarter model fixes this on its own?

This is the strongest version of the objection. If the model were good enough, it would discover from the tool descriptions alone that telethon beats Playwright on Telegram and that capture_screenshot beats browser_take_screenshot on a desktop ask. Two answers.

First, even if a future model learns to converge on the right answer in five turns, a shipped product cannot afford five turns. Each turn is a tool call, a wait, a re-prompt. Five wrong turns is a thirty-second wait the user reads as 'this thing is broken.' The harness collapses those five turns into one because the rule is in the prompt at turn zero.

Second, several of the rules are not about model intelligence, they are about contracts the harness owns. ask_followup ending the turn is a UI promise. The 20-word length cap on onboarding messages is a floating-bar geometry constraint. The 'never-type-reasoning-into-the-user's-document' rule is about the user's trust, not about a model's reasoning. No improvement in pretraining quality fixes any of those because they are not facts, they are decisions.

The version of the argument that gives the model its full due is: the model picks better sentences, the harness picks better turns. Sentence quality is what improved most between every major frontier model release in the last two years. Turn quality, on a real product, is mostly carried by what the harness has memorized from production failures, and that does not transfer when you swap the model.

Resolution

How to read this if you are picking an agent

Three concrete things to do, all of them in fifteen minutes, without trusting any vendor's marketing copy.

• Read the system prompt. If the candidate is open source, the file is in the repo. If it is closed, ask. The presence of a long, specific routing table with NEVER and ALWAYS rules is a positive signal. A short, vague, encouraging prompt is a signal that nobody on the team has run this in production with users yet.
• Look at the tool registry and timeouts. In Fazm, the registry is buildMcpServers around line 992 of acp-bridge/src/index.ts. The watchdog tiers (10 seconds for internal tools, 120 for MCP, 300 for the rest) are constants at the top of that file. If the candidate has one global timeout or none at all, the agent will hang at some point and the user will see the spinner forever.
• Find one runtime guardrail. The KNOWN_TABLES allowlist at fazm-tools-stdio.ts:617 is the kind of code you only write after you have seen the model do the thing the guardrail prevents. A repo with at least one of those has been bitten by a real user. A repo without any has not.

Once you have that picture, the question 'which model does it use' is interesting but secondary. Two products on the same model can produce wildly different user experiences because the harness is doing different work behind each one. That is the entire claim.

Closing

The model is the engine. The harness is the road.

A faster engine on a road full of potholes does not arrive sooner. The frontier model arms race is real and the engine is getting better. Every frontier model release feeds every harness equally. The differentiation, on any given product, is what the road is paved with. Eight rules in a system prompt, one allowlist in a tool wrapper, one watchdog on a stuck call, one length cap on a floating-bar message: these are paving stones, and they all ship in the harness.

The Fazm harness is open source. Every line referenced on this page resolves to a real file on disk in github.com/m13v/fazm. ChatPrompts.swift is 818 lines, mostly routing tables and length rules. acp-bridge/src/index.ts is 2,914 lines, mostly timeouts, retries, and diagnostic dumps. Read either one for ten minutes and the argument on this page stops being a position and starts being a description.