Un briefing diario con Claude: de Obsidian a Slack pasando por FileMaker

Cada mañana, antes de abrir el correo, ya sabemos qué importa del día. No porque seamos especialmente organizados, sino porque lo genera un agente automáticamente y lo deja en Slack antes de la primera reunión.

Ya hemos hablado de por qué conectar la IA con las herramientas de trabajo en MCP, el puente entre la inteligencia artificial y tus herramientas, y de qué acaba funcionando cuando una pyme pide IA en «Queremos IA». Aquí vamos a lo concreto: cómo está montado este briefing por dentro, en qué orden fuimos añadiendo piezas y qué decisiones de diseño pesaron más que la tecnología.

Primer paso: leer lo que ya está escrito

El punto de partida fue Obsidian. Allí tenemos las notas activas de cada proyecto (ya contamos por qué en por qué documentamos todo en Obsidian), así que el primer flujo fue sencillo: Claude lee esas notas, detecta qué tareas están bloqueadas o tienen urgencia, y el resumen llega a Slack.

Esto funciona porque la información ya existe. El agente no inventa el estado de un proyecto: lo lee de donde alguien lo apuntó. Si la nota está al día, el briefing es útil; si no lo está, el briefing lo refleja. Es una consecuencia incómoda y buena a la vez, porque empuja a mantener las notas vivas.

La conexión entre el modelo y el vault se hace mediante servidores MCP, el estándar que permite a un agente consultar herramientas concretas en lugar de recibir texto pegado a mano. Nada que el equipo tenga que hacer cada mañana: el flujo se ejecuta solo.

Segundo paso: añadir el estado de los proyectos desde FileMaker

Las notas de Obsidian cuentan lo que el equipo ha escrito, pero no todo el estado de un proyecto vive ahí. Los proyectos activos de clientes tienen su estado en una base de datos FileMaker, que es la herramienta en la que llevamos la gestión. El siguiente paso fue que el agente leyera también esa fuente.

El briefing pasó a incluir contexto técnico real: qué entregables están pendientes, qué cliente tiene revisión esta semana, qué hay que preparar. Es la diferencia entre un resumen de “lo que se ha escrito” y un resumen de “lo que hay que hacer”, porque combina lo narrativo (las notas) con lo estructurado (los registros).

Si tu empresa ya lleva su operativa en FileMaker, este es el patrón que más fácil se traslada: el dato ya está ordenado, solo falta que alguien (o algo) lo consulte y lo presente. Es parte de lo que hacemos en inteligencia artificial y en aplicaciones FileMaker.

Cómo es hoy, por dentro

Con el tiempo el briefing ha crecido, pero sigue siendo una tarea programada que se lanza sola a primera hora, de lunes a viernes. En cada ejecución junta, por este orden:

• Lo que ha cambiado en la documentación en las últimas 24 horas, resumido en un párrafo: quién ha escrito qué y en qué proyectos.
• Los calendarios, para saber qué reuniones hay ese día.
• El estado de proyectos y oportunidades desde FileMaker, y las tareas pendientes de cada uno.

Con eso envía un mensaje general al canal del equipo y, además, uno personal a cada uno de los tres, con lo que le toca a él. Si ese día hay reunión interna, deja preparada también la nota con el orden del día, para que la reunión empiece sobre algo escrito. Y si alguna fuente falla, lo dice y sigue con las demás: un briefing incompleto que llega vale más que uno perfecto que no sale.

Lo que más nos ha sorprendido es que no solo informa: a veces avisa de patrones. Una mañana señaló que el número de tareas vencidas llevaba varios días anormalmente alto y sin moverse, que la mayoría eran tareas antiguas del fondo de la lista que nadie había vuelto a tocar, y propuso revisar si estábamos manteniendo bien las fechas de vencimiento. Tenía razón, y era el tipo de cosa que nadie mira hasta que se ha convertido en ruido.

No es magia: son un par de servidores MCP y criterio

Visto desde fuera puede parecer sofisticado. Por dentro no lo es tanto: un par de servidores MCP bien configurados que dan acceso al agente a las notas y a la base de datos, un modelo que procesa lo que lee y un canal, Slack, donde se entrega el resultado.

Lo que sí llevó trabajo, y lo que de verdad marca la diferencia, fue pensar qué información merece estar ahí a primera hora. Un briefing que lo cuenta todo es otro documento que no se lee. La pregunta que nos hicimos fue qué necesitamos saber para empezar el día bien: qué está bloqueado, qué es urgente, qué tiene fecha cerca. Todo lo demás sobra por la mañana, aunque exista en las fuentes.

Lo que aprendimos montándolo

La automatización útil no es la que impresiona, es la que te cambia el primer cuarto de hora del día. Esa es la idea que nos llevamos, y condiciona cómo montamos cualquier flujo nuevo:

• Empezar por lo que ya está escrito. Antes de conectar sistemas complejos, comprobar qué información útil existe ya y está accesible.
• Añadir fuentes de una en una. Primero las notas, después FileMaker: cada paso añade contexto sobre una base que ya funciona.
• Decidir qué información merece estar. El tiempo de diseño se va más en recortar que en añadir.

No vamos a ponerle una cifra de horas ahorradas. Lo que sí notamos es que el primer rato del día es distinto: se empieza sabiendo por dónde tirar, en lugar de averiguarlo abriendo tres herramientas.

Para quién tiene sentido y para quién no

Un flujo así tiene sentido si ya hay información útil dispersa en varias herramientas y alguien dedica tiempo cada día a juntarla. Tiene menos sentido si la información no está escrita en ningún sitio, porque entonces el problema previo es ese, y automatizar solo lo haría más visible.

Y conviene tener presente que el briefing prepara la información, no decide por nadie. Lo que hacer con ella sigue siendo cosa de las personas. Si te interesa ver qué información de tu empresa podría llegar así a primera hora, puedes escribirnos desde contacto.