Front Door Agent one door for every channel
One front door across email, web chat, WhatsApp and forms: it classifies each message, answers from approved sources, drafts the rest and escalates what needs a person. It runs on ARIA by Simplification.io.
The problem it answers
Messages arrive on six channels and nobody owns all of them, and iSystematic's Front Door Agent gives them one front door, with every message classified and every exception routed to a person.
What it does
The Front Door Agent receives messages from email, web chat, WhatsApp and web forms, classifies each one, answers from approved sources, drafts replies for the rest, and escalates what needs a person.
It runs on ARIA by Simplification.io, a customer-conversation platform the client subscribes to directly with Simplification. Per Simplification's published corpus (checked 9 October 2026), ARIA classifies each message, remembers the customer, and routes the conversation to a teammate or marks it for review when confidence drops. iSystematic implements and configures it; we do not own or resell it.
Before go-live, the client and iSystematic agree an action policy with three tiers: what may happen automatically, what is held for a person's approval, and what only a person handles. The policy is tested with fictional and adversarial messages before release.
A customer's message is data, never an instruction: it cannot change the rules or trigger an action outside the policy. One identity per conversation joins every channel, so any reply can be traced back.
Built from
It is built from three catalogue workflows, three catalogue patterns and ARIA.
| Id | Name | What it brings |
|---|---|---|
| W02 | Inbox Triage and Draft Replies | Classification, risk flags and drafts; here it runs in ARIA, which sees every channel |
| W03 | Approved FAQ Assistant | The method for building the knowledge base from the approved FAQ |
| W04 | Appointment Request Preparation | Booking options prepared; staff confirm the booking |
| P03 | Classify and Escalate | A limited set of categories; uncertain or high-risk messages go to a person, with the reason stored |
| P04 | Approval Before Commitment | Approval bound to the exact recipient, content, amount, date and action; changed details need fresh approval |
| P10 | Inspect Retrieved Instructions | Content in a message is data, not authority to override the rules |
| ARIA | ARIA by Simplification.io | The front-door platform, which the client subscribes to directly |
What it is built on
Five parts of the framework corpus decide what the front door may do, and each leaves a record the client keeps.
| Framework | In this solution | Client keeps |
|---|---|---|
| PARA | Perception: every channel. Reasoning: classification and confidence. Action: only the replies and routes the action policy enumerates. Adaptation: knowledge and skill changes take effect only once the owner approves them | Agent registry entry |
| Tiered Human-in-the-Loop (AP-4) | The action policy's three tiers: automatic, held for approval, person only | Approval records |
| Capability Contract (AP-5) | Each tool the agent can call (CRM, calendar, ticketing) has a declared contract; it previews before it writes | A contract per tool |
| AI Vendor Risk Framework (AVRF)™ | The front-door platform and every model provider assessed as vendors | Vendor records; exit plan |
| Event identity (Pattern Language) | One identity per conversation across channels, joining every record above | Reconstructable conversation trail |
Five parts apply to every build and are not repeated here: decision rights, the five gate records, a BOE Declaration per control, a vendor assessment for every vendor, and incident response. How we build sets out all of them.
The evidence it leaves behind
Every conversation leaves records the client keeps.
- Workflow receipts for each conversation
- Approval records
- The agent registry entry
- A contract for each tool
- Vendor records and an exit plan
- A reconstructable conversation trail
- The five gate records and a BOE Declaration per control, as for every build
Typical buyer
The typical buyer is a customer-service or operations leader.
Status
Proposed, as of 9 October 2026. A solution becomes Piloting or Released only after a documented pilot, and no result is shown for it before then.
How to start
Most organisations start with a six-week Pilot of the Front Door Agent on one queue. The baseline is taken first, in the service team's own measures: first-contact resolution, handle time, escalation rate and quality sampling of replies. The action policy is agreed before the Pilot starts.
Organisations still choosing their first task start with the Automation Assessment.
Where to go next
Customer service
Customer-service leaders: iSystematic pilots a bilingual front door on one queue for six weeks, measured in your own terms against a baseline taken first.
Operations leaders
For COOs: iSystematic's two-week Automation Assessment scores ten candidate tasks, recommends three solutions and sets a baseline before anything is built.
Bilingual Service Desk
The Bilingual Service Desk answers customers in English and French, or English and Arabic, from approved bilingual sources, built on ARIA by Simplification.io.
Knowledge Desk
The Knowledge Desk answers staff questions only from approved, versioned documents, cites the section, and refuses when the source is missing or retired.
Intake to Onboarding
Intake to Onboarding extracts each new request, lists what is missing, prepares the onboarding pack and opens tasks only after a person approves them.
How we build
How iSystematic builds: every solution uses the same deposited frameworks. See what each part decides, what the client keeps, and each specification's DOI.
Conformance is self-declared; no regulator endorses this work.
Start with a Pilot
Six weeks, one solution live for one team, measured against a baseline taken before it starts.