Autonomous & infrastructure
Webhook-driven local mirror
Ten times fewer live API calls. Sweeps query in-process at two-hundred-millisecond medians instead of crossing the network.
Read the caseAll case studies
Case study · Autonomous sweeps
Meridian Operations · high-volume inbound queueFour reasoning sweeps. Every two hours. 92% pre-handled.
The sweeps don't replace operators — they handle the predictable fraction so operators spend their time on the unpredictable. Claude classifies; a confidence floor gates the write.
0
Reasoning sweeps running on a timer
0 hr
Sweep cadence — every two hours
0.00
Minimum confidence floor before any write
Built with
The problem
60–90 minutes of triage every morning, before any decision work begins
The morning queue had a shape. The same categories every day, the same checks in the same order, the same backlog from after-hours arrivals. The cognitive load wasn't deciding what to do — it was deciding which tickets needed deciding. That shape was a candidate for a timer.
- The Monday queueTickets that landed after 5pm Friday sat until Monday at 7am. Operators spent the first two hours of every week clearing a backlog that was structurally identical to the one from the week before. The categories were predictable; the work was not.
- Live API rate limitsBefore the mirror, sweep candidates were discovered by querying the external system directly. Rate limits were per-minute. On busy mornings, sweeps queued behind each other, the limit hit at 8:04am, and the first operator action of the day was a 429 error.
- Manual document checksA document-readiness check meant opening each ticket, viewing the attachment list, cross-referencing against a required-docs checklist, and updating the status. Forty tickets at six minutes each. Operators did this before they answered a single message.
- Missed declaration datasheetsPre-arrival declaration datasheets arrived as PDF attachments in the general queue. If the sweep didn't run on time, the ticket sat. An operator caught it eventually — sometimes same day, sometimes not.
Monday 7:02am · pre-sweeps
90 untouchedDocument checkssince Friday 5pm38 tickets
ETA updatessince Friday 5pm22 tickets
Declaration detectionsince Friday 5pm9 tickets
Status routingsince Friday 5pm15 tickets
Comment dedupsince Friday 5pm6 tickets
Same five categories · every Monday~90 min triage
The pipeline
From inbox to verified record in one pass
Same six steps across all four sweeps. The schema differs per sweep; the safety pattern is identical.
01Trigger
Timer fires; enable flag checked
An Azure Functions timer fires every two hours. Sweep reads its config row first; a disabled sweep exits immediately and logs the skip reason. No deploy needed to enable or disable.
Azure Functions
02Discover
Local mirror queried, not live API
Candidate query runs against the PostgreSQL mirror — indexed columns only, no live API call. Tickets touched within 24 hours are excluded; the sweep doesn't re-check work it already stamped.
PostgreSQL
03Confirm
Live state checked before any write
For each candidate, a live Zoho API call confirms current state. If the live state differs materially from the mirror, the sweep skips and logs the discrepancy.
Zoho Desk
04Classify
Floor-gated reasoning
Claude classifies according to the sweep's schema. Each sweep has a confidence floor — 0.80 minimum, 0.99 for declaration detection. Below the floor, log but do not act.
Claude
05Act
Sweep-specific action committed
High-confidence cases receive their action: a field update, a status change, a comment write, or a downstream pipeline trigger. The action depends on the sweep.
Zoho Desk
06Log
Skip reasons and counts written
Sweep stamps the per-ticket timestamp and writes a row to the run log: scanned, updated, skipped, skip reasons, elapsed time. Operators read it from the admin panel.
PostgreSQL
Above the floor
Sweep updates the ticket; no human touched it
Classification clears the floor. Sweep updates the ticket, stamps the timestamp, and logs the action. The morning queue is shorter by one.
Below the floor
Logged for human review — never silently skipped
Classification does not clear the floor. The sweep leaves the ticket in its prior state, records the reasoning in the run log, and moves on. The ticket does not sit untouched — it is explicitly flagged for the curator.
The four sweeps
Same architecture, four schemas
One pipeline shape. Each sweep parameterizes the candidate query, the classification schema, the confidence floor, and the action.
Shipment ETA Tracker
every 2 hrFinds tickets with carrier code + reference. Queries the manifest portal. Writes ETA-derived due date and arrival date directly to the ticket.
Document Readiness Checker
every 2 hrClassifies attachments against a required-docs checklist. Updates ticket status to 'Docs Received' or 'Docs Needed'. Handles combined PDFs.
Pre-Arrival Declaration Detector
every 2 hrFinds declaration datasheets in the general queue at a 0.99 floor. High-confidence detections trigger the form-creation pipeline; borderline cases are flagged.
Submission Readiness Orchestrator
every 2 hrRoutes non-actionable categories: arrival notices to 'Post Entry,' holds to 'Hold,' inquiries to the right queue. Doesn't try to resolve — routes.
Validation review
Confidence per sweep action type
Each action type has its own floor. The comment-dedup edge is the most actively watched — a fuzzy similarity threshold sits at the boundary between under- and over-aggression.
Field-level confidence
Pass 2 — Claude self-review
HighMediumLow
Manifest ETA writeCarrier code + reference resolves to a vessel ETA
95%High
Document classificationCombined PDF parsed into checklist items
91%High
Declaration detectionDatasheet vs. non-datasheet at 0.99 floor
99%High
Status routingArrival notice → Post Entry, holds → Hold queue
94%High
Comment dedupSkip if proposed comment matches prior at threshold
65%Low
Routed to human review. Semantic similarity at the margin. Under-aggressive dedup writes near-duplicate comments; over-aggressive dedup misses genuine updates. The most actively watched edge in the system.
4 of 5 fields cleared the 0.85 threshold
model: Per-action confidenceThe stack
Boring tech, glued together well
Each vendor handles what it's best at. Aisyst owns the orchestration layer in between.
Azure Functions
Timer triggers and sweep orchestration; one function per sweep, scheduled independently
Claude
Classifies attachments, statuses, and routing decisions with confidence scoring
Zoho Desk
Source data; live confirmation read before any write commits
PostgreSQL
Mirror tables, sweep config (enable flags), per-run log with skip reasons
Microsoft Teams
Notification surface for high-priority detections that need operator eyes within the hour
Third-party logos are trademarks of their respective owners and appear here only to indicate integration.
Outcomes
What the morning looks like now
Operators arrive to a queue that contains real decisions, not classification work. The 92% pre-handle rate is the number that changed what mornings feel like.
0
Reasoning sweeps running on timer
0 hr
Sweep cadence
0.00
Confidence floor on any write (minimum)
0%
Tickets handled before operator opens morning queue
Watch confidence-floor utilization
Floor utilization is the percentage of attempted classifications that clear the floor. If it drops, the model is meeting more new patterns than it can confidently classify — new attachment formats, status combinations, carrier codes. The fix is adding examples drawn from the cases that failed to clear, not retraining anything. Audit the run log first.
Related cases