Studio 3Sixty5

Context: the only problem that matters

Ask an agent or a broker what keeps them up at night and the answer is never marketing, or compliance, or software. It’s finding the next client. An agent’s business is a pipeline of strangers who have to become appointments, then proposals, then signed listings, and nothing in a typical agent’s toolkit gives them reliable control over any step of that. I know this from the inside — I’m a California DRE-licensed agent — and every conversation with agents and brokerages before building anything came back to it.

Everything else agents complain about is a symptom of how expensive and leaky that path is:

• Leads leak before they’re contacted. Inbound calls and portal leads arrive while the agent is in a showing, a car, or an inspection. Response time is the strongest predictor of conversion, and a solo agent can’t control it. A lead called back six hours later is usually someone else’s client. Most agents don’t have a lead-volume problem; they have a lead-leak problem.
• Winning the listing happens in a living room, with a pitch nobody tools. The seller interviews three agents. The one who shows up with the sharpest pricing position, a credible marketing plan and a picture of what their house will look like on the market wins. Most agents assemble that pitch by hand, late the night before.
• Delivering the listing is a vendor relay. Photographer, stager, videographer, copywriter, social freelancer — each a day of waiting and an invoice. The seller was promised speed in the pitch and gets Thursday.
• Compliance is a silent tax on every word. Fair Housing language, MLS rules and brokerage brand policy apply to every description and caption. One wrong phrase is a complaint or an escalation. Nobody has a checker.
• The tools attack the symptoms. The 2023–24 wave of AI products shipped a staging app, a copy generator, a video tool and an AI receptionist — each a separate subscription, none connected to the pipeline that actually produces a client.

For brokers the same problem is multiplied: recruiting and retaining agents depends on the brokerage helping them find business, and inconsistent marketing and compliance exposure across fifty agents is theirs to carry.

This study covers the shipped product. The platform strategy underneath it, a spatial data layer built to serve real estate first and other verticals later, is written up separately: Spatial data layer →

Insight

The product thesis follows from taking the root problem seriously:

1. Response time is the lead-generation feature. A voice agent that answers in two rings, qualifies on the call and books the appointment converts leads the agent already paid for. That is a larger lever than buying more leads, and it is the first thing the product does.
2. The proposal is the conversion step. The listing pitch is where the client is won or lost, and it’s the one step no software addressed. Generating it from the app — comps, pricing position, marketing plan, and a staged photo or video preview of the seller’s own home — turns the fulfilment engine into a sales weapon before the listing is signed.
3. The listing is the next lead. A well-marketed listing is the best seller-lead magnet in a neighbourhood. Delivering the marketing fast and well doesn’t just satisfy this client; it feeds the Client Engine with the next one. The two engines form a loop, not a sequence.
4. Compliance is a feature, not a constraint. Agents pay copywriters for knowing what you can’t say. Guardrails inside the generation path — not a post-hoc checker — are what make output publishable without review, and what brokerages buy.

Mini PRD

Strategy & bets

The product is organised as two engines around the lead-to-client path, and the roadmap is sequenced so the first funds the second.

• Client Engine — find and win the client. Lead capture, the voice AI agent, the custom CRM and the listing proposal. This is why an agent buys. It’s gated on funnel metrics: contact rate, appointments set, listings signed.
• Listing Engine — deliver the listing, generate the next lead. Staging, video, compliant copy, social, deal sourcing. This is what the proposal promised; it’s gated on fulfilment metrics: time to kit, publish-without-edit, listings per agent.

What I chose not to build: transaction management, a consumer search front end, and a “chat with your listing” interface. Each was requested; none moved a funnel metric.

Segmentation follows the two buyers. Agents buy on speed and price per listing; brokerages buy on consistency and compliance, and want white-label (a Vendasta-style integration is on the roadmap for exactly that reason). Pricing is per-seat with usage tiers rather than per-listing, because per-listing pricing taxes the behaviour we want more of.

Engine 1 — Client Engine

The Client Engine’s job is to turn a stranger into a signed listing without the agent having to be available. Four components, one record.

Lead capture. Inbound calls and web/portal inquiries land on the voice agent; outbound campaigns are initiated from the CRM and run on the same agent within TCPA consent rules.

Voice AI agent. Built on Bland as a library of pathways — each a conversation graph for one job, with a named state transition on every edge and a CRM write at every transition. Eight pathways run in production across three families: inbound (answering and routing calls, qualifying callers), outbound (targeted follow-up on specific lead types), and nurture (re-engaging leads that have gone quiet). The pathway framework has since been reused outside real estate, which is a useful signal that the design pattern, not the domain, is the asset.

Custom CRM. One contact record, one property record, one decision queue. The voice agent writes into it; the agent works from it. It is deliberately not a general CRM: every object exists to move a lead one step toward a signed listing.

