The RAILS Framework

Boards are not deciding whether members will begin using AI. Members are already using it in production work, often through general-purpose tools that sit outside a board-defined identity, permission, retention, provenance, and audit layer.

The RPR 2026 AI Adoption Survey also found that 92% use AI now or plan to, 71% identify time savings as its leading value, and 68% save at least one hour per week. The survey was self-reported by 225 U.S. NAR-member real estate professionals, so it should not be generalized as a census of every market. Read the full RPR survey .

The survey does not directly measure board oversight. The governance conclusion is an inference: when adoption is already embedded in member workflows, the practical choice is no longer AI versus no AI. It is governed, permissioned paths versus unmanaged workarounds with weaker visibility and fewer shared controls. What members can already delegate is measurable: HomieBench v3 benchmarks eight frontier models across 100 supervised realtor workflows.

The detailed answers sharpen that inference. In Q5, 38.74% reported using market analysis or pricing tools and 22.52% reported AI CMA tools. In Q7, 30.63% reported analyzing market trends and 24.32% reported running CMAs or pricing conversations. One qualitative respondent also said they use AI heavily when processing trends from MLS data. The survey does not establish how common it is for members to paste MLS, client, or transaction data into a model, but it demonstrates enough high-stakes use to make data-flow controls urgent.

Adoption is ahead of governance. Waiting does not preserve the status quo; it cedes the control surface.

Agentic AI is becoming an interface through which consumers and professionals discover information, compare options, make decisions, and initiate action. In real estate, the interface that captures the question also captures commercially valuable intent: preferences, search refinements, objections, timelines, affordability constraints, and next steps.

Boards and MLSs therefore face two risks at once. Blanket prohibition can push members toward ungoverned consumer tools and workarounds. Unrestricted access can transfer protected listing, client, and transaction data into systems that were not designed to govern it. Neither extreme is durable.

The AI may receive capabilities. It must not receive custody.

RAILS—the proposed Realtor Agentic Interoperability Layer Standard—keeps protected data in its proper system of record while exposing narrowly scoped, identity-bound, purpose-bound, auditable capabilities. Models may search, summarize, prepare, validate, or request an action. They do not receive feed credentials, become the CRM, persist a shadow listing database, create the authoritative contract in an unapproved sandbox, or apply a signature.

The result is a model-agnostic architecture that combines zero trust, least privilege, purpose limitation, split-channel secure rendering, deterministic computation, human approval for consequential actions, immutable audit events, and capability-level vendor certification.

Organized real estate was built around cooperation: competing professionals shared inventory under common rules for attribution, access, display, accountability, and data quality. That cooperative infrastructure also created an information advantage. AI and open distribution are reducing the marginal cost of basic access and interpretation.

The professional does not disappear when information becomes cheaper. The professional’s comparative advantage moves toward fiduciary alignment, judgement under uncertainty, negotiation, risk ownership, service coordination, and accountable execution. The board’s advantage changes in parallel: from information scarcity toward identity, permission, provenance, quality, interoperability, auditability, and revocation.

The market is already showing this shift. In October 2025, Zillow and OpenAI launched a conversational listing experience inside ChatGPT. Zillow says it controls the rendered experience, does not send OpenAI a raw MLS feed, and preserves MLS attribution and field controls. That architecture is a live example of a capability being made available without transferring feed custody. See the primary announcements from Zillow and Zillow’s industry explanation .

In June 2026, HouseCanary described a national expansion of Google’s mobile home-discovery program using listings from participating MLSs with broker and agent attribution. The announcement is evidence of real-estate discovery moving into a horizontal intent layer, although it should not be read as proof of any architecture beyond what the publisher describes. See the HouseCanary announcement .

Tool-connected AI is also becoming portable. OpenAI’s Apps SDK is built on the Model Context Protocol; Anthropic describes MCP as an open standard for connecting AI systems to external tools and data. These facts do not prove that every portal will integrate with every model. They do establish the interface pattern: natural-language request, controlled tool call, external system, structured result, and rendered experience. See OpenAI and Anthropic .

