CLU — a personal coordinator that lives in Telegram
Can I have a personal coordinator that lives in Telegram, uses Claude as its brain, and keeps its memory in tools I already own — Google Calendar and Drive — instead of a database I'd have to maintain?
A serverless Worker plus an existing chat app gets you 80% of an 'assistant' with almost no infrastructure: no server to patch, no database to back up. The hard part isn't the AI call — it's giving the agent durable memory without standing up new storage. Reusing Calendar/Drive as the memory layer was the unlock.
Phase 0 (plumbing: Telegram webhook ↔ Worker ↔ Claude) works end to end. It paused at the prerequisites for Phase 1 (Calendar/Drive auth and the memory schema) — parked at a clean proof of concept, not abandoned.
What it is
CLU is a small agent that you talk to inside Telegram. Behind the chat window sits a Cloudflare Worker — a piece of code that runs on demand in the cloud, with no server for me to keep alive — and the Worker calls the Claude API to do the thinking.
The personality is deliberate: cold, terse, efficient. A Tron-flavored operator, not a chirpy assistant. That tone is a design choice, not an accident — a coordinator should feel like a control surface, not a friend.
The interesting constraint
Most "build an assistant" tutorials reach for a database. I didn't want one — a database is a thing you provision, secure, and back up forever. The bet here was:
Use tools I already live in as the memory.
So CLU's memory is meant to live in Google Calendar (time-bound facts: events, deadlines) and Google Drive (everything else: notes, documents). The agent reads and writes those instead of a private store. If it works, the "database" is something I already trust and already back up.
Where it stands
- Phase 0 — done. The pipe is connected: a message in Telegram reaches the Worker, the Worker asks Claude, and the answer comes back in the chat.
- Phase 1 — parked. Wiring the Calendar/Drive memory needs an auth handshake and a small schema for how facts get stored. That's the next prerequisite, and it's where the POC sits.
Why it's in the log
This is exactly the kind of thing I build to "it works" and then keep. Documenting it here is the point: the proof of concept is the deliverable. If Phase 1 ever ships, this entry grows.