DMonitor — AI Operations Agent

Overview

DMonitor is an AI operations agent Daniel Mashkov built for his own business: one Telegram chat that reads leads, the CRM, search, speed and errors, and briefs him every day.

Running a one-person business meant a morning round of a dozen dashboards — leads, the CRM pipeline, search rankings, site speed, errors, uptime, deploys — and contract hours kept in a spreadsheet. Things slipped between them: a proposal nobody followed up, a problem a client noticed first.

One Telegram chat in front of an AI agent: it reads the live data itself, briefs me every morning and evening, raises an alert only when something crosses a line, keeps the contract-hours log and drafts a reply to every new lead — and anything that leaves the chat waits for my tap.

Challenge

The hard parts were the free plan's 50-request limit, a slow CRM, instructions hidden in outside content, and daylight saving on UTC schedules.

• Cloudflare's free plan allows 50 outgoing requests per run. A morning brief reads more than ten sources, and on a cold cache it ran out — the pipeline section came back empty.
• Airtable answers the Worker slowly — seconds, some mornings twenty — and a brief that waits on it misses its own deadline.
• Outside content — a forwarded message, an email, a web page — can carry instructions. An agent that can send email and deploy must never treat it as a command.
• Israel changes its clocks twice a year while Cloudflare's schedules run in UTC, so a fixed 09:00 brief drifts by an hour.

Solution

A Cloudflare Worker with a Gemini agent and about 30 tools: batched cache reads, an 08:55 prefetch, a taint gate on every write, and code-set recipients for every drafted email.

A Cloudflare Worker on the free plan with a Gemini tool-calling agent, Supabase for state, and readers for Google Analytics, Search Console, Sentry, Vercel, UptimeRobot, Cloudflare and the Airtable CRM. A job runs every five minutes, plus a 09:00 brief, a 21:00 summary and a Sunday review — each checks the Israel hour itself, so daylight saving never moves it.

• One batched cache read and one batched write per brief, so a cold morning stays far under the 50-request limit — a test runs a cold brief and fails at 40.
• An 08:55 prefetch of the slow Airtable reads, so the 09:00 brief reads them from cache.
• A taint gate: once outside content enters a turn, every write tool refuses. Email, deploys and cache purges always wait for a confirm tap.
• A reply draft for every new lead — the recipient, subject and language are set by code; the model writes only the body.
• A contract-hours log that replaced a Google Sheet, checked against it to the quarter hour.
• Telegram Bot API — the whole interface: commands, plain-language requests in Hebrew or English, buttons and an hours dashboard in a Mini App
• Gemini (with a fallback model) for the agent loop, the briefs and the reply drafts
• Supabase, Airtable, GA4 and Search Console (a read-only service account), Sentry, Vercel, Cloudflare and UptimeRobot

Impact

It replaced a morning round of dashboards with one brief, alerts only on real thresholds, and runs on free tiers at about one to three model calls a day.