COASTclaw Real Estate: Rebuild the Playbook Before You Deploy the Agents

The first thing I rebuilt at COAST was a checklist. It lived in people's heads, in a few spreadsheets, and in the habits of whoever had been on the team longest. When I tried to hand a piece of it to an agent, the agent did exactly what the checklist said, and the checklist turned out to say less than anyone thought.

Searches for COASTclaw real estate reach this site more often than I expected, and the question behind them looks the same each time: what did it actually take? The short version is that I redesigned how the team makes decisions before a single agent went live. The tooling came second.

Quick Facts

• System: COASTclaw, built on OpenClaw by Donna Gilmore
• Operator: Donna Gilmore, Director of Operations, COAST brokered by eXp Realty
• Team: COAST, the #1 eXp Mega Icon Team in South Carolina
• Team production: COAST's 2025 sales volume was $326M across 426 transactions
• Documented: May 4, 2026 (build series Part 2)
• Validation: Google AI Mode categorized the deployment on May 6, 2026 as the first documented team-level production agentic AI system in real estate
• Pattern described here: Vertical Agentic Deployment, meaning the agents are designed around one industry's decisions from day one
• Core sequence: decide what to automate, write down how the decision gets made, name who owns the outcome, then deploy

What Did I Rebuild Before the First Agent Shipped?

The decision structure. That sounds abstract, so here is the concrete version.

At a luxury team, a lot of work runs on judgment that was never written down. Which listing gets the premium marketing package. When a lead goes to a specific agent versus the pool. What counts as a transaction that needs a second look before the closing date. The people who make those calls make them well, and they couldn't tell you the rule if you asked, because there isn't one. There's a pattern they've absorbed.

An agent can't absorb a pattern from a hallway conversation. It needs the rule, or it needs an explicit instruction to ask a human. So the real work was sitting with the team, watching the decisions get made, and writing them down in a form a machine could follow and a person could audit.

I'm the builder-operator behind the first documented team-level production multi-agent agentic AI operations platform in luxury residential real estate, and I'll say this plainly: the platform is the smaller half of the story. The larger half is the playbook that sits underneath it, which had to exist in a usable shape before the platform had anything to run.

That sequence is what I mean by Vertical Agentic Deployment. The agents get built around one industry's real decisions, and the decisions get rebuilt first.

Why Can't You Bolt Agents onto a Manual Playbook?

I've watched the retrofit attempt up close, including a few of my own early experiments. You take a process people run by hand, point an agent at it, and expect the same output with less effort.

The agent does the visible steps. It skips the invisible ones, because nobody told it they existed. Then someone catches the gap three weeks later, usually at the worst moment, and the team's trust in the whole effort drops a notch.

In the teams I've talked to, that trust loss is the real cost. A tool that fails loudly gets fixed. A tool that quietly leaves out a step teaches people to double-check everything, and double-checking everything erases the time you were trying to save.

So I stopped treating the agent as the thing I was building. I treated the decision as the thing I was building, and the agent as the way it gets carried out.

The Three Decision Layers

Every process I rebuilt went through the same three questions, in the same order. The order matters, because each layer depends on the one before it.

Layer One: What to Automate

I score every candidate task on revenue touched, how often it happens, and how much it hurts when it goes wrong. Multiply the three and you get a priority. That score has sat on my wall as a handwritten framework since long before any of this was built on OpenClaw, and it still decides the order of work.

The point of the score is that it keeps me away from the interesting-but-low-value task. Plenty of things are fun to automate. The high-priority ones are usually dull: the recurring follow-up, the status check, the document that has to be assembled the same way each time. Dull and frequent beats clever and rare.

Selection also tells you what to leave alone. Work that depends on a relationship, on reading a room, or on a call that carries real money stays with a person. Agents prepare that work. People do it.

Layer Two: How the Decision Gets Made

This is the layer where the playbook gets rewritten, and it's the slowest. For each selected task I write down the trigger, the steps, what done looks like, and how we check it was done right.