The choice is not “AI or no AI.” It is whether adoption happens inside a governable perimeter or outside one. Governed access creates new diligence and enforcement work, but it also gives boards a path to set requirements, certify capabilities, monitor use, revoke access, and keep professional accountability visible.

Custody exists when a model provider, agentic harness, or vendor application can persist, redistribute, train on, broadly index, or become an alternate source of truth for protected data. Capability exists when an authenticated actor can request one defined business action through a controlled service with bounded input, output, purpose, retention, and side effects.

Every capability should declare its eligible actors, allowed purpose codes, data classes, result ceilings, risk tier, human approval requirement, retention class, audit events, failure behaviour, and revocation path. Credentials remain at the gateway or system of record; they never enter model context.

• The model is never the system of record.
• Protected data is purpose-bound and minimized.
• Credentials and signing keys never enter model context.
• Deterministic services calculate and validate where correctness matters.
• Consequential actions remain attributable to an authorized human.
• Every access is observable, revocable, and auditable.
• Interfaces remain model-agnostic to reduce platform lock-in.
• Human-rights, privacy, and professional duties are enforced by design.

A workable policy must stop treating “real-estate data” as a single class. Listing, client, and transaction data carry different permissions, risks, and authoritative systems. RAILS applies the same boundary to all three while preserving those differences.

Split-channel secure rendering

Protected listing detail does not always need to enter the model’s natural-language context. The model can receive a count, an opaque widget reference, policy metadata, and a secure view URL. The user interface then retrieves the authorized listing component directly from the IDX, VOW, DDF, brokerage, or board-controlled origin. The display channel and the model channel remain separate.

This pattern is compatible with existing permission-based distribution models. CREA describes REALTOR.ca DDF® as a managed, permission-based service in which broker owners control how listing content is shared. RESO publishes current Web API and Data Dictionary specifications that can provide common vocabulary for capability schemas. See CREA DDF® and RESO specifications .

RAILS separates probabilistic interpretation from identity, authorization, calculation, recordkeeping, and binding execution. A model may infer what a user is trying to achieve; it does not decide whether the user is entitled to achieve it.

The policy and identity plane evaluates the subject, action, resource, data class, purpose, consent, jurisdiction, time, and risk tier. The capability gateway then asks the authoritative application to perform the action. The default response is the minimum sufficient projection—not the entire underlying resource.

allow = policy(
  subject,
  action,
  resource,
  data_class,
  purpose,
  consent,
  jurisdiction,
  time,
  risk_tier
)

result = minimize(authoritative_data, purpose, role, consent, policy)

This architecture follows the same direction as zero-trust systems: no implicit trust based on location or ownership, explicit authentication and authorization, and policy focused on users, services, and resources. NIST SP 800-207A further describes granular application-level policy enforcement through gateways and service identities. See NIST SP 800-207 and NIST SP 800-207A .

Realtors and brokerages already use authorized IDX websites and applications to present listing information under applicable agreements, board rules, display requirements, and participant control. Coding agents can also modify website code. RAILS combines those facts without creating a new raw-data entitlement: the approved IDX application remains the only runtime permitted to hold credentials, query live listing data, enforce field and display rules, and render the result.

NAR’s current IDX policy describes authorized display through participant-controlled websites, mobile apps, and other approved mechanisms, requires the participant to control how listings are displayed, and states that MLS database access may not be given to an unauthorized person or entity. See NAR IDX Policy Statement 7.58 . In Canada, CREA describes DDF® as a permission-based distribution service and a Member Website Feed for listing display on a member-controlled website; see REALTOR.ca DDF® .

The coding agent changes the experience. The approved IDX application controls the data.

The model may help create a custom buyer-search page, neighbourhood experience, listing comparison, property page, or deterministic home-evaluation workflow. It can edit React components, templates, schemas, tests, mock fixtures, explanatory copy, and approved parameterized query definitions. It must not receive the raw feed, reuse feed credentials, query the live database, create a shadow index, or copy bulk listing data into model memory.

