Canary

Canary catches small building warnings before they become expensive outages: AI agents price the risk and draft the fix for one-click approval.

Comment 1

Inspiration

In commercial real estate, big failures rarely come out of nowhere. A tenant reports water on the floor, a chiller runs a little warmer each day, and somewhere a lease says who pays for the repair. Each signal lives in a different system, so nobody connects them until the equipment fails, and then it costs tenant penalties plus an emergency repair. We wanted a canary in the coal mine for buildings: something that notices the small warnings and acts while the fix is still cheap.

What it does

Canary is a crew of AI agents for building operations. When a report, sensor alarm or nightly check comes in:

  • Triage links scattered tickets into one root problem.
  • Sensor Watch fits a trend to two weeks of readings and forecasts when the equipment will hit its safe limit.
  • Lease / SLA reads the tenant leases to find who is affected and who pays for the repair.
  • The Lead agent prices the risk: the cost of waiting (tenant penalties plus an emergency repair) against the cost of fixing it now.
  • Dispatch drafts the fix: a vendor work order, a schedule change and tenant notices.

A facility manager reviews everything and approves with one click. After the repair, Canary checks the sensors again to confirm the fix held, and saves what it learned to the building's history for next time.

Facility managers can also build their own crew on a drag-and-drop canvas: add agents from templates, connect them end to end, and the connections decide the run order. Live forecast charts show each failure coming, with and without the repair. A portfolio view of buildings shows which equipment needs approval, which repairs are approved, and which are fixed.

How we built it

  • Frontend and backend: Next.js 16 (App Router), React 19 and TypeScript. Agents run in the background, and the UI polls for live progress, so you can watch each step and the Agent Map update as the crew works.
  • AI: NVIDIA Nemotron through its OpenAI-compatible API, with tool calling. Each agent has its own tools (ticket search, dependency graph, trend fitting, lease lookup, risk pricing, vendor search, drafting), and the Lead delegates to specialists through ask_* tools, running them in parallel by stage.
  • Self-hosted model: We deployed the Nemotron Nano 9B v2 NIM on an NVIDIA L40S GPU through Brev and connected it to the app over an SSH tunnel. If the GPU can't be reached, Canary automatically switches to NVIDIA's hosted Nemotron.
  • Data: Supabase (Postgres) stores buildings, equipment, dependencies, tenants, leases, tickets, sensor readings, agent steps, approvals and building memory.
  • Math: A least-squares trend line on the sensor history gives the time to failure. Risk pricing compares tenant penalties per hour × outage hours plus an emergency repair premium against the planned repair.

Challenges we ran into

  • Getting a GPU up: Our first two Brev instances failed during setup on one provider, so we switched to a different one.
  • Out of GPU memory: The model loaded, then crashed asking for 33 GB more. Its startup warm-up was sized for 256 requests at once. We tuned the context length and batch limits until it fit on a 48 GB L40S.
  • A tunnel that kept dying: Brev's SSH setup shares one connection between sessions, so our tunnel closed with it. We wrote a self-reconnecting tunnel with its own connection, plus a health check in the UI that turns red when the GPU, model or database is unreachable.
  • Keeping a 9B model on task: The smaller model reasoned out loud and sometimes skipped the specialist agents. We turned off its reasoning mode and made the runtime guarantee that every agent connected on the canvas actually runs.
  • Realistic, varied demo data: Every incident generates its own noisy sensor history, so the numbers and forecasts differ from run to run and across buildings.

Accomplishments that we're proud of

  • A full loop, from a small warning to a priced decision, a drafted repair, human approval and a verified fix, running end to end on our own Brev GPU.
  • A crew builder where the connections you draw are the real run order.
  • Showing the math instead of hiding it: every cost and time to failure can be opened up to see how it was calculated.
  • A forecast chart that makes the decision obvious: one line shows the failure, the other shows what the repair changes.

What we learned

  • Agents are most useful when each has a narrow job, its own tools and a clear hand-off. The orchestration matters as much as the model.
  • Smaller models can run a real agent workflow, but they need guardrails the large ones don't.
  • Self-hosting an LLM takes real infrastructure: GPU memory, startup limits, networking and fallbacks. That's exactly why NIM and Brev made our project manageable.
  • For facility teams, transparent code is key. This includes plain-language steps, visible math, and a human approval before anything is sent.

What's next for Canary

  • Connect to real building systems (BMS, CMMS and IoT sensor feeds) instead of simulated readings.
  • Send approved work orders and tenant notices through real vendor and email integrations.
  • Learn from verified repairs to sharpen forecasts and vendor choices per building.
  • Portfolio-wide planning that schedules the night's repairs across buildings by risk.
  • Mobile approvals so facility managers can sign off from anywhere.

Built With

  • ai-agents
  • brev
  • docker
  • lucide-react
  • national-weather-service-api
  • nemotron-nano-9b
  • next.js
  • node.js
  • nvidia-l40s
  • nvidia-nemotron
  • nvidia-nim
  • open-meteo
  • openai-compatible-api
  • postgresql
  • react.js
  • ssh
  • supabase
  • tailwindcss
  • tool-calling
  • typescript
Share this project:

Updates

Submission history