Horizon

Traditional monitoring platforms are built around a simple model: software generates alerts and humans investigate them. Horizon explores a different one: software investigates first and humans supervise the exceptions.

From telemetry to understanding

Large fleets generate millions of GPS positions, and almost all of them are completely normal. Sending every coordinate to a model would be expensive, slow and pointless. Horizon uses a layered architecture where deterministic systems identify what might actually matter before any reasoning happens.

1. GPS devices
2. Telemetry ingestion
3. Rules / algorithms / ML deterministic pre-filter
4. Interesting events
5. Horizon
6. AI investigation
7. Operational insight

Detectable situations include route deviations, unexpected stops, speeding, geofence events, fuel anomalies, abnormal driver behavior, device anomalies and repeated operational patterns.

Example

1. 14:21 left assigned route +6 min
2. 14:27 stopped unexpectedly +19 min
3. 14:46 returned to route +5 min
4. 14:51 speeding detected

A traditional platform shows four separate alerts. Horizon answers a more useful question — what actually happened? — by pulling the assigned route, recent positions, historical behavior, driver record, previous incidents, nearby geofences and trip context before reasoning:

Vehicle 3842 deviated 4.3 km from its assigned route at 14:21 and remained stopped outside the expected corridor for approximately 18 minutes. The vehicle later returned to its route. Similar behavior has occurred three times during the last 30 days.

The goal isn't to detect events. It's to understand them.

Specialized agents

Horizon is built around specialized agents rather than one general-purpose assistant.

• Supervisor Coordinates investigations, interprets requests, routes to specialists
• GPS Specialist Positions, trips, routes, geofences, movement patterns, historical telemetry
• Safety Officer Driver behavior, safety incidents, operational risk

Conversational operations

Instead of navigating dashboards and manually correlating information, operators ask directly:

• Why is unit 3842 stopped?
• Which vehicles left their assigned routes today?
• Has this driver done this before?
• Summarize the most important incidents from this morning.
• Which drivers are showing unusual behavior this week?

Answers reach people where they already work — web, WhatsApp, Telegram, SMS and real-time notifications — rather than requiring them to watch another dashboard.

Engineering notes

The interesting work here wasn't prompting; it was treating the agent layer as an engineering problem.

• Model selection by benchmark, not by leaderboard. I ran my own evaluation for the intent-classification cascade and landed on a regex pre-filter in front of a mid-size classifier — the long tail of trivial intents never reaches a model at all.
• Latency down from ~25s to ~8.9s, with a significant reduction in token spend, by restructuring the agent graph rather than swapping to a faster model.
• Multi-tenant and white-label from the ground up, since the same system serves distributors and their downstream customers.

Stack TypeScript · Go · Hono · Mastra · PostgreSQL · TimescaleDB · Redis · Centrifugo · React · TanStack · LLMs · WhatsApp Cloud API · Telegram · SMS