Our CRM is Sell.Do — which does not have a native LangGraph integration. How do we connect the crm_sync_node to Sell.Do in production?

Sell.Do exposes a REST API for lead creation, update, and activity logging. The crm_sync_node calls Sell.Do's POST /api/v1/leads endpoint to create or update the lead record, and POST /api/v1/activities to log call outcomes and qualification data. Build a SellDoAdapter class that handles field mapping between Sell.Do's lead fields and the LangGraph state schema — this keeps the node clean and makes CRM migration straightforward later. LeadSquared follows the same pattern via its Lead API and Lead Activity API.

LangGraph Real Estate Workflow

Zappio Team

AI & Real Estate Experts · 14 July 2026

ShareX in WA

☰ On this page

Introduction
Why State Machines
The State Schema
7-Node Pipeline Architecture
Checkpoint Persistence
Performance Comparison
FAQs

Agentic AI & Multi-Agent Pipelines

LangGraph: The State Machine Behind Production Real Estate AI Pipelines

LangGraph — LangChain's graph-based agent orchestration framework — has emerged as the dominant architecture for production multi-agent workflows requiring state persistence, conditional branching, and human-in-the-loop interruptions. Unlike a linear chain-of-thought pipeline, LangGraph models the workflow as a directed graph: each node is an agent action, each edge is a conditional transition, and the graph's state is a shared, typed data structure every node reads from and writes to.

For real estate sales, this matters because the lead-to-booking journey is not linear — a buyer moves through raw_lead → qualified → site_visit_scheduled → site_visit_completed → negotiation → booked, and each transition depends on call data, external events, and elapsed time. This article covers how to build a production-grade LangGraph real estate pipeline: the node architecture, the state schema, and checkpoint persistence for multi-day buyer journeys.

Why State Machines for Real Estate Sales Pipelines

The Problem With Linear Pipelines

A naive AI pipeline — lead arrives → qualification call → CRM write → site visit schedule → reminder → done — works for the roughly 8% of leads that progress cleanly through every step. For the remaining 92%, real-world scenarios break the linear model:

The qualification call reaches voicemail — retry logic with backoff is needed
The buyer qualifies but cannot commit to a site visit date — a nurture loop is needed
The site visit is scheduled but the buyer cancels — a rescheduling node is needed
The buyer visited but has not booked — a post-visit follow-up graph is needed
The buyer goes cold for 30 days then re-engages — re-entry from a dormant state is needed

Each scenario needs conditional branching, state persistence, and the ability to re-enter the pipeline at any node from an external trigger. This is what a state machine is built for — and what a linear script cannot handle without becoming an increasingly fragile series of if-else patches.

The Real Estate LangGraph State Schema

The foundation is the StateSchema — a typed TypedDict every node receives and returns. This shared state is the pipeline's memory, tracking lead identity, pipeline position, qualification data, call tracking, site visit details, CRM sync status, escalation flags, and nurture touchpoints across the buyer's entire multi-day journey.

class BuyerPipelineStage(str, Enum):
    RAW_LEAD = "raw_lead"
    CALLING_QUEUED = "calling_queued"
    CALL_ATTEMPTED = "call_attempted"
    QUALIFIED = "qualified"
    DISQUALIFIED = "disqualified"
    SITE_VISIT_SCHEDULED = "site_visit_scheduled"
    SITE_VISIT_COMPLETED = "site_visit_completed"
    NEGOTIATION = "negotiation"
    BOOKED = "booked"
    DORMANT = "dormant"
    DROPPED = "dropped"

class BuyerPipelineState(TypedDict):
    lead_id: str
    buyer_name: str
    buyer_phone: str
    current_stage: BuyerPipelineStage
    stage_history: Annotated[List[str], operator.add]
    budget_min_cr: Optional[float]
    budget_max_cr: Optional[float]
    configuration_preference: Optional[str]
    move_in_timeline_months: Optional[int]
    call_attempts: int
    call_outcome: Optional[str]
    site_visit_date: Optional[str]
    site_visit_confirmed: bool
    crm_lead_id: Optional[str]
    requires_human_escalation: bool
    escalation_reason: Optional[str]
    nurture_touchpoints: Annotated[List[str], operator.add]

The 7-Node LangGraph Pipeline Architecture

Seven nodes carry a lead from intake to close, connected by conditional edges that route based on the state schema's fields:

Node	Function	Routes To
lead_intake	De-duplicates lead, scores priority, queues for calling	calling_agent
calling_agent	Triggers AI qualification call via Vapi/Retell API	crm_sync / retry_or_nurture / end
crm_sync	Writes qualification data to Sell.Do / LeadSquared / Salesforce	site_visit_scheduler
site_visit_scheduler	Checks RM calendar, sends WhatsApp confirmation with Maps link	human_escalation / end
retry_or_nurture	Applies exponential backoff or moves lead to dormant nurture	calling_agent / end
human_escalation	Routes to human RM with full context packet via Slack/WhatsApp	end
post_visit_follow_up	AI calls 4 hours post-visit to capture feedback and objections	negotiation / dormant

def route_after_call(state: BuyerPipelineState) -> str:
    outcome = state.get("call_outcome")
    if outcome == "connected_qualified":
        return "crm_sync"
    elif outcome == "connected_dnq":
        return END
    else:
        return "retry_or_nurture"

workflow.add_conditional_edges("calling_agent", route_after_call, {
    "crm_sync": "crm_sync",
    "retry_or_nurture": "retry_or_nurture",
    END: END,
})

