Hay una diferencia entre tener los ingredientes y tener una receta. Una empresa puede tener logo, paleta, tipografía, campañas activas, un equipo de diseño que sabe lo que hace — y aun así no tener un sistema. Cada pieza sale bien. La coherencia depende de quién la hace ese día.
Ese era el problema de deRentas. Y no lo sabían del todo cuando llegamos a la sesión.
El problema que trajo Agus
Agus Irioni es diseñadora gráfica en deRentas, plataforma argentina que alquila autos a conductores de rideshare — principalmente Uber — para que puedan trabajar sin vehículo propio. Operan en Buenos Aires y Córdoba.
Agus llegó a Mate & Build con algo concreto: no había una forma estandarizada de crear ciertas tipologías de piezas como decks, templates y creativos según el canal de comunicación. La información estaba dispersa. Tenían cosas armadas en Figma, pero sin estructura ni sistema real detrás. Cada vez que alguien necesitaba producir una pieza nueva, arrancaba desde cero o buscaba en cinco lugares distintos para encontrar la versión correcta del logo o el color exacto.
El pedido inicial era concreto: estandarizar la producción de piezas y centralizar los assets de marca.
Pero cuando empezamos a mirar qué había realmente, el diagnóstico fue más preciso.
El problema real
A deRentas no le faltaban assets. Le faltaba una fuente de verdad.
Tenían un logo en varios formatos. Tenían una paleta de colores — el amarillo característico, el negro, el blanco. Tenían una tipografía (PP Neue Montreal, en 6 pesos). Tenían campañas activas de abril 2026, más de 35 piezas de referencia.
El problema era la capa siguiente: no había ningún lugar donde todo eso estuviera documentado con reglas explícitas, accesible para cualquier persona del equipo, y — esto es lo clave — legible para un agente de IA.
Cada área producía piezas a su manera. La coherencia visual no venía del sistema; venía de la memoria de las personas. Y eso no escala.
Si querías que Claude Code produjera una pieza on-brand de forma autónoma, no tenía dónde buscar qué significa "on-brand". No había un BrandBook. No había design tokens. No había specs de templates. No había nada que un agente pudiera consumir sin interpretación.
Ese era el problema real: la ausencia de una estructura que conecte el brand system con la automatización.
Por qué construimos esto (y no otra cosa)
Cuando entendimos el diagnóstico, tuvimos que decidir qué construir en 3 horas.
La tentación en este tipo de sesión es ir directamente a lo visible — armar el primer deck, mostrar algo concreto rápido. Lo descartamos. Si hacíamos eso, Agus se iba con una pieza. No con un sistema.
El trade-off fue claro: menos output visible en la sesión, más leverage a largo plazo. Un BrandBook bien armado en Markdown, con design tokens en JSON, vale más que 10 decks generados sobre una base frágil.
También decidimos no sobrescalar. No era el momento de armar un sistema de agentes complejo ni de cubrir todos los casos de uso posibles. El objetivo era construir la base correcta para que Agus la lidere y expanda desde ahí. Un sistema que tuviera sentido incluso sin nosotros.
Eso definió el scope: Claude Starter Kit → BrandBook → design tokens → templates → Figma MCP → skill /figma-deck. En ese orden, sin saltear pasos.
Cómo lo construimos
Arrancamos por donde siempre en Mate & Build: entender antes de construir. Pasamos los primeros 45 minutos revisando qué había. Los assets de logo, las tipografías, las campañas existentes de RRSS. Eso nos dio el insumo para lo que vino después.
Paso 1: Claude Starter Kit. Usamos el template que tengo para onboarding de proyectos en Claude Code — CLAUDE.md del proyecto, estructura de carpetas, contexto de empresa. Esto no es glamoroso, pero sin esta base el sistema no tiene dónde apoyarse. Todo esto corrió dentro de Google Antigravity — el IDE agéntico de Google que usamos para correr Claude Code, tomando unos mates.
Paso 2: BrandBook en Markdown. brand/BRANDBOOK.md como fuente de verdad. Documentamos el color system con 3 modos (amarillo, oscuro, claro), la tipografía PP Neue Montreal con sus 6 pesos y escalas por contexto, las reglas de uso del logo con variantes y clearspace, y la voz y tono rioplatense de la marca. No como PDF que nadie lee — como archivo Markdown que Claude Code lee directamente cada vez que necesita producir algo.
Paso 3: Design tokens en JSON. Acá es donde el brand system se vuelve algo que el tooling importa directo. colors.json, typography.json, spacing.json — los mismos valores del BrandBook, en formato estructurado. Y ojo: no es "para que la IA lo lea" — un LLM lee el color de un Markdown igual de bien. Los tokens pagan cuando los consume algo que NO es un agente — un build de CSS, un plugin de Figma — y como fuente única que evita que el color se vaya corriendo cuando el sistema escala.
Paso 4: Templates con specs. Cinco formatos definidos con sus dimensiones y reglas: deck 1920×1080px, carrusel 1080×1350px, story 1080×1920px, alerta WhatsApp 1200×1500px, doc A4. Para el deck de presentación: 7 tipos de slide, incluyendo estructura de deck de inversores de 14 slides.
Paso 5: Figma MCP. El Figma MCP corre como servidor local desde Figma Desktop — Claude Code se conecta ahí. Agus pudo crear componentes de marca en Figma de forma automática. Este paso fue el que empezó a hacer tangible lo que veníamos construyendo. Detalle de infra que descubrimos en el camino: sin Figma Desktop abierto el servidor MCP no existe, así que la primera corrida no aplicó tipografía hasta que bajamos la app y abrimos el archivo ahí.
Paso 6: Skill /figma-deck. El output final de la sesión. Un skill de Claude Code que genera presentaciones completas en Figma on-brand desde texto. El flujo: describís el deck → el skill planea la estructura → recopila el contenido → construye los slides uno a uno en Figma con el brand system ya incorporado. No hay que pensar en colores, tipografías ni specs. Eso ya está resuelto.
El momento "aha" de la sesión fue cuando vimos el primer slide generarse en Figma automáticamente, respetando el color system y la tipografía de deRentas, sin que nadie hubiera tocado Figma. Agus se quedó mirando la pantalla un segundo antes de decir algo.
Qué cambió — y qué queda
Al final de las 3 horas, deRentas tenía algo que no tenía al llegar: una fuente de verdad de su marca que un agente de IA puede consumir directamente.
El BrandBook existe. Los tokens están en JSON. Las specs de los 5 formatos están documentadas. El skill /figma-deck está en producción, generando su primer deck.
Lo que queda: Agus sigue expandiendo el sistema, con autonomía total sobre la base que construyó. Es una v1.0 diseñada para crecer — y la dueña del sistema es ella.
"Agus la rompió toda, armando un montón de cositas; ya tiene una buena estructura y sobre esto va a seguir trabajando."
En 3 horas, deRentas pasó de tener assets dispersos a tener un sistema de marca que un agente de IA puede operar de forma autónoma.
Una nota sobre timing: Claude Design
La sesión con Agus fue el 15 de abril. Dos días después, el 17, Anthropic Labs lanzó Claude Design. Una de sus features estrella: durante el onboarding, lee el codebase y los design files de un equipo y extrae un brand system — colores, tipografía, componentes — que después aplica en cada proyecto.
Acá vale ser honesto con cómo funciona Claude Design: no espera ni consume un tokens.json pre-armado. Hace lo contrario — extrae su propio brand system a partir de inputs desordenados (un Figma, una URL, un repo, imágenes). O sea, eso lo resuelve solo.
¿Entonces para qué tener tu propia versión armada a mano? Por control y portabilidad. Es portable y controlable — lo versionás con git, lo lee cualquier agente, no solo Claude Design. Si mañana usás otro modelo, otro IDE, otra herramienta, el sistema sigue funcionando. Y no dependés de qué tan bien lo extraiga una herramienta — tener el brand system explícito y versionado es la fuente de verdad que vos controlás, no la interpretación que hizo un onboarding automático.
Lo construimos así antes de que Claude Design existiera. Resulta que esa decisión envejeció bien.
Takeaways
La documentación de marca en Markdown no es solo para humanos. Es la interface entre tu brand y los agentes de IA que van a producir contenido. Si no está en un formato que Claude Code pueda leer, no existe para el sistema.
Tokens en JSON no son para el agente — un LLM lee el color de un Markdown igual. Pagan cuando los consume algo que NO es un agente (un build de CSS, un plugin de Figma) y como fuente única que evita drift cuando el sistema escala.
El diagnóstico define el build. Podríamos haber armado un deck en la primera hora y mostrar algo concreto rápido. En cambio, pasamos 45 minutos entendiendo el problema real. Ese tiempo fue el mejor gasto de la sesión.
El CLAUDE.md del proyecto es memoria operativa, no configuración. Es lo que hace que el sistema sea coherente en el tiempo, incluso cuando la persona que lo construyó no está presente.
Construir para que el sistema se expanda. El objetivo de la sesión no era entregar un sistema completo. Era construir la base correcta para que Agus la lidere y expanda desde ahí. Eso cambia qué construís y cómo lo documentás.