Select a problem. Watch the architecture assemble.
Four problems most organizations actually have. Pick one and the system that answers it is built in front of you, component by component. Open any component to inspect what it does, what it is allowed to do, and how it fails.
FOUR REFERENCE ARCHITECTURES
Inbound capture, qualification and scheduling
The problem. Enquiries land in an inbox, a form, a voicemail and a DM. Some get answered in an hour, some in a week, some never. Nobody can say which, because there is no single place the answer lives.
What changes. Every enquiry is captured to one record within seconds, qualified against written criteria, and either scheduled or routed to a named person. Response time becomes a number somebody owns.
- TRIGGER — Enquiry received. Form submission, inbound email, phone transcript or message. The trigger normalises all four into one event shape so the rest of the chain does not care where it came from. Inputs: Web form, IMAP/API mailbox, telephony transcript, messaging webhook Latency: Event queued on receipt; no polling interval to tune Failure mode: Unrecognised source is queued for a human rather than dropped
- AGENT — Intake agent. Reads the enquiry and extracts the fields a human would have typed: who, what, where, budget signal, urgency signal, and which of your services it touches. It writes what it found and what it could not find. Reads: Message body, attachments, prior thread history Writes: Structured intake record plus a confidence note per field Boundary: Extracts and proposes. It does not reply to the customer.
- TOOL — CRM write. The intake record is written to the system of record you already use. If a matching contact or company exists it is attached rather than duplicated. Targets: Whatever CRM is in place — the integration is a connector, not a migration Idempotency: Keyed on source message ID; a replay updates, it does not duplicate Fallback: If the CRM is unreachable the record is held and retried, and the queue depth is visible
- AGENT — Qualification. Scores the enquiry against criteria you wrote down — service fit, geography, size, timeline. The criteria are configuration, not model behaviour, so changing them is an edit rather than a retraining exercise. Method: Deterministic rules first; the model handles the language, not the decision Output: Tier, matched criteria, unmatched criteria, and the reason in plain sentences Auditability: The rule version that produced the score is stored with the score
- APPROVAL — Human gate. Anything above the threshold you set stops here and waits for a named person. Below it, the routine path continues. This gate is not optional and cannot be automated away by the system itself. Waits for: A named approver, or a deputy after a timeout you configure Surface: Email, chat or dashboard — approval is one click plus an optional note On timeout: Escalates. It never auto-approves.
- ACTION — Response and scheduling. The approved path sends the reply and offers real availability from the real calendar. A booking writes back to the CRM record it came from. Sends: Templated reply with the agent's draft in it, edited or accepted by the approver Calendar: Live availability, not a static link, with buffer rules honoured Guarantee: One enquiry cannot produce two outbound replies
- RECORD — Audit trail. Every step above writes an immutable line: what fired, what it read, what it decided, who approved it, what was sent. The trail is the product as much as the automation is. Contents: Actor, input hash, decision, approver, output, timestamp Retention: Set by your policy, not by the tool's default Access: Readable by the operator without an engineer present
- VERIFICATION — Did it actually work. A scheduled check measures the thing the system exists to fix: time to first response, percentage captured, percentage qualified, percentage that reached a human when they should have. If the numbers move the wrong way, that is a report, not a silence. Measures: Capture rate, time to first response, gate throughput, error and retry counts Cadence: Continuous collection, reported on the interval you choose Consequence: Thresholds raise an alert to a person; the system does not grade itself
One set of numbers, assembled on a schedule
The problem. Finance has one revenue figure, the CRM has another, the spreadsheet has a third, and the monthly report has a fourth. Meetings get spent reconciling rather than deciding.
What changes. One modelled layer both people and machines read from, built on a schedule, with every figure traceable back to the system it came from.
- TRIGGER — Scheduled build. The pipeline runs on a clock and on demand. A failed run is loud; a skipped run is impossible to miss. Cadence: Configurable — hourly through daily is typical On failure: Last good state is preserved and the failure is reported; stale data is labelled stale
- TOOL — Source extraction. Reads from each system through its API rather than through exports someone remembers to run. Extraction is read-only by design. Sources: Accounting, CRM, operational tooling, spreadsheets that are genuinely the source of truth Permissions: Least privilege, read scope only, credentials in a managed secret store Change handling: Schema drift raises an error rather than silently producing nulls
- DATA — Modelled layer. Raw extracts are kept untouched; the model is built on top of them. When a definition changes — what counts as an active customer, say — the definition changes in one place and everything downstream follows. Shape: Raw landing → conformed entities → reporting model Definitions: Version-controlled, reviewable, and named in the output Reprocessing: Any past date can be rebuilt from raw without touching a source system
- DATA — Quality tests. Tests run before anything is published: row counts inside expected bands, no orphaned keys, no duplicated identifiers, totals that tie to the source. A failed test blocks publication. Tests: Uniqueness, referential integrity, freshness, volume, and reconciliation to source totals On failure: Publication halts; the previous model stays live and labelled as of its date
- ACTION — Publication. One modelled layer feeds the dashboard, the report, the export and any agent that needs to reason over the business. Nothing downstream re-derives its own version. Consumers: Dashboards, scheduled reports, agents, exports Contract: Consumers read the model, never the raw sources
- RECORD — Lineage. Every published figure can be traced to the rows and the source systems it came from, at the version of the definition that produced it. Granularity: Column-level lineage from report back to source field Use: An unexpected number becomes a five-minute question, not a two-day investigation
- VERIFICATION — Reconciliation report. A standing report compares the modelled figures to the source systems and shows the variance. A variance of zero is a result you can show someone; an unexplained variance is a finding. Cadence: Every build Output: Variance by measure and by source, with the threshold that makes it an exception
Governed execution — automation that still asks
The problem. Either everything waits on one person's inbox, or the automation was given the keys and now nobody is sure what it is authorised to do.
What changes. Routine work runs unattended. Material work — money, contracts, external sends, irreversible changes — stops at a named human, and the record shows who decided what.
- TRIGGER — Proposed action. An agent or a workflow proposes something. Nothing is executed at this point; a proposal is a record, not an act. Contains: The action, its inputs, its predicted effect, and its reversibility Rule: A proposal with no classified risk tier cannot execute at all
- DATA — Risk classification. Each action carries a tier set in policy, not by the model: reversible and low-consequence, consequential, or material. Money, contracts, regulated claims, external communication and destructive infrastructure changes are material by definition. Tiers: Routine · Consequential · Material Authorship: Policy is written by the operator and version-controlled Escalation: Ambiguity resolves upward, never downward
- APPROVAL — Named approver. Consequential and material actions route to a person with the authority to approve them, with enough context to decide in under a minute and enough detail to decide properly. Shown: What will happen, to what, on whose behalf, and what undoing it costs Options: Approve · Approve with edit · Decline with reason Never: The system cannot approve on the approver's behalf under any condition, including timeout
- ACTION — Scoped execution. Execution runs with the narrowest credential that does the job, against the exact payload that was approved. An approved proposal that changes before execution is void. Credentials: Per-action scope, short-lived, never shared between tiers Integrity: The executed payload is hashed against the approved payload Blast radius: Rate and volume limits per action type
- RECORD — Decision log. Proposal, classification, approver, decision, edit, execution result. Written once, not editable afterwards. Immutability: Append-only Answers: Who approved this, when, on what information, and what happened next
- VERIFICATION — Reversal path. For every material action there is a defined way to undo or contain it, tested before the action is allowed to run unattended. Requirement: No reversal path, no unattended execution Tested: The reversal is exercised in staging, not assumed
Observability over an agentic system
The problem. Something is running. It mostly works. When it does not, the only evidence is a customer complaint, and the only fix is someone reading logs for an afternoon.
What changes. Every run is visible while it happens and reconstructable afterwards, in language an operator can read without an engineer translating.
- TRIGGER — Instrumented run. Every run carries an identifier from the first event to the last. A question about an outcome resolves to a single trace. Correlation: One ID across every service, agent and tool call in the run
- AGENT — Reasoning capture. What the agent read, what it chose, and which tool it called are captured as structured events — not free text buried in a log line. Captured: Inputs, tool selection, arguments, result, retry count Excluded: Sensitive payloads are referenced by hash, not copied into telemetry
- DATA — Telemetry store. Traces, metrics and events land in one store with a retention policy, so the record still exists when the question arrives three weeks later. Retention: Set by policy; long enough to answer a complaint Cost control: Sampling on routine paths, full capture on anything gated
- ACTION — Operator view. A view built for the person running the business, not the person running the cluster: what ran, what it did, what is waiting on a human, what failed and what it cost. Reads: Run status, queue depth, gate backlog, error class, spend Standard: Legible without an engineer present
- RECORD — Replay. A past run can be reconstructed exactly: same inputs, same decision points, same outputs. This is how a disputed outcome gets settled. Determinism: Inputs and tool responses are recorded, so a replay does not re-call the world Use: Incident review, dispute resolution, regression testing
- VERIFICATION — Standing checks. Health checks run against the behaviour that matters — gate latency, failure rate, drift in how often the agent asks for help — and alert a person when they move. Watches: Error rate, gate latency, escalation rate, cost per run Alerts: To a person with a name, not to a shared inbox
These are reference architectures — the shape of a system we would build, described honestly. They are not records of delivered engagements, and no client, deployment or result is implied by any of them.
