hikari-core
The durable event orchestration layer. It receives operator messages and device events, stores state, routes work to the right group, manages queues, and returns final analysis to the channel.
Back to projects 
Hikari
AI agent for OTDR monitoring
An agentic monitoring loop for dark fiber faults.
Hikari connects three important pieces: hikari-core for durable event orchestration,
hikari-connect for ALM/OTDR device access, and an external LLM provider for reasoning.
Together they let an agent investigate alarms, compare traces, and return an
operator-ready analysis.
system
The moving parts
Hikari is built around clear operational boundaries. Device events and operator messages
are handled as durable work items, agent reasoning is delegated to an external provider,
and all ALM/OTDR interaction passes through hikari-connect.
hikari-connect
The MCP bridge for ALM/OTDR devices. It exposes device operations as tools: ports, alarms, logbook, fingerprints, measurements, trace download, fault analysis, and generated diagrams.
External LLM provider
The reasoning layer used by the agent runtime. Hikari keeps model reasoning separate from event storage and device access, so the provider can be hosted or local.
Isolated agent runtime
Per-group agent execution with isolated sessions, mounted context, logs, skills, and IPC. The runtime lets investigations run with a controlled operational scope.
Operator and event channels
Telegram and Slack carry operator requests and reports. SNMP traps enter as fiber monitoring events, so human requests and device alarms follow the same durable workflow.
ALM device boundary
Physical ADVA/ADTRAN ALM devices and demo/test simulators are accessed through hikari-connect. Authentication, sessions, device APIs, and command status stay behind the tool boundary.
runtime flow
From alarm to analysis
An ALM trap becomes a durable incident workflow. hikari-core wakes the correct
group, the agent runtime uses an external LLM provider for reasoning, hikari-connect
queries the ALM/OTDR layer, and the result returns as structured incident evidence.
- SNMP parser extracts device, port, action, alarm name, and severity.
- SQLite stores messages, cursors, registered groups, sessions, and scheduled tasks.
- The queue bounds concurrency and retries failed processing without duplicating already-sent output.
- The agent uses hikari-connect MCP tools to inspect alarms, run measurements, download traces, and generate diagrams.
implementation model
Built for monitored infrastructure
Event-driven by default
Alarms and operator requests become durable messages before any agent work starts. That keeps investigations recoverable, traceable, and safe to retry.
Tool access over direct control
The agent uses defined MCP tools to inspect ports, run measurements, compare traces, retrieve evidence, and build incident output.
Clear responsibility boundaries
hikari-core owns orchestration and delivery, hikari-connect owns ALM/OTDR access, and the LLM provider owns reasoning and report synthesis.
Scoped agent execution
Groups run with their own sessions, context, logs, and tool scope so production monitoring, demos, and tests do not blend state.
Repeatable validation
The simulator can create realistic device states and fault scenarios so the same workflow can be demonstrated and tested without physical hardware.
demo and testing
Simulator-backed validation
Hikari includes an ALM/OTDR simulator for demos, integration testing, and repeatable development when physical devices are not available. It can emulate ports, monitoring cycles, OTDR traces, alarm transitions, and fault scenarios so the same core/connect/LLM workflow can be exercised end to end.
- Demo environment for showing an alarm-to-report workflow without a physical ALM shelf
- Test scenarios for fiber breaks, bends, cable pulls, and gradual degradation
- OTDR trace generation with connectors, attenuation, reflectance, end-of-fiber events, and noise
- Monitoring cycles with history rows, thresholds, alarm transitions, and queued fault analysis
- ALM-like UI and state model for exercising hikari-connect against realistic device behavior
example output
Fiber-break analysis output
This example shows the kind of data the Hikari agent can provide during a fiber incident: route context, fault classification, OTDR trace comparison, likely fault location, signal-loss evidence, and dispatch-ready conclusions.
Open full sample reportReport facts
Report ID
FLR-MCH-1-3-20260216-00001
Port
MCH-1-3 / Port 3
Port name
FTTH feeder - mixed build
Detected fault
fiber break at 5.0 km (+/-50 m)
Link loss
100.00 dB
Fault loss
93.86 dB
Signal beyond fault
none, noise floor only
The comparison overlays a healthy baseline trace with the fault-analysis trace. The current trace follows the baseline until the 5.0 km failure point, then drops to the noise floor. The baseline continues toward the known end-of-fiber event at 19.6 km, making the break location and service impact visible at a glance.