Mustafa.
ende
Back to all projects

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.

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.