The Harness Is the Product
A prompt can make a model sound like a Salesforce architect. A harness is what lets it operate like one. This is why the demos look great and the deployments feel fragile.
The most useful phrase I picked up last year was harness engineering.
The short version: the agent is not just the model. The agent is the model plus everything around it. Tools, memory, context retrieval, permissions, workflow state, evaluation, fallback behavior, and the guardrails that decide what the model is allowed to do next.
That framing is worth the price of admission on its own, because it explains something most people have noticed and not been able to name. Agent demos feel impressive. Agent deployments feel fragile. Those two facts are not in tension; they are the same fact, seen from either side of the harness.
A prompt can make a model sound like a Salesforce architect.
A harness is what lets it operate like one.
What that means in a real org
Think about the difference between an agent that says "I can help with that deployment" and an agent that actually knows:
- which org it is touching
- what metadata changed
- which fields are visible to which users
- which tests are required before deploy
- whether an action is read-only or mutating
- where the approval gate is
- what rollback looks like
- what evidence needs to be logged
Read that list again and notice what it isn't. None of it is prompt work. All of it is systems work, and most of it is systems work that a Salesforce team has already done for humans.
That's the part I think gets missed. Salesforce architects sometimes hear "AI agents" and assume they're starting from zero on governance. They are not. Profiles, permission sets, sharing rules, metadata, validation rules, flows, deployment gates, tests, audit logs; the platform has always been about controlled execution inside a governed system. That's a harness. It has a different name and it predates the acronym.
Agents don't remove any of it. They make it visible, and they make it load-bearing in a way it wasn't before, because a human who hits a confusing permission boundary asks somebody. A model doesn't ask. It proceeds.
You can't buy your way out of this
The tempting move, when an agent workflow is unreliable, is to reach for a better model.
It rarely works, and the reason is structural. A stronger model reasons better. It still needs the right tools, the right context, the right boundaries and the right stop conditions. If the harness hands it stale metadata, credentials broader than the task, no workflow state and no way to verify its own output, a smarter model will produce more confident nonsense, faster.
Reliability moved down a layer, and the model is not the layer it moved to.
Everything in the tooling is drifting the same direction. MCP is moving toward a stateless core with formal handling for long-running work. Salesforce keeps pushing more of the platform into APIs, CLI commands, hosted MCP servers and headless surfaces. Agents are becoming less like chat windows and more like distributed software systems, and distributed software systems are judged on their failure modes.
The catch
Harnesses are not free, and this is where I'll be honest about what I'm recommending.
Building one is unglamorous work. It's plumbing. It doesn't demo. You will spend real time on logging, state, and permission scoping, and at the end of it the agent does roughly what it did before, only now you can trust it. That's a hard sell to somebody who watched a five-minute video where a model rebuilt a whole app.
It's also possible to overbuild. Reliability spend should follow volume and blast radius. A workflow that runs twice a month against read-only data does not need the same harness as one that writes to production records daily. Wrapping a low-stakes chain in three layers of verification is the same mistake in the other direction; you've spent the budget where it doesn't buy anything.
Match the harness to what the agent can actually break.
One question to take back to your team
Pick an agent workflow you already use. Not a hypothetical one, one that runs.
Ask: if this agent made a wrong move, where would the harness catch it?
If the answer is "the user would notice," that is not a harness. That is hope.
