Listing Watch Agent

The first phone call wins. This is how you make it.

Real estate is a speed game wearing a patience costume. A well-priced apartment is listed at 9:14 and has twelve inquiries by noon. Our client, a real estate professional, was competing in that window with the same tools as everyone else: browser tabs, portal notifications that arrive late or not at all, and an assistant refreshing pages between other tasks. We built an agent that watches every relevant listing portal continuously, understands what the client is actually looking for, and delivers a real-time alert the moment a matching property appears. The agent watches the market. The human makes the call. In that order, always.

Hermes runtime Multi-portal monitoring Criteria profiles Telegram alerts Supabase

The listings the client needed were public. That was never the problem. The problem was time: every serious opportunity was visible to the entire market at the same instant, and the difference between winning and reading about it was often under an hour. Portal-native notifications were unreliable, filters were too crude to express what "interesting" actually meant, and no human can watch six websites at once while also doing the job the watching is for.

There was a second, quieter cost: false leads. The same property appears on three portals under three titles and two prices, posted by two different intermediaries. The team wasted attention rediscovering things they had already seen and dismissing duplicates one by one.

The brief had a hard boundary from day one, and it was the right one: watch and notify, nothing more. No automated messages to sellers, no harvesting of contact data, no outreach of any kind. The agent's job ends where the phone call begins. That boundary is not a limitation of the system. It is what keeps the client's business clean.

> profile

What the client wants is written down as criteria profiles: location, property type, price range, square footage, floor, and the softer signals, keywords in descriptions, price-per-square-meter thresholds, red flags to skip. Multiple profiles run in parallel for different acquisition goals.

> watch

The agent monitors all relevant sale and rental portals continuously, at a respectful, human-like cadence. It looks only at public listings, and it stores only what matches. It is a reader, not a vacuum.

> match

Every new listing is evaluated against the profiles. Not keyword filtering, evaluation: the agent reads the full description and checks it against what the profile means, catching matches a portal filter would miss and skipping ones it would falsely include.

> dedupe

Cross-portal fingerprinting recognizes the same property under different titles, photos, and prices. One property, one alert, with all its appearances and price points listed together.

> alert

A matching listing becomes a Telegram message within minutes of appearing: key parameters, the price across portals, why it matched the profile, and the direct link. Decision-ready, on the phone the client already has in hand.

> track

Matched listings are tracked over time. A price drop on a watched property triggers its own alert, sometimes the second look is the real opportunity.

Does

  • Watches every relevant listing portal around the clock, weekends included
  • Evaluates full listings against written criteria profiles, not just filter fields
  • Collapses cross-portal duplicates into a single alert
  • Notifies in real time via Telegram, with the reasoning attached
  • Tracks watched listings and alerts on price changes

Does not

  • Contact sellers, agents, or owners, ever, contact is a human act and stays one
  • Harvest, store, or process anyone's personal contact data
  • Republish or redistribute listing content, alerts link to the source
  • Hammer the portals, monitoring runs at a restrained cadence by design

Layer I · Visual Architecture

One diagram: portals in, profile matching, dedup, alert out, price tracking loop. And one line drawn in bold at the edge of the system: no path from the agent to any seller. The client approved the boundary before approving the features.

Layer II · Contracts

The criteria profiles are living contracts. Each one defines a goal, its hard limits, its soft signals, and its exclusions. When the client's strategy shifts, the profile is edited in one place and the watching shifts with it, no code changes, no retraining of habits.

Layer III · Technical Diagrams

Portal coverage, polling cadence, the matching pipeline, the cross-portal fingerprinting logic, and alert routing, specified before implementation. Deduplication got the most design attention: a system that cries wolf three times per property trains its user to ignore it.

Layer IV · Implementation

Hermes runtime on a dedicated isolated instance. Continuous monitoring with per-portal adapters, Supabase for listing history, fingerprints, and profile state, Telegram as the alert channel because it is where the client already lives.

runtime        Hermes
coverage       all major sale and rental portals, per-portal adapters
matching       criteria profiles, full-description evaluation
dedup          cross-portal property fingerprinting
alerts         Telegram, real-time, reasoning attached
state          Supabase (listing history, fingerprints, price tracking)

Alert fatigue

The fastest way to kill a monitoring system is to make it noisy. Profiles are precise, duplicates are collapsed, and borderline matches are labeled as borderline. The client trusts the ping because the ping earned it.

The duplicate flood

The same apartment, three portals, two prices, four days apart. Fingerprinting on property attributes rather than titles or photos keeps one property equal to one alert, with every appearance attached.

Portal changes

Listing sites change their structure without warning. Each portal adapter monitors its own health, and a portal going dark raises an alert about the coverage gap itself, silence is reported, never assumed.

Missed minutes

The value of the system is concentrated in the first hour of a listing's life. The pipeline is built for short, predictable time from appearance to alert, and its own latency is measured and watched.

Scope creep toward outreach

The tempting next step, "just have it message the seller too", was declined in design and locked out in architecture. Automated contact at scale is a legal and reputational trap. The system's restraint is a feature the client can defend in any room.

24/7

market coverage, no weekends off

< 5 min

median time from listing appearing to alert delivered

6

portals watched in parallel

~40%

of raw matches collapsed as cross-portal duplicates

first

call on multiple closed opportunities, per the client

Figures from the first months in production, latency measured end to end from listing publication to Telegram delivery.

Speed is a product you can engineer. The client's edge is not information nobody else has, every listing is public. The edge is minutes, manufactured reliably, every day, including Saturday at 7 AM when a private seller posts an underpriced apartment and the client's phone buzzes before coffee.

The boundary sells the system. "It watches but never contacts anyone" was not a compromise we talked the client into, it became the line they proudly repeat. In a market full of gray-zone automation, a system whose restraint is architectural, not aspirational, is easier to buy, easier to defend, and easier to keep.

Precision beats coverage. Early versions matched too generously, and every unnecessary alert spent a little of the system's credibility. The lesson generalizes: a monitoring agent is not judged by what it can see, but by whether its user still opens the notification in month four. Ours does, because the profile does the disagreeing before the phone does the buzzing.

The market moves at 9:14. Where are you at 9:15?

> ../book_a_call.sh