Hospital Org — a Salesforce org built by an AI agent loop I designed
A complete hospital-management Salesforce org — 7 custom objects, a trigger-handler architecture and 90–100 % test coverage — built not by hand-writing each class, but by designing a single agentic loop where Claude deploys, tests, reads failures, fixes and repeats until green, through six custom MCP deployment tools with ApexTestRunner as the verifier.
- Year
- 2026
- Role
- Salesforce Developer — Agentic Delivery
- Tech stack
- Model Context Protocol (Salesforce-hosted)Loop engineeringClaude (agentic driver)ApexTrigger-handler frameworkMetadata APITooling API7 custom objects90–100 % test coverageLightning App
Highlights
- A whole org, built by a loop, not by hand: 7 custom objects (Department, Patient, Doctor, Room, Appointment, Prescription, Admission) deployed in strict dependency order, plus 3 trigger-handler classes, their 3 triggers, and 3 test classes — all delivered through one agentic loop I designed
- Six custom MCP tools as the agent's hands — MetadataObjectDeployer, ApexClassDeployer, ApexTriggerDeployer, ApexTestRunner, RecordCreator, AppBuilder — each a Salesforce-hosted MCP tool the agent calls
- The verifier is ApexTestRunner, not the model: the loop's stop condition is objective — all 3 test classes pass at ≥90 % coverage. The agent doesn't grade itself 'done'; the test runner does
- Real loop discipline: deploy metadata → deploy Apex → run tests → read the actual failures → fix → repeat. When a deploy threw an opaque script-exception, the loop diagnosed root causes (object already exists? integration-user permissions? in-flight deploy?) instead of blindly retrying
- Dependency-aware execution: parentless objects (Department, Patient) deployed first and in parallel; children (Doctor, Room → Appointment → Prescription, Admission) followed, reusing returned record Ids for seed data
- 90–100 % test coverage across the deployed Apex — real coverage the runner executed, not numbers asserted by hand
- Honest framing: the org, the objects, the trigger-handler architecture, the test classes and the coverage are real and were produced by the loop. What's on show is the loop design and the verification discipline — not a claim that AI replaces engineering judgment. The judgment is in the loop.
Feature walkthrough
The loop meets its verifier — and doesn't grade itself
The moment that proves the design: ApexTestRunner reports PrescriptionTriggerHandler at 88 % — under the 90 % target. The loop doesn't declare success; it reads which lines are uncovered (the two addError guard branches), decides to add a null-appointment test, and keeps going. Above it, the runner had rejected a malformed request — the loop diagnosed the single-class-per-call constraint instead of blindly retrying.
Build complete — the loop's own delivery report
The closing message of the run: 7 objects created in dependency order, 3 trigger handlers on the Kevin O'Hara framework (double-booking blocked, prescriptions only on completed appointments, room availability synced), coverage at 92 / 100 / 90 %, and 19 seeded records — with the live triggers confirmed end-to-end: the Admitted admission actually flipped room ICU-01 to unavailable.
Independent proof in the org — 9/9 green, 93 % overall
Verified inside Salesforce, not just in the chat: the Developer Console run shows every test passing and 93 % overall coverage. Look at the coverage panel — the six MCP deployment tools themselves (ApexClassDeployer 97 %, ApexTestRunner 94 %, RecordCreator 97 %…) are real Apex classes in the org, and they're under test too.
The app the loop shipped, in use
The Hospital Management Lightning app with all seven object tabs, opened on a real seeded Appointment: patient Grace Adeyemi, Dr. Amara Okafor, a cardiac follow-up marked Completed. The record name is the raw ID — the loop built this, no human polished it afterwards.
The data model, as deployed
Schema Builder on the finished org: Department → Doctor, Appointment → Patient / Doctor, Prescription → Appointment, Admission → Patient / Room. Exactly the dependency chain the loop had to respect during deployment — parents first, children after, returned record Ids reused for the seed data.
The problem
By mid-2026 the conversation in AI had shifted from prompt engineering to loop engineering: the bottleneck is no longer a model's ability to write an Apex class — it's designing a reliable, verifiable loop that lets an agent do multi-step work without a human typing each step. AI agents can generate code. The hard part is doing it on a platform like Salesforce — governor limits, metadata dependencies, deployment order — with a verification mechanism strong enough to trust the result. A loop without a real verifier is just an expensive way to generate plausible-looking code.
The approach
I treated org-building as a loop, not a checklist. I defined the goal (all objects deployed in dependency order, all Apex deployed, all tests green at ≥90 % coverage), gave the agent a fixed toolset — the six MCP deployment tools — and let Claude run the cycle: deploy → test → read failures → fix → repeat. The verifier is ApexTestRunner: an objective, external check, so the model cannot declare success on its own judgment. I built in real loop discipline — a clear definition of 'done', hard stop conditions, and genuine adaptation: when the metadata deployer threw a generic script-exception on the minimal call, the loop stopped and diagnosed root causes (duplicate object, integration-user permissions, an in-flight deploy) rather than hammering the same failing call. The whole thing runs over Salesforce Hosted MCP, so the org's own security context is enforced throughout.
The outcome
A complete, tested hospital-management org produced through an agentic loop I designed once — the clearest proof in my portfolio of the 2026 shift from prompting a model to engineering the loop that runs it. It is the delivery-side counterpart to my MCP walkthrough: there, Claude uses my org; here, Claude builds one. The same pattern — goal, toolset, verifier, stop rules — is exactly what a Forward Deployed Engineer applies when standing up or extending a customer org with agentic tooling.