capability: idx.page.render
actor: participant_controlled_website
agent_visibility: [schema, mock_fixture, query_definition, rendered_metadata]
agent_prohibited: [feed_credential, live_database, raw_payload, bulk_export]
runtime:
  execute_query: approved_idx_application
  enforce: [field_permissions, attribution, freshness, display_rules, rate_limits]
output:
  returns: [rendered_page_ref, result_count, data_as_of, provenance]
deployment:
  tests_required: [query_bounds, prohibited_filters, attribution, stale_data, extraction]
  human_approval: required

RESO notes that its Web API can execute live queries for immediate results in web applications and defines an IDX payload as the structured fields needed for display on an IDX website. RAILS places that live query and payload handling inside the authorized application boundary—not inside model context. See the RESO Web API overview .

• The website or approved application—not the model—is the data recipient and runtime.
• The coding agent receives schemas, fixtures, and opaque result references, not feed credentials.
• Live queries execute server-side under participant identity, purpose, and policy.
• Rendered pages preserve attribution, freshness, filtering, display, and access requirements.
• Every deployed code or query-definition change is tested, reviewed, versioned, and reversible.
• Boards can audit and revoke the application capability without granting access to the model.

RAILS is not only a listing-search architecture. The same capability-without-custody boundary applies to the repetitive workflows that realtor tools are beginning to automate. Each workflow needs a named action, authorized actor, purpose, minimum data, deterministic checks, human boundary, audit event, and revocation path.

AI showing booking for Zillow, ShowingTime, BrokerBay, and Touchbase

Showing coordination is a high-value candidate for a board-defined API profile because the workflow crosses listing permissions, realtor identity, buyer context, calendars, seller instructions, appointment status, lockbox information, and feedback. Zillow’s Real-Time Touring currently uses ShowingTime availability and can synchronize booking changes between the Zillow Premier Agent experience and ShowingTime. See Zillow Real-Time Touring . ShowingTime has also described real-time availability for broker and agent websites through an API; see the ShowingTime announcement .

BrokerBay and Touchbase are important showing-management systems in Canadian and North American markets. Their public sites describe appointment scheduling, confirmations, availability, instructions, feedback, and brokerage/board workflows, but a consistently documented self-serve developer surface is not evident for every use case. Boards and vendors should expose permissioned capabilities rather than forcing innovators to infer access from the user interface. See BrokerBay and Touchbase showing workflows .

In the absence of a supported interface, some teams experiment with agentic browser use through development harnesses. That workaround can inherit a realtor’s broad session, break on interface changes, mishandle MFA, duplicate appointments, expose confidential showing instructions, or violate platform terms. Browser automation may be useful for a supervised prototype, but it should not become the industry’s default showing control plane.

profile: rails/1.0
capability: showing.request_create
eligible_roles: [licensed_realtor, authorized_assistant]
required_scopes: [showing:availability_read, showing:request_create]
input:
  listing_ref: opaque
  requested_slots_max: 3
  buyer_context_ref: crm-scoped
  idempotency_key: required
policy:
  listing_status_current: required
  calendar_conflict_check: required
  agency_and_consent_state: required
output:
  returns: [request_ref, status, expiry, secure_instruction_ref]
  model_visibility: no_lockbox_or_confidential_instructions
human_review: required_on_exception
audit: append_only
revocation: immediate

• showing.availability_read
• showing.request_create
• showing.request_reschedule
• showing.request_cancel
• showing.instructions_render_secure
• showing.feedback_submit

AI Follow Up Boss, AI GoHighLevel, AI Lofty CRM, AI kvCORE / BoldTrail, Sierra Interactive, CINC, Real Geeks, BoomTown, Wise Agent, and Top Producer

Search demand is clustering around specific realtor tools, but the governance unit should remain the capability. The 84-system integration directory maps this landscape with documented access status for every system. Follow Up Boss documents a REST API and signed webhooks. HighLevel exposes contacts, conversations, calendars, opportunities, payments, and a broad webhook catalogue. Lofty documents developer access to leads, listings, transactions, communications, and AI features. BoldTrail is the current ecosystem name associated with kvCORE. Sierra Interactive, CINC, Real Geeks, BoomTown, Wise Agent, Top Producer, HubSpot, Salesforce, and other CRMs vary in partner access, object coverage, and commercial terms.

