We are growing a lot of vegetables this year. Carrots, cauliflower, russet potatoes, Roma tomatoes, and more are all going into fourteen raised beds in our garden. We have done our research, but there are a lot of variables in a Pacific Northwest garden and a lot of plants to keep track of. So I decided to build a garden assistant.

I am calling it Ceres.

The Concept

Ceres is a multi-agent system. Seven specialist agents, coordinated by an orchestrator, produce a daily morning briefing and respond to on-demand questions. The specialists divide up responsibility cleanly:

  • A specialist in plant care and fertilization guidance
  • A record keeper for rotation history and bed layout
  • An expert in watering decisions based on soil sensors and weather
  • A specialist in pest and disease identification
  • An expert handles scheduling and phenology
  • A record keeper reads and writes the event journal
  • An orchestrator dispatches queries and merges outputs.

The daily briefing generates at 6am and lands in a Home Assistant dashboard. It covers per-bed watering recommendations with rationale and confidence tags, anticipatory alerts for things like bolting or pest pressure, a two-week time-lapse of the garden camera, and a todo list. Urgent things, frost warnings and critical moisture drops, push to the phone via Home Assistant Companion.

Kim captures garden events by holding a mic button in the Ceres app, saying something like “aphids on the kale,” and letting the system transcribe, tag, and log it. The camera frame detects where she is standing to auto-tag the bed. Everything gets appended to a permanent history. Nothing gets deleted.

The Design Principles

A few things I wanted to be true about this system from the start.

Every recommendation shows a rationale and a confidence level. Low-confidence items surface in a “Needs Your Judgment” view rather than blending silently into the main list. If a sensor is offline or a plant profile is missing, Ceres says so. Hidden failures are worse than obvious ones.

Kim should never have to ask me to update anything. Plant profiles, bed metadata, and preferences all live in a database she can edit herself through NocoDB, a spreadsheet-style web tool. No code required, no asking Jason.

Override patterns are signals, not noise. When Kim ignores a watering recommendation, that gets logged with context and feeds future evaluation. The system should get smarter from disagreement, not just from compliance.

How I Am Tracking the Build

The Ceres repo lives in my Gitea instance. I am using Gitea milestones to organize the build by phase, with individual issues for each task. Phase A covers physical setup: sensor range tests, camera procurement, sun mapping. Phase B covers the compute and data layer: TimescaleDB schema, Qdrant for vector storage, NFS shares on my Synology NAS. Phases C and D bring in networking, sensor pipelines, and weather integration.

I set up the Gitea MCP server alongside the repo. That means Claude Code can read and update issues directly during a session without me context-switching to a browser. When I am mid-implementation and something needs to be broken into sub-tasks or marked done, that happens in the same flow.

The CLAUDE.md in the repository gives Claude Code the orientation it needs: what the project is, what phase it is in, where the ADRs live, and hard rules about what goes in the database versus what goes in the repo. The two hardest rules right now are that operational data never goes into YAML files and that the main branch stays deployable at all times. Both of those exist because I have violated both before and it cost me time.

The First Real Deliverable

No agents are running yet. The first real deliverable after Phase A and B infrastructure is Kim sitting down with NocoDB and entering bed metadata, plant profiles, sun patterns and current plantings. That felt like the right milestone to aim for first. If the data layer is not there, nothing the agents do matters.

Meanwhile, I’ve been setting up a new Reolink WiFi camera for garden computer vision tasks, as well as Ecowitt Soil Moisture sensors to keep real data on what’s going on in the beds.

This project is going to be a doozy, so I will spend this week iterating on the spec, capturing data, laying groundwork for tracking, managing and structure. No code, no tables, just how I will build so far.