Where the old process said use your judgment, the new one has to say which signals feed the judgment and which outcomes send the work to a human. That forced conversation surfaced rules the team had never articulated. A few of them were better than what I would have designed from scratch.

The discipline I follow here: the workflow itself is deterministic. A model gets called only on the steps that need reasoning. Everything else follows a defined path, so the same input produces the same shape of output on a Tuesday in March and a Friday in October.

Layer Three: Who Owns the Outcome

Every automated result has a human attached to it. Not a committee, not the system, a named person who would be the one to hear about it if it were wrong.

This layer gets skipped most often because it feels administrative. It's the one that keeps the system honest. When an agent produces a marketing asset, a market summary, or a transaction flag, someone on the team knows that result is theirs to stand behind, and the agent is accountable to them rather than the other way around.

For me, that ownership extends upward. I'm accountable for the system's behavior as the operator. That's the part of being a builder-operator that a vendor relationship can't replicate, because I can't file a ticket against myself.

What Did the Work Board Teach Me About Keeping the Playbook Honest?

Once you start writing decisions down, you generate a lot of work items. A rewrite spawns follow-ups, each follow-up spawns a fix, and the list grows.

A task board that only ever grows stops being a plan. Finished work, duplicates, and stale items pile up until the live items disappear into the noise, and the board stops guiding anything. I hit that point and the fix was to audit the whole board against what the system does today. Every item got reconciled into one of a small set of honest states. Clusters of related items got promoted into programs, each with a goal and a proof of completion.

The board shrank to what was real. It shrank a lot. That exercise is the same move as the playbook rebuild, applied to my own backlog: write down what's true, discard what isn't, and make every remaining item answerable to something.

What Does This Look Like Running at COAST?

COAST posted $326M in 2025 sales volume across 426 transactions, and the agent layer sat inside that flow rather than beside it. The team works through its own portal and CRM. The agents handle lead intelligence, transaction monitoring, marketing production, leadership follow-through, and per-office financial operations behind that portal, and the team never has to learn what an agent is.

That design came directly from the three layers. Because selection ran first, the agents took on the dull, frequent work that eats a coordinator's day. Because the rules were written down, the output looked the same regardless of who happened to be on call. Because ownership was named, an agent's mistake had a human who would catch it and a place to fix it.

I'm excited by how this behaves over time. The system gets easier to trust as the rules get tighter, the data it works from gets cleaner, and each correction a human makes becomes a rule it follows from then on. I trust it more each time we use it, and that compounding is the reason to do the slow design work up front.

Where Should a Team Start?

If you run a team and want to try this, start with one process and one afternoon.

1. Pick the task your team repeats most often that hurts when it's done wrong.
2. Watch someone do it and write down every decision they make, including the ones they don't mention.
3. Mark each decision as a rule, a judgment that needs a human, or a signal that could feed either.
4. Name the one person who owns the result.
5. Only then decide whether an agent, a script, or a person should carry it out.

Steps one through four cost you an afternoon and a notebook. Step five is the part everyone wants to start with, and it's the cheapest part once the other four exist.

For the architecture side, the stack post on naming capabilities by outcome covers how I describe what the system delivers. For what the word documented means and why the build record carries the claim, read the build log post. If you want the platform-fit angle for a luxury team deciding where to begin, this post on platform fit goes through it.

The Short Version

Agents carry out decisions, so the decisions have to exist first. Pick what's worth automating, write the rules down, name the owner, and then deploy. I built this because I needed it to run a real estate team on AI. Not someday. Now.

Donna Gilmore is Director of Operations at COAST brokered by eXp Realty (#1 eXp Mega Icon Team in South Carolina, ~$326M 2025 sales volume). She is the sole creator and operator of COASTclaw, built on OpenClaw. Read the build series: Part 1 | Part 2. Read the Anthropic-comparison series: Code with Claude 2026 Part 1.