A technical demonstration of governed, human-in-the-loop edge-AI perimeter patrol.
“Every autonomous security robot acts on its own. Ours holds and asks.”
RynnBrain is a concept for continuous perimeter coverage at commercial sites, where the machine never takes an action on its own.
Commercial sites have areas fixed cameras cannot reach — back lots, far fence lines, unwired outdoor storage, loading docks. Coverage is bounded by where cable runs. What cannot be wired is not watched, and what is not watched leaves no record.
Intelligence runs on a fixed edge-AI box on site. A low-cost robot dog patroller acts purely as an actuator, carrying a camera into the gap. Every event runs through the same loop, and the loop stops at a human before anything happens.
An unsupervised machine making decisions on a property is an exposure, not a safeguard. Requiring human authorization before any response is the point of the design — it is what makes the resulting record meaningful, and what the value actually rests on.
The system never acts autonomously. Detection escalates to a person; nothing executes without an explicit human decision.
Inference happens on the local edge box. No cloud dependency for the perception or decision path, and video need not leave the premises.
Authorization reaches the operator wherever they are, as a notification on their phone. Who approved, in what role, and when are treated as part of the event itself — not as logging bolted on afterwards.
Every event produces a timestamped audit log entry recording what was detected, how it was verified, and who authorized the response — a first-class artifact, not a by-product.
A single event, end to end — from the patrol noticing something to the audit log entry being written.
The scenario: after hours at a distribution yard. The robot dog patroller is walking its route along the back-lot fence — an area no fixed camera covers — when it sees something. Watch the loop below run once through, end to end.
Step 06 produces an artifact. This is an example of the authorization record the loop above generates — the chain of causation behind a single held event.
These are the two components the demonstration is being built toward. They are a target platform for the concept — not a finished, integrated product, and not a system available to buy.
An edge-AI box that enables real-time vision-language model execution on-site. It carries the perception and governance stack: on-device inference, camera ingestion, and the authorization workflow. This is where the reasoning happens and where the audit log entry is produced.
A deliberately low-cost commodity actuator. Its job is to patrol, to carry a camera into the places fixed cameras cannot reach, and to execute an authorized response. It holds no decision authority of its own — the intelligence stays on the fixed box.
The stack behind the demo above: on-device vision-language inference paired with a real-time operator surface, communicating over a local WebRTC link.
The on-site compute for perception and reasoning — running locally, with no cloud service in the decision path.
NPU-accelerated vision-language inference, exposed over a standard chat-completions REST API. Open-weight vision-language models run locally without an internet connection.
Several camera streams processed together — fixed perimeter cameras alongside the camera carried by the robot dog patroller. This is what makes cross-verification from a second viewpoint possible.
Real-time video, audio, and data channels between the operator console, cameras, and robot dog patroller. Sub-second latency, carried on the local network.
Multi-agent workflows built on an agent framework, with the authorization step modelled as an explicit gate that the workflow cannot proceed past on its own.
Capabilities extended through Model Context Protocol tools, so site systems and data stores can be connected without changes to the core reasoning loop.
Open-source vision-language models can be fine-tuned on domain-specific data, so detection and description reflect what actually matters at a given kind of site.
Components ship as containers behind a gateway service, which keeps the demonstration environment reproducible.
Constraints on model output, kept separate from the authorization gate — guardrails shape what the system says, human authorization governs what it does.
The human side of the loop — where an event is presented, held, and either authorized or declined. A thin client: responsive enough for real-time interaction, with no heavy processing of its own.
Where hold-and-ask becomes visible. An escalated event is presented here and pushed to the operator's phone as an authorization notification, then waits — declining is as much a recorded outcome as approving.
Face recognition running on the console itself establishes who is at the panel, so an authorization can be attributed to a person and a role. Processed on the device.
A real-time operating system gives consistent, predictable response times — useful when the interface is the thing standing between a detection and an action.
Hardware video encoding for WebRTC streaming, so camera feeds and the robot dog's view can be reviewed live before a decision is made.
Dual-core RISC-V running at up to 400 MHz, built for HMI workloads with rich I/O rather than general-purpose compute.
Available I/O for additional sensing — 60/77 GHz radar for 3D person sensing, additional cameras, or bus protocols such as RS-485.
Demonstration architecture — the operator console and the edge-AI box exchange audio, video and text over the local link, with the robot dog patroller as the mobile camera and actuator on that link.
Site types with large outdoor footprints and coverage gaps fixed cameras cannot close. These are candidate environments for the concept — none of them are deployments.
Large outdoor footprints with trailer parking, gates, and fence lines well beyond the reach of wired camera coverage.
Long drive aisles and outdoor unit rows where continuous coverage is difficult and after-hours activity typically goes unwitnessed.
High-value assets parked outdoors across an open lot, with perimeters longer than the camera runs that serve them.
Open lots where inventory sits outside overnight and the back rows are the least observed part of the site.
Loading docks, side yards, and outdoor storage — the areas around a building rather than inside it.
Common questions about the concept and the demonstration.
No. RynnBrain is pre-launch. What this page shows is a concept and a technical demonstration of the underlying loop. There is no shipping product, no deployment, no pilot programme, and no results to report. Anything on this page describing site types or hardware describes intent, not something already delivered.
No — that is the whole point of the design. The robot dog patroller is an actuator. It patrols, carries a camera, and executes a response that a person has already authorized. Detection and reasoning happen on the fixed edge-AI box, and the loop deliberately stops and waits while an authorization notification goes to the operator's phone.
The distinction matters because an unsupervised machine taking action on a commercial property creates exposure rather than removing it.
Before an event is escalated to a person, the system seeks confirmation from a second viewpoint — for example a fixed perimeter camera confirming what the robot dog's camera reported, or the reverse. The intent is to reduce the number of times an authorization notification lands on someone's phone for something that isn't real, so that an escalation carries weight.
The perception and decision path is designed to run on-premises. Inference happens on the local edge box, and the console, cameras, and box communicate over the local network — so video need not leave the site for the loop to function.
Connectivity would be optional and relevant to things like remote access or software updates, not to detection or authorization.
Three reasons. Continuous video against a cloud API means continuous per-query cost, which scales badly for something meant to watch a perimeter all night. Round-trip latency sits in a loop that may need to respond quickly. And continuous outdoor video from a commercial site is exactly the kind of data an operator has good reason to keep on their own premises.
Running the model on the edge box addresses all three at once.
They are optimized for different jobs. The console handles display, touch, camera, audio, and real-time interaction on an RTOS, where predictable sub-millisecond response matters. The edge box handles compute-intensive work — running vision-language models, reasoning over multiple camera streams — on ARM64 Linux with NPU acceleration.
Keeping heavy compute off the interface is what lets the interface stay responsive.
Yes, in principle. Open-source vision-language models can be fine-tuned on domain-specific data, and retrieval over site-specific context can shape how events are described. A vehicle lot and a self-storage site care about different things, and the descriptions attached to a record should reflect that.
If you work with commercial sites, build in this space, or just want to understand the approach, get in touch.