An AI agent for security camera monitoring is real or it isn't, and the test is which tier of the loop the LLM sits in.

Because compute and latency budgets at the perception tier and the planner tier are different by two orders of magnitude. The perception tier runs at the camera's frame rate, on the order of 10 to 30 frames per second per tile, multiplied by 25 tiles per device. That is roughly 250 to 750 inferences per second, all of which need to finish in under 33 milliseconds to keep up. A modern VLM call is hundreds of milliseconds end to end, sometimes seconds, and costs cents per call from a hosted endpoint. Multiply that by 750 calls per second per device and a single property runs the cost of a small SaaS company per day before any alerts fire. So the LLM cannot live in the perception tier. It has to live above it, on a much smaller stream of events the perception tier and the state tier have already filtered down to. On a real Cyrano deployment the LLM is invoked at most once per (track id, zone, transition) tuple, which on a Class C multifamily property comes out in the low double digits per camera per day, not 750 per second.

Three different things, and the marketing copy almost never tells you which one. The first is a CNN object detector with a chat interface bolted on top so an operator can ask 'show me people near the gate after midnight last weekend' and get clips back. That is a search agent on top of a detector, the agent itself is not watching the cameras. The second is a frame-by-frame VLM running on every camera, asking 'is anything suspicious in this frame.' That is the most expensive and least reliable option, because VLMs hallucinate suspicious activity in long-tailed scenes and the cost scales with frame rate. The third is a planner agent: a tight perception layer surfaces structured events to a planner that decides what to do with each one, with the LLM only entering the loop when an event has already cleared the state-tier filters. Buyers should ask which of the three a vendor is shipping. Most are shipping the first or the second.

Tier one is perception, on the order of tens of milliseconds per inference. It runs object detection (and on some platforms a small classifier) over every frame of the input, emits bounding boxes with class labels, and runs a tracker so the same person across frames keeps the same track id. No LLM, no agent reasoning, no language calls. Tier two is state, sub-second. It takes detections from tier one, applies the per-camera zone polygon, increments dwell counters, dedups tracks, and emits transitions of the form 'track 4811 entered zone mailroom-01 at 02:14:33' or 'track 4811 has been in zone parcel-shelf for 920 seconds.' Still no LLM. Tier three is the planner, sub-30 seconds. It takes the small stream of transitions from tier two, decides whether to drop the event, route it as a LOW THREAT, escalate to HIGH THREAT, send a 10-second clip, retry a failed alert, or fold the event into an open incident. The planner is the only place where an LLM call (if you use one) belongs.

Four, and only four. zone_polygon_lookup(camera_id, point) returns whether a coordinate falls inside any armed zone for that camera, with the zone name, dwell threshold, and arming schedule. dwell_timer_increment(track_id, zone_id, seconds) reads and writes the dwell counter file at /var/lib/cyrano/meta/dwell_state and returns the current accumulated dwell, plus a flag for whether the dwell threshold has been crossed in this call. threat_router_classify(event) takes a structured event and returns one of drop, low_threat, high_threat, with an optional 10-second clip path. alert_outbox_append(event) appends a JSON line to the NDJSON outbox and returns the line number, so the alert can be retried in order if the outbound link is down. That is the entire toolset. There is no shell tool, no arbitrary API, no 'browse the internet.' The planner cannot do anything outside this set, which is also what makes its behavior auditable: every call is logged to a file the operator can read.

Two reasons. First, every additional tool is another surface for the planner to make a mistake on, and 'mistake' here means 'sent the wrong family a 2 a.m. text message about a possible break-in.' The cost of an agent error in this domain is not a wrong code change, it is a phone call to a tenant who is already asleep. Second, the four tools cover the entire decision space the planner needs. zone_polygon_lookup answers 'is this happening somewhere I care about.' dwell_timer_increment answers 'has it lasted long enough to matter.' threat_router_classify answers 'how loud should the alert be.' alert_outbox_append answers 'how do I make sure the alert actually leaves the device.' Anything outside that four is either a different layer's job (perception, state) or somebody else's job (the property manager, the on-call ops team, the cops). Keeping the toolset minimal is what makes the agent's behavior describable on one page.