Listing proposal. When a seller lead reaches “appointment set,” the app assembles the pitch: comparable sales, a pricing position, the marketing plan the Listing Engine will execute, and a staged photo or short video preview of the seller’s own property. The agent walks into the living room with it. This is the step that turns the Listing Engine into a sales tool before any listing is signed.

Anatomy of a pathway

The specific graphs are proprietary; the shape they share isn’t. Every pathway is built from the same seven node types in roughly the same order.

Pathway design principles

• One fact per node. Each node has a single job — a name, an address, a slot. Multi-question nodes fail more and are harder to repair mid-call.
• Every edge is a CRM write. The named transition (name acquired, slot selected, email logged) is the state the CRM records. A dropped call still leaves a partially-complete lead the agent can finish.
• Representation before scheduling. Whether the caller is already working with a brokerage decides commission and compliance; the pathway asks before it invests in booking.
• Answer from the record, not the model. Property Q&A reads from the listing record. If the listing isn’t found, the call routes out — a confident wrong answer about a property is the worst outcome a voice agent can produce.
• Exceptions leave early. Unknown listings and office inquiries exit to a handoff on the second node, not after five minutes of failed qualification.
• Confirmation reads back every variable. The final node repeats the address, time and contact detail that were captured, so errors surface on the call rather than at the door.
• One pathway per job. Eight small graphs beat one large one: each can be tested, versioned and tuned on its own completion rate.

Engine 2 — Listing Engine

The Listing Engine delivers what the proposal promised: a signed listing goes to market in under 15 minutes with staged photos, a narrated video tour, compliant MLS copy and a social kit — and the output is good enough that the listing itself becomes the next seller lead. The multi-agent pipeline below is the product; the engineering notes further down cover how the hardest part of it, the video, was built.

System design

Multi-model routing. No single model is best at photo cleanup, staging, cinematic motion, narration and MLS copy, and the best one at each is rarely the cheapest. The orchestrator routes each step to a model chosen on a cost/quality/latency budget per job, with cheaper fallbacks when the primary is slow or over budget. This is a product decision as much as an engineering one: the gross margin on a listing kit is the routing table.

Error scope. A 25-photo video job fails differently from a single-photo staging job. The pipeline distinguishes item-scoped failures (one photo can’t be processed — skip it, keep the job) from job-scoped ones (the template can’t be assembled — abort and retry). Parallel render paths settle independently so a single bad frame never takes down the tour.

Deterministic motion. The media engine moved from fully generative video toward a template architecture — predefined edits in the style of CapCut and Premiere templates, with the AI filling photo slots, transitions and narration. Target: at least 95 % of delivered motion deterministic. Quality went up, render cost went down, and brand consistency became a configuration rather than a prayer.

Engineering notes: building the media engine

This section is for technical readers. It covers the hardest problem in the product — constructing a video walkthrough from still photos — and the workflow engineering around it. Skip it if you’re here for the product story.

The problem

Input: 20–30 unordered still photos of a property, uploaded from a phone. Output: a 60–90 second narrated walkthrough that an agent will put their brand on, delivered in minutes, at a cost per tour that works inside a per-seat subscription. The photos have no camera path, no room labels, inconsistent exposure, and sometimes the wrong aspect ratio. The video has to look intentional.

Two walkthrough grammars, two construction strategies

The first thing building this taught me is that “real-estate video” is two different products with different rules, and a pipeline that treats them as one fails at both.

So the media engine is two template families sharing one pipeline, not one video style with a knob. Each family has its own deterministic template set (timing, transitions, motion vocabulary, text placement), and the AI fills slots inside the template. The ≥95 % deterministic-motion target came out of this: once motion vocabulary is a template property, the generated part is small, bounded, and reviewable.

The construction pipeline

1. Preprocess. Every photo goes through cleanup before anything generative touches it: exposure and tone normalisation, crop to the template’s aspect, removal of obvious artefacts. This step is cheap and deterministic and it removed a whole class of downstream failures — motion models behave far better on clean, consistently-framed input.
2. Classify and plan — one call. A single multimodal call takes the full photo set and returns room labels, a quality score per photo, and a shot list for the selected template family: which photos, in what order, with which motion from the template’s vocabulary. Doing this in one call rather than per-photo was the biggest single reduction in turns (and cost) in the pipeline.
3. Motion generation — fan out. Each shot becomes an independent image-to-video job. They run in parallel and settle independently.
4. Narration. Generated from the shot list and the property record so it describes what’s on screen, run through the same Fair Housing / MLS guardrails as listing copy, then TTS — in parallel with motion generation, not after it.
5. Assemble and render. Deterministic: the template dictates timing, cuts, transitions, text and music; the generated clips drop into slots. QA checks duration, missing slots and clip integrity before delivery.

Workflow engineering

The construction problem is a domain problem. Making it reliable at a cost that works is a systems problem, and most of the engineering time went here.

