How it works
Every step either produces an answer or stops and tells you why.
Most of what goes wrong in an automation is not a crash. It is a place the system stayed quiet when it should have spoken. This is the shape of every system we build, and what each stage does when it fails.
The same shape every time. Only the configuration changes.
-
Capture
Information arrives — a form, an email, an SMS, a phone call, a document, an API — and becomes one durable record before any external call is attempted. If a provider is down, a key has expired, or the process dies mid-flight, the work still exists.
Fails: never silently. The record exists before anything can go wrong. -
Understand
The model reads what was actually written the way a person would: what is being asked for, how urgent it is, what is missing, what the details imply. Keyword rules catch the obvious field and miss everything that decides what to do next.
Fails: to a named person at your business. Never to an automated guess. -
Decide
Your business rules and the model's reading together, not as alternatives. A deterministic floor runs underneath the model: anything where being wrong is expensive is caught by a rule and never left to a model's judgement. The model handles everything the rules do not cover.
Anything ambiguous goes to a person rather than to a default. -
Act
Update the CRM, reply to the customer, send the notification, book the time, generate the document, escalate to a human, trigger the next internal step. Into the systems you already run, in place — there is nothing new to log into.
Client-facing messages send from your account, in wording you approved. -
Track
Every stage logged, failures surfaced rather than swallowed. When something needs checking there is a trail instead of a reconstruction from memory.
The failure count is a monitored number, not a debugging convenience.
A voice track read over the film, served from this site. Nothing is sent anywhere, and the film stays silent unless you ask for it.
Read the film as text
- 9:40 pm. Your office closes. Inquiries don't.
- Web forms, missed calls and a voicemail arrive overnight. Every inquiry becomes a record.
- Checked. Phone number is real. Email is deliverable.
- Screened. Contact list searched for the opposing party. 0 matches.
- Understood. Family law. Berrien County. Urgent.
- Filed. Written to your case system, reasoning attached.
- You get one line: “Call back today. Family law, served today. Opposing party: 0 matches.” They get a booking link: “Thanks, Jordan. We have your message. Pick a time that works for you.”
- When something's off, it stops: “Opposing party matches a contact. No reply sent. Review before contacting.” And tells you.
- It fails toward you. Never toward your client.
Four mechanisms, in the order they matter.
A client is buying the confidence that a message arriving at 11pm is handled the same way as one arriving at 11am. These exist to make that defensible rather than aspirational.
- Durability first. Every stage becomes a stored record before any external call. A lead is never lost, only delayed.
- Bounded retry. Failures retry on an escalating ladder — one, two, four, eight, then sixteen minutes — which covers virtually every transient outage without hammering a struggling provider. A bad request or a revoked credential fails immediately rather than retrying five times against a fault that will not resolve on its own.
- Dead-letter and notify. Work that exhausts its retries is written aside and we are emailed. Nothing fails silently.
- Recovery on restart. Jobs left in flight by a crash or a deploy are requeued at boot. The failure mode of a restart is a delay, not a loss.
The claim we make, and the one we do not
We claim: no message is lost, failures are visible, and a failure parks work for a human rather than guessing.
We do not claim uptime percentages, response-time guarantees, or anything derived from a vendor's status page. We do not control the platforms underneath us, and a promise built on somebody else's availability is one we cannot keep.
On the sentence “couldn't check”
A retry that resumes past a failed lookup returns zero matches, and zero matches reads as cleared. Those are opposite answers. An error that stops the run and parks the record is correct behaviour; quietly continuing with a comfortable default is not. We hold that line in the code, in proposals, and on this page.
One of these running in production today.
A solo law practice in Southwest Michigan, live since 27 August 2026. The client is not named here, and will not be until they have given written permission — the system handles confidential prospective-client information, and consent has not been asked for.
An enquiry arrives on the firm's website. In about a minute, without anyone touching a keyboard, the system:
- verifies the phone number and returns whether it is mobile, landline or internet
- verifies the email address is deliverable
- searches the firm's existing contacts for the named opposing party, and reports the count and the names
- reads the description to determine practice area, county, jurisdiction, urgency and completeness
- writes a scored record with eight custom fields into the firm's case management system
- notifies the attorney with one plain-English outcome line
- replies to the client with a booking link — or, on a flagged match, sends the client nothing at all and tells the attorney why
That last branch is the whole design in one sentence. Silence toward the client is the correct output when a safety check has not resolved, and the alert goes to the person who can act on it.
What this is not
It is not a case study and there are no results on this page. Eleven real enquiries since 3 September is a small sample, and we have not verified that every one of them reached the attorney — it demonstrates the system works, not that it is proven. Two consultations have been booked and neither has yet been held. We would rather show you the thing running, live, on a call than quote you a number that has not earned its place.