Ops Fleet

Executive Snapshot
Agent Kanban
Agent Reasoning
Audit Logs

Inspiration At Quadriga Automations we build automation for internationally-oriented SMBs, and the same pattern shows up in almost every client conversation: someone spends hours a week chasing invoices, following up on late payments, or updating account records by hand, work that's scattered across five different tools nobody has stitched together. Fortified Enterprise Fleet started as an answer to that pattern: five agents, each one owning a single piece of that workflow, with a human able to switch any of them on or off at any time.

What it does The Fleet runs five agents. Outreach-Check watches for stalled conversations and flags who needs a follow-up. Invoice generates and tracks billing documents. Payment-Followup chases overdue accounts on a schedule. Account-Management holds a delivery-status gate that blocks any downstream action until a shipment or service is actually confirmed. Analytics rolls all of it into cash-cycle and SLA reporting. All five sit on a shared Registry, Gateway, Model Armor, and Observability layer, and every decision they make gets logged to an audit trail a human can read line by line. The dashboard shows an Executive Snapshot for a fast read and a kanban board for the detail, and clicking "Why" on any card shows the exact reasoning behind that specific action.

How it was built The Fleet runs on Google Cloud: Cloud Run for the service, Firestore for state, and Cloud Scheduler firing a tick every 30 minutes so the system keeps working in the background instead of sitting frozen at whatever state it was in during the last demo. Each of the five agents reaches its decision in deterministic Python, and Gemini 3.5 Flash, reached through Vertex AI with the Google Agent Development Kit, writes the one sentence explanation that appears beside that decision in the audit log. Those sentences are written by Gemini rather than templated, and a decision of a kind already seen reuses its cached sentence so the scheduled run stays inside its request deadline. A seeded CRM dataset gives every agent realistic records to act on, simulated rather than real client history, modeled after the kind of account data our actual clients work with. Lyria generates the demo video's soundtrack and Veo contributed a short b-roll clip, both genuinely integrated rather than bolted on for a bonus point.

Challenges we ran into Two real bugs surfaced during testing, both after the system already looked done. The rate limiter passed every check we threw at it in isolation, then let all 40 requests from a rotating IP header straight through a limit built to stop at 30, because it read the wrong entry in a header a caller can freely set. We rewrote the check to walk the header chain from a trusted point instead of trusting the first entry, and confirmed the fix held on both the direct Cloud Run URL and the public vanity path, since traffic through the two arrives from different addresses and can split across separate rate-limit buckets. The second bug showed up later, in the demo video itself: a fragment of narration played, cut off partway, and then played again in full, because the audio splice reused a chunk of the original track on the assumption it was pure music, when real narration actually started 1.25 seconds into that same chunk. Measuring the actual speech content directly, instead of trusting a waveform overview, found the exact moment narration started and fixed it.

What we learned Testing at 10 concurrent requests looked clean. Testing at 20 from a single IP is what actually exposed the rate limiter bug, because that's the volume where the wrong header entry started mattering. The lesson carried into how we verify everything now: test the failure path on purpose, and verify a fix through every route a real user might actually take, including the ones that are inconvenient to test from a laptop.