RAILS should make those differences explicit while preserving common actions: crm.person_match, crm.note_create, crm.task_create, crm.appointment_create, crm.stage_propose, and crm.opt_out_record. See the developer materials for Follow Up Boss , HighLevel , and Lofty .

AI social media for realtors: OpusClip, SumoClip, Higgsfield, Zernio, and ManyChat

A governed social agent can transform approved source material with AI clipping, create disclosed synthetic assets or presenter variants, obtain exact-artifact human approval, publish through official platform APIs, manage permitted comment and DM workflows, and write qualified leads back to the CRM. It should not scrape social dashboards, invent listing facts, reuse media without rights, impersonate a realtor, or continue a conversation outside platform and consent rules.

The follow-up Homies Research paper, The Real Estate Social Media AI Agent Stack, covers OpusClip, SumoClip, Supo, Higgsfield AI clones, the Zernio API, ManyChat, CRM integration, cost, measurement, and human-review controls in detail.

A model request necessarily processes some input during inference. “No data in the model” is therefore useful shorthand but not an enforceable specification. The policy must enumerate every place protected information may persist.

A defensible vendor matrix identifies retention by endpoint and feature, training and feedback status, memory defaults, file lifecycle, cache behaviour, trace redaction, human-review exposure, subprocessors, residency, deletion verification, encryption, and incident obligations. Consumer accounts should not be used for protected workflows.

In Canada, organizations subject to PIPEDA must address accountability, identified purposes, consent, limiting collection, limiting use/disclosure/retention, accuracy, safeguards, openness, access, and challenge rights. Provincial law and sector-specific rules may also apply. See the Office of the Privacy Commissioner of Canada .

The proposed rule is precise: protected real-estate data may not be used for training, fine-tuning, model improvement, feedback, persistent memory, reusable retrieval indexes, model-managed files, or long-lived application state unless every party with the legal authority to permit that use has done so. Transient processing must be minimized, purpose-bound, encrypted, contractually protected, and subject to the shortest available retention.

Traditional application security remains necessary, but an agent adds instruction interpretation, tool selection, workflow state, and cross-system action. Controls must assume that retrieved content can be hostile and that a fluent model output can still be wrong or manipulative.

The OWASP Top 10 for Agentic Applications 2026 provides a useful cross-industry baseline. NIST’s voluntary Generative AI Profile organizes risk work around governance, mapping, measurement, and management. RAILS translates those foundations into real-estate-specific data and action boundaries; it does not replace either framework.

Audit events should be append-only and include trace ID, actor, tenant, capability, purpose, risk tier, resource reference, request/response hashes, policy version, authorization result, approval reference, outcome, and retention class. Raw protected payloads should not be logged by default.

A model can help a professional reason about a result, but it should not free-form a CMA, filing deadline, disclosure decision, binding form, or protected-field determination. Deterministic services should calculate comparable filters, distances, date windows, prices, adjustments, mortgage figures, taxes, deadlines, required fields, signature completeness, and document hashes.

{
  "result_ref": "cma_01J...",
  "source": "approved-vow-service",
  "retrieved_at": "2026-07-14T14:21:08Z",
  "data_as_of": "2026-07-14T14:19:55Z",
  "policy_version": "board-agentic-policy-1.2",
  "tool_version": "cma-service-3.4.1",
  "calculation_version": "adjustments-2.0",
  "model_visibility": "metadata_only",
  "human_review_required": true
}

Agentic interfaces can amplify discrimination when they accept protected-class preferences, infer them from proxies, or translate vague language into demographic steering. The design rule is consistent even where specific protected grounds differ: do not accept, infer, optimize, or conceal protected-class criteria.

• Maintain prohibited-feature and proxy-feature catalogues.
• Log the objective criteria that include or exclude each result.
• Explain trade-offs rather than rank communities as good or bad.
• Test recommendations and ad delivery for disparate patterns.
• Escalate ambiguous requests to an authorized human.
• Apply the specific law and professional rule of each jurisdiction.

