What Is an AI Harness—and How Should Realtors Use One?

A language model can reason about text. It does not inherently know which CRM record is authoritative, which tools exist, whose credentials to use, what it is allowed to change, how to wait for approval, what happened yesterday, how to retry a failed webhook, or when to hand the job to a licensed human. The harness supplies those operating conditions.

A better model can improve reasoning. A better harness improves whether the job completes safely, cheaply, repeatably, and in the correct business system. In real estate, the harness often matters more because the work crosses CRM, email, texting, voice, calendar, documents, websites, property data, and human approvals.

If a product has a chat window and a CRM API key but lacks identity, policy, durable state, approval, retries, and evaluation, it is not a production harness. It is a demonstration with access to customer data.

Most individual realtors should live at Level 1 or 2. Teams can selectively move repeatable, measurable jobs to Level 3. Level 4 is a product and operations program, not a subscription setting.

These products overlap, but they are not interchangeable. Some are strongest for building and operating code, some provide persistent agent runtimes, some specialize in research, and one is the managed vertical product path.

Codex guidance describes a durable pattern: provide clear context, encode reusable repository guidance, connect external systems through tools or MCP, turn repeated workflows into skills, and test the result. Claude Code similarly exposes tool permissions and MCP configuration. OpenClaw documents a persistent runtime with a workspace and session store. Manus exposes managed multi-step agent tasks. Perplexity’s Agent API combines model and real-time search capabilities.

A real estate harness has two broad planes. The reasoning plane assembles context, plans, and proposes structured actions. The control plane resolves identity, applies policy, validates data, obtains approval, executes tools, records the result, and prevents unsafe actions even if the model asks for them.

Good harness jobs have a clear trigger, bounded outcome, authoritative systems, measurable success, defined owner, and known failure path. “Run my business” has none of those properties.

MCP describes itself as an open-source standard for connecting AI applications to external systems. It can reduce connector complexity, but it does not remove the need for authentication, least privilege, policy, approval, and tool-level auditing. See the official MCP introduction .

The best tool is narrow. Prefer propose_showing_slots, create_email_draft, or request_offer_approval over “run arbitrary SQL,” “open any URL,” or “send any message.”

Before wiring anything, check what the target system officially exposes: the 84-system real estate AI integration directory maps realtor CRM, MLS, IDX, email, voice, social, transaction, and website systems with official API links and honest access status.

1. 01

   Write the job contract

   Define trigger, user, client, inputs, allowed outputs, prohibited actions, owner, deadline, and success metric.

2. 02

   Choose systems of record

   Name the authoritative CRM, calendar, mailbox, transaction, document, website, listing, consent, and identity sources.

3. 03

   Design narrow tools

   Separate reads from writes. Use typed schemas, stable IDs, dry-run modes, idempotency keys, and explicit error models.

4. 04

   Implement identity

   Resolve the realtor, team, brokerage, client, tenant, credential, role, assignment, and purpose before retrieving context.

5. 05

   Build minimum context

   Retrieve only what the job needs, with source IDs and timestamps. Never dump the whole CRM or mailbox into the prompt.

6. 06

   Add policy outside the model

   Consent, quiet hours, restricted topics, approval thresholds, data rules, spending limits, and role permissions live in code.

7. 07

   Add state and queues

   Persist job progress, leases, retries, timeouts, checkpoints, webhook cursors, dead letters, and manual intervention.

8. 08

   Create the approval experience

   Show proposed action, recipient, source facts, changed fields, risk flags, cost, and exactly what will happen.

9. 09

   Instrument every action

   Trace context sources, model version, prompt/workflow version, tool request, policy result, approver, response, cost, and final outcome.

10. 10

    Build evaluations before autonomy

    Replay representative jobs and adversarial cases. Promote only workflows that meet explicit quality and safety thresholds.

request_appointment_booking({
  crm_contact_id,
  calendar_id,
  candidate_slot_ids,
  purpose,
  consent_record_id,
  expected_owner_id,
  idempotency_key
}) -> { proposal_id, conflicts, approval_required }

Separate transient working state from authoritative business records and from reusable instructions. The CRM remains the relationship record. The calendar remains the availability record. The transaction platform remains the deadline and document record. The harness stores only the state required to continue, verify, and evaluate the current job.

Avoid a giant permanent “memory” containing raw inboxes, CRM exports, listing feeds, client documents, and speculative summaries. It becomes stale, difficult to correct, expensive to search, and dangerous to authorize.

Realtors already use coding and browser-capable harnesses to operate systems that do not expose suitable APIs: showing platforms, portals, CRMs, websites, social tools, and administrative dashboards. This can unlock real productivity, but it inherits every weakness of a changing user interface.

