Case study · AI & automation · 2026
Five manual services, one agentic pipeline, a human at every gate.
An internal request-to-delivery platform for a 2,000-Realtor brokerage group with 50+ offices. Built first for internal operations, now being turned into a productised service the offices consume.
The problem
Agents in the brokerage could request five things from the in-house web team: a new website, a tier upgrade, an edit to an existing site, a domain connection, and a branding change. Each request type was handled by hand across a form tool, a CRM, a project board and email. Every type had its own undocumented path, and each path depended on one person remembering the next step.
Discovery
I started with the operators, not the tools. I mapped all five request paths end to end, from form submission to the delivery email. The observation that shaped everything: all five shared one intake and one close, and differed only in a two-or-three-step middle. That single finding collapsed five separate builds into one shared pipeline plus five small branches.
Most automation waste comes from automating the org chart instead of the process.
The agents
The pipeline runs as staged agents, each one reading and writing the CRM, the board and the Postgres source-of-truth database rather than just passing a payload along.
- Routing gateway. Classifies each submission, deduplicates it against existing cards, and resolves it to the right service branch.
- Eligibility agent. Checks the agent's entitlement against the database before any work starts. Service-agnostic, so new branches inherit it for free.
- Builder agent. Provisions and configures the site, applies the tier, swaps the logo, or connects the domain, depending on the branch.
- Delivery agent. Composes and sends the delivery email, tracks the click, and keys everything off the board card rather than the request type.
Oversight, as a feature
Nothing consequential fires unattended. Delivery is held behind an all-subtask completion gate. Specialist approval sits on the board before anything reaches an agent. A 48-hour escalation chases stalled work instead of letting it die quietly. The AI prepares, a human releases.
The wider stack touches escrow, lending and transaction platforms carrying account and identity data, so environment separation, least-privilege access and audit logging were build requirements from day one, not afterthoughts.
Reliability
Agentic systems rarely fail loudly. They fail by returning something plausible. Three failures I caught against verbatim production payloads before release:
- An indexing race that returned empty results with a clean HTTP 200, which would have defaulted every new build to the wrong template.
- Truncated identifiers that broke exact-match routing on 24 fields.
- Unmapped fields swept into a review bucket, so a new form option flows through untouched instead of crashing the run.
Supportability
Every workflow is documented in-canvas with annotated sticky notes per branch and per non-obvious node, plus runbooks and a status dictionary, so the platform is supportable by the team rather than dependent on me. The architecture is moving toward a code-defined orchestration engine for high-volume and sensitive flows.
What I would tell another builder
Map before you build. Put the gate where the consequence is. Test against real payloads, not fixtures you wrote yourself. And document in the canvas, because the next person to open it will not read your wiki.