Last week I showed you the Hospital Org project: Claude building a complete Salesforce org — seven objects, three trigger handlers, tests, seed data — through six custom MCP tools in an agent loop.
The reaction I get to that story splits into two camps. One camp hears “AI built an org” and gets excited about the model. The other camp — usually people who’ve shipped things — asks the better question: “How did you know when it was actually done?”
This article is for the second camp. Because the honest answer is that the model was the least interesting part. The loop worked because of three unglamorous engineering decisions, and you can reuse all three.
Decision one: the verifier is not the model
Here’s the sentence I’d put on a poster: a loop without a real verifier is an expensive way to generate plausible-looking code.
Large language models are optimized to produce output that looks right. That’s their nature, and most of the time it’s a feature. But in a loop, it becomes a trap: if you ask the model “is your code correct?”, you’re asking the same system that produced the plausible-looking code to evaluate its own plausibility. It will very often say yes. Confidently. With a nice summary of why.
So in the Hospital Org loop, the model never judged its own work. ApexTestRunner did. It’s one of the six MCP tools, and it’s the only one that builds nothing — it runs the org’s Apex tests and reports back two things the model cannot argue with: which tests passed, and what the coverage numbers are.
That’s what I mean by an objective verifier. Not “the model re-reads the code.” Not “a second model reviews the first one.” A system outside the model, running the actual code against actual assertions in the actual org, producing numbers.
If you take one thing from this series, take this: before you build an agent loop, ask yourself “what is my ApexTestRunner?” If you don’t have an answer, you don’t have a loop yet. You have a very fast way to produce code you’ll have to verify by hand anyway.
Decision two: define done before you start
The loop’s stop condition was written down before the first tool call: all tests green at ≥90% coverage.
Notice what that sentence has that “build a working hospital org” doesn’t:
- It’s binary. At any moment, the condition is either met or it isn’t. No judgment call.
- It’s measured by the verifier, not asserted by the model.
- It’s a hard stop in both directions. The loop can’t quit early because the output “seems fine,” and it can’t wander on forever polishing things nobody asked for.
I spent twenty years teaching before Salesforce, and this is just rubric design. If you tell students “write a good essay,” you get arguments about what “good” means. If you hand out the rubric first, everyone — including you — knows exactly what passing looks like. An agent loop needs a rubric, and the rubric needs a machine that can apply it.
The case study: the 88% moment
Theory is fine. Here’s where it got real.
Mid-run, ApexTestRunner came back with coverage for the three trigger handlers, and PrescriptionTriggerHandler sat at 88%. Everything was green. Two of the three handlers were comfortably over the bar. One was two points under.
Pause on how tempting that moment is. Every test passing. 88 is nearly 90. A human reviewer at 6 p.m. might round up. A model asked “are you done?” would almost certainly say yes — the output is entirely plausible.
The stop rule said no. Not “probably no” — just no, because 88 < 90 and the condition is binary.
So the loop went back to work. And this is the part I care about: how it went back to work.
Diagnosis, not retries
It didn’t regenerate the handler and hope. It didn’t add random tests. It read the coverage report line by line and found what wasn’t covered: the addError guard branches — the defensive code that rejects a prescription when its appointment is missing. The existing tests only exercised the happy path and the “appointment not Completed” path. Nobody had ever fed the handler a prescription with a null appointment.
So the loop wrote exactly that: a null-appointment test, targeting the uncovered branches by name. Ran the verifier again. Coverage cleared the bar — final numbers 92 / 100 / 90 across the three handlers — and then, and only then, the stop condition was satisfied.
The fix was surgical because the failure was understood. That’s the pattern.
The same pattern, different failure
It showed up a second time in the same run. At one point the test runner rejected a request as malformed. The blind-retry loop resends the same payload and burns tokens. This loop treated the rejection as information: it compared what it sent against what succeeded before, hypothesized that the runner accepts a single class per call, and reissued the work one class at a time. First retry under the new hypothesis worked.
Two different failures — a coverage shortfall and a protocol error — one discipline: read the failure, name the cause, fix the cause. Blind retries are the agent-loop equivalent of a student resubmitting the same essay hoping for a different grade.
The loop, as an engineering checklist
If you want to build one of these — over MCP tools into Salesforce or anywhere else — here’s the shape that worked:
- Narrow tools. Each MCP tool does one thing. Small surface, clear errors.
- One objective verifier. Something outside the model that runs the real thing and returns numbers. Mine was ApexTestRunner.
- A binary definition of done, written before the run, measured only by the verifier.
- Failures are inputs, not embarrassments. The loop’s job on a red result is diagnosis: which line, which branch, which constraint.
- No early exit. “Looks done” is not a state the loop is allowed to recognize.
None of this is AI magic. It’s the same discipline behind CI pipelines and test-driven development, pointed at an agent instead of a developer. The model brings the ability to read an error and write a fix; the loop’s architecture brings the refusal to accept anything less than proven.
The uncomfortable question this answers
People ask me whether they can trust AI-generated Apex in a real org. I think that’s the wrong question. I don’t fully trust my own Apex until the tests pass — that’s why we write tests.
The right question is: what verified it? Code that came out of a loop with an objective verifier and a hard stop rule arrives with evidence — green tests, coverage numbers, a live trigger flipping a room to unavailable. Code that came out of a model with no verifier arrives with vibes.
Next week I’ll close this series with the question I get most often after the demo: MCP tools versus Agentforce actions — when the AI reaches into Salesforce, and when it lives inside it.