Vision AI

Vision turns an Argos or Ring camera frame into structured state on the object the camera watches — so you can ask "what is the wash plant doing right now?" and get an answer with a picture behind it. Point a camera at a machine or a process, and its state, a one-line observation and a status colour keep themselves current on that object.

It owns no collection of its own: visual state and freshness land on devices and the frames and clips on artifacts, both documented in Devices & Media. You read what vision wrote from the device:

Retrieve a device — GET /api/v1/devices/a60h-12

curl "https://trydozer.com/api/v1/devices/a60h-12" \
  -H "Authorization: Bearer $DASH_API_KEY" \
  -H "Project-ID: pr_northpit"

Show me the CANedge on HT-14

data_get {
  "collection": "devices",
  "object_id": "a60h-12"
}

{
  "object": "device",
  "id": "obj_123",
  "device_id": "canedge-ht14",
  "name": "CANedge2 — HT-14",
  "status": "transmitting",
  "status_color": "status color",
  "status_reported_at": "2026-07-25T12:00:00.000Z",
  "state": "state",
  "observation": "observation",
  "timeline_changes": "timeline changes",
  "metrics": {},
  "created_at": "2026-07-25T12:00:00.000Z",
  "updated_at": "2026-07-25T12:00:00.000Z"
}

What the worker does for you

The owner is a device-worker skill, dozer-video-vision, executed by the Argos and Ring integration workers. It is declared per device rather than in the agent catalog, so it has no page in the skill catalog; add a camera from the devices surface and the worker comes with it. A worker you host yourself calls it at POST /api/v1/skills/dozer-video-vision/run with a run-scoped device key — the Argos add-flow hands you that exact call to paste in.

Each pass returns strict JSON — properties plus property_colors — and only fields inside that device's approved field set survive normalization; anything else is dropped rather than written. The core four are state, observation, status_color and camera_visibility, and a device can add its own (a washplant camera declares sluice_status, tailings_status, cycle_time, spray_bars, water_flow). Writes carry full provenance — provider, model, prompt_id, prompt_version, prompt_hash, integration version and the worker run id — so a dashboard claim traces back to the frame and the prompt that made it. Prompt ids and hashes are stored; prompt text never is.

Snapshot frequency, clip duration and the analyze prompt itself live in the device's settings and are editable without a deploy. Short prompts beat rigid checklists, and the contract prefers camera obstructed plus n/a / unclear over a confident idle/no-flow claim on a hazy frame — an honest gap is worth more on a dashboard than a wrong number. To force a pass now, run the registered worker from the device page, or call devices_upload_media and devices_worker_run from your own agent (MCP Tools).

A pass that finds nothing it can use finishes skipped with the reason counted — an unsupported MIME type, or media older than the run's age window (1h by default). Selection stops before crossing the per-run AI budget ($0.25) or media ceiling (100 MB); if actual usage still lands over budget the run fails rather than truncating and reporting success. A malformed model response is an error, not a partial write.

Next: Devices & Media to add the camera and read what it wrote · TV & Dashboards to put the result on a screen · Site & Fleet for the machine a camera is linked to.