Built for the rules real estate already works under.

Agents in RealtyOS draft; they never send. Emails, texts, marketing, listing websites, deadline changes, and document reviews each open a request in one approval queue. Approving the request is what performs the action, such as sending the message, publishing the site, or applying the deadlines. Approved marketing is marked ready for your team to post from its own tools; RealtyOS does not send campaigns or post to social media.

Compliance-sensitive items, such as buyer agreement reminders and contract reviews, need a broker's decision. Those requests show who may decide, and no one else can approve them.

Approval rules can be tightened by the brokerage but never switched off for client messages, compliance-sensitive output, publishing, or document review.

Every record belongs to one organization. The application reads and writes through Postgres row-level security with a restricted database role, so a query can only reach rows in the signed-in organization, even if application code has a bug. Automated tests try cross-organization reads, updates, and deletes on every table and expect them to fail.

Within an organization, roles decide what each person sees and does. Agents see their own and unassigned records; team leads, brokers, and coordinators see the team's work.

Every agent run, approval decision, edit, message, status change, and export writes an audit entry with who did it, when, and what changed. The application's database role can add entries and read them but cannot change or delete them.

Owners, broker admins, and team leads can filter the log and export it as a CSV file, up to the newest 10,000 matching entries per export. Exporting is itself recorded.

RealtyOS uses Anthropic's Claude or OpenAI through their business APIs. For each task it sends only the records that task needs, with instructions to use only those facts. Both providers state that API data is not used to train their models by default; review each provider's current terms for your account.

If a provider is unavailable, the task falls back to an offline generator and says so on the result. A workspace can also run entirely on the offline generator.

Agent output is checked before anyone sees it: Fair Housing language, legal, tax, and lending questions that need a professional, and whether the draft needs approval.

A text can only be sent to someone with recorded consent, which stores when and how it was given. Texts are never sent between 8 p.m. and 8 a.m. in the brokerage's time zone: an approval in those hours is refused, and the text stays in the queue until someone approves it after 8 a.m. Replying STOP opts a person out immediately in every workspace that has their number, and START opts them back in.

Consent, opt-outs, and quiet hours are checked again when a text is approved, not only when it was drafted. US business texting also requires A2P 10DLC registration with your carrier; RealtyOS is built for it and we help you register.

RealtyOS does not send marketing email; approved campaigns go out through your own email platform, which handles unsubscribes. An email campaign a person submits for approval must include the brokerage's postal address and an unsubscribe line.

Drafts, listing copy, and campaigns are scanned for language that expresses a preference based on a protected class, or that steers buyers. Findings explain the concern and suggest a property-focused alternative.

Phrases on the scanner's blocking list, such as “adults only” or “no children,” block approval until they are edited out. Other findings are shown to the reviewer as warnings. These checks are guidance for your broker, not a legal determination.

Following the 2024 industry practice changes, RealtyOS tracks whether each buyer has a signed written agreement and flags showings scheduled without one, with a task to get it signed. A reminder to the client can be drafted in one click and needs broker approval. Your broker confirms the requirements in your state and MLS.

RealtyOS runs on Vercel with a Supabase Postgres database, Supabase Auth, and a private Supabase Storage bucket for documents. Traffic is encrypted in transit with TLS, and the database and file storage are encrypted at rest by those providers.

Keys for the database, AI, email, texting, and payment providers live only in environment variables, never in the database or code. Public forms are rate limited, and inbound text and payment webhooks are signature-verified before they are read.