What this does
Three services, one org. ProductZoningService answers GET /ProductZoning/{productCode} with the permissible fly zone for the country named in the CountryCode header. AssetService exposes POST /lost — a kill switch that retires a lost drone and files a claim when comprehensive coverage is active. CredentialVerificationService confirms a pilot's certification status over SOAP.
Before touching anything, the Assemble agent read the org: instance assemble60-dev-ed.develop.my.salesforce.com on API v67.0 (Summer '26), then full describes of Product_Geo_Mapping__mdt, Asset, Insurance__c, Claim__c, and Contact_Certification__c. Fly-zone rules, device serials, coverage, and pilot credentials were already modeled.
That inspection settled the plan: no schema changes, just services over data that already exists. The whole change is six ApexClass records, three services and three test classes, each reversible with a single recorded DELETE.
How it works
Salesforce
TATooling API
ARApex REST
- 01Read the brief. The business requirement names the three services, their endpoints, and the acceptance checks that will judge the final org state.
- 02Inspect the org. Describe calls against the newest API version map what already exists. No code is written until the data model is understood.
- 03Stage and approve. All six classes are compiled, validated, and staged as one reversible unit. The staged change is approved before deployment.
- 04Deploy via Tooling API. Six
POST /tooling/sobjects/ApexClasscalls, each answered201 Created, each with a recorded revert path. - 05Test until passing. The first suite run fails on a real org rule; the Assemble agent rebuilds the fixture and re-runs to a full pass above 85% coverage.
- 06Verify. The acceptance checks inspect the org itself. Three checks, three passes.
Same shape a senior Salesforce engineer would use: read the org before writing code, stage one reviewable change, let the failing test explain the org's rules, and don't call it shipped until every acceptance check passes.
Outcomes you can verify
The results aren't self-reported. The acceptance checks inspect the org itself. All three pass by reading the deployed classes and the records they touch. Claims alone don't count; org state does.
The endpoints answer for themselves: GET /services/apexrest/ProductZoning/GC1020 with CountryCode: US returns "Recommended", and POST /lost with an unknown serial returns "No device found." Every persistent change sits in the ledger with a revert path — six creates, six recorded deletes, nothing else touched. The full run: 30 steps, 0.95M input / 27K output tokens.