Garden advisor: four layers, zero infrastructure cost

A homeowner in northern Finland wanted a garden advisor that knows his plants, checks the weather, and tells him what to do each morning. No app on the market handled the specifics of zone 4 growing well enough. Building a custom app meant encoding too many edge cases. Asking ChatGPT each time, you lose all context between conversations.

We built a Telegram bot that runs 24/7 on a free tier, costs under $1/month in API calls, and gets smarter with every conversation.

What it does

Every morning at 8:00 the bot sends a summary to Telegram: what’s due for sowing, what needs watering, which seedlings are ready to harden off. Every four hours it checks frost risk. If temperature drops below threshold, you get an alert. Nobody asked it to.

You can message it anytime. “Sowed basil today” updates the plant registry, logs the journal, adjusts the timeline. Send a photo of a plant and it identifies species, growth stage, health issues. Writes to the tracker automatically.

All plant data lives in markdown files. No database, no migrations. The owner reads and edits the same files in Obsidian alongside his other notes. The bot and the owner work with the same data.

How it works

Four independent components that each do one thing and work alone. They compose at runtime.

Layer 1: Knowledge. A Claude Code skill, which is a folder of markdown files. Plant registry with a state machine (planned → sown → germinating → seedling → hardening → outdoor → harvesting → done), a season journal, a location profile. All dates computed from one variable: last frost date. Move cities, change one line.

Layer 2: Real-time data. An MCP server with seven tools pulling from Open-Meteo, SoilGrids, and sunrise-sunset.org. Free APIs, no keys needed. One tool, garden_check, aggregates four APIs in a single call with seasonal filtering built in.

Layer 3: Autonomy. Claude Agent SDK loads the skill as system prompt, connects MCP tools, polls the Telegram gateway. The agent decides when to spend tokens and when to skip the LLM entirely. Frost check = direct API call, zero tokens. Morning summary = full agent reasoning, once per day.

Layer 4: Interface. Telegraf on Fly.io. 14 MB of RAM, free tier. Handles webhooks, queues up to 100 messages. When the agent goes offline, the bot keeps working. Messages queue up and get processed on reconnect.

Security was harder than functionality

An agent with a public Telegram input is an open channel. Anyone can message it.

User messages get XML-wrapped to block prompt injection. User queries run with read-only tools, no write permission. Proactive prompts (hardcoded inside the agent, trusted) get write access. Two permission tiers from one SDK. The agent trusts the prompt origin, not the input channel.

Memory that survives restarts

When conversation history crosses 20K tokens, old messages get LLM-summarized and appended to the garden journal as a dated entry. Recent messages stay in working memory. The context survives restarts. The knowledge base grows with every conversation.

What this cost

	Monthly	Setup
Infrastructure	$0 (Fly.io free tier)	—
Claude API	<$1 (morning check + conversations)	—
Weather data	$0 (Open-Meteo, SoilGrids, sunrise-sunset.org)	—
Development	—	~40 hours across four repos

When this pattern fits

This isn’t a gardening product. It’s a pattern. Skill + MCP + agent + bot gateway works for any domain where:

• You have structured knowledge that changes over time (inventory, schedules, logs)
• You need real-time external data (weather, prices, shipping status)
• Proactive behavior matters (the system should act without being asked)
• The user already lives in a messaging app

A property manager tracking maintenance schedules. A warehouse operator watching stock levels against supplier lead times. A clinic receptionist triaging appointment requests overnight.

Same components. Different knowledge files.