The Model Is a Component, the Harness Is the System

🌏 中文版

Part 1 drew the workflow/agent line and left one thread hanging: compounding error means "a few more steps" is not linearly harder. This part covers the industry's shared answer to that.

Line up seven companies' own words and the convergence is hard to ignore.

Seven companies, one sentence

All seven share one editor, so "is this a narrative the editor imposed?" is a fair objection. Two things make it hard to sustain.

First, I went back to Dex Horthy's 12-Factor Agents. The framing genuinely originates with the author; it was not applied during the retelling.

Second, and more decisively — the OpenAI Data Platform piece is the only one that argues itself out of a complex architecture. Their agent is a single model plus context assembly, a curated tool set and a runtime. They deliberately skip routing, multi-model mixes, fine-tuning and elaborate retrieval pipelines, because each of those "adds cost, latency, and more ways to fail." And the scale this deliberately plain system carries is 1.5 EB of data, 90,000 datasets, around 4,000 internal users. A team volunteering "we didn't build any of the cool stuff" is hard to explain away as editorial storytelling.

"Give the deterministic parts back to code," productized four times

Convergence on a slogan is worth little. What carries weight is that four companies each shipped the same idea as a product.

• Salesforce's Agent Script — TypeScript that says "if the intent matches X, skip the reasoning loop and run this tool sequence"
• Intercom's Procedures — natural-language reasoning wrapped in deterministic control: conditional steps at decision points, small code blocks guaranteed to produce identical output for identical input, and checkpoints that pause for human approval before sensitive actions
• Microsoft's runtime — only the parts that genuinely need reasoning reach the LLM
• Stripe's blueprints — a sequence of nodes where "implement the feature" and "fix the CI failure" get a full agentic loop, while "run the linter" and "push the branch" are hard-coded

Stripe's rationale is the most direct: some things should never be left to agent judgment, and every deterministic node is one fewer place to go wrong. Back to Part 1's compounding error — that directly shortens the chain that has to be entirely correct, and it compounds across hundreds of runs a day.

Four companies independently building structurally identical things is stronger evidence than seven quotes agreeing. Opinions can converge because people read each other. Products require engineering budget.

Salesforce's three anti-patterns

From twenty thousand enterprise deployments. The first is the inverse of the previous section:

1. Using LLM reasoning where code belongs
2. Escalating the tone of a prompt instead of encoding the rule as policy — "NEVER" and "ALWAYS" in bold with exclamation marks do not work
3. Poor context engineering — their example is compressing a get_orders response from 100K tokens down to 2K

The second deserves an extra sentence. Shouting at a prompt is a natural instinct: the model ignored the rule, so say it louder. The failure mode is that it appears to work — the test passes afterwards, the rule stays in the prompt, and then some edge case comes along and the model ignores it again. Writing the same rule as a policy check in code costs about the same, and code doesn't have moods.

The same principle at the loop layer: LinkedIn rejected ReAct

ReAct (thought → action → observation) is close to the default answer for agent loops. But LinkedIn's Hiring Assistant explicitly rejected it in favour of plan-and-execute: a Planner decomposes the request into a structured plan, and an Executor works through it step by step, each step running its own reasoning loop.

Their reason is blunt: "LLMs become unreliable when asked to handle too many things at once."

That is the same principle as Agent Script and blueprints, applied one layer up — shrinking how much the model has to decide at once. A side benefit is cost control: expensive models for planning, cheap ones for simple steps.

This is the only substantive objection to ReAct from a production system I found anywhere in the corpus, which is worth recording, since most write-ups present ReAct as the general answer.

So how do you improve an agent system

The convergence has a practical corollary: swapping the model is usually the lowest-leverage move available.

Microsoft puts it more bluntly — a model is not a database version. You can swap Postgres versions and expect things to keep working; you cannot do that with a model. Every model behaves differently and the harness needs retuning. Their example: when a new frontier model shipped, the GitHub Copilot CLI team had to retune and retest before they could ship it.

The leverage is elsewhere: the environment (Stripe, in Part 4), how context and memory are trimmed (Part 3), the speed of the feedback loop (Salesforce, in Part 4), and knowing when to stop and hand back to a human.

The series

1. Drawing the Lines: Agent, Workflow, RAG, and MCP
2. The Model Is a Component, the Harness Is the System (this post)
3. Context and Memory: Where Agents Actually Fail
4. Launch Is Where the Work Starts: Enterprise Cases Read Sideways
5. Security: Prompt Injection Can Only Be Contained in the Harness
6. The Protocol Layer: MCP, A2A, ACP, Skills
7. Three Shapes of RAG and the Evaluator Paradox

References

• ByteByteGo — How Microsoft Ships AI Agents at Enterprise Scale
• ByteByteGo — What Salesforce Learned from 20,000 Enterprise Agent Deployments
• ByteByteGo — How Stripe's Minions Ship 1,300 PRs a Week
• ByteByteGo — How OpenAI Built Its Data Agent
• ByteByteGo — How OpenAI Codex Works
• ByteByteGo — How LinkedIn Built an AI-Powered Hiring Assistant
• ByteByteGo — Best Practices for Building AI Agents That Work in Production
• Anthropic — How we built our multi-agent research system
• Dex Horthy — 12-Factor Agents
• Intercom — What's new with Fin 3