The Deal Closed. The Internet Didn’t. Build an Oppy Move-In Relay

By Anna with Oppy | October 25, 2026

In September, HousingWire reported a survey of 1,000 recent U.S. homebuyers in which 46% named uncoordinated providers as the largest transaction hassle. Another 69% expected their agent to coordinate mortgage, title or closing, and insurance.

Those figures concern the purchase, not move-in utilities. But the coordination problem does not respect a closing date. The transaction finishes. Someone still needs internet, building access, and a utility start date. Several people are “on it.” None can say what is confirmed.

Build a Move-In Relay: an AI-prepared plan that separates resident requests from provider commitments and names the human responsible for each next step. Add a second agent to challenge the plan before a person releases it. Not an autonomous concierge. A useful division of labor.

Start with the handoff, not another chatbot

Recent AI news points toward reusable procedures. On October 22, Anthropic announced the donation of its Agent Skills standard to the Agentic AI Foundation. A skill packages instructions and supporting material for a specific task. That is the useful idea here: define the job before giving an agent more freedom.

There is also a timely real estate example. In Proptech Espresso’s October 24 episode, guest Oliver Alexander described a second AI reviewing the first system’s work:

“we have adversarial agentic review”

Oliver Alexander, episode transcript, 31:48.

That is a process description, not evidence of error-free output. For move-in work, borrow the review lane. Keep final authority with a human. Two agents agreeing does not make a missing confirmation appear.

Oppy’s public platform description supports launching and managing dedicated AI agents and connecting with existing tools. The relay below is a proposed operating specification, not a claim that Oppy includes native multi-agent routing, provider booking, approval enforcement, or these particular integrations. Have a person transfer the drafts between agents until your actual configuration is tested.

Give “confirmed” a stricter definition

Use five states. Requested means the resident asked for help. Draft means an agent prepared something and nobody sent it. Pending confirmation means an authorized request exists, but the service start or appointment lacks verified evidence. Confirmed requires a human-recorded provider, date or window, proof source, and verifier. Blocked means information, permission, ownership, or evidence is missing or conflicting.

Every service card gets one human owner. “The team” is not an owner. It is a weather system.

A confirmation also needs a checked-at timestamp. If possession timing changes, yesterday’s green card may need to become pending again. This extends the distinction between proposed workflows and actual product capabilities made in Oppy’s recent configuration-release article.

Agent one: prepare the move-in plan

Create a dedicated Oppy agent where supported by your account. Give it this draft-first specification, adapted to your approved systems:

ROLE: Move-In Relay. Prepare one residential move-in plan.
Do not take external actions.


INPUTS: Human-verified possession window; services the resident
requested; approved contact channels and consent status; permitted
property/unit details; human-selected providers; preferred service
windows; named human owners; source records and timestamps.


OUTPUT: One card per requested service or access step:
service | state | human owner | resident decision-maker |
next action | due date | evidence source | checked-at time |
missing information | what must be verified before release.


RULES:


    

  1. Never send, order, book, cancel, modify an account, or commit funds.
    2. 

  2. Never infer consent, provider selection, account authority,
availability, pricing, or possession timing.
    3. 

  3. Never request or retain passwords, payment-card details,
security answers, door codes, or account credentials.
    4. 

  4. Use Confirmed only when a human supplied the provider,
date/window, proof source, and named verifier. Preserve that source.
    5. 

  5. Mark missing or conflicting essentials Blocked. Ask the human
owner a precise question. Do not invent a service to fill a blank.
    6. 

  6. If possession changes, flag affected confirmations for rechecking.
    7. 

  7. Label every resident-facing message DRAFT. Escalate requests
involving money, identity checks, credentials, or commitments.
    8. 



FINISH: What is confirmed? What is pending? Who owns the next
step? What must the resident decide?

Agent two: try to break the plan

Give a separate reviewer the same permitted source records and the first agent’s output. Do not give it authority to “fix” the case by making assumptions.

ROLE: Relay Reviewer. Challenge the draft against supplied records.


For each card, identify:


    

  • unsupported confirmation or expired/conflicting evidence
    • 

  • an absent owner, consent record, or resident decision
    • 

  • a date inconsistent with possession or another service dependency
    • 

  • unnecessary sensitive data or an unauthorized external action
    • 

  • a requested service omitted from the plan.
    • 



Return PASS FOR HUMAN REVIEW or BLOCK, followed by the exact
card, supporting source, and correction needed. Never invent facts,
change source records, or contact anyone. PASS is not authorization
and is not proof that the underlying source is true.

The human owner resolves every block and independently checks consequential confirmations. A reviewer is a challenge function, not a second rubber stamp.

Test a Monday move-in before connecting anything

The resident requests internet, utilities, and building-access instructions. They have not authorized provider outreach. Internet options are Draft. Utilities are Blocked until the resident chooses a provider. Building access is Blocked pending property-manager instructions. Appliance service is absent because nobody requested it.

Now introduce a Friday-to-Monday possession change. Does the reviewer flag the earlier utility start date? Can it distinguish a provider’s “request received” email from an appointment confirmation? Does it catch a card assigned to “everyone”?

Start with ten completed cases. Count false confirmations, ownerless tasks, missed requested services, and unresolved blocks. Pilot live cases only after people can explain those failures and correct them. Keep external action disabled during this first pilot.

A closing ends the deal. The relay makes the next responsibility visible. That is a better first job for an AI employee than confidently announcing that the router is handled.

References