Error scope: item vs. job. The error catalog carries an explicit scope. An item-scoped failure (one shot’s motion generation timed out or came back malformed) is handled inside that shot: retry, then fall back to a cheaper motion model, then fall back to a deterministic Ken Burns move on the still. The tour still ships. A job-scoped failure (plan call failed, template can’t be satisfied, storage unavailable) aborts the job and schedules a retry. Before this distinction existed, one bad frame out of twenty-five failed the whole tour and re-ran everything — the single largest source of wasted compute and user-visible latency.

Parallelism with Promise.allSettled. The per-shot fan-out settles with allSettled, not all, so one rejection doesn’t cancel the siblings. The assembler receives a list of fulfilled and rejected shots and decides per template whether it has enough to proceed (the traditional template needs its room order intact; the creative template can drop a shot and re-pace). That decision is a template property, not a pipeline constant.

Minimising turns. Each model round-trip costs latency, money and a failure opportunity. The design rule was: one planning call, N independent generation calls, zero mid-pipeline “ask the model what to do next.” Anything that would have been an agent loop was replaced by a deterministic rule in the template or a field in the plan output. The pipeline is agentic at the planning step and a DAG everywhere else.

Fallback and retry policy. Retries are bounded and typed: transient (rate limit, timeout) retries with backoff on the same model; content failures (malformed output, failed QA) fall through to the next model in the routing table; structural failures escalate to job scope. Every fallback is logged with the reason so the routing table can be tuned on data rather than anecdote.

Model selection as a routing table. No step is hard-wired to a model. Cleanup, staging, motion, narration and copy each have a primary and at least one fallback, chosen on a cost/quality/latency budget per template family — the creative template can afford a more expensive motion model for three hero shots; the traditional template needs a cheaper, steadier one for twelve. Models have been swapped at several steps as the market moved; the pipeline didn’t change.

Idempotency and resumability. Every shot’s output is keyed by content hash and template, so a retried job re-uses completed shots instead of regenerating them. A job interrupted at assembly resumes at assembly.

What this cost and bought

• Fully generative tours (the first version) were unpredictable, slow and expensive, and agents didn’t trust them with their brand. The template architecture fixed all three at once.
• The item/job error scope and allSettled fan-out cut wasted renders dramatically and turned “the video failed” into “one shot used a fallback” — invisible to the agent.
• Collapsing planning into one call removed most of the pipeline’s turns and made cost per tour predictable enough to price.
• The two-family template design is what lets the same pipeline produce an MLS-ready walkthrough and a social reel from one upload — which is the product promise.

What I’d build differently

• Start with two template families. I built one style, discovered it was two products, and retrofitted. The grammar split should have been the first design decision.
• Make error scope a first-class type from day one. It was added after the pain, and everything downstream got simpler once it existed.
• Instrument fallback rates per model before tuning anything. The routing table got good only once it was tuned on logged fallback reasons rather than on how the output looked in demos.

Metrics & experimentation

• Activation is defined as the first complete listing kit generated, measured within seven days of sign-up. Everything in onboarding is tuned to that event — a trial that ends with a staged photo but no kit is a failed activation.
• Retention is tracked as listings per active agent per month, segmented agent vs. brokerage-seat. Brokerage seats are stickier but lower-usage per seat; agents churn faster but use more — which is why both segments exist.
• Output quality is instrumented as the share of generated copy published without edit. That number is the leading indicator for whether the compliance guardrails are earning their keep.
• Cost per kit is tracked per model-routing configuration so a cheaper route that degrades the publish-without-edit rate shows up as a net loss, not a saving.

Outcomes

• Full photo-to-market pipeline live, with sub-10-minute turnaround on the listing engine.
• Fair Housing and MLS guardrails embedded in generation — a responsible-AI control that de-risks agent-facing output in a regulated market and is a selling point to brokerages.
• Voice agent shipped for inbound and outbound calls: lead intake, qualification, follow-up, scheduling.
• Platform extended into buyer-side deal sourcing: an agentic STR/MTR screener that ingests listings, rental comps, occupancy and local regulation to score acquisition targets on projected yield.
• Social-media automation running on GitHub Actions with a 30-theme content library and full auto-approval — the “amplify” layer at near-zero marginal cost.
• Legal foundation (ToS, privacy notice, data-provider, TCPA and CCPA review) completed ahead of brokerage sales — compliance as a go-to-market asset.

Next: a lead-to-live redesign that reorganises the app around one property record, one decision queue and one command surface; brokerage white-label; and evaluating where photogrammetry fits in the media engine.

Retro — what I’d do differently

• Start with the template architecture for video. I spent several months on fully generative tours before accepting that agents wanted predictable, branded motion. The deterministic-template decision should have been the day-one architecture.
• Instrument publish-without-edit earlier. It turned out to be the best single quality metric and I added it late.
• Pick the brokerage channel sooner. Direct-to-agent is a good wedge but a hard business; brokerages are a slower sale with a far better retention profile. I’d have built the white-label path in parallel from the start.