←Tornar al blog
notionhermesohanasmartrunningtelegramlong-polling
·5 min de lectura

Kanban Notion + coach conversacional

El 15 d'abril vaig fer dues coses que semblaven no tenir res a veure: vaig muntar una taula Kanban a Notion per als leads d'OhanaSmart, i li vaig posar listener conversacional al bot de running @harvieRun_bot.

Mirant-les juntes, sí que la tenen: les dues són el mateix pas. Deixar de barallar-me amb dades i agents amagats, i lligar-los a una interfície que ja uso tot el dia.

Problema 1: els leads viuen en 17 llocs

El pipeline d'OhanaSmart té leads a:

  • JSON files a ~/.hermes/workspace/projects/ohanasmart/leads/
  • IMAP del buzó de Diana
  • Drafts a Gmail
  • Missatges a Telegram del cronjob de prospecció
  • El meu cap

Això funciona per a ~5 leads. Per a ~130 és un desastre. Cada matí me preguntava "A qui he de fer follow-up avui?" i la resposta era "Obri 4 pestanyes i recorda".

No és un problema d'agent. És un problema de superfície humana: necessito una vista única on collocar els leads en columnes i moure'ls. Això és un Kanban. I jo ja uso Notion tots els dies.

El que vaig muntar

Pas 1 — integració:

  1. notion.so/my-integrations → New integration "Harvie"
  2. Token ntn_4733... guardat a ~/.hermes/.env
  3. Vaig crear una pàgina "OhanaSmart — Pipeline" i la vaig connectar amb la integració
  4. Harvie va poblar el Kanban automàticament

Pas 2 — schema:

  • Status: Nou / Investigat / Actiu / Respost / Tancat
  • Sector: Coworking / Hotel / Residència / Universitat / Restaurant
  • Responsable, data últim contacte, email, notes

Pas 3 — dades reals:

  • 4 leads actius: DiR, CASA SEAT, Sant Antoni, Nobu
  • 16 leads de batch 2 com a "Investigat": UB, Resa, Glovo, Wallapop, etc.

Des d'ahir obro Notion, miro la columna "Actiu", i sé exactament què fer. Sense preguntar-me res.

El que no vaig fer (a propòsit)

  • No vaig escriure un CRM propi
  • No vaig muntar Airtable
  • No vaig pagar HubSpot
  • No vaig meter un dashboard web a Hermes

L'agent escriu a Notion. Notion és la UI. Jo movo les cards a mà quan canvia un estat. Si vull que Harvie mogui automàticament, ho faré quan em dugi — no abans.

Regla d'or: la UI està resolta (Notion). No reinventis el que funciona.

Problema 2: el coach de running no escoltava

El meu agent de running (~/.hermes/agents/running-coach/) tenia dos cronjobs:

  • daily_check.py — 06:00 UTC, push a Telegram amb pla del dia
  • weekly_check.py — diumenge 10:19 UTC, push amb revisió setmanal

Push només. Zero input meu.

Si volia dir-li "Avui no puc, mou l'entreno a demà", havia d'anar al JSON a mà. Si volia preguntar-li "Quant he fet aquesta setmana?", no podia.

Un coach que no escolta no és un coach.

El que vaig muntar — chat_listener.py

Long-polling contra la API de Telegram per al bot @harvieRun_bot (8617451500:...). 8.7K de Python. L'essencial:

  • Filtre per user_id — només respono a Johnny (406057010). Si algú altre troba el bot, silenci.
  • Historial rotatiu de 20 missatges — context suficient per que el coach recordi la conversa sense explotar el prompt.
  • Proxy two-phase (:18792) amb fallback al simple (:18791). Si un cau, respono igual.
  • Model Haiku 4.5 — estable, barato, suficient per a un coach. Opus és massa per a això.
  • Prompt prompts/chat.md — to consultiu, estil coach mà dura, coneix el meu pla de Maratò Barcelona 2027.
  • PID viu + crontab keepalive cada 30 min — si es mor, s'arranca sol.

Resultat

Ahir nit li vaig escriure "Avui ja no puc, prepara'm-lo per a demà..." i "Hola". Els dos van arribar al listener, es van parsejar, van entrar a l'historial, i el model va respondre. El proxy va trigar un parell de vegades i va caure al fallback — anotat per revisar, però el chat funcionava.

Per primera vegada puc tenir conversa amb el coach que m'acompanya a la maratò. No només rebre ordres a les 6 del matí.

La regla comuna

Els dos canvis són el mateix:

  1. Les dades existeixen (leads en JSONs, pla de running en profile.json) però no tinc on veure'ls/tocar-los còmodament.
  2. L'agent ja existeix (Harvie, running-coach) però només em parla, no m'escolta.

La solució en ambdós casos és la mateixa: donar a l'agent una superfície on jo ja vivo — Notion per al pipeline, Telegram per al coach. No construir una UI pròpia. No esperar a "quan tingui temps". Lligar les dues puntes i desfer el desordre.

Això no és arquitectura sofisticada. És el mínim que un builder independent ha de fer per que el sistema deixi de ser un munt de scripts i passi a ser una eina.

Stack usat (altra vegada tot local)

  • Hermes agent framework (~/.hermes/)
  • Notion API (integració pròpia, no MCP)
  • Telegram Bot API (long-polling, no webhooks)
  • Proxy two-phase local (:18792) amb Haiku 4.5
  • Python 3.11

Zero dependències externes de pagament. Zero vendor lock-in.

Què vaig aprendre

  1. La UI sempre és el coll de botella. No el model, no l'arquitectura, no els prompts. La UI. Si no puc veure ni tocar les meves dades còmodament, el sistema no em serveix encara que sigui tècnicament brillant.

  2. Usa el que ja usas. Jo uso Notion, uso Telegram. Meter els meus agents allà val més que muntar un dashboard propi que després no obriré.

  3. Long-polling està infravalorat. Tot el món munta webhooks amb ngrok o Cloudflare Tunnel. Long-polling des d'un script Python contra la API de Telegram són 150 línies i zero infra. Per a un bot personal amb tràfic d'una conversa, sobra.

  4. El cost real del "model petit". Haiku 4.5 pel proxy respon a les preguntes del running en uns segons, i una conversa completa costa cèntims. Opus allà és gast pur. Cada decisió de model la prenc cas per cas.

Què ve

  • El Kanban es plenarà de respostes de batch 2 en els pròxims dies
  • El chat listener necessita pujà el timeout del client Anthropic (el proxy està en la cua)
  • Següent: que Harvie actualitzi el Kanban automàticament quan Diana rep una resposta per IMAP (watcher ja existeix, falta el webhook a Notion)

Petit, avorriment, útil. Així es construeixen les coses que duren.

— jo, Johnny — agent configurat: Harvie. La UI és l'única cosa que importa.