Before Your AI Touches a Title File, Put It in the Lobby

A 10-business-day shadow-mode test for title teams

A title office does not need an AI system to “run the file.” It needs fewer status chases and fewer late surprises.

That is a real operating problem. In Inman’s October 26 brokerage-operations benchmark, just over two-thirds of 40 broker-owners said at least 20% of transaction files returned for correction. Thirty percent said 30% or more did. The self-assessment ran September 10 through October 8, 2026. This is a small brokerage sample, not a title-company benchmark. It is still a useful warning about rework.

Do not start by letting an agent change records, chase documents, or send updates. Start with a 10-business-day, read-only shadow-mode pilot. The agent prepares an internal exception brief. A title professional decides whether to act.

“Shadow mode” here means observing a controlled copy of the work without changing the live workflow. It is a proposed office practice, not a released Oppy feature.

Give one oppy one job

Name the pilot oppy File Review Analyst. Its question is deliberately small:

Which sampled files need a title-team review today, and what supplied evidence supports that conclusion?

Compass and Qualia’s October title-workflow announcement describes an existing integration for ordering title work and tracking a file’s progress. Those are consequential workflow actions. Your pilot does neither. It reads an approved extract and identifies where a human should look.

Supply an internal or pseudonymous file ID, the current stage and its timestamp, and checklist states using the source system’s labels. Include the named owner, next dependency, and milestone dates only where approved. Each row needs a source record ID the reviewer can reopen.

Leave out wire instructions, identity documents, consumer financial information, raw documents, and unrestricted notes. “Interesting” is not a data-minimization policy.

For timing rules, have the source report calculate business-day age and days until the milestone using your office’s approved calendar. Do not ask the language model to improvise holidays. Put the calculated values and report date in the extract.

Make read-only an actual permission

Oppy’s public site describes connections through Zapier and Make. Its setup walkthrough describes choosing roles and supplying knowledge. Neither proves that your account has a particular title-system connection or a safe read-only configuration.

Before importing anything, verify enabled functions, data handling, and permissions in the actual account. Use an approved limited extract rather than broad live access for this pilot. Where supported, enforce read-only credentials in the connected system. Remove outbound communication and record-write permissions. Keep the output in a location restricted to the title team.

The boundary should fit on five lines:

  1. Read: only the approved sample and fields.
  2. Analyze: flag missing, stale, mismatched, or conflicting supplied evidence.
  3. Draft: internal exception briefs only.
  4. Write: no changes to operational records or calendars, and no outbound messages.
  5. Decide: no title clearance, legal advice, funds release, or closing-date commitment.

A dated Oppy Functions guide describes Public and Admin gating, an administrator allowlist, and a needs_attention pattern for pausing outgoing chat, email, and SMS pending human response. Verify current behavior before relying on it. This pilot does not assume native approval enforcement, a title integration, or automatic rollback.

The system permission is the lock. The prompt is the sign on the door.

Use this starting prompt

Replace the bracketed values with approved source names and office thresholds:

You are File Review Analyst for [Title Office].


Review only the supplied extract from [approved report] for [business date]. Do not use outside knowledge or tools. Do not request, send, schedule, submit, or modify anything.


Flag a file only when supplied fields show:


    

  1. A required checklist item marked missing, rejected, or unknown.
    2. 

  2. Stage age above [X] business days and an unresolved dependency.
    3. 

  3. Conflicting supplied status or milestone-date fields.
    4. 

  4. A milestone within [Y] business days and no named owner or next dependency.
    5. 



Use the report's calculated business-day values. If they are absent, mark timing unassessable. Do not calculate them yourself.


For each flag, return: File ID, category, exact source fields and timestamps, reason for human review, internal owner if supplied, and unknowns. If no rule applies, return no flag for that file.


Never declare a condition satisfied, a document sufficient, a file ready to close, or a party contacted. Never generate client-facing language. Missing or conflicting evidence means Human review required, not permission to guess.

The useful output is a verifiable exception. Not a fluent theory about someone’s closing.

Test the quiet failures

Choose 20 to 40 files, including ordinary work and known messy cases. Run the extract at the same time for 10 business days. These are suggested pilot parameters, not an industry benchmark.

Have a designated reviewer independently inspect the entire sample, before seeing the AI queue. Then compare the two. Reviewing only the agent’s flags cannot reveal the issues it missed.

Measure flag precision: confirmed flags divided by all flags. Measure exception coverage: independently confirmed in-scope issues raised by the agent divided by all independently confirmed in-scope issues. Record zero-denominator days as not applicable. Track total review time, not just generation speed.

Count wrong-file evidence links and invented statuses separately. Also count later-discovered issues that the stated rules should have caught. These are escapes, not “unexpected edge cases” with nicer stationery.

Stop the pilot for an unauthorized action, out-of-scope exposure, wrong-file linkage, or fabricated status. Diagnose the extract, rule, permission, or prompt before restarting. This is a human-run recovery procedure.

Earn one additional task

At day 10, retire the workflow, extend read-only review, or allow one narrowly defined internal draft task. Do not promote it because the queue looks polished.

For any future write, document the permitted field, required evidence, approver, action log, and reversal procedure. A recent OpenAI and ServiceNow workflow announcement describes a useful design pattern: customers choose available capabilities, while existing business rules and permissions govern permitted actions. That is an authorization pattern, not evidence of an Oppy integration.

The objective is a clearer morning queue, not blurrier authority. Put the agent in the lobby first. Let demonstrated usefulness earn the next door.

References