System

How the layer is built.

Five layers. One governed loop. A thin adapter for every platform we write to. Built to Canadian privacy standards (PIPEDA/PHIPA-aligned), and HIPAA-aligned for US deployments. Encrypted at rest and in transit.

§ Architecture · control layer

We install a layer, we don't replace your stack.

Calls, texts and web inquiries enter through our layer. The layer applies your rules, reads and writes to your existing systems, and keeps one structured memory of your whole business. Your booking platform, calendar and team tools are unchanged.

Inbound demand

Customers

Phone callsSMSWeb inquiries
demand enters

ABI control layer

Governance · memory · intelligence

active

inbound

Voice agent

inbound

SMS agent

data

Business memory

rules

Governance engine

outbound

Lifecycle engine

outbound

Intelligence

governed actions

Your stack · unchanged

Existing systems

SquareVagaroPhorestJaneGoogle Calendar

What we do

Capture every call, govern every booking, remember every customer, run every lifecycle message. All on your existing platform.

What we don't do

Replace your booking platform, your CRM, or your calendar. Rip-and-replace isn't the deal. The layer sits above.

§ Layers · 01 to 05

Each layer is built for one job, and fully replaceable.

01

Voice, SMS, web

Interaction layer

Answers every inbound call and text, 24/7. Detects the caller's language in the first sentence and responds in that language across 30+ languages. Classifies intent before responding. Transfers live to the owner when a human conversation is needed.

Voice agentSMS agentWeb form captureIntent classifier
02

Rules, routing, capacity

Governance layer

Applies service duration, staff hours, pre- and post-buffers, staff-service eligibility, conflict rules against Google Calendar, and no-show rebooking tiers. Every booking is validated before it is written. A slot is never offered if it cannot actually be booked.

Availability engineRouting rulesBooking validatorNo-show tiering
03

Structured and persistent

Memory layer

One record per customer, written to on every interaction. Holds contact data, booking history, service preferences, preferred staff, cadence, recovery tier, and patient-submitted files (insurance, referrals, intake, photos). Never resets between sessions. Encrypted at rest and in transit.

Customer profilesService catalogBooking recordsAttached filesInteraction logs
04

Event-driven automation

Lifecycle layer

Runs the full chain from confirmation through dormancy recovery. Every message is triggered by a real event (booked, confirmed, attended, overdue) and carries a three-step delivery audit (planned → sent → confirmed). Replies stay threaded to the same conversation.

ConfirmationsReminders 24h / 2hStaff check-inReview requestsRecovery tiers 1–3
05

Competitor watchdog

Intelligence layer

Monitors nearby operators across ten structured categories. Changes are detected by hashing page state, filtered for actionability, and delivered as structured insights with a recommended response. A supporting feature, not the headline.

Page monitorGoogle Business monitorChange detectorInsight generator

§ Execution loop

Every contact runs the same governed loop.

A call, a text, a web inquiry. The path is the same: identify the customer, load what we know, apply your rules, act, and log. The loop doesn't drift. It compounds, because every pass writes back to memory.

This is why the system gets more accurate over time without manual retraining. Intelligence is a by-product of operating, not a separate effort.

Loop running · step 1 of 7

Step 01 · Contact

Call, SMS or web inquiry arrives.

  1. 01

    Contact

    Call, SMS or web inquiry arrives.

  2. 02

    Identify

    Phone number matched to a profile, language detected.

  3. 03

    Load memory

    History, preferences, files already on record.

  4. 04

    Apply rules

    Service duration, buffers, staff routing, conflicts.

  5. 05

    Act

    Booking written, transfer to staff, or escalation.

  6. 06

    Log

    Outcome and delivery audit written to the record.

  7. 07

    Compound

    Memory updated so the next call starts smarter.

§ Principles

The decisions behind the architecture.

None of this is incidental. Each principle is a trade-off we chose so the system would hold up at real volume, across real businesses, under real compliance pressure.

Adapter pattern for every platform

Each booking platform (Square, Vagaro, Phorest, Jane, Google Calendar) has a dedicated adapter. The core is platform-agnostic. Adding a new platform is a new adapter, not a rewrite.

Delivery-truth logging

Every outbound message is logged three times: as planned, as sent, and as confirmed by the provider. Silent failures are not possible. If delivery doesn't land, we see it.

Multi-client by construction

One instance serves many businesses. client_id is the universal routing key. No cross-client data is ever reachable, even by the agent, even in the same conversation thread.

Compliance-aware defaults

Built to Canadian privacy standards (PIPEDA/PHIPA-aligned), and HIPAA-aligned for US deployments. Encryption at rest and in transit. PHI handling reviewed in every adapter. Designed for regulated health environments, not retrofitted to them.

Read real state, never guess

Availability is read from the platform at the moment of the call, not a cached snapshot. Google Calendar conflicts are resolved live. The agent never offers an impossible slot.

Compounding memory

Every interaction writes back. The voice agent starts the next call with what it learned in the last one. No retraining cycle, no configuration drift.

See how this would configure for your business.

Book intro meeting