I built a Telegram-native AI agent on free-tier infra — here's the stack and what broke

I'm Basavaraj Patil (Basavaraj_nick), a self-taught dev and CS diploma student, and I built a Telegram-native multi-agent AI system entirely on free-tier infrastructure — no server bills, no paid APIs. Here's how it works, and what broke along the way.

What it does

It's not a chatbot. It's a full agent system that lives inside Telegram — 14+ commands, 8 autonomous sub-agents running on schedules, image generation, web research, and memory that persists across conversations. All of it running on free tiers.

The stack

• Cloudflare Workers — two workers (github-backend + image-api) handle routing and image requests
• GitHub Actions — 8 sub-agents run on cron schedules throughout the day (IST)
• Telegram Bot API — the entire interface; no web dashboard needed
• Cloudflare D1 — logs commands and stats to a dashboard
• Cloudflare KV — a 5-minute rolling memory window so the agent has short-term conversational context
• LLM chain: Mistral → Cerebras → Groq → OpenRouter → Gemini, falling back in that order so a single provider's rate limit never takes the whole thing down
• Image gen: FLUX 1 Schnell as primary, Pollinations AI as fallback
• Image editing: Stable Diffusion v1.5 img2img for the /edit command
• Web research: Tavily + Jina for live search grounding

Why Telegram, not a web app

Every other agent framework I looked at assumed you'd build a dashboard. I didn't want to maintain a frontend, an auth flow, and a backend just to send myself a daily briefing. Telegram already solved auth, mobile notifications, and UI. The bot is the UI.

What actually broke

A few patterns that cost real debugging time, in case they save you some:

• Return-type mismatches across agents — when 8 sub-agents pass data between each other, one agent returning a slightly different shape than the next one expects fails silently until something downstream breaks.
• GitHub Actions permissions on workflow files — Actions can't modify other workflow files by default; needed explicit permissions.
• KV memory misconfiguration — early versions stored memory in a public repo memory.json, which is a bad idea for anything with even mildly sensitive context. Moved it to private Cloudflare KV.
• RLS conflicts — wherever a database enforces row-level security, make sure your service role key is actually bypassing it where intended, or reads silently return empty sets.

Where it stands now

The repo is public and secrets-clean — full README with the architecture, a competitor comparison, and the env var table if you want to run your own version.

Repo: github.com/basavarajpatil660/Ultimate-Ai
More of what I'm building: basavaraj.dev
Project page: basavaraj.dev/projects/ultimate-ai-agent

If you're building something similar or want to talk architecture, find me at @basavaraj_nick or drop a comment below.