Three files, all under /var/lib/cyrano/meta/. track_registry.ndjson is one JSON line per track id observed in the last six hours, with first-seen timestamp, last-seen timestamp, last bounding box, and the camera id the track was last seen on. dwell_state is a per-(track, zone) accumulator: how many seconds track 4811 has been inside zone parcel-shelf since it first entered. outbox.ndjson is the append-only alert log, one event per line, with a delivery_state field that is updated when the alert is acknowledged by the on-call ops team. All three files survive a process restart and a reboot. None of them ever leaves the device. If an operator wants to know why an alert fired or did not fire on a particular night, they grep the outbox file by timestamp and the dwell_state file by track id, and the answer is right there.

A VLM on every frame is the wrong shape for two reasons. First, it conflates perception and reasoning into a single expensive call, which means you pay LLM costs for every frame even when the answer is 'no person, no vehicle, nothing.' The vast majority of frames at a residential property are exactly that, which means the vast majority of the inference budget is wasted. Second, VLMs are unreliable on long-tailed surveillance scenes (low light, partial occlusion, weird angles, motion blur) in a different way than detectors are. Detectors miss objects. VLMs hallucinate plausible-sounding stories about objects, and a 'person carrying what may be a weapon near the rear gate' alert that turns out to be a maintenance technician with a flashlight is much harder to recover trust from than a missed detection. The agent loop solves both: tier one and tier two never call an LLM, so you only pay LLM cost when something has already cleared a structured filter, and tier three's prompt is tightly scoped (here is the event, here are the four tools, decide an action) so hallucination space is small.

Four. First, where in the loop does the LLM run, and on what input rate? A real answer names the tier (planner) and gives a per-event budget (low double digits per camera per day). A non-answer is 'continuously, on every frame.' Second, what is the explicit list of tools the agent can call? A real answer is short and names each tool, what it reads, and what it writes. A non-answer is 'it can do many things' or a vague reference to plug-ins. Third, what state does the agent persist, and where does it live? A real answer is specific files on local disk with named fields. A non-answer is 'the model has memory.' Fourth, what happens during a six-hour WAN outage? A real answer describes the outbox file, the order of replay, and the local-only operation of perception and state tiers. A non-answer is 'the cloud handles failover.' A vendor that cannot answer those four questions with file paths, integers, and behaviors is selling a marketing wrapper around an object detector, not an agent.

For a fixed property with a stable rule set, yes, a rule engine is enough, and on most production Cyrano deployments today the planner is a deterministic Typescript function (the per-class router shown on this site) rather than an LLM call. The LLM earns its keep when the rules need to handle messy free-form context: an operator who just sent a text saying 'expect a contractor at the rear gate at 2am tonight, do not page me on this one,' or a property where the on-call schedule changes weekly, or a building with a known pattern of 1 a.m. delivery drivers that should be silenced for the next 20 minutes only. The deterministic router cannot express those without code changes. An LLM-backed planner can take the operator note, the on-call schedule, and the event and produce the right routing, then write back to the outbox. So the answer to 'do you need an LLM' is 'only when the rules need natural-language context the operator wants to set and forget.' Detection, state, and the four tools never need one.

Yes. Both modes are supported. In the deterministic mode the planner is the per-class Typescript function and runs in microseconds, fully on device, with no outbound network call. In the LLM-backed mode the planner can be wired to either a hosted endpoint (in which case only the structured event and the four tool descriptors leave the device, never video) or a local model running on the same hardware (in which case nothing leaves the device at all). The mode is a config switch, not a separate product. Most multifamily deployments today run the deterministic mode because the rules are stable. Construction site and commercial deployments where context shifts daily benefit more from the LLM-backed mode, often paired with a local 7B-class model so the privacy story stays clean.