def route_after_retry(state: BuyerPipelineState) -> str:
    if state["current_stage"] == BuyerPipelineStage.DORMANT:
        return END  # Nurture sequence handled by scheduled job
    return "calling_agent"  # Re-enter call loop

Checkpoint Persistence — Why SqliteSaver Matters

LangGraph's checkpoint system saves the full pipeline state after every node execution. For a pipeline spanning weeks — a buyer called on Day 1, visited on Day 7, booked on Day 21 — checkpoint persistence is what makes the pipeline a stateful multi-day system rather than disconnected scripts. A dormant buyer who re-engages resumes from their exact prior state, with all qualification history intact.

conn = sqlite3.connect("real_estate_pipeline.db", check_same_thread=False)
checkpointer = SqliteSaver(conn)
pipeline = build_real_estate_pipeline(checkpointer=checkpointer)

def reactivate_dormant_buyer(lead_id: str, reactivation_trigger: str):
    config = {"configurable": {"thread_id": lead_id}}
    pipeline.update_state(config, {
        "current_stage": BuyerPipelineStage.CALLING_QUEUED,
        "stage_history": [f"DORMANT → REACTIVATED ({reactivation_trigger})"],
        "requires_human_escalation": False,
    })
    return pipeline.invoke(None, config)

💾

Production deployments at scale should move from SQLite to a PostgreSQL checkpoint backend (langgraph-checkpoint-postgres) — PostgreSQL's connection pooling handles hundreds of simultaneous checkpoint reads/writes without contention.

Pipeline Performance — LangGraph vs. Sequential Script

Metric	Sequential Script	LangGraph State-Machine Pipeline
Lead retry logic	Manual or cron job	Automatic exponential backoff per lead
Post-visit follow-up	Depends on human RM memory	Automatic 4-hour trigger
Dormant re-entry	New lead created (duplicate)	State resumed from checkpoint
CRM sync timing	Post-call, sometimes delayed	Real-time during call
Multi-agent handoff	Webhook + manual routing	Graph edge — deterministic
Site visits per 1,000 leads	68–82	110–135

Sell.Do exposes a REST API for lead creation, update, and activity logging. The crm_sync_node calls Sell.Do's POST /api/v1/leads endpoint to create or update the lead record, and POST /api/v1/activities to log call outcomes and qualification data as activities. Authentication is via Sell.Do's API key. Build a SellDoAdapter class that handles field mapping between Sell.Do's lead fields and the LangGraph state schema — this keeps the crm_sync_node clean and makes CRM migration straightforward later. LeadSquared follows the same pattern using its Lead API and Lead Activity API.

As a scheduled external trigger that re-enters the pipeline when a dormant buyer crosses a time threshold or responds to a nurture message. A daily cron job queries the checkpoint database for leads in DORMANT stage with days_in_current_stage >= 14, sends a WhatsApp template, and on response calls reactivate_dormant_buyer(lead_id, "whatsapp_response") — which updates state to CALLING_QUEUED and re-enters at the calling_agent node with full historical qualification context intact.

LangGraph with SQLite checkpointing handles 50–200 concurrent threads comfortably but is not built for 500+ truly concurrent executions. At scale, use a PostgreSQL checkpoint backend (langgraph-checkpoint-postgres) instead of SQLite — its connection pooling handles hundreds of simultaneous checkpoint reads/writes without contention. Since most leads at any moment sit in DORMANT, CALLING_QUEUED, or SITE_VISIT_SCHEDULED rather than actively executing a node, only 10–30 threads are typically active concurrently even at 500 total leads.

Because the real estate lead-to-booking journey is not linear — it requires retry logic with backoff, dormant-to-active re-entry, multi-day state persistence, and deterministic conditional routing between nodes like calling, CRM sync, scheduling, and human escalation. Hand-rolled if-else branching accumulates edge-case patches quickly; LangGraph's typed state schema, conditional edges, and checkpoint system model this directly as a graph, making the pipeline's logic traceable node-by-node rather than buried in nested conditionals.

No. LangGraph orchestrates the pipeline around the calling layer — it doesn't replace the telephony/voice AI platform (Vapi, Retell, Bland, or similar) making the actual calls. The calling_agent node simply triggers a call via that platform's API and waits for the outcome; LangGraph's job is deciding what happens before and after that call — retries, CRM writes, scheduling, escalation — based on the pipeline's current state.

Disclaimer: LangGraph framework capabilities, API interfaces, and checkpoint system descriptions in this article reflect the LangGraph library as of Q2 2026. LangGraph is an actively developed open-source framework — refer to the official LangGraph documentation for current API specifications before implementation. Pipeline performance figures are estimates based on deployment observations and will vary by project, call script quality, lead source, and configuration.

Loading article...

LangGraph Real Estate Workflow — Building a State-Machine Sales Pipeline for Property Lead Conversion

LangGraph: The State Machine Behind Production Real Estate AI Pipelines

Why State Machines for Real Estate Sales Pipelines

The Problem With Linear Pipelines

The Real Estate LangGraph State Schema

The 7-Node LangGraph Pipeline Architecture

Checkpoint Persistence — Why SqliteSaver Matters

Pipeline Performance — LangGraph vs. Sequential Script

LangGraph: The State Machine Behind Production Real Estate AI Pipelines

Why State Machines for Real Estate Sales Pipelines

The Problem With Linear Pipelines

The Real Estate LangGraph State Schema

The 7-Node LangGraph Pipeline Architecture

Checkpoint Persistence — Why SqliteSaver Matters

Pipeline Performance — LangGraph vs. Sequential Script