BEACON — the Inbound Lead Agent, end to end

The agent is the easy part. The foundation underneath it is the work.

BEACON is a genuinely small piece of software: one Edge Function, one or two LLM calls, a decision table, an email. If the only question were "can we build the agent," the answer is yes, quickly.

That is not the question. The question is whether the agent's answer is worth anything — and that depends entirely on whether the account and contact data underneath it is clean, current, resolved and complete. An agent that confidently routes a lead to the wrong rep, or greets a five-year customer as a cold stranger, is worse than no agent at all, because now it is wrong at machine speed and nobody is checking.

So this page deliberately spends eight of its nine phases on the foundation and one on the agent's actual decision. Every amber and red marker below is a place where BEACON's answer would currently be weaker than it should be. Some are being fixed right now in the data-cleanup work; some nobody has looked at yet. All of them are named, because the entire point of choosing this as the first joint build is to see exactly where the floor is before we put weight on it.

Answer fast on what you know; get complete later

Fast path (meets the KPI). A HubSpot-native webhook fires the instant a form creates or updates a contact, straight at BEACON — bypassing both nightly syncs entirely. BEACON attempts an immediate synchronous identity lookup: exact email against the contact map, exact domain against known companies and aliases. If it resolves, pull the full Monocle overlay and route on real relationship knowledge. If it doesn't — a genuinely new company — don't block the SLA waiting for resolution. Decide on the raw form fields plus Made's own RAG, ship the routing email, and flag the decision row for a backfill pass once the standard pipeline catches up.

Slow path (unchanged, never duplicated). The nightly sync → Transfer → MADE-ID drain → Monocle overlay stays exactly as it is, as the system of record for reporting, dedup and CRM-wide identity. BEACON only ever reads from it. It never re-implements it and never races it.

The cost of the fast path is honest: it answers with less context. A brand-new company gets a decision made on a domain and a paragraph of text, not on a scored, enriched, classified account. That's an acceptable trade for an internal routing email — and an unacceptable one for anything that writes to the CRM or contacts the lead directly. That distinction is exactly what the tier table below encodes.

What BEACON is allowed to do on its own

Made's submitted spec described these as a flat list of cases. Written as ordered tiers, the human-in-the-loop boundaries become unambiguous — and it becomes obvious which tier deserves the most scrutiny.

Why Tier 1 gets the closest watch: Tiers 3 and 4 are cheap to reverse — a human looks before anything leaves the building. A wrong Tier 1 is the only failure mode that reaches a person unreviewed. So the threshold should be biased conservatively: when in doubt, drop to Tier 2. Recommend an explicit circuit-breaker — if disagreement on Tier 1 auto-routes exceeds a set rate in any week, Tier 1 switches off and everything falls to Tier 2 until it's corrected.

Branch 1 for v1 — and it's not a compromise

Routing to a rep is the only branch where a wrong answer costs nothing external. It exercises the entire foundation above — capture, triage, recognition, admission, enrichment, mapping, the clean brief — while keeping the worst-case failure at "a colleague received an email they didn't need." That makes it the ideal instrument for measuring whether the foundation is actually sound, before anything irreversible is wired to it.

It also produces the one thing every other branch depends on and none of them can generate on their own: a corrections log. Every time a rep says "wrong territory," "we already own this account," or "this was junk," that's a labelled training example. A few hundred of those and the confidence thresholds stop being guesses. Branch 2 and Branch 4 both become far safer propositions after Branch 1 has run for a quarter — and considerably riskier before.

Everything else can be settled while building

1. Trigger speed. A real-time HubSpot webhook that meets the 5-minute KPI but needs HubSpot-side automation work and possibly an Operations Hub tier — or accept the batch path's ~24–48 hour latency and rewrite the KPI honestly. This is a business decision about how fast Made wants to answer, not a technical one.
2. How the message reaches us. Given B-01, does HubSpot start posting submissions to an endpoint we control, do we store the payload ourselves, or does BEACON reason from contact properties alone and accept a weaker input?
3. Which branch is v1. Recommendation above is Branch 1 — route to a rep. Confirm or redirect, because it changes what gets built in Creation.

Two things worth stating plainly: the territory table and rep roster already existed and closed two planned open questions outright — which is the kind of thing you only find by checking the database instead of the documentation. And the HubSpot credential that had been dead since 2026-07-09 came back today, mid-verification. Both are reminders that the fastest way to be wrong about this system is to trust a document over a query.