intake: un sistema di acquisizione link che si usa davvero
Da dove parte
Prima di costruire intake, i link che trovavo su smartphone finivano in due posti: messaggi WhatsApp a me stesso e note sparse. Il 90% non veniva mai rivisto. Il problema non era la mancanza di motivazione: era l’assenza di un sistema che trasformasse il salvataggio in qualcosa di utile.
Muovendomi tra tre aree (aggiornamento professionale su AI e management, monitoraggio del mercato del lavoro IT, produzione di contenuti LinkedIn), il flusso di input era alto. Un articolo sull’AI governance, un post LinkedIn di un CTO, un’offerta di lavoro su un sito che non monitoravo. Ognuno richiedeva un’azione diversa. Senza classificazione automatica, tutto finiva in uno stesso contenitore inerte.
Il sistema è composto da quattro layer: Telegram come interfaccia mobile, n8n come orchestratore, Claude come classificatore, Airtable come database strutturato. Invio un link dal telefono, ricevo una card con titolo, rating, categoria, tag e priorità già assegnata.
Il sistema e come è cresciuto
Quattro workflow separati invece di uno: intake-main per l’acquisizione, intake-briefing per il riepilogo periodico, intake-ricerca per gli approfondimenti, intake-job-scanner per le offerte di lavoro. Non è una scelta di purezza architetturale. È praticità: quando un workflow fallisce, l’area di debug è circoscritta. Un monolite con 50 nodi rende ogni errore un’operazione di discovery.
Il prompt di classificazione invia a Claude Haiku un JSON stretto e attende JSON in risposta, niente testo libero. Il parser a valle non è tollerante: se la risposta non è JSON valido, c’è un fallback esplicito che imposta rating=2 e category=news, segnalando il problema senza bloccare il flusso. Avrei potuto accettare Markdown nel prompt e fare parsing del testo. L’ho escluso perché un parser robusto su testo libero non esiste: esiste solo un parser tollerante che prima o poi ingoia un errore silenzioso.
Il tunnel verso n8n usa Tailscale Funnel: nessun VPS, nessun account Cloudflare da mantenere, URL stabile incluso nel piano. Telegram richiede HTTPS per i webhook. La risposta ovvia sarebbe stata un VPS. La risposta giusta, per un tool personale, era la soluzione con zero costo fisso e zero manutenzione infrastrutturale.
La Fase 9: job scanner con filtro AI calibrato
La ricerca di lavoro attiva ha generato un problema specifico: monitorare 30+ aziende italiane che usano TeamTailor come ATS, ogni giorno, su un profilo non banale. Le offerte non sono sempre etichettate bene. Il titolo “Project Manager” può nascondere un ruolo operativo puro o un ruolo di coordinamento tech, e la distinzione conta.
Il workflow intake-job-scanner interroga ogni mattina alle 08:00 le API JSON pubbliche di ogni azienda nella lista, filtra le offerte degli ultimi 7 giorni, deduplica contro Airtable e passa le offerte nuove a Claude Haiku con un prompt calibrato sul profilo. Il prompt non è generico: definisce ruoli cercati, settori ammessi, competenze chiave, lingua, preferenze di sede. Contiene penalità esplicite per posizioni in presenza fuori Sicilia, che abbassano il rating massimo a 2, e criteri di esclusione diretti: DevOps puro, SRE, posizioni esclusivamente coding.
Il risultato è un digest Telegram giornaliero. Di solito 0-3 offerte rilevanti, già con score e motivazione. Leggere in 30 secondi, decidere in altri 30. Lo scanner ha già scartato correttamente posizioni come Automotive Design PM, Tecnico NOC e Key Account Manager su offerte reali: ruoli che un filtro per parole chiave avrebbe potuto far passare.
Il MCP server: API design per consumatori AI
Il MCP server custom è un layer Python che espone 17 tool semantici verso Claude Code via protocollo standard. Copre tre sistemi: Airtable (gestione record), n8n (ispezione workflow, nodi, esecuzioni), Apify (verifica run e log).
La scelta progettuale rilevante non è nel numero di tool: è nel formato delle risposte. Ogni tool restituisce il minimo utile per la sessione. get_new_jobs restituisce una preview di 300 caratteri per item, non il campo full_text completo. n8n_get_workflow restituisce un summary condensato dei nodi, senza i parametri grezzi che occupano la maggior parte dello spazio in un workflow da 70+ nodi. Un dump completo sarebbe controproducente: il modello lavorerebbe su contesto troppo rumoroso per produrre output precisi.
Il transport è stdio. Il server nasce come processo figlio all’avvio di una sessione Claude Code e muore alla chiusura. Nessuna porta aperta, nessun processo persistente da monitorare. La semplicità operativa non è un compromesso: è la proprietà che rende il sistema manutenibile da una persona sola.
Stato e limiti
Il sistema è in produzione e funziona per uso personale. Ha limiti documentati.
La deduplicazione avviene dopo lo scraping e la classificazione: URL già presenti in Airtable consumano crediti Apify e token Claude prima di essere scartati. Il fix richiederebbe di spostare il check-duplicate prima del branch scraping. Non è stato fatto perché con il volume attuale il costo è trascurabile.
Il Markdown nel briefing non è renderizzato in Telegram. Due nodi in intake-briefing e intake-ricerca inviano ancora messaggi con il footer automatico di n8n. Sono i tre nodi rimanenti di una refactoring iniziata e quasi completata sugli altri workflow. La Fase 7 (comandi vocali via Whisper) non è implementata: non serviva per il valore che uso ogni giorno.
Riepilogo
Il problema era catturare link da mobile senza perdere contesto e senza aprire un laptop.
Sono quattro workflow con responsabilità separate, un prompt Claude con fallback esplicito su JSON malformato, una scelta di tunnel che azzera il costo infrastrutturale, un job scanner con criteri di esclusione calibrati su un profilo professionale e un MCP server con 17 tool progettati per non sovraccaricare il contesto LLM.
Lo uso ogni giorno.