Ontario’s Human Rights Code protects equal treatment in buying, selling, and renting housing on Code-protected grounds. In the United States, HUD guidance identifies risks including denying housing information, differential terms, and steering through digital advertising. See the Ontario Human Rights Commission and HUD’s digital-platform guidance . Implementers must verify current local law rather than reuse either list as a universal rule.

A vendor may be suitable for secure listing rendering and unsuitable for transaction dispatch. A brokerage tool may be approved to create a CRM task and prohibited from bulk export. Certification should therefore attach to a capability, data class, actor, purpose, and risk tier—not to a logo.

Evidence should include architecture and data-flow diagrams, a field-level data inventory, model and subprocessor lists, retention matrices, training-use commitments, tenant-isolation tests, OAuth scopes, tool schemas, red-team results, fair-housing or human-rights testing, approval design, audit-event catalogues, incident response, business continuity, kill-switch procedures, deletion evidence, and software/AI bills of materials.

From feed governance to capability infrastructure

The same institutions that created permissioned distribution can expose controlled search, valuation support, statistics, geographic intelligence, rendering, compliance validation, attribution, and provenance endpoints. The strategic product is no longer only a feed. It is a governed capability platform that lets new interfaces operate on board-defined terms.

The safest adoption path increases capability only after the preceding control layer has been demonstrated. Boards should begin with inventory and a narrow read-only path, not a high-risk transaction automation showcase.

1. 0–90 daysPhase 1

   Policy and inventory

   Map systems and data classes; identify shadow AI; define prohibited uses; create legal, privacy, security, technical, and member governance.

2. 90–180 daysPhase 2

   Read-only pilot

   Certify a narrow search and secure-rendering path; test injection, bulk extraction, attribution, freshness, field permissions, and revocation.

3. 180–270 daysPhase 3

   Analytics and CRM

   Add deterministic CMA/statistics and purpose-bound CRM tools; implement shared audit events and privacy-impact review.

4. 270–365 daysPhase 4

   Transaction preparation

   Integrate approved forms platforms; bind human approval to immutable document versions; keep dispatch platform-side.

5. Year 2Phase 5

   Standards and scale

   Publish an Agentic Access Profile, align schemas with RESO concepts, support multiple vendors, and operate red-team and incident-sharing programs.

Keeping the human in the loop: safe integration in one workflow

The tier progression stays abstract until it is applied to a single consequential workflow. Take the one members care about most: writing an offer.

In the first phase, the AI writes the offer inside a supervised harness, and the realtor does everything else: uploads the document into the approved platform, reviews it, and completes the signing flow themselves. The model’s autonomy ends at the draft. Review is enforced by the physics of the workflow, because nothing reaches a client that the realtor did not personally move and sign.

In the second phase, the AI writes the offer, uploads it, and routes it for signature. One rule changes: the signing order. The document goes to the realtor before the client. By signing first, the realtor legally binds themselves to the AI-prepared instrument before the client ever sees it. Accountability stops being a procedural checkbox and becomes a property of the instrument itself.

The pattern generalizes across every tier in this framework. As autonomy increases, the human checkpoint does not disappear; it moves earlier and its consequences get heavier. The AI may earn more of a workflow only where the accountable human’s commitment is captured by a mechanism that cannot be skipped: a signature order, a document hash, a step-up approval. Section 14 shows the hash-bound version of the same idea, where approval binds to the exact document version and any later mutation invalidates it.

Phase two does not remove the human. It moves the signature earlier, so the licensee is bound to the AI’s work before the client ever sees it.

Success metrics should be operational: policy violations prevented, field-minimization rate, attribution correctness, tool-call failure rate, human-review completion, revocation time, incident detection time, unauthorized extraction resistance, and member time saved—not raw prompt volume.

The following clauses are starting points for jurisdiction-specific drafting. They are deliberately technology-neutral and preserve existing duties.

Natural-language policies are necessary but insufficient. Each approved capability should have a machine-readable profile that certification tests can exercise.