• Use a dedicated least-privilege account and isolated browser profile.
• Require human approval before bookings, messages, purchases, form submissions, or irreversible changes.
• Pin the exact domain and workflow; do not grant unrestricted browsing with production credentials.
• Validate the final confirmation page and record a screenshot or structured receipt.
• Detect layout drift, login challenges, stale sessions, overlays, and ambiguous UI state.
• Rate-limit, randomize nothing for evasion, and comply with platform terms and board/brokerage policy.
• Prefer an official API as soon as one becomes available.

For showing booking, the safest long-term path is an authorized API from platforms such as ShowingTime, BrokerBay, Touchbase, or the relevant regional service. Browser automation can demonstrate demand, but an API enables stronger permissions, validation, audit, and reliability.

Realtors can already operate authorized IDX websites under applicable agreements and rules. Coding agents can also edit website code. The safe combination is an architecture where the approved IDX application remains the only runtime allowed to query and render live listing data, while the agent changes page templates, parameterized query definitions, components, and deterministic presentation logic.

• Do not place raw board or MLS feed credentials in the model, prompt, repository, or agent workspace.
• Do not let the model query the live IDX database or receive bulk raw listing exports.
• Develop against documented schemas, approved SDKs, fixtures, and redacted test data.
• Execute live listing queries inside the authorized website or participant application.
• Server-render deterministic results with attribution, refresh, display, and access rules enforced.
• Use approval and automated tests before deploying changes to listing search or valuation pages.

The RAILS controlled IDX website boundary gives boards, MLSs, brokerages, and vendors a policy and architecture model for this capability-without-custody approach.

Every tool call should inherit the real user, tenant, role, purpose, and scope. Credentials belong in a managed secret system and should be resolved at execution time. The model receives a capability description and opaque IDs—not reusable passwords, refresh tokens, database strings, or board feed credentials.

• Use least-privilege read and write tools with separate scopes.
• Require re-authentication or explicit approval for high-impact actions.
• Block arbitrary code, SQL, URLs, recipients, file paths, and destinations by default.
• Treat websites, emails, documents, DMs, CRM notes, and attachments as untrusted input.
• Bind approvals to the exact action payload so the agent cannot change it after review.
• Use tenant-aware encryption, retention, access logs, token rotation, and offboarding.
• Red-team prompt injection, data exfiltration, confused-deputy, cross-client, and stale-context failures.
• Keep a global pause, per-workflow pause, per-user revocation, and manual recovery path.

Review the MCP security best practices and the relevant vendor’s permission model before exposing any production tool.

Long-running real estate work is full of waits: a lead replies, a showing is approved, a document arrives, a human reviews an offer, a calendar changes, or a provider rate-limits the next step. Persist the workflow and resume from events instead of keeping a model session alive and hoping.

Track cost per completed job—not only token spend. A cheap model that creates CRM cleanup, missed appointments, wrong messages, or human rework is an expensive system. Homies’ HomieBench v3 applies that completed-job logic to realtor work.

The base harness or model subscription is often the smallest line. The budget grows with connected systems, dirty data, identity, custom workflows, browser use, approvals, production uptime, security, evaluation, and the people who handle exceptions.

A realtor can get value from a $20–$100 monthly tool stack and a disciplined manual workflow. A brokerage-grade operating layer costs more because it becomes shared production infrastructure. The correct comparison is not “subscription versus free ChatGPT.” It is total cost per trustworthy completed job versus existing human work.

1. Days 1–5

   Choose one job

   Define trigger, owner, inputs, outputs, system of record, prohibited actions, success metric, and human fallback.

2. Days 6–10

   Build read-only context

   Connect one CRM or mailbox with least privilege; resolve identity and source records; generate drafts only.

3. Days 11–15

   Add evaluation and policy

   Create normal, edge, adversarial, stale-data, wrong-client, and prompt-injection cases with explicit pass thresholds.

4. Days 16–20

   Add one write behind approval

   Use a typed tool, dry-run preview, exact-payload approval, idempotency, audit, rollback, and instant pause.

5. Days 21–25

   Run a consented pilot

   Use a small real cohort, monitor every job, compare human edits, and measure completion and rework.

6. Days 26–30

   Promote only the proven branch

   Automate a bounded low-risk path; keep high-impact work supervised and schedule recurring evaluation.

Continue with the channel-specific implementation guides for email agents, CRM text messaging agents, voice agents, and the real estate social media agent stack.

Build when the workflow is genuinely differentiated, the volume justifies it, your team controls the systems and data, you can staff engineering and operations, and you need the flexibility of a custom operating layer.

Buy when the goal is to respond faster, keep the CRM current, book more appointments, create better content, and serve clients. The vertical product should absorb the scaffolding so the realtor can own judgment, relationships, negotiation, and accountability.