profile: rails/1.0
capability: cma.prepare
risk_tier: 2
eligible_roles: [licensed_realtor]
required_scopes: [cma:prepare]
purpose_codes: [seller_evaluation, buyer_analysis, brokerage_review]
input:
  schema: cma-request/2.1
  max_records: 50
output:
  model_visibility: metadata_only
  returns: [cma_ref, secure_view_url, expiry, provenance]
human_review: required_before_share
retention_class: audit_metadata_only
revocation: immediate

For transactions, approval must bind to an immutable artifact. A later mutation must invalidate the approval and force a new review.

function dispatchApproved(documentBytes, approval) {
  assert(approval.expiresAt > now())
  assert(sha256(documentBytes) === approval.documentSha256)
  assert(currentActor.id === approval.reviewerId)
  assert(policyAllows("transaction.dispatch", approval.purpose))

  // The approved platform holds the signing credential.
  return transactionPlatform.dispatch(documentBytes, approval.id)
}

Production implementations should use asymmetric signatures or a managed key service, short-lived tokens, replay protection, step-up authentication, and explicit audience and tenant binding. Samples in this paper illustrate control shape; they are not production security code.

Consumers will choose convenient interfaces. Professionals will choose tools that save time. Portals and model providers will continue competing for the point at which intent becomes workflow. The durable response is not to pretend that shift can be stopped. It is to define the trust infrastructure through which it operates.

The useful boundary is custody versus capability; persistent storage versus controlled transient processing; autonomous action versus accountable approval; probabilistic explanation versus deterministic calculation; and ungoverned distribution versus auditable access.

Better interfaces should operate through board-defined trust—not around it.

Boards that define identity, permission, provenance, quality, interoperability, auditability, certification, and revocation can protect data while improving member capability. Boards that focus only on yesterday’s interface may preserve the feed while losing influence over tomorrow’s consumer journey.

Product claims are factual only to the extent supported by the linked publisher. The RAILS architecture, tiers, policy language, and roadmap are proposals by the authors. Legal requirements vary and must be re-verified before adoption.

1. 01

   Zillow

   Zillow debuts the real estate app in ChatGPT (Oct. 6, 2025)
2. 02

   Zillow

   How the app preserves listing reach and industry rules (Oct. 9, 2025)
3. 03

   OpenAI

   Introducing apps in ChatGPT and the Apps SDK (Oct. 6, 2025)
4. 04

   Anthropic

   Introducing the Model Context Protocol (Nov. 25, 2024)
5. 05

   HouseCanary

   Google Home Discovery national expansion (June 11, 2026)
6. 06

   RPR

   2026 AI Adoption Survey: 82% of real estate agents use AI
7. 07

   OpenAI

   How data is used to improve model performance
8. 08

   OpenAI

   ChatGPT Search
9. 09

   Anthropic

   Consumer data-use choices for Claude
10. 10

    Anthropic

    Enabling and using web search
11. 11

    Zillow

    Real-Time Touring and ShowingTime-integrated booking
12. 12

    BrokerBay

    Brokerage and board showing-management ecosystem
13. 13

    Touchbase

    Showing availability, confirmation, instruction, and feedback workflows
14. 14

    Follow Up Boss

    REST API and webhook documentation
15. 15

    HighLevel

    CRM, conversation, calendar, opportunity, and webhook API
16. 16

    Lofty

    Real estate CRM developer API
17. 17

    NIST

    SP 800-207: Zero Trust Architecture
18. 18

    NIST

    AI 600-1: Generative AI Profile
19. 19

    OWASP

    Top 10 for Agentic Applications 2026
20. 20

    RESO

    Current specifications and supporting materials
21. 21

    RESO

    Web API, IDX payloads, and live web-application queries
22. 22

    NAR

    Internet Data Exchange Policy Statement 7.58 (Jan. 1, 2026)
23. 23

    CREA

    REALTOR.ca DDF®
24. 24

    OPC Canada

    PIPEDA requirements in brief
25. 25

    OHRC

    Freedom from discrimination in housing
26. 26

    HUD

    Guidance on housing advertising through digital platforms