# Alejandro Rioja — ES > Alejandro Rioja — AI agent systems for founders. Plus posts on growth, marketing, sales, ops, and business from inside live P&Ls. Site: https://alejandrorioja.com/es/ Author: Alejandro Rioja Language: es --- ## Agentes de IA con Supervisión Humana: Cuándo Construir una Puerta de Aprobación (y Cuándo No) Source: https://alejandrorioja.com/es/human-in-the-loop-ai-agents-when-to-build-an-approval-gate/ Published: 2026-07-23 Tags: AI Agents, Operations TL;DR: Una puerta de aprobación tiene sentido cuando un error es costoso, irreversible o de cara al cliente — y cuando un humano puede detectarlo a tiempo. No tiene sentido cuando el volumen es demasiado alto para revisar, el error es barato de corregir o los humanos aprueban sin leer. Uso cuatro preguntas para decidir, y la mayoría de mis 30+ agentes en producción no tienen ninguna puerta de aprobación. ## Tabla de contenidos _Publicado julio 2026._ **TL;DR:** Una puerta de aprobación tiene sentido cuando un error es costoso, irreversible o de cara al cliente — y cuando un humano puede detectarlo a tiempo. No tiene sentido cuando el volumen es demasiado alto para revisar, los errores son baratos de corregir o los humanos aprueban sin leer. Uso cuatro preguntas para decidir, y la mayoría de mis 30+ agentes en producción funcionan completamente automatizados. **Lectura del operador:** Gestiono agentes en dos negocios — una marca de consultoría y Pickleland, una instalación de pádbol en Pflugerville, TX. Al principio puse puertas de aprobación en todas partes porque se sentía "seguro." En pocas semanas tenía un canal de Slack lleno de notificaciones que nadie leía, y agentes técnicamente supervisados pero prácticamente sin supervisión. Eso es peor que ninguna puerta: la ilusión de supervisión sin la sustancia. Este artículo explica cómo razono la decisión ahora. ## Qué es realmente una puerta de supervisión humana En su forma más simple, una puerta de aprobación es una pausa en el flujo de trabajo de un agente donde un humano debe confirmar antes de que el agente continúe. El agente redacta un correo — un humano lo aprueba antes de enviarlo. El agente marca una transacción — un humano la revisa antes de procesar el reembolso. La puerta puede ser síncrona (el agente bloquea hasta que alguien aprueba) o asíncrona (el agente pone la acción en cola, envía una notificación y un humano aprueba desde un panel o mensaje de Slack a su tiempo). Asíncrono es casi siempre mejor para cualquier cosa que no sea crítica en tiempo, porque las puertas síncronas crean contrapresión en la cola y rompen las garantías de fiabilidad del agente. Lo que una puerta no es: un bucle de reintentos, un umbral de confianza o un retroceso a un modelo más simple. Esos son mecanismos de manejo de errores dentro del agente. Una puerta de aprobación trata sobre el juicio humano entrando en el bucle — deliberadamente, en un punto específico, por una razón. ## Las cuatro preguntas que hago Antes de añadir una puerta, respondo cuatro preguntas. Un "sí" en cualquiera es una señal para considerar una. Un "sí" en las cuatro significa que la puerta es fundamental. **1. ¿La acción es irreversible (o costosa de revertir)?** Enviar un correo a 10.000 personas no se puede deshacer. Enviar un pago no se puede retirar fácilmente. Eliminar un registro de base de datos sin copia de seguridad es permanente. La irreversibilidad es el argumento más fuerte para una puerta, porque el agente no puede deshacer lo que hizo. Compáralo con: etiquetar una consulta entrante con una categoría. Si la etiqueta es incorrecta, la corriges en dos clics. No se necesita puerta. **2. Si el agente se equivoca, ¿quién paga?** Una etiqueta interna incorrecta — pago unos segundos corrigiéndola. Un correo de cara al cliente incorrecto — el cliente paga con una mala experiencia, y yo pago con pérdida de confianza. Una transacción financiera incorrecta — pago con dinero real y posiblemente riesgo de cumplimiento. Los agentes que afectan solo a sistemas internos pueden tolerar más error sin una puerta. Los agentes que tocan clientes o dinero necesitan ganarse el derecho de funcionar sin supervisión. **3. ¿Puede un humano detectar realmente el error antes de que importe?** Esta es la pregunta que la mayoría de la gente omite, y es la que elimina más puertas que cualquier otra. Si un agente procesa 500 elementos por hora y recibes una notificación de Slack por elemento, nadie va a leer los 500. Estás creando fatiga de alertas, no supervisión. La matemática es simple: una puerta solo añade valor si un humano puede revisar de forma realista el elemento marcado en la ventana de tiempo disponible. Si el agente es de alto volumen y rápido, la puerta o bien necesita ser muy selectiva (marcando solo los casos límite) o eliminarse. **4. ¿Los humanos leen de forma fiable lo que el agente presenta?** Si tu cola de aprobación se llena y la gente aprueba sin leer, la puerta es peor que ninguna puerta — crea una falsa confianza de que un humano comprobó el trabajo. He estado en esta situación. La solución no es presionar más a la gente; es replantearse si la puerta tiene sentido. ## Cuándo las puertas claramente tienen sentido Estos son los patrones donde siempre añado una puerta, sin excepciones: - **Comunicaciones externas irreversibles** — correos, SMS, publicaciones en redes sociales que van a personas reales. El agente redacta; un humano envía. Según el volumen permita. - **Acciones financieras por encima de un umbral** — cualquier cosa que mueva dinero tiene una puerta si supera un límite en dinero que establezco según el contexto. Por debajo del límite, los registros de auditoría son suficientes. - **Patrones nuevos que el agente no ha visto antes** — si el clasificador del agente marca algo como "desconocido" o fuera de su distribución de entrenamiento, eso es una escalada forzada. Manejo esto con un umbral de confianza que enruta los elementos de baja confianza a una cola humana en lugar de bloquear el flujo principal. - **Salidas sensibles al cumplimiento** — cualquier cosa que toque HIPAA, PCI, avisos legales o contenido financiero regulado es revisada por una persona. No porque el agente se equivoque más a menudo, sino porque la responsabilidad requiere un humano en la cadena. ## Cuándo las puertas silenciosamente matan el producto Estos son los patrones donde una puerta se siente segura pero silenciosamente rompe la adopción: - **Operaciones de alto volumen y reversibles** — si puedes deshacerlo en dos clics y ocurre 200 veces al día, la fatiga de revisión ganará. Sin puerta; buenos registros de auditoría en su lugar. - **Flujos de trabajo sensibles al tiempo** — un agente que responde a consultas de clientes entrantes en 30 segundos no debería tener una puerta síncrona. Para cuando alguien apruebe, el cliente habrá seguido adelante. - **Tareas donde el humano tiene menos contexto que el agente** — si el agente ha leído 50 páginas de contexto para hacer una clasificación y el revisor obtiene un resumen de una línea, la revisión es teatro. El humano no puede mejorar realmente el juicio del agente. - **Enriquecimiento y etiquetado interno** — etiquetar registros de CRM, categorizar gastos, resumir notas de reuniones. Las apuestas no justifican la interrupción. Deja correr el agente; comprueba aleatoriamente según un horario. ## Los tres patrones de puerta que realmente implemento Cuando una puerta está justificada, elijo uno de tres implementaciones: **1. Aprobación asíncrona por Slack/correo** El agente completa su borrador, publica un mensaje en un canal de Slack designado con la acción propuesta y un botón de aprobar/rechazar, y hace pausa. Uso Cloudflare Queues para mantener la acción pendiente, y un Worker separado que escucha el webhook de aprobación antes de reanudar. Es el patrón que describo en [agentes activados por eventos vs. programados](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) — el evento de aprobación es el disparador. Funciona bien para: borradores de correo, contenido de redes sociales, actualizaciones significativas de CRM. **2. Escalada basada en confianza** El agente funciona completamente automatizado para salidas de alta confianza (digamos, ≥0,85 de confianza en un esquema estructurado) y enruta los elementos de baja confianza a una cola humana. El humano solo ve los casos límite ambiguos — no cada elemento. Es el patrón escalonado que uso en [la matemática de costes de agentes](/ai-agent-cost-math-when-haiku-beats-sonnet/): el modelo barato maneja la mayor parte, los casos límite escalan. Funciona bien para: clasificación, enrutamiento, triaje — cualquier tarea donde la mayoría de los elementos son claros pero algunos genuinamente necesitan una decisión humana. **3. Revisión en panel con aprobación por lotes** En lugar de una puerta por elemento, todas las salidas del agente van a un panel de revisión. Un humano revisa en lote — por ejemplo, cada mañana — y aprueba o corrige en grupo. El agente sigue funcionando; el trabajo del humano es escanear en busca de patrones y corregir valores atípicos, no aprobar cada elemento individualmente. Funciona bien para: generación de contenido, redacción de informes, resúmenes programados. ## La trampa de la fatiga de alertas Cada puerta que añades es un impuesto permanente sobre la atención de alguien. El riesgo no es solo que una puerta se ignore — es que tres puertas creen un canal de Slack ruidoso, que entrena a la gente a descartar todas las notificaciones, lo que significa que una futura puerta que realmente importa también se descarta. La disciplina que he construido: cada puerta tiene un propietario explícito y un SLA explícito. Si nadie revisa constantemente dentro del SLA, la puerta se elimina y se reemplaza con un rastro de auditoría. Una puerta sin mantenimiento no es una red de seguridad — es una responsabilidad. Hago una auditoría mensual de todas las colas de aprobación: cuántos elementos llegaron, cuántos fueron aprobados dentro del SLA, cuántos fueron aprobados sin modificación (lo que sugiere que el humano no está realmente revisando). Si una cola muestra un 95% de aprobación el mismo día con un 0% de modificaciones, la elimino. ## Conectándolo a la fiabilidad del agente Una puerta es una capa de una pila de fiabilidad, no toda la pila. Mi pila de fiabilidad completa para un agente en producción: 1. **Arnés de evaluación** — confirma que el agente produce salidas correctas antes de implementar. 2. **Salidas estructuradas con validación de esquema** — la salida del agente está restringida a un esquema tipado; si no analiza, la ejecución falla con un error reintentable antes de que se tome ninguna acción. 3. **Umbral de confianza** — las salidas de baja confianza van a revisión humana en lugar de proceder. 4. **Registro de auditoría** — cada acción que toma el agente se registra con entradas, salidas y metadatos de llamadas al modelo. 5. **Puerta de aprobación humana** — solo para las acciones donde lo anterior no es suficiente. Las puertas son la última línea de defensa, no la primera. Si tu agente es tan poco fiable que necesitas una puerta en cada acción, el problema subyacente es la cobertura de evaluación y el diseño de prompts, no el proceso de supervisión. ## Mi regla general Si no querría que un empleado junior hiciera esto sin consultarme primero, el agente necesita una puerta. Si dejaría que un empleado junior lo hiciera sin pensarlo dos veces, el agente debe funcionar sin supervisión. Ese encuadre ayuda porque fuerza una comparación con un proceso humano real, no un cálculo de riesgo abstracto. La mayoría de los agentes hacen cosas que dejaría que una persona capaz manejara sin supervisión. Las puertas son para las excepciones. ## FAQ ### ¿Cómo manejo un agente que necesita aprobación pero funciona a alto volumen? Cambia la arquitectura: no requieras aprobación por elemento — requiere aprobación por patrón. Deja correr al agente, pero haz que presente anomalías estadísticas para revisión humana. Comprueba aleatoriamente una muestra. Reemplaza las puertas por elemento con supervisión probabilística. ### ¿Qué pasa si un error podría causar daños graves pero no puedo permitirme una revisión humana completa? Eso suele ser una señal de no implementar el agente para esa acción todavía. Alternativamente, usa un umbral de confianza para que el agente solo actúe cuando está muy seguro y escale todo lo demás. Una tasa de escalada alta al inicio es esperada; debería bajar conforme mejora la cobertura de evaluación del agente. ### ¿Existe una herramienta que facilite la aprobación asíncrona? El patrón en sí es sencillo de implementar en Cloudflare Workers + Queues, y el constructor de flujos de trabajo de Slack maneja la interfaz de aprobación sin código personalizado. Si usas [Claude](/recommends/claude) como capa de modelo, los patrones de uso de herramientas del SDK de Anthropic facilitan definir una herramienta de "escalar" que el agente puede llamar cuando le falta confianza. --- ## Claude Tool Use: Cómo Doy Capacidades Reales a Mis Agentes de IA Source: https://alejandrorioja.com/es/claude-tool-use-production-agents/ Published: 2026-07-21 Tags: AI Agents, Claude TL;DR: Claude tool use permite que tu agente tome acciones — no solo generar texto. Defines herramientas como esquemas JSON, Claude decide cuándo llamarlas, y tu código ejecuta la acción en el mundo real. El bucle tiene tres pasos: enviar mensaje → recibir bloque tool_use → ejecutar y devolver resultado. He implementado esto en más de 15 agentes de producción en Cloudflare Workers. El fallo casi nunca es la IA — son los resultados ambiguos que regresan de las herramientas. ## Tabla de contenidos _Actualizado julio 2026._ **TL;DR:** Claude tool use permite que tu agente tome acciones — no solo generar texto. Defines herramientas como esquemas JSON, Claude decide cuándo llamarlas, y tu código ejecuta la acción en el mundo real. El bucle tiene tres pasos: enviar mensaje → recibir bloque tool_use → ejecutar y devolver resultado. He implementado esto en más de 15 agentes de producción en Cloudflare Workers. El fallo casi nunca es la IA — son los resultados ambiguos que regresan de las herramientas. **[Lectura del operador]** Dirijo más de 30 agentes de IA en producción entre una marca de consultoría y Pickleland, una instalación de pádel pickleball en Pflugerville, TX. Aproximadamente la mitad usa tool use — la función de la API de Claude que permite al modelo llamar funciones que tu código define. Este es el patrón al que he llegado tras implementar e iterar en producción. ## Por qué el tool use cambia lo que un agente puede hacer Sin herramientas, un agente solo puede generar texto. Eso es útil para resumir, redactar y clasificar — pero no es lo que la mayoría de las automatizaciones empresariales realmente necesitan. Las automatizaciones necesitan buscar información, escribir en bases de datos, llamar a APIs, enviar mensajes. El tool use es la forma en que le das a Claude ese acceso. Defines un conjunto de herramientas como esquemas JSON. Claude lee los esquemas, decide qué herramienta llamar y con qué argumentos, y devuelve un bloque de contenido `tool_use` estructurado. Tu código ejecuta la función real. Claude obtiene el resultado y decide qué hacer a continuación — incluido llamar a otra herramienta o producir una respuesta de texto final. La clave: **Claude decide cuándo y si llamar a una herramienta.** Tú defines las capacidades. El modelo razona sobre cuándo usarlas. ## Cómo funciona el flujo de la API El bucle de tool use tiene tres pasos. Puedes ejecutar este bucle una o varias veces dependiendo de cuántas llamadas de herramienta haga el modelo. **Paso 1: Envía tu mensaje con las herramientas definidas** ```typescript const response = await anthropic.messages.create({ model: "claude-haiku-4-5-20251001", max_tokens: 1024, tools: [ { name: "check_court_availability", description: "Check if a court is available at a given date, time, and duration", input_schema: { type: "object", properties: { date: { type: "string", description: "Date in YYYY-MM-DD format", }, time: { type: "string", description: "Start time in HH:MM format (24h)", }, duration_minutes: { type: "number", description: "Duration of the booking in minutes", }, }, required: ["date", "time", "duration_minutes"], }, }, ], messages: [ { role: "user", content: "Is a court available tomorrow at 2pm for 90 minutes?", }, ], }); ``` **Paso 2: Comprueba si Claude quiere llamar a una herramienta** ```typescript if (response.stop_reason === "tool_use") { const toolUseBlock = response.content.find( (block): block is Anthropic.ToolUseBlock => block.type === "tool_use" ); if (!toolUseBlock) throw new Error("Expected tool_use block"); // Run your actual function const toolResult = await checkCourtAvailability( toolUseBlock.input as CourtAvailabilityInput ); // Step 3: Return the result to Claude const finalResponse = await anthropic.messages.create({ model: "claude-haiku-4-5-20251001", max_tokens: 1024, tools: [ /* same tools as before */ ], messages: [ { role: "user", content: "Is a court available tomorrow at 2pm for 90 minutes?", }, { role: "assistant", content: response.content }, { role: "user", content: [ { type: "tool_result", tool_use_id: toolUseBlock.id, content: JSON.stringify(toolResult), }, ], }, ], }); // finalResponse.content now has the text answer } ``` Ese es el patrón completo. Tres interacciones con la API por llamada de herramienta: definir herramientas → recibir bloque `tool_use` → devolver resultado. ## Ejemplo real: el verificador de disponibilidad de Pickleland Pickleland es una instalación de pickleball. Recibimos consultas de reserva en Facebook Messenger, en comentarios y a través de un chatbot. La pregunta casi siempre es alguna variación de "¿están abiertos el sábado a las 3pm?" o "¿puedo reservar una cancha para mi grupo de 8 personas?" El agente verificador de disponibilidad usa tool use para consultar el sistema de reservas real en tiempo real, en lugar de dar una respuesta enlatada. Aquí está el agente completo — simplificado pero fiel a producción: ```typescript // workers/availability-checker.ts import Anthropic from "@anthropic-ai/sdk"; const anthropic = new Anthropic(); const AVAILABILITY_TOOLS: Anthropic.Tool[] = [ { name: "check_availability", description: "Check court availability for a date, time, and group size. Returns available courts and their prices.", input_schema: { type: "object", properties: { date: { type: "string", description: "YYYY-MM-DD" }, start_time: { type: "string", description: "HH:MM (24h)" }, duration_minutes: { type: "number" }, players: { type: "number", description: "Number of players" }, }, required: ["date", "start_time", "duration_minutes"], }, }, { name: "get_pricing", description: "Get current pricing for court rentals and open play sessions", input_schema: { type: "object", properties: { session_type: { type: "string", enum: ["court_rental", "open_play", "clinics"], }, }, required: ["session_type"], }, }, ]; export async function handleInquiry( userMessage: string, env: Env ): Promise { const messages: Anthropic.MessageParam[] = [ { role: "user", content: userMessage }, ]; // Agentic loop — keep going until stop_reason is "end_turn" while (true) { const response = await anthropic.messages.create({ model: "claude-haiku-4-5-20251001", max_tokens: 512, system: "You are the booking assistant for Pickleland, a pickleball facility in Pflugerville, TX. " + "Use the tools to look up real availability and pricing. Never make up availability or prices. " + "If the customer wants to book, direct them to pickleland.com/book.", tools: AVAILABILITY_TOOLS, messages, }); // Push the assistant's response into message history messages.push({ role: "assistant", content: response.content }); if (response.stop_reason === "end_turn") { const textBlock = response.content.find( (b): b is Anthropic.TextBlock => b.type === "text" ); return ( textBlock?.text ?? "I wasn't able to answer that — please call us directly." ); } if (response.stop_reason === "tool_use") { // Process ALL tool calls in this response (Claude can request multiple at once) const toolResults: Anthropic.ToolResultBlockParam[] = []; for (const block of response.content) { if (block.type !== "tool_use") continue; let result: unknown; switch (block.name) { case "check_availability": result = await checkAvailability( block.input as AvailabilityInput, env ); break; case "get_pricing": result = await getPricing(block.input as PricingInput, env); break; default: result = { error: `Unknown tool: ${block.name}` }; } toolResults.push({ type: "tool_result", tool_use_id: block.id, content: JSON.stringify(result), }); } // Return all tool results in a single user message messages.push({ role: "user", content: toolResults }); } } } ``` Dos cosas a destacar aquí. **El bucle agéntico.** Sigo hasta que `stop_reason === "end_turn"`. Claude puede llamar a `check_availability`, decidir que también necesita precios, llamar a `get_pricing`, y luego producir la respuesta final — son tres llamadas a la API por un único mensaje del usuario. El bucle maneja esto sin lógica especial. **Múltiples llamadas de herramienta por turno.** Claude puede devolver múltiples bloques `tool_use` en una sola respuesta. Proceso todos ellos y devuelvo todos los resultados en un único mensaje `user`. Si los procesas uno a la vez y los devuelves individualmente, rompes el flujo de la conversación y desperdicias tokens. ## Ejemplo real: el agente de investigación de leads Mi marca de consultoría usa un agente de investigación que enriquece los leads entrantes antes de hablar con ellos. Cuando alguien rellena el formulario de contacto, el agente investiga su empresa y extrae lo que necesito saber antes de la llamada. Las definiciones de herramientas para este incluyen una herramienta de escritura — y aquí es donde el patrón se vuelve interesante: ```typescript const RESEARCH_TOOLS: Anthropic.Tool[] = [ { name: "search_company", description: "Search for information about a company", input_schema: { type: "object", properties: { company_name: { type: "string" }, website: { type: "string", description: "Company website if known" }, }, required: ["company_name"], }, }, { name: "save_research", description: "Save the completed research summary to Airtable. Call this when all research is complete.", input_schema: { type: "object", properties: { company_summary: { type: "string" }, estimated_size: { type: "string", enum: ["1-10", "11-50", "51-200", "200+"], }, likely_use_case: { type: "string" }, priority: { type: "string", enum: ["high", "medium", "low"] }, notes: { type: "string" }, }, required: [ "company_summary", "estimated_size", "likely_use_case", "priority", ], }, }, ]; ``` `save_research` es lo que llamo una **herramienta de escritura** — su propósito no es obtener información, sino confirmar el resultado de Claude en una base de datos en forma estructurada. Uso este patrón en lugar de intentar parsear JSON de una respuesta de texto. Claude sabe cuándo ha terminado la investigación y llama a `save_research` con campos correctamente tipados. No escribo ningún parser. Esta es la aplicación más limpia del tool use: define una herramienta de "acción final" con el esquema exacto que quieres, y Claude entrega la salida estructurada a través de la llamada a la herramienta. Sin parseo de texto, sin regex, sin validación JSONSchema de salida en texto libre. ## Una herramienta vs. muchas El instinto al empezar con tool use es construir una herramienta gigante que lo haga todo. Resiste esto. Las herramientas pequeñas y enfocadas son mejores por tres razones: 1. **Claude razona mejor sobre herramientas pequeñas.** Una herramienta llamada `get_court_status` que devuelve disponibilidad es más fácil de razonar para el modelo que una herramienta llamada `manage_facility` que toma un parámetro `mode` y ramifica internamente. 2. **Las herramientas pequeñas son más fáciles de probar.** Cada herramienta es una función TypeScript que puedes testear unitariamente de forma independiente del LLM. Deberías hacerlo — los errores en las herramientas son difíciles de depurar dentro de una conversación activa. 3. **Claude puede paralelizar herramientas pequeñas.** Si dos herramientas no dependen entre sí, Claude puede llamarlas en la misma respuesta y tú las procesas en paralelo. Esto solo funciona si las herramientas son genuinamente independientes. La excepción: herramientas que necesitan acceso a mucho estado interno compartido. Si la función necesita 10 variables de la misma fuente de datos, una herramienta con un esquema más rico supera a 10 herramientas que cada una accede a la base de datos por separado. Mi regla general: empieza con una herramienta por capacidad distinta. Fusiona herramientas solo cuando veas que Claude las llama juntas en cada solicitud. ## Implicaciones de coste El tool use agrega tokens. Cada definición de herramienta va al contexto del prompt del sistema. Cada bloque `tool_use` y `tool_result` consume tokens en el historial de la conversación. Para un bucle agéntico multi-turno, esto se acumula rápidamente. Para el verificador de disponibilidad de Pickleland, una conversación típica ejecuta 3–4 llamadas a la API en total (mensaje inicial + 1–2 llamadas de herramienta + respuesta final), cada una procesando 600–900 tokens. A los precios de Haiku, esto cuesta menos de $0,001 por consulta. Como explico en [el post sobre el cálculo de costes de agentes de IA](/ai-agent-cost-math-when-haiku-beats-sonnet/), Haiku maneja las tareas de llamada a herramientas bien definidas de forma fiable y es 10× más barato que Sonnet para el mismo volumen de tokens. El agente de investigación de leads funciona con Sonnet porque las decisiones de juicio — priorizar un lead, estimar el ajuste — requieren más capacidad de razonamiento de la que Haiku ofrece de forma fiable en inputs abiertos. La matemática sigue funcionando porque se ejecuta con poca frecuencia (algunas veces por semana, no miles por día). La elección del modelo sigue la complejidad de la tarea, no la preferencia personal. ## El fallo que nadie menciona El fallo más común que veo en el tool use en producción no es que Claude llame a la herramienta equivocada. Es la herramienta que devuelve algo que Claude no puede razonar claramente. Si tu herramienta devuelve un objeto de base de datos en crudo con 40 campos, Claude se confunde sobre qué campos importan. Si tu herramienta lanza una excepción (que aparece como un crash del Worker en lugar de un resultado de herramienta), el bucle se rompe silenciosamente. Si tu herramienta devuelve `null` cuando significa "sin resultados", Claude no sabe si reintentar o rendirse. Tres reglas para los resultados de herramientas: **Devuelve resultados concisos y explícitos.** `{ available: true, courts: ["Court 3", "Court 5"], price_per_hour: 20 }` — no la fila completa de la base de datos. **Captura errores dentro de la función de la herramienta y devuélvelos como resultados estructurados.** `{ error: "booking system timeout", retry: true }` — no una excepción lanzada que crashea el Worker. **Haz que "sin resultados" sea explícito.** `{ available: false, next_available: "2026-07-23T14:00:00Z" }` — no `null` ni un array vacío sin contexto. Claude razona mucho mejor sobre señales claras que sobre valores de retorno ambiguos. Cada hora que he pasado depurando tool use en producción ha sido por resultados poco claros, no por razonamiento del modelo. ## La conclusión del operador El tool use es la función que convierte a Claude de un generador de texto en un operador. Define herramientas enfocadas con esquemas de entrada claros. Gestiona todos los bloques `tool_use` en una única respuesta al modelo. Ejecuta el bucle agéntico hasta que `stop_reason === "end_turn"`. Devuelve resultados limpios y concisos desde tus funciones de herramienta — no objetos de datos en crudo, no excepciones lanzadas, no nulos ambiguos. El modelo maneja el razonamiento. Tu código maneja las acciones en el mundo real. Mantén esos dos trabajos claramente separados y la arquitectura seguirá siendo mantenible incluso a medida que añadas herramientas. Si estás construyendo tu primer agente con tool use, empieza con el patrón del verificador de disponibilidad anterior — una herramienta, un propósito, un bucle agéntico. Impleméntalo. Luego añade la segunda herramienta. --- **Relacionado:** [El stack de agentes que uso para ejecutar 30+ agentes en producción](/the-agent-stack-i-use-to-run-30-production-agents-no-python/) · [Haiku vs Sonnet: el cálculo de costes para tareas de agentes](/ai-agent-cost-math-when-haiku-beats-sonnet/) · [Agentes disparados por eventos vs programados: qué patrón usar](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) **¿Construyendo un agente con tool use y te has atascado?** [Contáctame](/contact/) — diseño y construyo arquitecturas de agentes de producción para equipos de operadores. ## Preguntas frecuentes ### ¿Funciona el tool use de Claude con todos los modelos? Sí — el tool use es compatible con todos los modelos actuales de Claude. [Claude](/recommends/claude) Haiku maneja herramientas bien definidas con esquemas claros de forma fiable y es la opción más económica para tipos de tareas de alto volumen. Sonnet maneja mejor las decisiones de llamada a herramientas más ambiguas o abiertas. Empieza con Haiku; sube si la calidad de la salida no es suficiente. ### ¿Cuál es la diferencia entre el tool use de Claude y el function calling de OpenAI? Mecánicamente idénticos. OpenAI acuñó "function calling"; Anthropic lo llama "tool use". En ambos casos: defines esquemas JSON, el modelo devuelve llamadas estructuradas, tu código ejecuta la función. La forma de la API difiere, pero el concepto es el mismo. ### ¿Puede Claude llamar a múltiples herramientas en una sola respuesta? Sí. Claude puede devolver múltiples bloques `tool_use` en una sola respuesta `assistant`. Procésalos todos y devuelve todos los resultados en un único mensaje `user`. Consulta el patrón del bucle agéntico en el ejemplo de Pickleland — el bucle `for` sobre `response.content` lo maneja correctamente. ### ¿Cuántas herramientas debo definir por agente? Me mantengo por debajo de 8–10 herramientas por agente. Más allá de eso, he visto que Claude ocasionalmente elige la herramienta equivocada en el primer intento, lo que desperdicia tokens en un bucle de corrección. Si necesitas más de 10 capacidades, divide el agente en múltiples agentes con conjuntos de herramientas especializados en lugar de construir un agente que lo sepa todo. ### ¿Debo usar el tool use para obtener salida estructurada? Sí — el patrón de herramienta de escritura `save_research` es más limpio que pedirle a Claude que devuelva JSON en un bloque de texto y luego parsearlo. Define una herramienta de "acción final" con el esquema exacto que quieres. Claude la llamará con campos correctamente tipados cuando haya terminado. No necesitas un parser. --- ## Cómo Evalúan Realmente los Motores de Búsqueda la Calidad del Contenido en 2026 Source: https://alejandrorioja.com/es/how-search-engines-evaluate-content-quality/ Published: 2026-07-20 Tags: SEO, GEO ## Tabla de contenidos _Publicado en julio de 2026._ **TL;DR:** Los motores de búsqueda y los motores de IA dejaron ambos de puntuar páginas de forma aislada. Puntúan sitios — profundidad de cobertura sobre un tema, señales de confianza que resisten el escrutinio y consistencia a lo largo de meses, no un artículo excelente aislado. Gestiono 384 posts en inglés traducidos a 13 idiomas y rastreo semanalmente si me citan en ChatGPT, Perplexity y Google AI Overviews. El patrón es consistente: los posts aislados se estancan, los clusters se acumulan, y las señales de confianza que mueven las tasas de citación son aburridas, estructurales y baratas de construir. **Lectura del operador:** No estoy teorizando sobre la calidad del contenido — dirijo el motor de contenido de este sitio y observo lo que pasa con las tasas de citación cuando cambio algo. Este post está construido enteramente a partir de cosas que he medido en alejandrorioja.com: tamaños reales de cluster, un experimento real de citación de seis semanas, pruebas reales de schema markup. Nada aquí es una suposición sobre cómo "probablemente" funcionan los algoritmos. ## La calidad dejó de ser una cuestión por página hace ya tiempo El modelo mental que la mayoría de la gente todavía lleva encima es: escribe un buen artículo y posicionará. Eso nunca fue del todo cierto, y ahora es activamente engañoso para cualquier cosa que vaya más allá de un término de cola larga muy específico. Tengo una forma directa de verlo en mi propio sitio. Publico dentro de un puñado de clusters reales — un cluster de 29 posts sobre Agentes de IA y Claude, un cluster de explicadores de modelo de negocio "Cómo Gana Dinero X" que ya suma 20 posts (Google, OpenAI, Anthropic, Uber, Salesforce, y más), y un gran cluster de SEO/GEO que es el tema individual más grande del sitio por número de etiquetas. Un post aislado en un tema que solo he tocado una vez se comporta de forma completamente distinta a un post que forma parte de uno de estos clusters, incluso cuando la pieza aislada está objetivamente mejor escrita. Los posts en cluster reciben más citaciones, posicionan de forma más estable y se recuperan más rápido después de una actualización de algoritmo. Los aislados suben de golpe o no lo hacen, y cuando no lo hacen, no hay autoridad circundante en la que apoyarse. Ese es el mecanismo real detrás de lo que a menudo se vende como una [estrategia de autoridad temática para IA](https://www.linkbuildinghq.com/blog/how-to-build-topical-authority-for-ai/) — no una puntuación de confianza mística, sino el hecho llano de que una página situada junto a otras 28 páginas sobre el mismo tema le da tanto al rastreador de Google como al paso de recuperación de un LLM más contexto corroborante en el que apoyarse. Escribí [la mecánica completa de esa estructura](/pillar-content/) de forma deliberada — la versión corta es que un cluster solo funciona si cada post dentro de él enlaza al pilar y el pilar enlaza de vuelta, de modo que el mapa temático sea explícito en lugar de algo que el rastreador tenga que reconstruir. La prueba práctica que aplico antes de publicar cualquier cosa nueva: ¿este post extiende un cluster que ya tengo, o inicia algo suelto y aislado? Las piezas sueltas no están prohibidas — algunas consultas genuinamente solo necesitan una página — pero sé de antemano que una pieza suelta compite únicamente con señales a nivel de página, sin nada del efecto acumulativo que un post de cluster obtiene gratis. ## "Valor real, no relleno" es una afirmación comprobable, no una sensación La versión genérica de este consejo dice "añade profundidad y contexto, no repitas información de fácil acceso". Cierto, pero inútil sin una forma de comprobarlo. Aquí está mi prueba real, aplicada a escala de verdad: tengo 384 posts en inglés. Cada uno se traduce a otros 12 idiomas mediante [un agente que construí exactamente para eso](/how-to-translate-one-blog-post-into-13-languages-with-one-agent/). Traducir es barato — todo el backlog de 341 posts costó unos 1,70 dólares en llamadas a la API con Haiku. Escribir no lo es. Si pudiera inflar el volumen reescribiendo ligeramente la misma idea en diez enfoques distintos, ese agente me dejaría escalar la duplicación con la misma facilidad con que escala la traducción. No lo hago, porque un enfoque duplicado no supera la prueba real: ¿esta página responde a una pregunta que ninguna otra página de mi sitio ya responde igual de bien o mejor? Ese es el filtro que importa más que cualquier guía de estilo. "Relleno" no es un problema de tono, es un problema de redundancia — una página que reformula a una página vecina sin añadir un ángulo, un dato o un ejemplo nuevo. Lo compruebo antes de publicar preguntándome si el nuevo post canibalizaría las citaciones de uno ya existente en lugar de añadir nueva superficie de citación. Si dos posts de mi sitio satisficieran igual de bien la misma consulta, uno de ellos es relleno, por muy bien escrito que esté. ## Señales de confianza que realmente he construido y medido "Fiabilidad" es el término más vago de cualquier artículo genérico de SEO, normalmente seguido de una lista tipo "cita fuentes, muestra experiencia, sé preciso" sin ninguna forma de verificar si algo de eso movió realmente algo. La versión concreta que aplico: schema markup, porque es la única señal de confianza que un motor de IA analiza de forma mecánica en lugar de inferir. Detallé [la implementación completa](/schema-markup-for-geo/) en otro post y profundicé en [qué tipos realmente compensan](/schema-markup-for-ai-engines-the-types-that-punch-above-their-weight/). La versión corta: `Article`/`BlogPosting` con un autor real nombrado y un `dateModified` honesto es el ancla de autoría; `FAQPage` y `HowTo` son los tipos de mayor impacto porque le entregan al modelo una pregunta ya respondida o un procedimiento ya estructurado en lugar de obligarlo a inferirlo de la prosa; el schema de `Person` y `Organization` existe para que el modelo no me confunda con alguien que comparte mi nombre. Nada de esto es abstracto para mí — es la intervención detrás de un resultado real. Aplicar una capa estructural de cuatro partes (bloque de TL;DR, pasos numerados, sección de preguntas frecuentes, citas de fuentes primarias) a 41 posts pilar que ya estaban activando Google AI Overviews llevó la frecuencia de citación de 4 de 41 a 19 de 41 a lo largo de seis semanas — [la prueba completa de seis semanas está documentada aquí](/google-ai-overview-citation-case-study/). Eso no es "añade señales de confianza y confía en que funcione". Es un antes/después medido en mis propias páginas, con la salvedad que el propio post deja clara: solo funcionó en páginas que ya tenían el piso de autoridad de posicionar entre los cinco primeros orgánicamente. La estructura amplifica una señal existente; no fabrica una de la nada. ## La consistencia se acumula, pero "consistencia" no significa actualizaciones constantes La afirmación genérica aquí suele ser "la frescura importa, pero no todo artículo necesita actualizarse", dicha sin ninguna cadencia real asociada. Aquí está la mía. No toco la mayoría de los posts después de publicarlos. Sí mantengo un conjunto rotativo de posts pilar y los actualizo cada 6-12 meses cuando cambian los hechos subyacentes — sale un modelo nuevo, cambia el precio de una herramienta, un dato queda desactualizado. `dateModified` solo cambia cuando el contenido realmente cambia; he probado a falsearlo y no funciona — los motores detectan una fecha adelantada sin una edición sustantiva, que es exactamente lo que también encontró el estudio de caso de AI Overview. La señal de consistencia que realmente vigilo cada semana no es la cadencia de publicación, es la cobertura de citaciones: paso semanalmente una lista rastreada de consultas críticas para el negocio por ChatGPT, Perplexity y Google, y registro si me citan — [la metodología está aquí](/how-to-measure-ai-search-traffic/). La cobertura de citaciones es un indicador adelantado — se mueve antes que el tráfico de referencia o el aumento de búsquedas de marca, así que es el número que me dice si un cluster está ganando autoridad de verdad con el tiempo o simplemente está ahí parado. Un sitio que publica una vez y luego se calla no recibe una segunda mirada en esa revisión semanal; un sitio que sigue extendiendo un cluster, sí. ## Qué recompensa realmente la evaluación "a nivel de sitio", capa por capa Los tres motores que rastreo no ponderan las mismas señales de forma idéntica. Esta es la tabla práctica que tengo en la cabeza al decidir dónde invertir esfuerzo: | Capa de calidad | Cómo se ve realmente en la práctica | Dónde lo he medido | | --- | --- | --- | | Profundidad temática | 20-30+ posts interconectados sobre un tema, el pilar enlazando a cada post del cluster y viceversa | Cluster de Agentes de IA (29 posts), cluster "Cómo Gana Dinero X" (20 posts) | | Extraíbilidad estructural | Bloque de TL;DR, pasos numerados, FAQ, alineados con la fraseología real de los usuarios | 4/41 → 19/41 citaciones en AI Overview en 6 semanas | | Autoría/confianza | Autor nombrado + `dateModified` preciso + schema de Person/Organization | Schema markup para GEO, desglose de tipos de schema | | Consistencia en el tiempo | Rastreo semanal de citaciones entre motores, no reescrituras constantes | Metodología de medición de búsqueda con IA | El modo de fallo que más veo en los consejos genéricos es tratar estas capas como una única puntuación de "calidad" indiferenciada. No lo son. Una página puede clavar la extraíbilidad estructural y aun así perder frente a una competidora con más profundidad temática. Una página puede estar dentro de un cluster profundo y aun así perder una citación concreta frente a una competidora más reciente y con mejor schema. Saber cuál es realmente el cuello de botella para una página determinada es la mayor parte del trabajo. ## Dónde se rompe esto — las salvedades honestas Prefiero señalar los límites antes que sobrevender el patrón: - **La autoridad de dominio sigue siendo una puerta de entrada.** La intervención de AI Overview solo funcionó en páginas que ya posicionaban entre las cinco primeras orgánicamente. La estructura amplificó una señal existente; no creó autoridad desde una página fría. - **Los motores divergen en lo que premian.** Al pasar los mismos 50 términos principales por ChatGPT y Google, encontré solo un 40% aproximado de solapamiento en qué fuentes eran citadas — [desglose completo aquí](/chatgpt-search-vs-google-50-term-test/). Optimizar para "los motores de búsqueda" como un objetivo único ya es el enfoque equivocado; estás optimizando para varios motores que coinciden en lo básico y divergen en el resto. - **Algunas categorías genuinamente no necesitan un cluster.** Un puñado de mis páginas de mejor rendimiento son piezas sueltas de verdad. La profundidad es una palanca, no un requisito universal — forzar un cluster donde el espacio de consultas no lo sostiene produce exactamente el contenido superficial y relleno que todo este marco intenta evitar. ## Preguntas frecuentes ### ¿Un solo artículo excelente puede superar alguna vez a un cluster mediocre? Sí, para una consulta lo bastante específica con poca competencia. Pero para cualquier término principal con competencia real, las páginas que mantienen su posición a largo plazo casi siempre están respaldadas por un cluster. He visto posts aislados dispararse y desvanecerse de una forma en la que los posts en cluster no lo hacen. ### ¿Cuántos posts necesita un tema antes de contar como un cluster de verdad? No hay un número fijo, pero en mis propios datos el efecto se vuelve claramente visible en algún punto alrededor de 8-10 posts genuinamente distintos sobre subtemas del mismo asunto — suficientes para que el pilar pueda enlazar hacia afuera con sentido y cada post del cluster tenga un sitio concreto adonde enviar a los lectores que necesitan más profundidad. ### ¿El schema markup es realmente necesario, o basta con escribir bien? Escribir bien es necesario pero no suficiente específicamente para la citación por motores de IA. Los motores extraen hechos estructurados de forma más fiable a partir de schema `FAQPage` y `HowTo` que de la prosa por sí sola, porque el schema elimina el paso de inferencia. He medido incrementos de citación de un dígito hasta mediados de dos dígitos porcentuales al añadirlo a posts que antes no tenían schema. ### ¿Con qué frecuencia debería actualizar contenido antiguo en lugar de publicar posts nuevos? Actualizo los posts pilar cada 6-12 meses cuando cambia un hecho real, y nunca adelanto el `dateModified` sin una edición sustantiva. La mayor parte de mi presupuesto de contenido va a posts nuevos que extienden clusters, no a reescrituras — la frescura importa, pero no es la palanca dominante comparada con la profundidad temática y la estructura. ### ¿Cuál es lo primero de mayor impacto que hay que corregir? Si una página ya posiciona razonablemente bien de forma orgánica pero no está siendo citada por motores de IA, añade un bloque de TL;DR limpio que responda directamente a la consulta principal. En mi propia prueba de seis semanas, esa fue con diferencia la palanca individual más grande — mayor que el schema de FAQ, mayor que las citas de fuentes primarias, mayor que los pasos numerados. ## La conclusión La evaluación de la calidad del contenido pasó de la página al sitio, y las señales a nivel de sitio que realmente mueven la aguja son medibles, no místicas: profundidad de cluster que puedes contar, capas estructurales que puedes probar con A/B, schema que puedes validar, y un número de cobertura de citaciones que puedes rastrear cada semana. Nada de eso requiere adivinar qué "quiere" un algoritmo. Requiere publicar dentro de una estructura temática real, darles a los motores una respuesta limpia y extraíble en lugar de obligarlos a inferirla, y comprobar el resultado con la frecuencia suficiente para saber si está funcionando. Aplico estas cuatro disciplinas en este sitio cada semana, y los números de arriba son lo que realmente han producido — no lo que una guía genérica afirma que deberían producir. --- ## Claude vs ChatGPT para Negocios en 2026: La Opinión Honesta de un Operador Source: https://alejandrorioja.com/es/claude-vs-chatgpt-for-business-2026/ Published: 2026-07-18 Tags: AI Agents, Productivity TL;DR: Claude gana en construcción de agentes, trabajo con contextos largos, programación y cualquier cosa que corra en producción a escala. ChatGPT gana en integraciones de consumidor, modo de voz y el ecosistema de plugins más amplio si tu flujo de trabajo vive en la interfaz de chat. Si estás construyendo flujos de trabajo automatizados o agentes de IA, Claude es la mejor base. Si quieres un asistente de chat capaz con más conexiones de terceros, ChatGPT tiene la ventaja. Para la mayoría de los emprendedores, la pregunta real es: ¿estás charlando con IA o construyendo con IA? Esa respuesta determina la herramienta. ## Tabla de contenidos _Publicado julio 2026._ **TL;DR:** Claude gana en construcción de agentes, trabajo con contextos largos, programación y cualquier cosa que corra en producción a escala. ChatGPT gana en integraciones de consumidor, modo de voz y el ecosistema de plugins más amplio si tu flujo de trabajo vive en la interfaz de chat. Si estás construyendo flujos de trabajo automatizados o agentes de IA, Claude es la mejor base. Si quieres un asistente de chat capaz con más conexiones de terceros, ChatGPT tiene la ventaja. Para la mayoría de los emprendedores, la pregunta real es: ¿estás charlando con IA o construyendo con IA? Esa respuesta determina la herramienta. **[Perspectiva del operador]** Gestiono dos negocios — una marca de consultoría y Pickleland, una instalación de pádel (pickleball) en Pflugerville, TX — con más de 30 agentes de IA en producción gestionando respuestas en redes sociales, promoción de eventos, seguimiento de reservas, borradores de newsletter y más. Todo mi stack de agentes está construido sobre [Claude](/recommends/claude). También he usado ChatGPT lo suficiente para saber dónde falla cada uno. Esto no es una reseña de benchmarks. Es la perspectiva de un profesional. ## La pregunta que realmente importa La mayoría de las comparaciones preguntan "¿qué modelo es más inteligente?" Esa es la pregunta equivocada para uso empresarial. La pregunta correcta es: **¿qué estás construyendo y qué necesita hacer de manera confiable a escala?** Un gerente de marketing que quiere que la IA le ayude a redactar contenido tiene requisitos diferentes a los de un fundador que construye un pipeline automatizado de calificación de leads. Un solopreneur que usa IA para prepararse para reuniones tiene necesidades diferentes a las de un operador que construye agentes que procesan 500 solicitudes de clientes por semana. La herramienta que gana para uno suele ser incorrecta para el otro. Ese enfoque determina todo lo que sigue. ## Donde Claude gana ### 1. Trabajo con contextos largos La ventana de contexto nativa de Claude — 200K tokens — maneja cosas que rompen otros modelos. Regularmente le paso historiales completos de conversaciones de clientes, borradores de contratos enteros o resúmenes de investigación multi-documento a Claude y le pido que sintetice o haga referencias cruzadas. Mantiene el hilo. Los modelos competidores soportan técnicamente contextos largos ahora, pero la degradación práctica en tareas complejas sigue siendo peor que la de Claude. Para tareas empresariales que implican leer documentos extensos, analizar exportaciones de datos densos o mantener coherencia en flujos de trabajo largos, Claude tiene una ventaja genuina. ### 2. Comportamiento de agente en producción Cuando ejecutas Claude como agente — llamando herramientas, tomando decisiones en un bucle, escribiendo en bases de datos, manejando errores — se comporta de manera más consistente que ChatGPT en mi experiencia. Sigue las instrucciones del system prompt de manera más confiable, produce salidas estructuradas más fáciles de parsear y es menos probable que se desvíe de la tarea cuando el contexto crece. Esto importa enormemente para los agentes. Un modelo que sigue tu system prompt el 95% del tiempo versus el 99% del tiempo suena similar. Con 500 llamadas al día, eso son 25 casos de desvío por día que hay que detectar y limpiar. El artículo que escribí sobre [cómo escribir system prompts para agentes de IA que no fallen en producción](/how-to-write-ai-agent-system-prompts-that-dont-fail-in-production/) cubre esto en detalle, pero la versión corta es: el seguimiento de instrucciones de Claude a nivel de system prompt es el mejor que he probado. ### 3. Programación y trabajo técnico Construyo casi todo en TypeScript sobre Cloudflare Workers. Claude Code es mi herramienta de desarrollo diario — y es genuinamente útil en lugar de solo "bastante bueno". Para preguntas de arquitectura, depuración, refactoring y escritura de lógica de agentes desde cero, Claude supera consistentemente lo que he usado en el equivalente de ChatGPT. Esto no es solo una comparación de Claude Code versus ChatGPT Chat. Incluso el Claude Opus 4.8 crudo vía API escribe código más limpio con menos importaciones alucinadas que el equivalente GPT-4o en las mismas tareas. ### 4. Experiencia de desarrollador en la API Si estás construyendo con la API — no solo chateando — la experiencia de desarrollador de Claude es mejor en 2026. El Anthropic SDK es limpio, el endpoint de conteo de tokens es genuinamente útil para estimación de costos, el caché de prompts está bien implementado y ahorra dinero real en contextos repetidos, y el manejo de errores es predecible. Para cualquiera que construya agentes programáticamente, la brecha en calidad de API importa. No es grande, pero es consistente. ### 5. Fidelidad de instrucciones en prompts complejos Claude maneja system prompts matizados con múltiples condiciones mejor que ChatGPT. Cuando necesito que un agente siga un conjunto de reglas — "si el comentario es una pregunta, haz X; si es una queja, haz Y; si menciona competidores, márcalo para revisión humana" — Claude analiza y aplica esas ramas de manera más consistente. Para prompts simples, la diferencia es mínima. Para lógica condicional compleja embebida en un system prompt, Claude es más confiable. ## Donde ChatGPT gana ### 1. Integraciones de consumidor y plugins El ecosistema de plugins de ChatGPT y la gama de herramientas disponibles a través de la interfaz nativa son más amplios. Si tu flujo de trabajo ya vive en herramientas que tienen integraciones nativas con ChatGPT — ciertos CRMs, apps de productividad, herramientas de investigación — y principalmente trabajas a través de una interfaz de chat, las conexiones out-of-the-box de ChatGPT ahorran fricción. Para usuarios avanzados que quieren hacer todo desde la interfaz de chat sin construir integraciones personalizadas, esto importa. ### 2. Modo de voz El Advanced Voice Mode de ChatGPT es genuinamente excelente. Para uso móvil, desarrollar ideas verbalmente o prepararse para llamadas mientras conduces, es la mejor interfaz de voz de IA que he usado. Claude tiene entrada de voz pero nada comparable al modo de voz conversacional completo de GPT-4o a mediados de 2026. Si la voz es una interfaz principal para tu caso de uso, ChatGPT gana claramente. ### 3. Generación de imágenes (vía DALL-E) ChatGPT Plus incluye generación de imágenes a través de DALL-E dentro de la misma suscripción. Claude no genera imágenes de manera nativa. Si quieres una sola herramienta para trabajo de texto e imágenes sin agregar Midjourney u otro servicio, ChatGPT tiene una ventaja. ### 4. Familiaridad y adopción Más personas han usado ChatGPT. Si estás introduciendo herramientas de IA a un equipo sin experiencia en IA, comenzar con ChatGPT tiene menor fricción — la mayoría de las personas lo han abierto al menos una vez. Eso no es una ventaja de capacidad, pero la velocidad de incorporación es un factor operativo real. ## Comparación de costos Aquí las cosas se vuelven matizadas, y donde la mayoría de las comparaciones engañan. Ambas plataformas tienen precios escalonados. A nivel de API: - **Claude Haiku 4.5** y **GPT-4o mini** son los caballos de trabajo económicos para tareas simples de alto volumen. Son comparables en rango de precios, con la elección principalmente impulsada por los requisitos de la tarea. - **Claude Sonnet/Opus** y **GPT-4o** son el nivel medio a alto. Claude tiene [caché de prompts](/prompt-caching-cut-your-claude-costs-without-switching-models/) que reduce significativamente los costos en flujos de trabajo con contexto repetido — si tus agentes reutilizan el mismo system prompt y ventana de contexto entre llamadas, los precios en caché de Claude pueden ser 50–80% más baratos que la tarifa sin caché. ChatGPT no tiene un equivalente directo. - En el nivel más alto, Claude Fable 5 y las últimas variantes de GPT-4 están en el mismo rango de costos brutos, pero la diferencia de tokenizador importa — Fable 5 tiene un tokenizador que cuenta los tokens de manera diferente a los modelos anteriores, por lo que los recuentos de tokens de referencia no se traducen directamente. La conclusión sobre costos: **para agentes en producción con alto volumen de llamadas, el caché de prompts de Claude lo hace materialmente más barato** en cargas de trabajo que reutilizan contexto. Para pago puro por llamada en contextos frescos, están lo suficientemente cerca como para que el rendimiento deba guiar la elección, no el precio de lista. El marco que uso para evaluar esto está en el [artículo sobre matemáticas de costos de agentes de IA](/ai-agent-cost-math-when-haiku-beats-sonnet/). ## La matriz de decisión | Caso de uso | Ganador | |---|---| | Construir agentes de IA en producción | Claude | | Programación compleja y arquitectura | Claude | | Análisis de documentos con contextos largos | Claude | | Asistente de chat con integraciones de plugins | ChatGPT | | Flujos de trabajo con voz como interfaz principal | ChatGPT | | Imágenes + texto en una interfaz | ChatGPT | | Automatización impulsada por API a escala | Claude | | Incorporación de equipo sin experiencia en IA | ChatGPT | | Agentes de cara al cliente en producción | Claude | | Eficiencia de costos en pipelines de alto volumen | Claude (con caché) | ## Mi respuesta real Uso [Claude](/recommends/claude) para todo en producción. No porque gane cada benchmark — no lo hace — sino porque: 1. Mis agentes siguen las instrucciones del system prompt de manera suficientemente confiable como para que casi no gaste tiempo limpiando salidas alucinadas o fuera de tarea. 2. El stack de Cloudflare Workers + Claude API cuesta menos de $100/mes para mi carga de trabajo combinada, y el caché de prompts ha reducido los costos en mis flujos de trabajo más pesados en más de la mitad. 3. Claude Code se ha convertido en mi interfaz de programación principal, y tener el mismo modelo disponible tanto para desarrollo como para producción simplifica el modelo mental. 4. Para tareas con contextos largos — leer PDFs, sintetizar entre documentos, mantener coherencia en flujos de trabajo de múltiples pasos — Claude maneja la ventana completa de 200K mejor de lo que he experimentado en otros lugares. Si dirigiera un equipo que necesita herramientas asistidas por IA sin construir ninguna infraestructura personalizada, probablemente los tendría en ChatGPT Plus — la amplitud de plugins out-of-the-box y el modo de voz son genuinamente útiles en el nivel de consumidor. Pero para construir cosas en lugar de solo usarlas, Claude es la base correcta. ## Preguntas frecuentes ### ¿Es Claude más inteligente que ChatGPT? Ninguno es universalmente más inteligente. Claude es mejor en razonamiento con contextos largos, seguimiento de instrucciones y programación. ChatGPT (GPT-4o) es mejor en tareas multimodales que involucran imágenes y voz. Los benchmarks específicos cambian entre ellos con cada lanzamiento de modelo. La pregunta más útil es qué modelo es mejor para tu tarea específica. ### ¿Puedo usar tanto Claude como ChatGPT? Sí, y para algunos flujos de trabajo puede que quieras hacerlo. La API de Claude y la API de OpenAI son ambas sencillas de integrar. Algunos equipos usan Claude para backends de agentes y ChatGPT para interfaces de chat de cara al usuario con integraciones. Dicho esto, ejecutar dos proveedores de IA agrega complejidad operativa — gestión de credenciales, seguimiento de costos, diferencias de comportamiento a gestionar. Empieza con uno. ### ¿Cuál es mejor para escritura de contenido? Claude, en mi experiencia. Produce salidas que suenan menos genéricas, mantiene un estilo específico mejor cuando se le dan ejemplos y maneja contenido de formato largo de manera más coherente. Para contenido social corto o correos electrónicos donde cualquiera funcionaría, la diferencia es pequeña. ### ¿Tiene Claude un nivel gratuito? Sí — Claude.ai tiene un nivel gratuito con límites de mensajes. [Las suscripciones Claude Pro y Max](/recommends/claude) eliminan los límites y añaden acceso prioritario, carga de archivos y la ventana de contexto completa. ChatGPT tiene de manera similar un nivel gratuito con acceso a GPT-4o limitado por uso. ### ¿Debería cambiar de ChatGPT a Claude? Si principalmente usas IA como interfaz de chat y estás contento con ChatGPT, el costo de cambio puede no valer la pena a menos que tengas una necesidad específica que Claude maneja mejor. Si estás construyendo automatizaciones, agentes o haciendo trabajo de programación, recomendaría fuertemente probar Claude — el comportamiento del agente y la experiencia de desarrollador marcan una diferencia significativa para cargas de trabajo en producción. --- ## Cómo construir un servicio productizado: mi marco para convertir la experiencia en ingresos escalables Source: https://alejandrorioja.com/es/productized-service-how-to-package-your-expertise/ Published: 2026-07-16 Tags: Entrepreneurship, Marketing TL;DR: Un servicio productizado es una oferta de alcance fijo y precio fijo que entregas de la misma manera cada vez. Cuatro pasos: identifica el trabajo que los clientes ya te contratan repetidamente, define el límite de alcance con firmeza, fija el precio según el valor del resultado (no las horas), y construye el sistema de entrega antes de venderle al siguiente cliente. La mayoría de los consultores se saltan el paso cuatro y siguen atrapados cambiando tiempo por dinero. Ese es el único paso que realmente crea escala. ## Índice _Publicado en julio de 2026._ **TL;DR:** Un servicio productizado es una oferta de alcance fijo y precio fijo que entregas de la misma manera cada vez. Cuatro pasos: identifica el trabajo que los clientes ya te contratan repetidamente, define el límite de alcance con firmeza, fija el precio según el valor del resultado (no las horas), y construye el sistema de entrega antes de venderle al siguiente cliente. La mayoría de los consultores se saltan el paso cuatro y siguen atrapados cambiando tiempo por dinero. Ese es el único paso que realmente crea escala. **[La lectura del operador]** Pasé años haciendo proyectos de consultoría personalizada — cada uno con un alcance diferente, precio diferente, entrega diferente. El resultado fue un negocio que requería mi atención directa en cada proyecto. La productización lo solucionó: convertir mi trabajo más solicitado en ofertas definidas con entregables claros, precios fijos y un manual de entrega repetible. Aquí está el marco exacto y los errores que cometí al construirlo. ## Qué es realmente un servicio productizado Un servicio productizado no es una retención. No es una suscripción. Es una oferta definida y repetible con un alcance fijo, un precio fijo y un proceso de entrega documentado lo suficientemente bien como para que funcione igual cada vez. El contraste con la consultoría personalizada: en lugar de "hacemos estrategia de automatización de IA por $X–Y según el alcance," vendes "un mapa de ruta de automatización de IA: una auditoría escrita de 5 flujos de trabajo, recomendaciones de construcción priorizadas y una llamada de entrega de 30 minutos, por $2.500." Alcance fijo. Precio fijo. Cronograma fijo. La única variable es si el cliente dice que sí. La diferencia con una retención es que es por proyecto. Inicio claro. Fin claro. Sin facturación mensual abierta, sin desviación de alcance, sin conversaciones de "¿puedes ver esto también?" después del hecho. Lo que lo hace escalable: el sistema, no la oferta. Una oferta de precio fijo es solo trabajo personalizado con precio renegociado. Un servicio productizado tiene un manual de entrega detrás. ## Paso 1: Encuentra lo que los clientes ya te contratan El servicio productizado más fácil de construir es el que ya estás entregando repetidamente pero tratando como trabajo personalizado cada vez. Revisa tus últimos 10 a 15 clientes o proyectos y busca patrones: - ¿Qué problema aparece con más frecuencia? - ¿Qué entregable produces con más frecuencia? - ¿Qué tipo de proyecto funciona mejor y recibe los mejores comentarios de los clientes? Para mí, el patrón era claro: los clientes seguían pidiendo lo mismo — ayuda para mapear sus procesos, elegir cuáles automatizar y seleccionar las herramientas correctas. Lo hacía repetidamente pero con un alcance diferente cada vez. Ese patrón es tu punto de partida. No un nuevo servicio que crees que el mercado necesita. Lo que ya estás haciendo. Un filtro: solo productiza trabajo donde el resultado sea en gran medida el mismo para todos los clientes. Si cada cliente recibe un entregable completamente diferente, el trabajo aún no es productizable — todavía es genuinamente personalizado. Eso está bien; simplemente significa que primero viene el trabajo de definición. ## Paso 2: Define el límite de alcance — y mantenlo Aquí es donde la mayoría de los consultores fracasan. Definen la oferta vagamente, dejan el alcance abierto a interpretación y terminan en las mismas conversaciones de expansión de alcance que tenían antes. Un servicio productizado requiere límites de alcance firmes. Defines lo que está incluido y lo que no, por escrito, antes de la primera llamada de ventas. Ejemplo de definición de alcance para un sprint de estrategia de automatización de IA: **Incluido:** - Llamada de incorporación estructurada de 60 minutos - Auditoría escrita de hasta 5 flujos de trabajo - Mapa de ruta de automatización priorizado con recomendaciones de herramientas - Evaluación de construir vs. comprar para los 3 mejores candidatos - Llamada de entrega de 30 minutos **No incluido:** - Implementación (construcción de agentes o integraciones) - Revisiones después de la entrega - Más de 5 flujos de trabajo - Trabajo fuera del alcance de automatización acordado La lista de "no incluido" importa tanto como la de "incluido." Cuando un cliente pide algo fuera del límite, tienes dos opciones: decir que está fuera de esta oferta, o crear un complemento con alcance propio y precio propio. Lo que no haces es absorberlo. Esto se siente incómodo al principio. Estás acostumbrado a decir que sí para mantener contentos a los clientes. La productización requiere decir "eso es un proyecto separado" — y cumplirlo de manera consistente. ## Paso 3: Fija el precio según el valor del resultado, no tus horas La facturación por hora y los servicios productizados no se mezclan. En el momento en que empiezas a calcular según tu tiempo, lo has convertido en trabajo personalizado nuevamente. Tres variables para fijar el precio de una oferta productizada: 1. **El costo del cliente de no resolver el problema.** Un mapa de ruta de automatización de IA que libera $4.000 al mes en eficiencia operativa vale miles para el comprador. Tus 8 horas de trabajo son la base de precio equivocada. 2. **Lo que los compradores gastan en resultados comparables.** No lo que cobran los competidores — lo que los clientes realmente gastan en resultados similares de consultores, ejecutivos fraccionarios o software que resuelve el problema parcialmente. Esto establece tu techo. 3. **Tu piso mínimo.** ¿Cuánto necesitas ganar en esta oferta para que valga la pena tu atención, considerando el tiempo de entrega, gestión del cliente y gastos generales? Esto establece tu piso. Fija tu precio en ese rango. Para las primeras ofertas productizadas, empieza en el medio. A medida que reúnas testimonios y refines la velocidad de entrega, muévete hacia el techo. No des descuentos. Si alguien no puede pagar la oferta, no es el cliente correcto para ella. Puedes construir una oferta de menor precio para un segmento diferente — pero no diluyas la oferta principal con descuentos ad-hoc, o volverás a los precios personalizados. ## Paso 4: Construye el sistema de entrega antes de la próxima venta Este paso es lo que determina si tienes un servicio productizado o solo un proyecto de precio fijo. Después de tu primera entrega — antes de venderle al siguiente — haz esto: 1. **Documenta cada paso en orden.** No un esquema vago. Una lista de verificación lo suficientemente detallada como para que alguien familiarizado con el dominio pueda ejecutar el 80% del proceso. Guardo estas en [Notion](/recommends/notion) — una página por paso del flujo de trabajo, con plantillas, ejemplos de resultados y árboles de decisión para los juicios complicados. 2. **Identifica qué tardó más de lo que debería.** Cada primera entrega es más lenta de lo necesario. Encuentra los cuellos de botella y sistematízalos: formularios de incorporación, plantillas de entregables, marcos prearmados. 3. **Construye el proceso de incorporación estructurada.** Obtener la información del cliente en un formulario estandarizado antes de la llamada es lo que hace que la entrega sea predecible. La llamada es para preguntas de aclaración, no para recopilar información. 4. **Crea la plantilla de entregables.** Cada cliente recibe la misma estructura de salida. El contenido varía; la estructura no. Esto hace que la entrega sea rápida y el resultado parezca consistente y profesional cada vez. Si te saltas este paso y simplemente vendes el siguiente, todavía estás haciendo trabajo personalizado — solo le has puesto un precio fijo. El sistema es lo que lo hace realmente escalable. ## Lo que la productización realmente desbloquea El beneficio principal no es mayor ingreso. Es mejor ingreso: demanda predecible, entrega más rápida, menos conversaciones de negociación y la capacidad de decir no a clientes que quieren algo fuera de la oferta. Un segundo beneficio: la documentación de entrega se convierte en propiedad intelectual. El manual que construyes para una oferta de consultoría productizada es la mayor parte del contenido para un curso o programa de formación. Lo hice con consultoría de automatización de IA — el manual de entrega se convirtió directamente en la columna vertebral del currículo de mi curso AI Agents for Beginners. Un tercer beneficio: apalancamiento. Con un sistema documentado, puedes capacitar a alguien para que ejecute partes de la entrega — la auditoría, la investigación, la redacción de documentos — mientras tú te concentras en las llamadas de incorporación y entrega. Ese es el comienzo de salir de la cinta de correr de uno a uno de tiempo por dinero. ## Las herramientas que uso para gestionar ofertas productizadas **[Airtable](/recommends/airtable)** — una fila por proyecto de cliente, seguimiento de estado, enlaces de entregables y pagos. Escala de uno a cincuenta clientes sin complejidad. **[Notion](/recommends/notion)** — manuales de entrega y espacios de trabajo orientados al cliente. Cada cliente obtiene un espacio de trabajo de Notion compartido construido a partir de una plantilla que se ha refinado con entregas repetidas. **[ConvertKit](/recommends/convertkit)** — gestión de listas de espera y secuencias de seguimiento. Cuando una oferta se completa (la capacidad se llena rápido con trabajo de alcance fijo), una secuencia de lista de espera mantiene a los prospectos cálidos comprometidos hasta la próxima apertura. ## Los errores que veo más a menudo **Productizar antes de haberlo entregado suficientes veces.** Si no has hecho este trabajo 3 a 5 veces, aún no conoces el alcance real. Entrégalo como trabajo personalizado primero. Aprende dónde están los límites. Luego define el producto. **Dejar el alcance difuso.** Un servicio productizado con alcance indefinido es un proyecto personalizado de precio fijo — que es lo peor de ambos mundos. Define lo que está incluido, define lo que no está, ponlo por escrito y ponlo en la página de ventas. **Decir que sí a solicitudes fuera del alcance.** Cuando un cliente pide más, crea un complemento con su propio alcance y precio. No lo absorbes "solo esta vez." **Saltar el sistema de entrega.** No has terminado después de la primera entrega. Construye el manual antes de vender el segundo. El sistema es lo que hace el producto. ## Preguntas frecuentes ### ¿Con cuántas ofertas productizadas debo empezar? Una. Constrúyela, entrégala, refina el sistema, reúne testimonios y luego considera una segunda. La mayoría de las personas que lanzan dos a la vez terminan con dos sistemas a medio construir y sin testimonios para ninguno. ### ¿Necesito una página de destino antes de empezar a vender? No. Para las primeras 5 a 10 ventas, un PDF de una página o un correo electrónico bien redactado es suficiente. No dejes que construir un sitio web sea la razón por la que no has vendido nada todavía. ### ¿Qué pasa si un cliente quiere algo fuera del alcance? Dile que es un proyecto separado. Cotiza un complemento en el momento o programa una llamada de definición de alcance para ello. No lo absorbes en el proyecto actual. La disciplina de mantener el alcance es lo que hace que el modelo funcione. ### ¿Cómo consigo el primer cliente? Cuéntales a 10 personas que conocen tu trabajo sobre la oferta — conversaciones cálidas con personas que confían en ti o conocen a alguien que lo necesita. La primera venta casi siempre proviene de una conversación directa, no de una página de destino. Una vez que tengas un caso de estudio, el [enfoque de ventas lideradas por el fundador](/founder-led-sales-how-to-reach-decision-makers/) empieza a escalarlo. ### ¿Puedo productizar algo que solo he hecho una vez? No. Todavía no entiendes el alcance real. Entrégalo dos o tres veces más como trabajo personalizado, luego formaliza lo que aprendiste en el producto. --- **Próximos pasos:** Mi [curso AI Agents for Beginners](/course/) cubre los sistemas de automatización que hacen que la entrega productizada sea escalable. El [programa cowork](/cowork/) es para operadores que construyen negocios impulsados por sistemas y quieren un entorno estructurado para hacerlo. --- ## Estrategia de generación de leads en LinkedIn: cómo consigo clientes B2B sin anuncios de pago Source: https://alejandrorioja.com/es/linkedin-lead-generation-strategy/ Published: 2026-07-14 Tags: Marketing, Growth, Entrepreneurship TL;DR: LinkedIn es el canal gratuito con mayor apalancamiento para la generación de leads B2B, siempre que lo trates como un motor de confianza y no como un disparador masivo de mensajes en frío. Optimiza tu perfil como una página de aterrizaje, publica de forma constante sobre un ángulo de tu experiencia y construye una secuencia de contacto corta que lidere con valor. El efecto compuesto tarda 60–90 días en notarse, pero después funciona casi solo. Los anuncios de pago son opcionales; un perfil sólido y un feed de contenido útil no lo son. ## Tabla de contenidos _Publicado en julio de 2026._ **TL;DR:** LinkedIn es el canal gratuito con mayor apalancamiento para la generación de leads B2B, siempre que lo trates como un motor de confianza y no como un disparador masivo de mensajes en frío. Optimiza tu perfil como una página de aterrizaje, publica de forma constante sobre un ángulo de tu experiencia y construye una secuencia de contacto corta que lidere con valor. El efecto compuesto tarda 60–90 días en notarse, pero después funciona casi solo. Los anuncios de pago son opcionales; un perfil sólido y un feed de contenido útil no lo son. **Lectura del operador:** He usado LinkedIn para generar consultas de consultoría, compradores de cursos y conversaciones de asociación, todo sin publicar un solo anuncio. Lo que funciona no es un truco ni una herramienta; es aparecer como alguien genuinamente útil en un espacio que tus compradores ya habitan. Este es el manual exacto que uso y el orden en que lo ejecutaría si empezara desde cero hoy. ## Por qué LinkedIn en 2026 El alcance orgánico de LinkedIn se ha mantenido mejor que el de casi cualquier otra plataforma. Una publicación de una persona con unos pocos cientos de seguidores relevantes aún puede llegar a miles de profesionales cualificados, algo que cuesta dinero real en la mayoría de los otros canales. El algoritmo sigue premiando el contenido denso en experiencia que genera guardados y compartidos, no solo «me gusta». Para B2B específicamente, LinkedIn no tiene sustituto creíble: - Los responsables de la toma de decisiones son más accesibles aquí que en cualquier otra plataforma. - La señal de intención es profesional: las personas están en «modo trabajo», no haciendo scroll sin rumbo. - Un comentario o publicación crea un registro público de tu pensamiento que los prospectos pueden encontrar semanas o meses después. - Los mensajes InMail y las solicitudes de conexión siguen siendo algunos de los mecanismos de prospección con menor coste de adquisición disponibles. La advertencia: la misma apertura que hace valioso LinkedIn también lo llena de mensajes masivos, publicaciones genéricas de liderazgo de pensamiento y pitches mal disimulados. El listón para destacar es bajo. La mayoría de la gente simplemente no lo supera. ## Paso 1: Arregla tu perfil antes de publicar nada Tu perfil de LinkedIn es lo primero que lee un prospecto cuando recibe tu solicitud de conexión o tropieza con una publicación que escribiste. Si no comunica de inmediato a quién ayudas y cómo, todo lo demás que hagas queda socavado. Los cuatro puntos que más importan: 1. **Titular** — No es tu cargo. La fórmula que funciona: _[Lo que hago] para [quién] para que puedan [resultado]_. «Ayudo a fundadores de SaaS B2B a cerrar sus primeros 10 tratos empresariales sin equipo de ventas» es buscable, específico y auto-cualificador de inmediato. 2. **Imagen de portada** — Úsala para reforzar el mismo mensaje. Un visual limpio con tu nicho o una breve declaración de prueba supera a un degradado genérico. 3. **Sección «Acerca de»** — Escribe en primera persona. Dos párrafos cortos: qué haces y para quién, luego uno o dos puntos de prueba (clientes, resultados, logros — reales). Termina con una llamada a la acción clara: «Escríbeme un DM si estás intentando hacer X». 4. **Sección «Destacado»** — Ancla uno o dos elementos: un imán de leads, tu mejor publicación, un caso de éxito, un enlace de reserva. Este es un espacio privilegiado que la mayoría deja vacío. La prueba: lee tu propio perfil como un extraño. En 10 segundos, ¿pueden saber qué haces, para quién lo haces y qué hacer a continuación? Si no, sigue editando. ## Paso 2: Publica sobre un ángulo, de forma constante El error más común en LinkedIn es publicar al azar — un consejo de marketing el lunes, una cita motivacional el miércoles, un pitch de producto el viernes. El algoritmo te ignora y tu audiencia también. Lo que funciona es elegir un ángulo específico de tu experiencia y apropiarte de él. Publica desde ese ángulo tres o cuatro veces a la semana durante 90 días. El volumen y la consistencia superan a la inspiración y el pulido en las etapas iniciales. ### La mezcla de contenido que genera efecto compuesto | Formato | Úsalo para | Por qué funciona | | --- | --- | --- | | Publicación de texto corta (3–5 líneas) | Opiniones contrarias, marcos rápidos, lecciones del trabajo reciente | Alto alcance, bajo esfuerzo para consumir, genera comentarios | | Publicación de lista | Desglose paso a paso, comparaciones, herramientas | Guardados y compartidos; favorecida por el algoritmo | | Publicación de historia | Una situación específica que viviste, qué hiciste, qué ocurrió | Genera confianza más rápido que cualquier otro formato | | Artículo largo | Guías profundas, explicaciones perennes | Indexado en búsqueda; te posiciona como experto con el tiempo | | Carrusel (documento) | Marcos visuales, resúmenes de publicaciones más largas | Mayor tasa de guardados de cualquier formato | El ratio que uso: 70% publicaciones cortas y listas, 20% historias, 10% artículos largos o carruseles. Las publicaciones de formato largo no generan mucho alcance, pero se acumulan a lo largo de meses en búsqueda y compartidos por DM. Una nota práctica: escribe las publicaciones el día anterior, en texto plano, sin pensar demasiado en el formato. Las publicaciones que más engagement generan suelen ser las que escribí en 10 minutos porque estaba pensando en algo real, no las que trabajé mucho. ## Paso 3: Construye tu base de conexiones con intención Hacer crecer el seguimiento correcto en LinkedIn es diferente de hacerlo crecer en tamaño. Mil seguidores que sean exactamente tu comprador potencial valen más que diez mil que sean tus pares u observadores aleatorios. Mis criterios de segmentación: - Responsables de decisiones en los sectores en los que trabajo - Fundadores y operadores en empresas dentro del rango de ingresos con el que trabajo - Conexiones de segundo grado de clientes y colaboradores existentes (la fuente más cálida) - Personas que interactúan con competidores o pares en mi espacio Envío 15–20 solicitudes de conexión por día, cada una con una nota de una línea que deja claro por qué me estoy conectando. No es un pitch, solo contexto: «Vi tu comentario sobre [tema], conecta con lo que yo trabajo — encantado de conectar». Esa nota eleva la tasa de aceptación del ~30% (genérica) al ~55–65% (específica). La nota tiene dos frases como máximo. No te conectes con todos. Una lista de conexiones inflada llena de cuentas no cualificadas en realidad te perjudica: el algoritmo de LinkedIn distribuye parcialmente tus publicaciones a tus conexiones, por lo que una audiencia de baja calidad suprime tu alcance. ## Paso 4: Secuencia tu prospección — el enfoque de tres toques Una vez que alguien se conecta, el objetivo no es hacer un pitch de inmediato. Es iniciar una conversación que podría, con el tiempo, llevar a una reunión. Las personas que tratan la conexión como permiso para pegar un deck de ventas envenenan cada punto de contacto posterior. La secuencia que uso: **Toque 1 (Día 1, dentro de las 24 horas de conectar):** Envía un mensaje de bienvenida corto y cálido. Menciona por qué te conectaste y comparte un recurso útil — una publicación, un marco, un artículo — relevante para algo que hayan compartido. Sin petición. Termínalo como una declaración, no como una pregunta. **Toque 2 (Día 5–7):** Interactúa genuinamente con una de sus publicaciones — no solo un «me gusta», sino un comentario reflexivo que añada a la conversación. Esto mantiene tu nombre visible en su feed sin enviar otro DM. **Toque 3 (Día 14–21):** Haz seguimiento en DM con una petición suave y específica. Una pregunta clara y fácil de responder, vinculada a algo relevante que hayas notado sobre su trabajo. Si el momento es el adecuado y el dolor es real, aquí es cuando se reservan las reuniones. Si no, sigue adelante — la cuenta está caliente y conocen tu nombre. El error que veo constantemente: saltarse los toques 1 y 2 y lanzarse directamente a un mensaje con llamada a la acción en el momento en que alguien se conecta. Eso no es generación de leads; es un impuesto a la reputación. ## Paso 5: Convierte conversaciones en reuniones Una buena conversación en DMs necesita una salida limpia hacia una invitación de calendario. En el momento en que alguien muestra interés genuino — hace una pregunta de seguimiento, menciona su problema directamente o interactúa con tu solución — es cuando haces la petición. El mensaje que convierte: > «Parece que [cosa específica que dijeron] es real para ti. He ayudado a algunas empresas en situaciones similares — encantado de pasar 20 minutos explicando cómo lo abordamos, sin pitch, solo para ver si es relevante. [enlace de reserva] — coge un hueco si te viene bien.» Corto, de bajo compromiso, fácil de decir que sí. El enlace de reserva elimina la fricción de programación que destruye la mitad de las reuniones que deberían ocurrir. ## Qué no hacer Los comportamientos que hacen que las cuentas sean ignoradas, reportadas o bloqueadas: 1. **Solicitudes de conexión masivas sin contexto** — LinkedIn restringirá tu cuenta y tu tasa de aceptación caerá. 2. **DMs de pitch primero** — El primer mensaje no es el lugar para presentar tu producto, tu precio o tu enlace de calendario. 3. **Pods de engagement** — El engagement falso infla las métricas de vanidad y recibe penalizaciones algorítmicas. 4. **Publicar todos los días sin punto de vista** — El volumen sin perspectiva es ruido. Una publicación a la semana con información real supera a siete «opiniones calientes» semanales sin sustancia. 5. **Automatizar la prospección** — La detección de bots de LinkedIn se ha vuelto agresiva. Las herramientas de conexión automatizadas y las secuencias de DM escritas por IA a escala son marcadas. La secuencia del Paso 4 tarda unos 30 minutos al día y tiene una relación señal-ruido que ninguna herramienta puede igualar. ## Medir lo que realmente importa Métricas de vanidad que ignorar: impresiones, visitas al perfil, número de seguidores. Los números que te dicen si el sistema funciona: - **Tasa de aceptación de conexiones** — objetivo del 50%+ con nota; si está por debajo del 30%, reescribe la nota. - **Tasa de respuesta en mensajes de seguimiento** — 20–30% es saludable para una lista bien segmentada. - **DMs entrantes por mes** — personas que se ponen en contacto contigo por tu contenido. Rastrea mes a mes. - **Llamadas reservadas desde LinkedIn por mes** — el único número que se correlaciona con los ingresos. Hago seguimiento en una tabla simple de Notion. El objetivo en los primeros 90 días es llegar a un DM entrante por semana y una llamada reservada por mes solo desde LinkedIn. En el tercer mes, si el contenido está funcionando, esos números aumentan sin un esfuerzo proporcionalmente mayor. ## El balance del operador LinkedIn funciona para la generación de leads B2B porque es la única red profesional donde el alcance orgánico aún tiene peso y donde tu reputación se acumula públicamente con el tiempo. La mecánica es simple: un perfil que explica a quién ayudas, contenido que demuestra que sabes de lo que hablas, y una secuencia de contacto que lidera con valor en lugar de un pitch. Ejecuta eso de forma constante durante 90 días y los contactos entrantes empezarán a llegar. Ejecútalo durante un año y se convierte en una de las fuentes más fiables de conversaciones cualificadas que tienes, sin presupuesto para anuncios. --- **Relacionado:** [Venta liderada por el fundador](/founder-led-sales-how-to-reach-decision-makers/) · [Cómo construir una marca personal](/how-to-build-a-personal-brand/) · [Estrategia de prospección](/crafting-a-successful-outreach-strategy-in-the-world-of-digital-marketing/) --- ## Cómo construí Courtlines: un SaaS de gestión de clubes, desarrollado con Claude Source: https://alejandrorioja.com/es/how-i-built-courtlines-a-club-management-saas-with-claude/ Published: 2026-07-11 Tags: AI Agents, Case Study TL;DR: Courtlines es el sistema operativo para clubes y estudios de deportes de raqueta: reservas, membresías, entrenamiento, punto de venta y eventos bajo un mismo techo con marca propia. Lo construí como operador en solitario con Claude como mi socio de ingeniería. La lección: la IA no solo me hizo programar más rápido, cambió el tamaño de producto que una sola persona puede lanzar y operar con credibilidad. ## Tabla de contenidos _Actualizado en julio de 2026._ **TL;DR:** Courtlines es el sistema operativo para clubes y estudios de deportes de raqueta: reservas, membresías, entrenamiento, punto de venta y eventos bajo un mismo techo con marca propia. Lo construí como operador en solitario con Claude como mi socio de ingeniería. La lección: la IA no solo me hizo programar más rápido, cambió el tamaño de producto que una sola persona puede lanzar y operar con credibilidad. **[La lectura del operador]** Manejo más de 30 agentes en producción entre una marca de consultoría y Pickleland, la instalación de pickleball que opero en el área metropolitana de Austin, Texas. Operar una instalación real me enseñó exactamente lo mal que está el software para clubes como el mío, así que construí el software que ojalá hubiera tenido. Esta es la historia de [Courtlines](https://courtlines.com), qué hace y cómo apoyarme en Claude le permitió a una sola persona construir algo que normalmente requiere un equipo. ## Por qué un club necesita un sistema operativo, no una app Si nunca has manejado una instalación deportiva, el problema del software es invisible. Desde afuera parece que «la gente reserva canchas». Desde adentro, un club es un pequeño negocio caótico con una docena de piezas móviles que tienen que coincidir entre sí. Un socio reserva una cancha. Esa reserva tiene que saber si está en un plan de membresía, si tiene créditos, si la cancha ya está apartada para una clínica, si hay un entrenador asignado y si la recepción anuló el precio. Cuando llega, alguien le cobra un bote de pelotas en el mostrador: eso es punto de venta. Inscribe a su hijo en un programa juvenil: eso es eventos y cuentas familiares. Compra un paquete de 10 clases: eso es un paquete de entrenamiento con su propia lógica de pago al entrenador. Recomienda a un amigo: eso es un embudo de membresías. La mayoría de los clubes manejan esto con tres o cuatro herramientas desconectadas, más una hoja de cálculo, más un chat grupal. El sistema de reservas no sabe nada del punto de venta. El punto de venta no sabe nada de las membresías. A fin de mes, las cifras de nadie cuadran. **Courtlines es la respuesta a «¿y si todo eso fuera un solo sistema?»** No es una app de reservas con funciones agregadas por encima: es un único sistema operativo donde el calendario, las membresías, la caja, los pagos a entrenadores y las páginas públicas de eventos son todos los mismos datos subyacentes. Esa es toda la tesis, y es el lema del sitio: el sistema operativo para clubes y estudios. ## Qué hace Courtlines en realidad A grandes rasgos, [Courtlines](https://courtlines.com) le da a un club: - **Una grilla de canchas con arrastrar y soltar** para la recepción: cada reserva, clínica y bloqueo en una sola pantalla que un administrador puede reorganizar en tiempo real. - **Reservas y juego libre** para los socios, incluyendo los casos límite incómodos pero esenciales: reservas recurrentes, listas de espera, ventanas de cancelación y créditos. - **Membresías y facturación**: planes, cuentas familiares, accesos para niños o juveniles vinculados a un padre, y la gestión de cobros morosos que evita que los ingresos se fuguen en silencio. - **Entrenamiento**: paquetes de clases, agendamiento y pagos automatizados a entrenadores independientes. - **Punto de venta**: una caja registradora de verdad para la tienda del pro y la cafetería, ligada al mismo registro de cliente que todo lo demás. - **Eventos y páginas públicas**: clínicas, ligas y torneos con páginas de cara al público que la gente puede encontrar e inscribirse. El objetivo de diseño es que la plataforma desaparezca. Un club pone su propia marca por encima, y para sus socios simplemente se siente como «la app de nuestro club», no como «un SaaS que pagamos». Es un contraste deliberado con los actores establecidos de este rubro —los CourtReserve y Skedda del mundo— donde el software es la marca y el club es el inquilino. Pickleland es el inquilino #1. No me puedo esconder detrás de un demo; la cosa tiene que operar de verdad una instalación por la que respondo personalmente. Esa restricción ha sido el mejor gerente de producto que he tenido. Puedes [ver Pickleland aquí](https://pickleland.com): es el campo de pruebas del mundo real, y cada aspereza con la que se topa un socio es un error que siento ese mismo día. ## La parte que me sorprendió: lo que un solo operador puede lanzar ahora Esta es la versión honesta de la historia, y es la razón por la que escribo este artículo en lugar de simplemente lanzar en silencio. Un SaaS multiinquilino con facturación, punto de venta, acceso basado en roles, pagos a entrenadores y un sistema público de eventos no es un proyecto de fin de semana. Hace diez años, esto era un equipo con financiación semilla de cinco a ocho ingenieros durante un año. Es el tipo de alcance donde a un fundador en solitario normalmente le dicen, con amabilidad, que lo reduzca a una sola función y levante capital. Lo construí como una sola persona, con **Claude como mi socio principal de ingeniería.** No es «a veces le pedí un fragmento a ChatGPT»: quiero decir que Claude escribió la gran mayoría del código de este sistema, trabajando a partir de especificaciones y decisiones de producto que son mías. Mi trabajo pasó de *teclear la implementación* a *decidir qué es verdad*: cuál debe ser el modelo de datos, qué le está permitido hacer a un rol, qué significa «terminado» para una función y qué es seguro lanzar. El cambio interesante no es la velocidad, aunque también es más rápido. Es el **alcance.** La IA no me convirtió en un desarrollador 2× sobre el mismo tamaño de producto. Cambió el tamaño de producto que puedo construir con credibilidad y, tan importante como eso, *operar y mantener* en solitario. Una base de código que solo un humano escribió colapsaría bajo su propio peso. Una base de código donde un socio de IA sostiene el detalle de implementación y yo sostengo la arquitectura y las barreras de seguridad es algo genuinamente distinto, y es la razón por la que un operador en solitario ahora puede ir tras una categoría que antes requería una empresa. Deliberadamente no publico aquí mi manual exacto de operación de Courtlines: esa es la parte que considero una ventaja competitiva, y prefiero que mis competidores sigan creyendo que esto requiere un gran equipo. Pero si quieres ver la *mecánica* de cómo hago funcionar a Claude en un proyecto real, en detalle, lo documenté todo para una construcción mucho más pequeña: un juego móvil que lancé a las tiendas de apps. Mira [cómo construí Quads, un juego de mesa para móvil, con Claude](/how-i-built-quads-a-mobile-board-game-with-claude/): el mismo estilo de trabajo, sin nada que ocultar, todos los trucos sobre la mesa. ## Los principios en los que no cederé Aun manteniendo el manual en privado, vale la pena enunciar algunos principios porque le aplican a cualquiera que construya software serio con IA: **El humano sostiene las plumas peligrosas.** Hay un puñado de acciones donde un error es costoso y difícil de revertir: cambios de esquema, despliegues, cualquier cosa que toque dinero o datos de producción. Esas se quedan firmemente conmigo. La IA puede proponerlas; no le toca ejecutarlas. Trazar esa línea con claridad es lo que hace seguro darle a la IA mucha cuerda en todo lo demás. **Los tests en verde son necesarios, no suficientes.** Un flujo de reservas que pasa todos los tests unitarios aún puede estar visiblemente roto en un navegador real. La verificación más importante para un producto con interfaz es un humano —o un proceso supervisado— haciendo clic de verdad a través de él con datos realistas. Los tests son un gradiente que evita que las cosas empeoren; no son prueba de que una función funcione. Esta la aprendí por la vía cara, y cambió permanentemente cómo defino «terminado». **Las especificaciones son la verdadera interfaz.** El apalancamiento no está en el prompting ingenioso: está en mantener documentos claros y actualizados sobre qué es el sistema y qué se supone que debe hacer cada parte. El tiempo invertido en mantenerlos precisos se paga muchas veces a lo largo de cada sesión futura. Si quieres la versión más profunda de esto, es la misma disciplina que describo en [cómo escribir prompts de sistema para agentes de IA que no fallen en producción](/how-to-write-ai-agent-system-prompts-that-dont-fail-in-production/). **Construye la cosa con la que tienes que convivir.** La mejor decisión que tomé fue hacer que Courtlines operara una instalación que me pertenece. Es fácil lanzar un demo que impresiona; es imposible esconderte de un software del que dependen tus propios socios. Si estás construyendo con IA, apúntala a un problema que sientas personalmente: la prueba de realidad vale más que cualquier suite de tests. ## Dónde encaja esto con todo lo demás que estoy construyendo Courtlines no existe en aislamiento. Es parte de un pequeño ecosistema de deportes de raqueta que estoy construyendo: [The Court Scout](https://thecourtscout.com) es un directorio verificado de canchas de pickleball, construido para ser genuinamente más preciso que los directorios rastreados con los que compite, y Pickleland es la instalación insignia contra la que se prueba todo. El directorio ayuda a los jugadores a encontrar canchas; Courtlines ayuda a los clubes detrás de esas canchas a operar de verdad. El tejido conectivo de todo esto es el mismo modelo operativo: un operador en solitario amplificado por IA, manejando más superficie de la que un operador en solitario podía históricamente. Courtlines es la expresión más ambiciosa de ese modelo hasta ahora: una plataforma SaaS completa que, hace unos años, simplemente no habría intentado en solitario. Si manejas un club o estudio de deportes de raqueta y estás cansado de coser cuatro herramientas entre sí, echa un vistazo a [Courtlines](https://courtlines.com). Y si eres un constructor preguntándose hasta dónde puedes llevar la IA en un producto real, ese es todo el punto de este artículo: más lejos de lo que probablemente crees. ## Preguntas frecuentes ### ¿Qué es Courtlines? Courtlines es un sistema operativo multiinquilino para clubes y estudios de deportes de raqueta: pickleball, tenis, pádel y más allá. Combina reservas, membresías, entrenamiento, punto de venta y gestión de eventos en una sola plataforma con marca propia, de modo que un club maneja todo su negocio desde un único sistema en lugar de cuatro herramientas desconectadas. Puedes verlo en [courtlines.com](https://courtlines.com). ### ¿De verdad Claude escribió la mayor parte del código? Sí. Claude fue mi socio principal de ingeniería y escribió la gran mayoría de la implementación, trabajando a partir de especificaciones, arquitectura y decisiones de producto que yo poseo y controlo. Yo sostengo el esquema, los despliegues y la definición de «terminado»; la IA sostiene el detalle de implementación. Esa división del trabajo es lo que hace que un SaaS de este alcance construido en solitario sea sostenible de mantener. ### ¿De verdad una sola persona puede construir y operar un SaaS tan grande con IA? Construirlo ahora es genuinamente factible: esa es la parte sorprendente. El desafío mayor es operarlo y mantenerlo, porque una base de código grande necesita a alguien que entienda la arquitectura aun cuando una IA haya escrito los detalles. La clave es mantener especificaciones claras y mantenerse firme en el puñado de acciones de alto riesgo que un humano debe poseer. Hecho de esa manera, la superficie mantenible para un solo operador es mucho mayor de lo que solía ser. ### ¿Por qué construir tu propio software de club en lugar de usar CourtReserve o Skedda? Porque operar Pickleland me mostró exactamente dónde se quedan cortas las herramientas existentes: el sistema de reservas, la caja y las membresías no comparten una única fuente de verdad, así que nada reconcilia limpiamente. Quería un sistema donde todo eso fueran los mismos datos subyacentes y donde la marca del club —no la del proveedor de software— sea lo que los socios ven. Esa es la brecha que Courtlines está construido para cerrar. ### ¿Dónde puedo aprender cómo trabajas realmente con Claude en el día a día? Mantengo el manual detallado de Courtlines en privado por razones competitivas, pero documenté exactamente el mismo estilo de trabajo en un proyecto más pequeño y totalmente abierto: un juego de mesa para móvil llamado Quads. Lee [cómo construí Quads, un juego de mesa para móvil, con Claude](/how-i-built-quads-a-mobile-board-game-with-claude/) para ver la mecánica, o [cómo decido si vale la pena construir una automatización](/ai-agent-roi-how-i-decide-whether-automation-worth-building/) para el razonamiento de retorno de inversión detrás de todo lo que lanzo. --- ## Cómo construí Quads, un juego de mesa para móvil, con Claude: de un hackathon de 2 horas a la App Store Source: https://alejandrorioja.com/es/how-i-built-quads-a-mobile-board-game-with-claude/ Published: 2026-07-11 Tags: AI Agents TL;DR: Quads es un juego de mesa para móvil —una versión limpia del clásico juego abstracto Quarto— que empezó como un hackathon de 2 horas con un amigo en Colombia y se lanzó a las tiendas de apps. Esta es la versión totalmente abierta de cómo construyo con Claude: worktrees de agentes en paralelo, una IA de juego real (no un LLM), diseño offline-first y los tropiezos específicos que me costaron horas. ## Tabla de contenidos _Actualizado en julio de 2026._ **TL;DR:** Quads es un juego de mesa para móvil —una versión limpia del clásico juego abstracto Quarto— que empezó como un hackathon de 2 horas con un amigo en Colombia y se lanzó a las tiendas de apps. Esta es la versión totalmente abierta de cómo construyo con Claude: worktrees de agentes en paralelo, una IA de juego real (no un LLM), diseño offline-first y los tropiezos específicos que me costaron horas. **[La lectura del operador]** Manejo más de 30 agentes en producción entre una marca de consultoría y Pickleland, mi instalación de pickleball en el área metropolitana de Austin. La mayor parte de lo que construyo es software de negocio serio donde mantengo el manual en privado. Quads es lo opuesto: un proyecto paralelo divertido que puedo mostrarte de arriba abajo. Si quieres ver exactamente cómo trabajo con Claude, sin nada limado, este es el artículo. Puedes encontrar el juego en [playquads.com](https://playquads.com). ## Empezó como un hackathon de 2 horas en Colombia El origen es casi vergonzosamente casual. Estaba en un viaje a Colombia, y un amigo y yo nos dimos un hackathon de 2 horas: elegir algo pequeño, construirlo con IA, ver hasta dónde llegábamos. Nos decidimos por Quarto, un pequeño y hermoso juego de estrategia abstracta que es fácil de aprender y sorprendentemente profundo. Dos horas después teníamos un prototipo jugable, y la idea era demasiado buena para dejarla en un portátil. Lo que empezó como un reto con límite de tiempo se convirtió en una app móvil real y publicada en iOS y Android. Ese arco —*de prototipo de broma a ficha en la tienda*— es toda la razón por la que creo que vale la pena escribir sobre este proyecto. La distancia entre «idea divertida» y «cosa que desconocidos pueden descargar» se ha colapsado, y Quads es un caso de estudio limpio de cómo. Primero, un desvío rápido sobre el nombre. El juego es una reimplementación de **Quarto**, que es un juego con marca registrada propiedad de Gigamic. Así que la primerísima decisión no relacionada con el código fue *no* llamarlo Quarto en ningún lugar que un cliente pudiera ver. Pasó de Quarto (la mecánica) a un par de nombres intermedios a **Quads**: un nombre que es mío para usar. Si estás reimplementando un clásico, resuelve la cuestión de la marca registrada antes de enamorarte de un nombre. ## Qué es Quads en realidad Para los no iniciados: Quads se juega en un tablero de 4×4 con 16 piezas únicas. Cada pieza tiene cuatro atributos binarios —alta o baja, oscura o clara, cuadrada o redonda, sólida o hueca— y las 16 piezas cubren cada combinación posible exactamente una vez. Ganas completando una línea de cuatro piezas que compartan *cualquier* atributo. El giro que lo hace brillante: **no eliges la pieza que colocas. Tu oponente te la entrega.** Luego tú le entregas la suya. Así que cada turno es un doble aprieto: intentas colocar la pieza que te dieron sin armar una victoria, mientras eliges una pieza para entregar que no le regale la partida a tu oponente. Es elegante y genuinamente difícil. La app trae cuatro formas de jugar, todas completamente offline: contra la computadora en cinco niveles de dificultad, pasar y jugar en un solo dispositivo, un puzle diario y un modo asíncrono de «reta a un amigo». Sin cuenta, sin servidor, sin inicio de sesión. Esa decisión offline-first guio buena parte de la ingeniería, y es una gran parte de por qué una construcción en solitario fue viable. ## La lógica del juego: todo un conjunto de reglas que sale de la aritmética de bits Esta es mi parte favorita, porque es el tipo de cosa que satisface haya escrito o no la IA. Cada una de las 16 piezas es solo un entero de 0 a 15. Cada uno de los cuatro bits es un atributo. Eso es todo: el conjunto entero de piezas son los números del 0 al 15, porque cuatro bits te dan exactamente 16 combinaciones. La detección de victorias entonces se vuelve casi trivial. Para cualquier línea de cuatro piezas, mantienes dos acumuladores corrientes: los bits que están en `1` en *todas* las piezas, y los bits que están en `0` en *todas* las piezas. Si cualquiera de los acumuladores es distinto de cero después de las cuatro, las piezas coinciden en al menos un atributo: eso es una victoria. Todo el conjunto de reglas se colapsa en un par de ANDs a nivel de bits. Como la lógica son funciones puras sobre enteros —sin framework, sin interfaz, sin estado— es directamente testeable por unidades, y es trivial de extender. Quads incluso trae una variante de regla casera donde los nueve cuadrados de 2×2 también cuentan como formas ganadoras, lo cual es una adición de dos líneas sobre el mismo truco de bits. Cuando tú y un socio de IA mantienen la lógica central así de limpia, agregar una función es un placer en lugar de un riesgo. ## El oponente IA no es un LLM (y esa es la decisión correcta) Aquí hay un momento didáctico que me importa: **no toda «IA» debería ser un modelo de lenguaje grande.** El oponente de Quads es IA de juego clásica pura, y así debe ser. En cada turno toma dos decisiones —dónde colocar la pieza que le entregaron y qué pieza devolver— y la dificultad escala qué tan fuerte piensa: - **Novato** juega esencialmente al azar y te regalará la victoria. - Los niveles intermedios agregan heurísticas: tomar una victoria inmediata si existe, y evitar regalar una pieza con la que el oponente pueda ganar, prefiriendo la pieza que arma la menor cantidad de amenazas futuras. - **Maestro y Gran Maestro** ejecutan una búsqueda negamax acotada —búsqueda de árbol de juego real— pero con un **presupuesto de nodos** estricto para que un movimiento nunca pueda colgar el hilo principal del teléfono. Temprano en la partida, donde la búsqueda perfecta es intratable, recurre a heurísticas rápidas; tarde en la partida, donde el árbol es lo bastante pequeño, busca de verdad. Dos cosas que vale la pena robar de esto. Primera, un modelo de lenguaje sería *peor* aquí —más lento, más caro, no determinista y vencible— que cincuenta líneas de negamax. Empareja la herramienta con el problema. Segunda, el presupuesto de nodos es la ingeniería de verdad: en un dispositivo móvil, «correcto pero ocasionalmente se cuelga cuatro segundos» es una función fallida. Acotar la búsqueda para que un movimiento sea siempre rápido, aunque ocasionalmente subóptimo, es la diferencia entre un juguete y un producto. Saber *cuándo* echar mano de un LLM es el mismo criterio que aplico a cada automatización: es el núcleo de [cómo decido si vale la pena una construcción con IA](/ai-agent-roi-how-i-decide-whether-automation-worth-building/). ## Cómo hago funcionar a Claude en la práctica: agentes en paralelo en worktrees Ahora la parte que mantengo en privado en mis productos más grandes pero que puedo mostrarte por completo aquí. No construyo con una sola sesión de Claude a la vez. Ejecuto **varias en paralelo**, cada una en su propio git worktree en su propia rama. Un agente agrega internacionalización, otro construye el sistema del puzle diario, otro hace el modo para daltónicos, otro conecta el sonido; cada uno aislado en su propia copia de trabajo para que no puedan pisarse entre sí, y cada uno se fusiona de vuelta cuando está en verde. El historial de git de Quads es un muro de commits `Merge branch 'worktree-agent-…'`, que es exactamente cómo se ve ese flujo desde afuera. La razón por la que los worktrees importan es simple: agentes en paralelo editando el mismo directorio de trabajo se pisan al instante. Dale a cada uno un checkout aislado y puedes tener genuinamente cuatro funciones en construcción a la vez, y luego fusionarlas como cualquier otra rama. Es el cambio de mayor apalancamiento en cómo trabajo: pasé de una conversación, una función, a una pequeña flota. Si quieres la disciplina detrás de los prompts con los que corren esos agentes, es la misma que describo en [cómo escribir prompts de sistema para agentes de IA que no fallen en producción](/how-to-write-ai-agent-system-prompts-that-dont-fail-in-production/): el apalancamiento está en especificaciones claras y actualizadas, no en el fraseo ingenioso. ## El tropiezo que me costó una hora (para que no te cueste una a ti) Cada proyecto te enseña una lección tonta y cara. En Quads fue esta: **la herramienta de vista previa no siempre muestra la rama que crees que está mostrando.** Cuando ejecutas múltiples agentes en múltiples worktrees y previsualizas su trabajo, la vista previa puede lanzarse desde un directorio *diferente* al que está tu sesión actual, así que tomas una captura de la app, no ves ninguno de tus cambios y empiezas a depurar una interfaz «faltante» que nunca faltó. La función estaba bien; la vista previa apuntaba al checkout equivocado. Perdí tiempo real en esto antes de darme cuenta de qué pasaba, y lo anoté en las notas del propio proyecto para que mi yo futuro (y cualquier agente al que le entregue el repo) revise el objetivo de la vista previa *antes* de depurar errores fantasma. La trampa relacionada: el archivo de configuración que define esas vistas previas se comparte entre sesiones paralelas, así que dos agentes editándolo a la vez pueden sobrescribir en silencio las entradas del otro. Si vas a correr una flota, trata la configuración compartida como un recurso en disputa: te morderá exactamente una vez, y luego nunca más si anotas la lección. Ese hábito —capturar cada tropiezo ganado a pulso en un archivo duradero que la siguiente sesión leerá— es la columna vertebral silenciosa de construir con IA a cualquier escala. El contexto se evapora entre sesiones; las lecciones escritas no. ## Los trucos offline-first de los que estoy orgulloso Como Quads no tiene backend, algunos problemas necesitaron respuestas ingeniosas y sin servidor: - **El puzle diario** se elige de forma determinista a partir del día local del año, así que cada jugador en el mundo recibe el mismo puzle con cero coordinación de servidor. (Lección extra: lancé, y luego arreglé de inmediato, un error de más-o-menos-uno por horario de verano en esa aritmética de fechas. Las fechas siempre son más difíciles de lo que parecen.) - **«Reta a un amigo»** codifica un puzle en un código de texto corto —algo como `QC1-01-03-3`— resguardado por una suma de verificación para que un error de tipeo no pueda producir un reto válido pero equivocado. Tu amigo lo teclea en su propia copia de la app y juega la posición exacta, completamente offline. Sin cuentas, sin emparejamiento, sin servidor. - **Las vistas previas enriquecidas de enlaces** son el único lugar donde sí usé un poquito de código de servidor. Cuando compartes un enlace de reto, una única Cloudflare Pages Function renderiza etiquetas Open Graph por código para que el enlace se despliegue bien en iMessage o WhatsApp. Los rastreadores sociales no ejecutan JavaScript, así que una vista previa renderizada en el cliente se vería idéntica para cada enlace; una pequeña función lo arregla sin necesitar un backend de verdad. Ninguno de estos es difícil una vez que los ves, pero cada uno es un lugar donde la respuesta perezosa es «levanta un servidor y una base de datos», y la mejor respuesta es «haz la cosa ingeniosa offline». Evitar un backend por completo es por lo que una sola persona pudo lanzar y mantener esto. ## Del hackathon a la ficha en la tienda El último tramo —la parte que nadie te cuenta de un «proyecto de 2 horas»— es todo lo que hay entre «funciona en mi teléfono» y «desconocidos pueden descargarlo». Internacionalización en ocho idiomas de una sola pasada. Textos de la tienda que nunca usan el nombre con marca registrada. Herramientas de compilación para la tienda de apps, versionado y las limpiezas de permisos específicas de cada plataforma que evitan que una revisión de la tienda te rebote. Esto es poco glamoroso, y es donde muchos proyectos paralelos mueren en silencio. Hacerlo con Claude no acortó la lista, pero hizo cada ítem lo bastante barato como para que de verdad terminara. Esa es la historia real de Quads: no que la IA escribió un juego de mesa —mucha gente puede prototipar uno—, sino que bajó el costo de la *última milla* lo suficiente como para que una broma de hackathon se convirtiera en un producto publicado. Si tienes una idea pequeña sobre la que has estado sentado, ese es todo mi argumento. Empieza la versión de 2 horas. Te sorprenderá lo cerca que se ha movido la meta. Y si quieres ver hasta dónde sube en la escala este mismo estilo de trabajo, lo llevé hasta el final con un SaaS multiinquilino completo: [cómo construí Courtlines, una plataforma de gestión de clubes, con Claude](/how-i-built-courtlines-a-club-management-saas-with-claude/). Juega Quads en [playquads.com](https://playquads.com). ## Preguntas frecuentes ### ¿Qué es Quads? Quads es un juego de mesa para móvil para iOS y Android: una reimplementación limpia del clásico juego de estrategia abstracta Quarto. Juegas en un tablero de 4×4 con 16 piezas únicas, y el giro es que tu oponente elige la pieza que tienes que colocar. Es gratis para jugar, con modos para solitario, pasar y jugar, un puzle diario y retos asíncronos. Encuéntralo en [playquads.com](https://playquads.com). ### ¿Claude escribió todo el juego? Claude escribió la gran mayoría del código, trabajando a partir del diseño y las decisiones que yo poseo. Ejecuté varias sesiones de Claude en paralelo, cada una en su propio git worktree, construyendo distintas funciones que fusioné entre sí. La lógica del juego, el oponente IA, la internacionalización, los sonidos y el sistema de puzles se construyeron en gran parte de esta manera y fueron revisados por mí. ### ¿El oponente IA dentro del juego funciona con un LLM? No, y deliberadamente. El oponente usa IA de juego clásica: heurísticas en las dificultades bajas y una búsqueda negamax acotada en los niveles superiores, con un presupuesto de nodos estricto para que un movimiento nunca cuelgue el dispositivo. Un modelo de lenguaje sería más lento, más costoso y más débil para este trabajo. Elegir el tipo correcto de IA para el problema importa más que echar mano siempre del modelo más grande. ### ¿Cuánto tardó en construirse Quads? El primer prototipo jugable salió de un hackathon de 2 horas con un amigo en un viaje a Colombia. Convertir ese prototipo en una app pulida y publicable en ambas tiendas de apps —con internacionalización, un oponente IA real, retos offline y cumplimiento de las tiendas— tardó considerablemente más, pero cada paso individual fue lo bastante barato con IA como para que el proyecto de verdad llegara a la meta. ### ¿Cuál es la mayor lección de construir Quads con Claude? Dos cosas. Primera, ejecuta agentes en git worktrees aislados para poder construir varias funciones en paralelo sin que se pisen entre sí. Segunda, anota cada tropiezo en un archivo duradero que la siguiente sesión leerá: el contexto se evapora entre sesiones, pero las lecciones escritas se acumulan. Para el panorama más amplio de este estilo de trabajo, mira [cómo construí Courtlines con Claude](/how-i-built-courtlines-a-club-management-saas-with-claude/). --- ## Cómo escribir prompts de sistema para agentes de IA que no fallen en producción Source: https://alejandrorioja.com/es/how-to-write-ai-agent-system-prompts-that-dont-fail-in-production/ Published: 2026-07-11 Tags: AI Agents TL;DR: Un prompt de sistema en producción tiene cinco capas: identidad (quién es el agente y qué no puede hacer), contexto (qué sabe sobre el entorno), tarea (cómo se ve el éxito paso a paso), formato de salida (la capa más subestimada) y casos extremos (qué hacer cuando las entradas fallan). La mayoría de los prompts fallan porque omiten las capas 4 y 5. Escribe el formato de salida antes que cualquier otra cosa — te obliga a ser preciso sobre lo que realmente quieres. ## Tabla de contenidos _Actualizado julio 2026._ **TL;DR:** Un prompt de sistema en producción tiene cinco capas: identidad (quién es el agente y qué no puede hacer), contexto (qué sabe sobre el entorno), tarea (cómo se ve el éxito paso a paso), formato de salida (la capa más subestimada) y casos extremos (qué hacer cuando las entradas fallan). La mayoría de los prompts fallan porque omiten las capas 4 y 5. Escribe el formato de salida antes que cualquier otra cosa — te obliga a ser preciso sobre lo que realmente quieres. **[Perspectiva del operador]** Gestiono más de 30 agentes de IA en producción para mi marca de consultoría y Pickleland, una instalación de pádel en Pflugerville, TX. He reescrito más prompts de sistema de los que he escrito — generalmente porque la primera versión parecía funcionar bien en las pruebas y luego se degradaba silenciosamente en producción. Esto es lo que he aprendido sobre cómo escribir prompts que duran. ## El problema del prompt de sistema que nadie admite La mayoría de los prompts de sistema para agentes se escriben en unos 20 minutos, se prueban con dos o tres ejemplos y luego nunca se vuelven a tocar. El modelo se lanza. Por un tiempo, funciona. Luego algo cambia — las entradas se vuelven más complejas, el modelo se actualiza, aparece un caso extremo nuevo — y el agente empieza a producir basura. En silencio. A escala. El problema no es que el prompt original fuera malo. Es que la mayoría de los prompts se escriben para demostrar el camino feliz. Están diseñados para la entrada que tenías en mente cuando construiste el agente, no para la distribución completa de entradas que el agente verá en realidad. Los prompts de sistema en producción son diferentes a los prompts de demostración. Deben manejar entradas que no diseñaste, fallar con gracia cuando algo va mal y producir una salida consistente incluso cuando el comportamiento del modelo cambia ligeramente entre versiones. ## Las cinco capas de un prompt de sistema en producción Pienso en cada prompt de sistema que escribo en cinco capas. No tienen que aparecer en este orden — pero todas deben estar presentes. ### Capa 1: Identidad La identidad le dice al modelo quién es y cuáles son sus restricciones operativas. No un personaje de juego de roles — una definición funcional de lo que este agente hace y no hace. Una capa de identidad sólida responde tres preguntas: - ¿De qué es responsable este agente? - ¿De qué NO es responsable explícitamente (y debe escalar o rechazar)? - ¿Qué estándares mantiene? Capa de identidad débil: ``` Eres un agente de atención al cliente útil para una instalación de pádel. ``` Capa de identidad más sólida: ``` Eres el asistente de reservas de Pickleland, una instalación de pádel en Pflugerville, TX. Tu trabajo es responder preguntas sobre disponibilidad de pistas, opciones de membresía y próximos eventos. NO gestionas disputas de facturación, solicitudes de reembolso ni quejas sobre el personal — enruta esas al equipo de operaciones humano a través de la ruta de escalado definida a continuación. Respondes con un tono amistoso pero eficiente. Nunca inventas disponibilidad ni precios. Cuando no sabes algo, lo dices y ofreces tomar un mensaje para el equipo de operaciones. ``` El alcance explícito de lo que NO se hace es la parte que la mayoría de los operadores omiten. Sin él, el modelo intentará ser útil fuera de su ámbito — y ahí es donde las cosas salen mal. ### Capa 2: Contexto El contexto es lo que el agente sabe sobre su entorno que no está en el mensaje del usuario. Esto incluye: - La fecha y hora actuales (inyéctalas dinámicamente — nunca confíes en el sentido interno de tiempo del modelo) - Estado relevante de sistemas externos (próximos eventos, inventario, detalles de la cuenta del usuario) - Reglas de negocio que no son obvias a partir de la descripción de la tarea La mayoría de los agentes que reviso están escasos de contexto. El operador asume que el modelo "sabe" cosas que no sabe — precios actuales, nombres de miembros específicos del personal, qué funcionalidades están activas en el sistema. No lo asumas. Inyéctalo. ### Capa 3: Tarea La capa de tarea describe lo que hace el agente, paso a paso. No "ayudar a los clientes" — el flujo de decisión real. La trampa aquí es escribir una capa de tarea demasiado abstracta. "Responde la pregunta del cliente" no es una capa de tarea. Una capa de tarea real parece un diagrama de flujo: clasifica la intención, busca la información correcta para esa intención, aplica las reglas de negocio, produce la salida. Los diagramas de flujo son más robustos que las directivas porque reducen la necesidad del modelo de inferir qué quieres en casos ambiguos. ### Capa 4: Formato de salida Esta es la capa más subestimada, y la más responsable de los fallos silenciosos. Si no especificas el formato de salida con precisión, el modelo producirá una salida que parece correcta para un lector humano pero que es suficientemente inconsistente como para romper el análisis posterior. He tenido agentes que funcionaron perfectamente durante semanas y luego empezaron a añadir una nueva línea adicional antes del JSON que rompía mi lógica de extracción. Escribe el formato de salida antes que cualquier otra cosa. Si no puedes describir exactamente cómo quieres que sea la salida, no entiendes la tarea lo suficientemente bien como para automatizarla todavía. Para la salida estructurada, especifica el esquema exacto: ``` Devuelve un único objeto JSON con estos campos exactos: { "intent": "availability" | "event" | "membership" | "complaint" | "other", "reply": string, "escalate": boolean, "escalation_note": string } No incluyas ningún texto fuera del objeto JSON. No añadas marcadores de código markdown alrededor del JSON. ``` ### Capa 5: Casos extremos La capa de casos extremos responde: ¿qué hace el agente cuando la entrada es ambigua, incompleta, en el idioma incorrecto, hostil, o claramente incorrecta? Para cada caso extremo, dale al modelo una ruta de respuesta explícita. Esta capa es tu protección contra el comportamiento predeterminado del modelo en situaciones ambiguas, que generalmente es intentar ser útil — lo que a menudo significa inventar algo. ## El punto de apalancamiento: el formato de salida Si tuviera que elegir una capa en la que invertir más tiempo, sería el formato de salida. Cada acción que toma tu agente — escribir en una base de datos, enviar un mensaje, llamar a una herramienta — depende de analizar la salida del modelo. Si la salida es inconsistente, la acción posterior falla. Para agentes de alto riesgo, uso el output estructurado de [Claude](/recommends/claude) con un esquema JSON definido. El modelo está obligado a llamar a una herramienta con un esquema validado — sin lógica de análisis, sin regex, sin esperar que el JSON esté bien formado. ## Cómo mantengo los prompts de sistema con el tiempo Un prompt de sistema en producción es un documento vivo: 1. **Revisión semanal puntual.** Reviso cinco a diez salidas aleatorias de cada agente de alto riesgo frente a la salida esperada. 2. **Revisión tras actualización del modelo.** Cada vez que cambia la versión del modelo subyacente, ejecuto el agente contra el conjunto dorado completo de mi [marco de evaluación](/how-i-measure-whether-an-ai-agent-is-actually-working/). 3. **Registro de casos extremos.** Mantengo un registro de entradas que el agente manejó mal. Cuando tres o más entradas comparten un patrón, añado una regla explícita. 4. **Versionado del prompt.** Cada cambio significativo recibe un comentario de versión en el archivo del prompt. ## Preguntas frecuentes ### ¿Cuánto debe durar un prompt de sistema en producción? Lo suficientemente largo como para cubrir las cinco capas. Lo suficientemente corto como para que puedas leerlo en dos minutos y detectar la deriva. Para la mayoría de mis agentes, eso son 200–600 palabras. ### ¿Cuándo debo dividir una tarea compleja en múltiples agentes en lugar de un prompt largo? Cuando la tarea tiene dos o más modos distintos que requieren contexto diferente, formatos de salida diferentes o manejo de errores diferente. Consulta [agentes por eventos vs programados](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) para el patrón. ### ¿Cuál es la razón más común por la que un prompt que funcionó en las pruebas falla en producción? Las entradas de prueba no eran representativas de la distribución de producción. Construye un conjunto de pruebas a partir del tráfico de producción real, no de entradas imaginadas. ### ¿Cómo sé cuándo actualizar el prompt vs actualizar el código? Si el agente produce el formato de salida incorrecto, actualiza el prompt. Si el agente produce la salida correcta pero el sistema posterior no puede usarla, actualiza el código. Si el agente produce hechos incorrectos con confianza, verifica primero la capa de contexto. --- ## ROI de Agentes de IA: Cómo Decido si Vale la Pena Construir una Automatización Source: https://alejandrorioja.com/es/ai-agent-roi-how-i-decide-whether-automation-worth-building/ Published: 2026-07-09 Tags: AI Agents, Operations TL;DR: Antes de construir cualquier agente de IA, realizo una verificación de ROI de cuatro partes: cuantificar el costo manual, estimar el costo de construcción, proyectar el costo de ejecución y agregar un impuesto de mantenimiento. El resultado es un período de retorno. Si supera los seis meses para una tarea no estratégica, la elimino. La mayoría de las ideas de agentes fallan esta prueba — y ese es el punto. ## Tabla de contenidos _Actualizado julio 2026._ **TL;DR:** Antes de construir cualquier agente de IA, realizo una verificación de ROI de cuatro partes: cuantificar el costo manual, estimar el costo de construcción, proyectar el costo de ejecución y agregar un impuesto de mantenimiento. El resultado es un período de retorno. Si supera los seis meses para una tarea no estratégica, la elimino. La mayoría de las ideas de agentes fallan esta prueba — y ese es el punto. Construir la automatización equivocada es peor que no construir nada. **[Perspectiva del operador]** Gestiono más de 30 agentes en producción en una marca de consultoría y Pickleland, una instalación de pádel en Pflugerville, TX. He eliminado al menos tantos agentes como los que he lanzado. Los que eliminé no eran malas ideas — eran buenas ideas que fallaron en las matemáticas. Este marco es lo que ejecuto antes de escribir una sola línea de código de agente. ## La pregunta que nadie hace primero Todos en 2026 preguntan "¿cómo automatizo esto?" La mejor pregunta es "¿debería automatizar esto, y cuándo se amortiza?" Un agente de IA no es gratuito. Cuesta tiempo construirlo, dinero ejecutarlo y atención continua para mantenerlo. Si la automatización no recupera esos costos más rápido que la alternativa manual, has hecho tu operación más compleja y costosa — no más eficiente. El instinto de automatizar todo es comprensible. Los agentes son genuinamente poderosos, y la curva de capacidad es empinada. Pero capacidad y ROI son ejes diferentes. Una tarea puede ser completamente automatizable y aun así no vale la pena automatizarla, ya sea porque la versión manual ya es barata o porque la automatización en sí es demasiado frágil para confiar en ella. ## Paso 1: Cuantificar la línea base manual El primer número es cuánto cuesta el proceso actual por año, con todos los costos incluidos. ``` costo_manual_por_año = (tiempo_por_instancia × tarifa_por_hora × frecuencia_por_año) + costo_de_errores_por_año ``` **Tiempo por instancia** es el tiempo de reloj que alguien realmente dedica — no el tiempo de calendario de inicio a fin, que incluye espera. Si una tarea nominalmente toma dos horas pero el trabajo real es de 20 minutos, usa 20 minutos. **Tarifa por hora** es el costo total de quien realiza el trabajo — salario más beneficios más gastos generales. Si es tu propio tiempo, usa tu tarifa de consultoría u oportunidad objetivo, no cero. Tu tiempo tiene un costo aunque no aparezca en una nómina. **Frecuencia por año** es cuántas veces realmente se ejecuta esta tarea. Muchas automatizaciones parecen atractivas por instancia pero se ejecutan tan raramente que el valor anual es mínimo. **Costo de errores** es el que más gente olvida. ¿Cuánto cuesta un error? Si la tarea es entrada de datos en un CRM y un error humano pasa desapercibido durante dos semanas, ¿cuál es el costo de la limpieza? ¿Cuál es el costo para el cliente? Para algunas tareas es cero. Para otras es el número que cambia todo el cálculo. Ejemplo real de Pickleland: enviar manualmente promociones de eventos de Facebook solía tomar 45 minutos por semana (escribir la publicación, encontrar los grupos correctos, publicar, responder a los comentarios iniciales). A mi tarifa de oportunidad, eso es $45/semana o $2,340/año. El costo de errores era bajo — una mala publicación de promoción es incómoda pero corregible. Esa es la línea base. ## Paso 2: Estimar el costo de construcción honestamente El costo de construcción casi siempre se subestima. El error es contar solo el tiempo de codificación e ignorar todo lo demás. ``` costo_de_construcción = (horas_de_desarrollo × tarifa_por_hora) + costo_de_configuración_de_herramientas + horas_de_prueba_e_iteración × tarifa_por_hora + horas_de_depuración_de_integración × tarifa_por_hora ``` **Horas de desarrollo** es el tiempo de codificación directo. Para un Worker de Cloudflare sencillo que llama a Claude y escribe en Airtable, esto podría ser 4–8 horas. Para cualquier cosa con estado complejo, lógica de reintentos o uso de herramientas en múltiples pasos, planifica 2–3× eso. **Costo de configuración de herramientas** incluye cualquier servicio nuevo que necesites poner en marcha — claves API, cuentas de facturación, configuraciones de webhooks, cambios de DNS. **Prueba e iteración** suele ser el 50–100% del tiempo de construcción inicial. Necesitas ejecutar el agente contra entradas reales, encontrar los casos extremos, ajustar el prompt y confirmar los resultados. **Depuración de integración** es el costo oculto. Conectar a una API de redes sociales, un sistema de reservas o un CRM heredado siempre tiene sorpresas. Para el promotor de eventos de Pickleland: estimé 6 horas para construir, 3 horas para probar y ajustar, 2 horas de depuración de integración. A mi tarifa, eso es $990 en costo de construcción. ## Paso 3: Proyectar el costo de ejecución El costo de ejecución es lo que cuesta la automatización por año una vez en producción. ``` costo_de_ejecución_por_año = (llamadas_api_por_año × costo_por_llamada) + costo_de_infraestructura_por_año + horas_de_revisión_humana × tarifa_por_hora ``` **Llamadas API** son las llamadas a Claude/LLM, más cualquier API de terceros. Calcula esto en función de recuentos reales de tokens — no lo estimes vagamente. Utiliza el endpoint de conteo de tokens para medir los prompts reales contra el modelo objetivo antes de comprometerte con una elección de modelo. **Infraestructura** es hosting, colas, almacenamiento. En Cloudflare Workers + Queues, esto suele ser menos de $5/mes para volumen moderado. **Revisión humana** es el costo que más gente olvida. Un agente que requiere que un humano revise cada resultado antes de actuar no está completamente automatizado — está semi-automatizado. Ese tiempo de revisión es un costo continuo real. Para el promotor de Pickleland: ~1,000 llamadas API de Claude/año. Al precio actual de Haiku — el modelo correcto para esta tarea — el costo de API es bien bajo. La revisión humana asciende a ~$800/año. Costo de ejecución total: ~$810/año. ## Paso 4: Aplicar el impuesto de mantenimiento Este es el factor más subestimado en cada cálculo de ROI de agentes. Los agentes se rompen. Se rompen cuando la API upstream cambia su formato de respuesta, cuando el prompt deja de funcionar después de una actualización del modelo, cuando aparece un caso extremo que no estaba en el conjunto de pruebas. Aplico un 20% plano del costo de construcción por año como impuesto de mantenimiento. Para flujos de trabajo que tocan APIs volátiles, uso 30–40%. ``` costo_de_mantenimiento_por_año = costo_de_construcción × tasa_de_mantenimiento ``` Para el promotor de Pickleland: $990 × 20% = $198/año. ## La fórmula de retorno Ahora el cálculo se une. ``` ahorro_neto_anual = costo_manual_por_año − costo_de_ejecución_por_año − costo_de_mantenimiento_por_año meses_de_retorno = (costo_de_construcción ÷ ahorro_neto_anual) × 12 ``` Para el promotor de eventos de Pickleland: - Costo manual: $2,340/año - Costo de ejecución: $810/año - Mantenimiento: $198/año - Ahorro neto anual: $1,332/año - Costo de construcción: $990 - **Retorno: 8.9 meses** Eso está en el límite. Mi umbral para automatizaciones no estratégicas es de seis meses. El promotor de eventos pasa por un factor adicional: eliminó una tarea que genuinamente detestaba y liberó atención creativa los domingos por la noche, que tiene un valor que no capturo completamente en dólares. ## Mis umbrales de retorno - **Menos de 3 meses:** Construirlo de inmediato. Estos son raros. - **3–6 meses:** Sí rotundo. Estas son las automatizaciones que se acumulan. - **6–12 meses:** Construir si es estratégicamente importante o si el proceso manual es un cuello de botella de calidad. Eliminar de lo contrario. - **Más de 12 meses:** Casi siempre eliminar. La carga de mantenimiento sola tiende a evitar que esto se amortice completamente. ## Cuándo NO automatizar El error más costoso que veo cometer a los equipos es automatizar procesos inestables. Si el flujo de trabajo cambia cada pocas semanas porque el negocio en sí todavía está descubriendo qué está haciendo, la automatización bloquea la versión rota actual y hace que sea más difícil cambiarla. Antes de automatizar, pregunta: ¿este proceso ha sido estable durante al menos tres meses? Si no, documéntalo, ejecútalo manualmente hasta que se estabilice, luego automatiza. El segundo error es automatizar tareas de baja frecuencia con altas apuestas. Una tarea que se ejecuta dos veces al año y tiene consecuencias graves si sale mal no es un buen candidato para la automatización. Tercero: no automatices para evitar una conversación. He visto equipos construir automatizaciones complejas para evitar decirle algo a un cliente directamente. Automatizar alrededor de un problema honesto no soluciona el problema. ## La pila de agentes que ejecuta estas automatizaciones La mayoría de las automatizaciones que ejecuto en producción están en Cloudflare Workers + Queues, con [Claude](/recommends/claude) como el LLM. El costo de infraestructura es genuinamente bajo, lo que significa que el cálculo de ROI para flujos de trabajo de volumen moderado casi siempre pasa por el lado de la infraestructura — son los costos de construcción y mantenimiento los que dominan. ## Preguntas frecuentes ### ¿Qué tarifa por hora debo usar para mi propio tiempo? Usa tu costo de oportunidad — lo que ganarías o crearías si dedicaras ese tiempo a otra cosa. Para fundadores, esto suele ser tu tarifa efectiva de consultoría o asesoría. No uses cero. Tu tiempo tiene un costo aunque no aparezca en un cheque de pago. ### ¿Cómo estimo los costos de API de Claude antes de construir nada? Usa el endpoint de conteo de tokens de Claude con una muestra representativa de entradas reales y tu modelo objetivo. Esto te da recuentos reales de tokens. Multiplica por llamadas/año y la tarifa por token del modelo. ### ¿Qué cuenta como automatización "estratégica"? Una automatización estratégica (1) sirve directamente a los clientes de una manera que afecta la retención o conversión, (2) permite una escala de operación que no podrías lograr manualmente, o (3) produce datos que impulsan mejores decisiones. ### ¿Debo contar el tiempo que paso monitoreando el agente? Sí. El tiempo de monitoreo es un costo continuo real. Inclúyelo en tu estimación de costo de ejecución. ### ¿Qué pasa si la tarea es algo que simplemente odio hacer? Odiar una tarea tiene un costo real — en motivación, en procrastinación, en la carga mental de temerla. Aceptaré un período de retorno más largo para tareas que genuinamente detesto, pero no es un cheque en blanco — "odio hacer esto" es una razón para extender el umbral un mes o dos, no una razón para ignorar las matemáticas por completo. --- ## Ventas lideradas por el fundador: cómo encontrar y llegar al comprador correcto antes de escalar un equipo Source: https://alejandrorioja.com/es/founder-led-sales-how-to-reach-decision-makers/ Published: 2026-07-09 Tags: Entrepreneurship, Growth, Marketing TL;DR: Antes de contratar un equipo de ventas, tienes que demostrar que sabes vender. Las ventas lideradas por el fundador se reducen a tres cosas: identificar a la única persona que de verdad puede decir que sí, investigar lo suficiente para ganarte una respuesta, y secuenciar tus canales: correo para el pedido, teléfono para el seguimiento urgente, LinkedIn para la presentación cálida. La mayoría de los tratos se estancan no porque el pitch fuera flojo, sino porque cayó en la bandeja de entrada equivocada. Sortea eso y agendarás reuniones que un vendedor a sueldo no podría. ## Índice _Publicado en julio de 2026._ **TL;DR:** Antes de contratar un equipo de ventas, tienes que demostrar que sabes vender. Las ventas lideradas por el fundador se reducen a tres cosas: identificar a la única persona que de verdad puede decir que sí, investigar lo suficiente para ganarte una respuesta, y secuenciar tus canales: correo para el pedido, teléfono para el seguimiento urgente, LinkedIn para la presentación cálida. La mayoría de los tratos se estancan no porque el pitch fuera flojo, sino porque cayó en la bandeja de entrada equivocada. Sortea eso y agendarás reuniones que un vendedor a sueldo no podría. **[La lectura del operador]** Cada fundador que he visto construir una empresa de verdad cerró los primeros tratos él mismo, normalmente mal al principio, y luego bien. No hay atajo que valga. No puedes delegar un motor de ventas que nunca has puesto en marcha, porque todavía no sabes a qué responde realmente tu comprador. Este es el proceso que uso y con el que guío a los fundadores: cómo encontrar a la persona correcta, investigar lo justo para ganarte una respuesta, y llegar a ella sin rociar a desconocidos ni comprar una herramienta de scraping. ## Por qué los fundadores tienen que vender primero No puedes delegar un motor que nunca has puesto en marcha. Si contratas a un vendedor antes de haber cerrado tú mismo un puñado de tratos, no estás escalando un proceso: estás externalizando el descubrimiento de uno, y pagando un sueldo por aprender lo que deberías haber aprendido gratis. Las ventas lideradas por el fundador no son una fase que toleras hasta que puedas permitirte un vendedor. Son la forma en que aprendes las palabras exactas que usa tu comprador, la objeción que mata nueve tratos de cada diez, y la frase que hace que alguien se incline hacia adelante. Ese conocimiento se convierte después en el guion, el manual y el listón de contratación. Sáltatelo y tu primer fichaje de ventas hereda una conjetura. La buena noticia: como fundador tienes una ventaja injusta que un vendedor nunca tendrá. Tú construiste la cosa. Puedes responder cualquier pregunta, doblar el roadmap en una llamada, y hablar con una credibilidad que ningún desconocido con cuota puede fingir. Tu trabajo es ponerte delante de la persona correcta con la frecuencia suficiente para que esa ventaja importe. ## Paso 1: Identifica a la única persona que puede decir que sí La razón más común por la que el alcance falla es que llega al rol equivocado. Tu mensaje no es rechazado: lo recibe alguien que nunca tuvo el poder de actuar sobre él, y muere en silencio. En la mayoría de las empresas, tres tipos de personas se interponen entre tú y un trato: - **El campeón** — siente el dolor que tu producto resuelve y quiere arreglarlo. A menudo no es alguien de alto rango, pero es quien defenderá tu caso puertas adentro. - **El comprador económico** — controla el presupuesto y puede aprobar el gasto. Es quien en última instancia dice que sí. - **El bloqueador / guardián** — compras, un asistente ejecutivo, TI, o un lugarteniente escéptico cuyo trabajo es filtrar el ruido. No es tu enemigo, pero tampoco es tu objetivo. Antes de contactar a nadie, decide a cuál apuntas y por qué. Para una primera reunión normalmente quieres al campeón o al comprador económico, nunca a un empleado cualquiera cuyo nombre encontraste porque era fácil de encontrar. Llegar a la persona equivocada no solo desperdicia el mensaje; puede quemar la cuenta, porque ahora tu nombre queda asociado a un pitch en frío mal dirigido. Si no puedes articular por qué una persona concreta es el contacto correcto, todavía no estás listo para escribirle. ## Paso 2: Investiga lo suficiente para ganarte una respuesta Investigar a un contacto no es "encontrar una dirección de correo". Es reunir suficiente contexto para que tu mensaje solo pudiera haber sido escrito para esa única persona. Eso es lo que gana una respuesta en una bandeja de entrada que recibe cincuenta pitches por semana. Antes de redactar nada, ten claro: 1. **El detonante** — ¿por qué ahora? Una ronda de financiación, una nueva contratación en un rol relevante, el lanzamiento de un producto, una queja pública, una oferta de empleo que revela un hueco. Una razón por la que el momento tiene sentido para *ellos*. 2. **El dolor específico** — no "empresas como la tuya luchan con X", sino evidencia de que *esta* empresa lo hace. 3. **El tejido conectivo** — una conexión compartida, un cliente en su sector, algo que notaste y que una plantilla no podría fingir. Las fuentes públicas te dan la mayoría de esto sin ninguna herramienta especial: el propio sitio de la empresa y su página de empleo, LinkedIn, prensa reciente, apariciones en pódcast, las llamadas de resultados de las empresas cotizadas, y las comunidades donde tu comprador realmente pasa el rato. Si validaste bien el mercado, ya hiciste parte de este trabajo; consulta [Cómo validar una idea de negocio antes de construirla](/how-to-validate-a-business-idea/) para la investigación de demanda y competencia que también sirve como inteligencia de ventas. La prueba para saber si has hecho lo suficiente: ¿podrías escribir las dos primeras frases del mensaje de forma que *no tuvieran ningún sentido* enviadas a cualquier otra empresa? Si la respuesta es sí, estás listo. Si tu apertura serviría para cien empresas, sigue investigando. ## Paso 3: Secuencia tus canales: correo, teléfono, LinkedIn No existe un único mejor canal. Existe un mejor canal para cada momento. El error es elegir uno y machacarlo. La habilidad está en secuenciarlos para que cada uno haga el trabajo en el que de verdad es bueno. | Canal | Mejor caso de uso | Riesgo si se usa mal | | --- | --- | --- | | Correo | El pedido principal, el seguimiento detallado, cualquier cosa que el comprador necesite reenviar internamente | Ignorado al instante si se lee como una plantilla | | Teléfono | Seguimiento urgente, agendar un trato reservado pero a la deriva, una referencia cálida que te dijeron que llamaras | Se siente intrusivo sin contexto ni motivo previo | | LinkedIn | Primer toque suave, calentar un contacto en frío, mantenerte visible entre correos | Saturado, lento, fácil de parecerse a todos los demás pitches | | Presentación cálida | Cualquier cosa, cuando puedas conseguir una | La credibilidad de quien te presenta está en juego, no la desperdicies | Una secuencia que funciona en la práctica: abre con un correo corto y específico ligado al detonante que encontraste. Si no hay respuesta, aporta valor en LinkedIn: un comentario genuino, un recurso útil, una solicitud de conexión con contexto, para que tu nombre no sea una sorpresa fría. Solo escala a una llamada telefónica cuando haya un motivo real: un plazo, una referencia, un trato que se quedó en silencio tras mostrar interés. Una llamada de la nada, a alguien que nunca ha oído tu nombre, es la forma más rápida de acabar archivado como spam. Y siempre prefiere la presentación cálida cuando puedas ganártela. Una sola presentación de alguien en quien el comprador confía supera a veinte correos en frío perfectamente redactados. Dedica esfuerzo real a mapear quién de tu red puede abrir qué puerta antes de lanzarte al frío. ## Paso 4: Escribe el mensaje que recibe respuesta Una vez que te has ganado el derecho a escribir, mantén el mensaje corto y pon fácil el sí. Los pitches largos de desconocidos no se leen; se archivan. Un buen correo en frío hace cuatro cosas en menos de 90 palabras: 1. **Nombra el detonante** — demuestra que estás prestando atención y que esto no es un envío masivo. 2. **Plantea el dolor relevante** — una frase, enmarcada como suyo, no como tuyo. 3. **Hace un solo pedido pequeño** — una llamada de 15 minutos, no "exploremos una alianza". 4. **Da una salida fácil** — "Si esto no es lo tuyo, ¿podrías indicarme quién lo lleva?". Esta es la forma: > "Hola Priya, vi que acabáis de abrir dos vacantes en el equipo de RevOps, lo que suele significar que los reportes se están volviendo dolorosos más rápido de lo que la plantilla puede arreglar. Ayudamos a equipos en Serie B a reducir el tiempo de reportes manuales en un 60% aproximadamente sin arrancar su stack. ¿Valen 15 minutos la próxima semana para ver si es relevante? Y si esta no es tu área, te agradecería que me indicaras quién lo lleva." Eso es específico, respetuoso con su tiempo y trivialmente fácil de responder; incluso el "no" es útil, porque te encamina a la persona correcta. La misma disciplina aplica en todos los canales; si quieres la mecánica más a fondo del alcance a escala sin que te marquen ni te ignoren, la desglosé en [Cómo diseñar una estrategia de alcance exitosa](/crafting-a-successful-outreach-strategy-in-the-world-of-digital-marketing/). ## Paso 5: Prepárate como si la reunión fuera la única que vas a tener El acceso te da la apertura. La preparación te gana el siguiente paso. Los fundadores pelean rutinariamente durante semanas para conseguir una reunión, y luego entran sin haber pensado en el mundo del comprador, y el trato muere no por falta de interés sino por falta de preparación. Antes de cualquier llamada, sé capaz de responder, en seco: - ¿Cómo es el día de esta persona, y dónde encaja mi producto en él? - ¿Cuál es el único resultado que le importa y que yo puedo mover? - ¿Cuáles son las dos objeciones que planteará, y cuál es mi respuesta honesta? - ¿Cuál es el paso siguiente más pequeño que puedo pedir si está interesada pero no lista? Tú construiste el producto, así que la demo es fácil. Lo difícil es sostener las prioridades del comprador en tu cabeza en lugar de las tuyas. Los fundadores que convierten el alcance en ingresos son los que se presentan sonando como si ya entendieran el negocio, porque hicieron el trabajo en el Paso 2. ## Cuándo no escribir El alcance agresivo quema más pipeline del que construye. Sáltate el toque en frío, o frena, cuando: - No puedes nombrar por qué esta persona concreta es el contacto correcto. - Ya has hecho más de dos seguimientos sin respuesta. (Pasa página; el mercado es grande.) - Tu apertura serviría enviada a otras cien empresas. - Estarías llamando fuera del horario laboral normal o sin ningún contexto previo. - La única razón por la que elegiste a esta persona es que su información de contacto era fácil de encontrar. El buen alcance se siente como una nota relevante y bien cronometrada de alguien que hizo su tarea. El mal alcance se siente como spam con mejor segmentación. La diferencia está enteramente en la investigación y en la contención. ## El stack de ventas liderado por el fundador Las herramientas y los hábitos en los que me apoyo para esto, ninguno de los cuales requiere un equipo de ventas: - **Investigación:** el propio sitio de la empresa y su página de empleo, LinkedIn, prensa reciente, y las comunidades donde tus compradores realmente hablan - **CRM:** cualquier cosa que de verdad vayas a actualizar; un simple tablero de Notion o un Airtable le gana a un CRM empresarial que ignoras - **Secuenciación:** un rastreador ligero de quién está en qué etapa y cuál es el próximo toque, para que nada quede a la deriva - **Correo:** una dirección de envío real y calentada y mensajes en texto plano; sin imágenes, sin píxeles de rastreo, nada que grite "campaña" - **Calendario:** un enlace de reserva para que un "sí" se convierta en una reunión con un clic en lugar de cinco correos de ida y vuelta ## La conclusión del operador No necesitas un equipo de ventas para empezar a vender. Necesitas saber exactamente quién puede decir que sí, investigar lo suficiente para que tu mensaje solo pudiera haber sido escrito para esa persona, y secuenciar tus canales para que cada uno haga su trabajo. El correo lleva el pedido, LinkedIn calienta el terreno, el teléfono cierra un hueco urgente, y una presentación cálida les gana a todos. Haz las repeticiones tú mismo el tiempo suficiente para aprender qué de verdad funciona; entonces, y solo entonces, entrega ese manual ganado a pulso a tu primer fichaje. --- **Relacionado:** [Cómo diseñar una estrategia de alcance exitosa](/crafting-a-successful-outreach-strategy-in-the-world-of-digital-marketing/) · [Cómo validar una idea de negocio](/how-to-validate-a-business-idea/) · [Guía de estrategias de growth marketing](/growth-marketing-strategies-guide/) --- ## Cómo construir un negocio solopreneur: la guía 2026 Source: https://alejandrorioja.com/es/how-to-build-a-solopreneur-business/ Published: 2026-07-07 Tags: Entrepreneurship, Growth TL;DR: Elige un modelo de negocio (contenido, servicio, SaaS o productos digitales), construye una audiencia en torno a un nicho concreto y añade fuentes de ingresos secundarias una vez que la principal convierta. La trampa está en empezar los cuatro a la vez: elige el modelo que se ajuste a lo que ya sabes, no el que suene más pasivo. ## Tabla de contenidos _Actualizado julio 2026._ **TL;DR:** Elige un modelo de negocio (contenido, servicio, SaaS o productos digitales), construye una audiencia en torno a un nicho concreto y añade fuentes de ingresos secundarias una vez que la principal convierta. La trampa está en empezar los cuatro a la vez: elige el modelo que se ajuste a lo que ya sabes, no el que suene más pasivo. **[Perspectiva del operador]** He gestionado este sitio, vendido cursos y administrado ingresos de afiliados durante años sin ningún empleado a tiempo completo. Nada de eso empezó con un gran plan — empezó con una cosa que funcionó y, a partir de ahí, la expansión fue deliberada. Esta guía es lo que ojalá hubiera leído antes de intentar hacerlo todo a la vez. ## Qué es realmente un negocio solopreneur Un solopreneur dirige un negocio solo — sin cofundadores, sin empleados, quizás contratistas cuando el volumen lo exige. El objetivo es un negocio que funcione gracias a la experiencia y los sistemas, no al número de personas. Esto es diferente del freelancing. Un freelancer vende tiempo. Un solopreneur construye sistemas que generan ingresos sin requerir su tiempo para cada euro ganado. ## Los 4 modelos de negocio solopreneur Cada negocio unipersonal encaja aproximadamente en uno de estos: 1. **Negocio de contenido.** Publicas (blog, newsletter, YouTube, podcast) y monetizas a través de anuncios, ingresos de afiliados, patrocinios y productos propios. Menor barrera de entrada, mayor tiempo de despegue. 2. **Negocio de servicios.** Ofreces un resultado específico a clientes — consultoría, roles fraccionales, servicios done-for-you. El camino más rápido a 10.000 €/mes, el menos escalable. 3. **Productos digitales.** Cursos, plantillas, ebooks, herramientas. Alto apalancamiento una vez creados, difícil de generar tráfico sin audiencia previa. 4. **Micro-SaaS.** Un pequeño producto de software que resuelve un problema específico. El techo más alto, la barra técnica más exigente. El modelo correcto depende de lo que ya tienes: habilidades, audiencia o capital. ## Paso 1: Elige tu nicho con profundidad real Los nichos amplios (marketing, finanzas, salud) tienen tráfico pero una competencia brutal. Los nichos estrechos (herramientas de IA para fundadores de e-commerce, finanzas personales para enfermeros que empiezan) convierten mejor y posicionan más rápido. La prueba que uso: ¿puedo escribir 50 piezas de contenido genuinamente útil sobre este tema sin quedarme sin ideas? Si sí, el nicho tiene profundidad. Si me cuesta nombrar 20, es demasiado estrecho o no lo conozco suficientemente bien. Tu nicho debe situarse en la intersección de: - Algo que conoces por experiencia, no solo por investigación - Una audiencia con dinero o tiempo para gastar - Un problema que se repite, no una solución puntual ## Paso 2: Construye tu audiencia antes de necesitarla El mayor error que veo: lanzar un producto a una audiencia de cero. Audiencia antes que producto es la regla. Esto es lo que realmente funciona: 1. **Elige un canal de distribución y profundiza en él.** Blog + SEO es lento pero duradero. Una newsletter es rápida de monetizar. El vídeo corto tiene un techo alto pero depende del algoritmo. No dividas la atención entre cuatro plataformas en el primer año. 2. **Publica de forma consistente antes de tener algo que vender.** La audiencia que construyes mientras no tienes nada que vender confía en ti cuando finalmente lo haces. 3. **Construye una lista de email desde el primer día.** Los seguidores en redes sociales son tierra arrendada. Tu lista de email es tuya. Yo uso [ConvertKit](/recommends/convertkit) — gestiona secuencias y broadcasts sin interponerse. Un punto de referencia útil: 1.000 fans verdaderos (suscriptores de email que abren cada email) son suficientes para generar 100.000 €/año con productos digitales. ## Paso 3: Optimiza primero tu fuente principal de ingresos Una vez que tienes audiencia (o un cliente de un servicio), dobla la apuesta en la fuente principal de ingresos antes de añadir secundarias. **Para negocios de contenido:** los ingresos de afiliados son el primer dinero más rápido. Escribes sobre herramientas que usas, enlazas a través de tu página de recomendaciones y ganas un porcentaje. Ningún producto que crear, ningún servicio al cliente. El techo es real — un sitio con mucho tráfico en un nicho lucrativo puede ganar 5.000–30.000 €/mes — pero es el mejor mecanismo de arranque que he encontrado. **Para negocios de servicios:** cobra más de lo que te resulta cómodo. Infravalorar el precio es el error más común del solopreneur. Si tienes una tasa de cierre del 100%, estás cobrando muy poco. **Para productos digitales:** mantén el alcance ajustado. Un curso enfocado de 97 € supera en conversión y tasa de finalización a uno extenso de 497 €. **Para Micro-SaaS:** construye para un dolor que tú mismo tengas. La ventaja de la empatía es real cuando tú eres tu propio cliente objetivo. ## Paso 4: Apila fuentes de ingresos secundarias Una vez que tu modelo principal está convirtiendo, añade fuentes de ingresos que no requieran tiempo proporcional: - **Ingresos de afiliados** — incluso los negocios de servicios y operadores de SaaS pueden ganar ingresos de afiliados con su contenido - **Productos digitales** — aunque seas principalmente un negocio de servicios, un curso o un conjunto de plantillas puede generar ingresos mientras duermes - **Patrocinios** — cuando tu audiencia supere los ~5.000 suscriptores comprometidos - **Licencias** — si has construido un sistema o herramienta, licéncialo a otros en nichos adyacentes El stack es un resultado, no una estrategia. Haz que funcione una fuente primero. ## El stack tecnológico del solopreneur Gestiono toda esta operación con seis herramientas: | Herramienta | Para qué sirve | |---|---| | [Claude](/recommends/claude) | Primeros borradores de contenido, emails y código | | [ConvertKit](/recommends/convertkit) | Lista de email, automatizaciones y broadcasts | | [Notion](/recommends/notion) | Calendario editorial, documentos de clientes y SOPs | | [Canva](/recommends/canva) | Gráficos para redes sociales y diseño de miniaturas | | [Airtable](/recommends/airtable) | Seguimiento de afiliados, CRM, base de datos de contenido | | [SEMrush](/recommends/semrush) | Investigación de palabras clave y seguimiento de posiciones | Coste mensual total: menos de 300 €. Un equipo que reemplazara este stack costaría más de 15.000 € al mes en salarios. ## Los 3 errores que matan los negocios solopreneur 1. **Escalar prematuramente.** Contratar antes de que el modelo de negocio esté probado consume recursos y añade gestión antes de tener ingresos repetibles. 2. **Diversificar demasiado pronto.** Cuatro fuentes de ingresos a medio rendimiento generan menos que una totalmente optimizada. Profundiza, no te amplíes, en el primer año. 3. **Construir sin distribución.** El mejor producto sin audiencia no supera a un producto mediocre con una lista grande y comprometida. La distribución es el foso. ## La conclusión del operador Un negocio solopreneur es una elección deliberada de intercambiar la complejidad de un equipo por propiedad y margen. Los negocios que he visto funcionar de forma consistente comparten el mismo patrón: un modelo, un nicho, un canal de distribución, mantenido el tiempo suficiente para que se componga. Elige el modelo que se ajuste a tus habilidades existentes. Construye la audiencia antes de necesitarla. Añade fuentes de ingresos solo después de que la principal convierta. El resto es ejecución. --- **Relacionado:** [Cómo validar una idea de negocio](/how-to-validate-a-business-idea/) · [Cómo monetizar un boletín](/how-to-monetize-a-newsletter/) · [Cómo construir una marca personal](/how-to-build-a-personal-brand/) --- ## Cómo automatizar tu pequeña empresa con agentes de IA: guía práctica Source: https://alejandrorioja.com/es/how-to-automate-your-small-business-with-ai-agents/ Published: 2026-07-04 Tags: AI Agents, Entrepreneurship, Operations TL;DR: Automatizar una pequeña empresa con agentes de IA no consiste en reemplazar personas — se trata de delegar el trabajo repetitivo y basado en reglas para poder dedicar tu tiempo a las decisiones que solo tú puedes tomar. Empieza con una tarea, registra todo, mantén a los humanos en el circuito para todo lo que afecte dinero o clientes directamente, y expande desde ahí. El stack que uso en dos empresas cuesta menos de $100/mes en total. ## Tabla de contenidos _Actualizado julio 2026._ **TL;DR:** Automatizar una pequeña empresa con agentes de IA no consiste en reemplazar personas — se trata de delegar el trabajo repetitivo y basado en reglas para poder dedicar tu tiempo a las decisiones que solo tú puedes tomar. Empieza con una tarea, registra todo, mantén a los humanos en el circuito para todo lo que afecte dinero o clientes directamente, y expande desde ahí. El stack que uso en dos empresas cuesta menos de $100/mes en total. **Nota del operador:** Dirijo dos empresas — una instalación de pádel interior de nueve canchas en Pflugerville, TX (Pickleland) y una marca de consultoría. Entre las dos, tengo más de 30 agentes de IA en producción que manejan desde respuestas a comentarios en redes sociales hasta promoción de eventos, borradores de newsletter y seguimientos de reservas. Este es el manual sin rodeos de lo que realmente funciona, lo que desperdicia tiempo y cómo empezar sin contratar a un desarrollador. El planteamiento honesto: los agentes de IA para pequeñas empresas no son magia. No reemplazan el duro trabajo de las relaciones con los clientes, la calidad del producto o el juicio estratégico. Lo que hacen es eliminar la carga administrativa que consume dos o tres horas del día de cada operador — la clasificación del buzón de entrada, los reportes de copiar y pegar, las respuestas sociales, el formateo de datos. Eso es suficiente para marcar la diferencia. ## Los 4 tipos de trabajo que se automatizan bien Antes de construir cualquier cosa, mapea tu carga de trabajo en cuatro categorías. Solo una de ellas es adecuada para los agentes de IA. ### 1. Basado en reglas, repetitivo, texto de entrada / texto de salida Este es el punto óptimo. Clasificar un correo electrónico de un cliente, redactar una respuesta a un comentario en redes sociales, resumir una semana de reservas en una lista de puntos, reformatear un CSV en un informe. La entrada es texto; la salida es texto; las reglas son consistentes. Estas tareas se automatizan con un prompt de un solo uso y un wrapper delgado alrededor de la API. **Ejemplos de Pickleland:** - Clasificar correos de consulta sobre canchas (pregunta / queja / reserva / otro) - Redactar publicaciones para grupos de Facebook sobre próximos eventos - Generar resúmenes semanales de ocupación desde el sistema de reservas ### 2. Pipelines de varios pasos con traspasos claros Una tarea que tiene tres pasos — obtener datos, transformarlos, enviar una notificación — donde cada paso tiene una entrada y salida claras. Esto funciona bien con una capa de orquestación ligera (yo uso Cloudflare Workers Queues). La clave es que cada paso puede fallar de forma independiente y reintentarse sin rehacer todo el trabajo. **Ejemplos de Pickleland:** - Nueva reserva → actualización de CRM → correo de confirmación → notificación de Slack - Envío de formulario → clasificación → borrador de respuesta dirigida → cola de revisión humana ### 3. Monitoreo y alertas Agentes que vigilan una condición y te notifican cuando ocurre. Estas son algunas de las automatizaciones con mayor retorno de inversión porque reemplazan la carga cognitiva de revisar manualmente los paneles. También son de las más simples: la lógica es solo "¿X está por encima del umbral? Si sí, alerta." **Ejemplos de mi marca de consultoría:** - Alertas de anomalías en Google Analytics (caída de tráfico, pico) - Tasa de cancelación de reservas por encima del promedio semanal - Nueva reseña publicada — marcar para respuesta humana ### 4. Primeros borradores de contenido (no el producto final) Los agentes de IA pueden redactar publicaciones sociales, boletines de correo electrónico, esquemas de blog y descripciones de productos con una calidad útil. El problema: no pueden reemplazar tu juicio editorial. Cada borrador pasa por un paso de revisión humana. El retorno de inversión viene de empezar al 70% en lugar de con la pantalla en blanco. **Lo que NO se automatiza bien:** gestión de relaciones con clientes, decisiones de precios, conversaciones de ventas, contrataciones y todo lo que tenga un costo real para una persona real si sale mal. Mantén a los humanos en esas tareas. ## El stack que realmente uso No necesitas software empresarial para esto. Esto es lo que impulsa mis automatizaciones: 1. **[Claude](/recommends/claude)** — la capa de modelo para todas las tareas de IA. Uso la API directamente, no una interfaz gráfica. La calidad por dólar es la mejor que he probado, y el [caché de prompts](/prompt-caching-cut-your-claude-costs-without-switching-models/) reduce aún más los costos cuando los prompts de sistema se repiten. 2. **Cloudflare Workers** — donde viven los agentes. Sin servidor, distribuido globalmente, y el nivel gratuito cubre la mayoría de las cargas de trabajo de pequeñas empresas. El manejador `scheduled` ejecuta tareas cron; el manejador `fetch` recibe webhooks para flujos activados por eventos. 3. **Airtable** — la columna vertebral de datos. Cada agente lee y escribe en tablas de Airtable. Aquí es donde viven el estado del trabajo, las colas de revisión y los datos operativos. Los no desarrolladores pueden editar los datos sin tocar el código. 4. **Kit (antes ConvertKit)** — automatización de correo electrónico y boletines. Mi agente de redacción de boletines escribe en un borrador de Kit; yo reviso y envío. Costo mensual total por más de 30 agentes en dos empresas: menos de $100. La mayor partida es el uso de la API de Claude. Todo lo demás es nivel gratuito o casi gratuito. ## Ejemplos reales: automatizaciones de Pickleland ### El promotor de eventos Cada domingo, un agente programado consulta el sistema de reservas para ver los eventos de los próximos cuatro días. Hace coincidir cada evento con los grupos de Facebook locales relevantes y redacta una publicación de promoción adecuada para cada uno. Los borradores van a una tabla de revisión de Airtable. Paso cinco minutos revisando y haciendo clic en "Aprobar" — el agente hace los 40 minutos de redacción. Nada se publica automáticamente sin mi aprobación. Este es el [patrón de agente programado](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) — se ejecuta en un horario, hace trabajo por lotes y presenta borradores para revisión humana. ### El clasificador de comentarios sociales Cuando llega un nuevo comentario en una publicación de Facebook monitoreada, se activa un webhook y el agente clasifica la intención: pregunta, queja, cumplido o spam. Para preguntas y quejas por encima de un umbral de confianza, redacta una respuesta y la marca para revisión. Los cumplidos los registra. El spam lo suprime. Un ciclo de 30 segundos desde el comentario hasta el borrador. Sin el agente, cada comentario era un cambio de contexto manual; ahora la cola de respuestas pre-redactadas lleva cinco minutos en lugar de treinta. Este es el [patrón de agente activado por eventos](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) — se activa por webhook, debe responder rápido. ### El resumen operativo semanal Cada lunes por la mañana, un agente extrae los datos de reservas de la semana anterior, la tasa de cancelación, la ocupación por tipo de cancha y cualquier anomalía detectada. Formatea un resumen de cinco puntos y lo deposita en una página de Notion. Lo leo con mi café y tengo el contexto operativo que necesito para la semana en dos minutos en lugar de veinte. ## Por dónde empezar: 4 pasos ### Paso 1: Elige la tarea repetitiva de mayor fricción que haces cada semana No la más glamurosa, no la más estratégica — la que más te pesa. El informe semanal que copias y pegas de tres fuentes. Las respuestas sociales en las que pasas una hora. Los correos de seguimiento que envías uno por uno. Ese es tu primer agente. ### Paso 2: Mapea la tarea en entradas y salidas Escribe: - Qué activa la tarea (un reloj, un evento, el envío de un formulario) - Qué entradas necesita (fuentes de datos, texto, contexto) - Cuál es la salida (un borrador, una notificación, una fila de base de datos) - Cuál es el paso de revisión humana (cada primer agente debería tener uno) Si no puedes mapearlo claramente, la tarea no está suficientemente bien definida para automatizarse. Aclara primero el proceso de forma manual. ### Paso 3: Construye la versión más pequeña posible No un sistema. Un prompt, una llamada a la API, una salida. Una función TypeScript que toma la entrada, llama a Claude y devuelve el borrador. Sin base de datos, sin webhook, sin cola — solo la lógica central. Ejecútala manualmente cinco veces. ¿La calidad de la salida se mantiene? Si es así, tienes un agente funcionando. Luego agrega la infraestructura. ```typescript // El primer agente más simple posible: borrador de promo de evento async function draftEventPromo(event: PadklelandEvent, env: Env): Promise { const msg = await env.ANTHROPIC.messages.create({ model: "claude-opus-4-8", max_tokens: 400, system: `You write Facebook event promo posts for Pickleland, an indoor pickleball facility in Pflugerville, TX. Tone: friendly, local, community-focused. Max 150 words.`, messages: [ { role: "user", content: `Write a promo post for this event: ${JSON.stringify(event)}`, }, ], }); return (msg.content[0] as { text: string }).text; } ``` ### Paso 4: Agrega observabilidad antes de agregar más funciones Registra cada ejecución con un ID de traza. Registra la entrada, la salida y la marca de tiempo. No necesitas una herramienta sofisticada — el JSON estructurado en stdout es suficiente para empezar. La razón: tu primer agente fallará de maneras que no predijiste. Cuando lo haga, necesitas poder ver qué pasó sin recrear el estado de memoria. Este es el hábito que separa a los operadores que escalan su stack de agentes de los que se rinden después de una mala experiencia. Profundizo en esto en [cómo depurar un agente de IA en producción](/how-to-debug-an-ai-agent-in-production/). ## Errores comunes (y cómo evitarlos) **Automatizar antes de entender el proceso.** Si no puedes hacer la tarea tú mismo de manera consistente, un agente de IA simplemente la hará de manera inconsistente a escala. Documenta primero el proceso manualmente, luego automatiza. **Eliminar el paso de revisión humana demasiado pronto.** Empieza cada agente con un bucle de revisión humana. Déjalo correr durante dos semanas, revisa cada salida y gana confianza antes de permitir que cualquier cosa vaya completamente automatizada. La excepción son las acciones de bajo riesgo y fácilmente reversibles (como escribir un borrador en una carpeta). **Construir el sistema completo antes de validar el núcleo.** Construye primero la versión más simple posible. Si la calidad central no está con un prompt, más infraestructura no lo arreglará. **Ignorar los costos.** Los costos de la API de IA escalan con el uso. Conoce tu costo por ejecución antes de desplegar a volumen. La [matemática de costos de Haiku vs Sonnet](/ai-agent-cost-math-when-haiku-beats-sonnet/) importa cuando haces miles de ejecuciones por semana. **Tratar los fallos como catástrofes.** Los agentes fallan. Los prompts regresan. Las APIs caen. Construye lógica de reintentos, construye [arneses de evaluación](/the-eval-harness-i-use-to-ship-ai-agents/) y trata los fallos como datos, no como desastres. ## El cambio de mentalidad que lo cambia todo El cuello de botella en una pequeña empresa casi nunca es el dinero — es el tiempo y la atención del propietario. Cada hora que dedicas a tareas que un agente puede manejar es una hora que no dedicaste a los clientes, al producto o a la estrategia. El marco que uso: si una tarea se puede escribir como un proceso repetible con entradas y salidas claras, es candidata a ser un agente. Todo lo que requiere juicio, relación o creatividad se queda conmigo. El agente maneja lo primero para que pueda concentrarme en lo segundo. Empezar con agentes de IA no requiere un cofundador técnico, un presupuesto de software de seis cifras ni meses de construcción. Requiere elegir una tarea de alta fricción, construir la versión más pequeña que funcione y aprender de la salida. La mayoría de los operadores encuentran su primer agente funcionando en un fin de semana. A partir de ahí, el segundo lleva una tarde. ## Preguntas frecuentes ### ¿Cuánto cuesta ejecutar agentes de IA para una pequeña empresa? Mi stack ejecuta más de 30 agentes por menos de $100/mes. El mayor costo es el uso de la API de IA (Claude). Cloudflare Workers es gratuito hasta 100.000 solicitudes/día y $5/mes después. Airtable tiene un nivel gratuito que cubre la mayoría de las necesidades de datos de pequeñas empresas. Los costos escalan con el uso — un solo agente que se ejecuta unas pocas veces a la semana es insignificante. ### ¿Necesito un desarrollador para construir agentes de IA? Para los patrones básicos — un cron programado, un manejador de webhooks, un prompt simple — puedes arreglártelas con un poco de JavaScript y disposición para leer documentación. Para pipelines más complejos, orquestación y observabilidad de nivel de producción, un desarrollador hace el trabajo más rápido. Mi curso ([Agentes de IA para principiantes](/ai-agents-for-beginners-cowork-codex-guide/)) enseña los caminos sin código y de código bajo para operadores. ### ¿Cuál es el mejor primer agente de IA para una pequeña empresa? El resumen operativo semanal. Se ejecuta en un horario, tiene entradas claras (tus fuentes de datos), produce una salida consistente (un resumen formateado) y tiene riesgo cero a la baja — si el borrador está mal, simplemente no lo lees. Construye tu intuición sobre lo que los agentes pueden y no pueden hacer sin riesgo para los clientes u operaciones. ### ¿Qué modelo de IA debo usar para la automatización de negocios? Uso Claude para casi todo mi trabajo con agentes. La calidad de la API, la fiabilidad y el precio favorable para operadores (especialmente con el [caché de prompts](/prompt-caching-cut-your-claude-costs-without-switching-models/)) lo convierten en la opción correcta para uso en producción. Para tareas de clasificación baratas y de alto volumen, Claude Haiku 4.5 es rápido y económico. Para redacción y tareas matizadas, Claude Sonnet u Opus. ### ¿Cómo evito que los agentes de IA cometan errores que perjudiquen a mi empresa? Tres prácticas: mantén a los humanos en el circuito para todo lo que afecte directamente a clientes o dinero; registra cada ejecución para poder rastrear qué salió mal; y construye un [arnés de evaluación](/the-eval-harness-i-use-to-ship-ai-agents/) para que los cambios en tus prompts no rompan silenciosamente la producción. Empieza con tareas internas de bajo riesgo y expande solo después de confiar en la calidad de la salida. --- ## Cómo construir una marca personal online: El manual del practicante 2026 Source: https://alejandrorioja.com/es/how-to-build-a-personal-brand/ Published: 2026-07-02 Tags: Entrepreneurship, Growth TL;DR: Una marca personal se construye eligiendo una audiencia específica, publicando contenido útil de forma consistente en un solo canal y teniendo un punto de vista claro — no optimizando tu bio de LinkedIn. Enfoca tu nicho, escribe desde la experiencia real, construye una lista de correo electrónico como tu único canal propio y repite hasta que las personas correctas no puedan ignorarte. ## Tabla de contenidos _Actualizado julio 2026._ **TL;DR:** Una marca personal se construye eligiendo una audiencia específica, publicando contenido útil de forma consistente en un solo canal y teniendo un punto de vista claro — no optimizando tu bio de LinkedIn. Enfoca tu nicho, escribe desde la experiencia real, construye una lista de correo electrónico como tu único canal propio y repite hasta que las personas correctas no puedan ignorarte. **[Nota del operador]** He estado construyendo en público a través de múltiples negocios — Pickleland, consultoría de agentes de IA, este sitio — y el patrón que sigo viendo es el mismo: las personas que construyen marcas personales reconocibles no son las más talentosas. Son las más específicas y las más consistentes. Aquí está el framework que uso y recomiendo. ## Qué es realmente una marca personal (y qué no) Una marca personal es la respuesta a una pregunta: *¿Qué dicen de ti las personas cuando no estás en la sala?* No es tu logo. No es tu paleta de colores. No es cuántos seguidores tienes. Una marca personal es el atajo mental que las personas forman cuando escuchan tu nombre — el problema específico que creen que puedes resolver, la perspectiva que esperan que tengas. El error que comete la mayoría: intentan crear una marca antes de haber desarrollado un punto de vista. Diseñan la presentación antes de hacer el trabajo. Una marca es lo que se acumula al hacer cosas reales y ser específico sobre lo que aprendiste — no algo que fabricas por adelantado. Lo que puedes controlar desde el principio: 1. Con quién hablas 2. Qué problema resuelves para ellos 3. Dónde te encuentran 4. Qué tan consistentemente apareces Lo que se acumula con el tiempo: - Una reputación por un tipo específico de experiencia - Una audiencia que confía en tu criterio - Oportunidades entrantes que no tuviste que perseguir ## Paso 1: Elige el nicho más estrecho con el que puedas vivir El error más común en la construcción de marca personal es ser demasiado amplio. "Experto en marketing." "Consultor de negocios." "Emprendedor tecnológico." Estas son etiquetas sin sentido en un mundo donde todos las tienen. Cuanto más estrecho vayas, más rápido construyes reputación. En lugar de "experto en marketing," prueba: "marketing de crecimiento para productos SaaS B2B con menos de $10M ARR." En lugar de "consultor de negocios," prueba: "ayudar a propietarios de negocios de servicios a sistematizar sus operaciones para que puedan alejarse de la entrega diaria." Prueba tu nicho con este filtro: - **Suficientemente específico para ser buscado.** ¿Puede alguien buscar en Google tu nicho y encontrar una comunidad real alrededor de él? - **Suficientemente específico para ser referible.** Si alguien conoce a una persona con tu problema exacto, ¿piensan en ti primero? - **Suficientemente amplio para producir contenido durante 2+ años.** Deberías poder escribir 100 publicaciones sobre él sin quedarte sin ideas. El nicho correcto no siempre es obvio al principio. Recomiendo elegir la versión más estrecha de tu expertise que tenga demanda real, empezar allí y expandir solo una vez que hayas establecido autoridad en ese carril estrecho. Usa una herramienta de palabras clave como [Semrush](/recommends/semrush) para verificar si tu nicho se busca — unos pocos cientos de búsquedas mensuales para términos específicos significa demanda real; cero búsquedas significa que estás adelantado al mercado o que no hay mercado. ## Paso 2: Elige un canal primario Intentar estar en todas partes a la vez es una manera garantizada de ser mediocre en todas partes. Al principio, elige un canal y profundiza. El canal correcto depende de tu audiencia y preferencia de formato: - **Contenido escrito (blog/newsletter):** Mejor para audiencias analíticas y de practicantes. Se compone con el tiempo a través del SEO. Eres dueño de la lista de correo; no eres dueño del algoritmo. - **LinkedIn:** Mejor para audiencias B2B y profesionales. Alcance nativo para el liderazgo de pensamiento. - **YouTube / video:** Mejor para temas que se benefician de la demostración visual. Mayor costo de producción, mayor techo de confianza. - **X / Twitter:** Mejor para ideas que viajan — observaciones concisas, opiniones, comentarios de la industria. Construí la mayor parte de mi audiencia a través de contenido escrito en este sitio más el correo electrónico — porque escribo más rápido de lo que hablo, y porque poseer el canal me importa más que tomar prestado el alcance de un algoritmo. ## Paso 3: Encuentra tu punto de vista El contenido sin punto de vista es ruido. Lo que separa las marcas personales que se citan, recomiendan y buscan es una perspectiva distinta — una opinión sobre cómo funciona el mundo, informada por la experiencia real. Un POV sólido tiene estas propiedades: - Está fundamentado en algo que realmente has hecho, no solo leído - Desafía al menos un supuesto convencional que tiene tu audiencia - Es suficientemente específico para que algunas personas estén en desacuerdo ## Paso 4: Construye una audiencia propia Cada plataforma en la que construyes puede cambiar su algoritmo, suspender tu cuenta o cerrar. El único canal de distribución que realmente posees es tu lista de correo electrónico. Empieza a construirla desde el primer día, incluso si publicas principalmente en una plataforma social. Para el correo electrónico, uso [ConvertKit](/recommends/convertkit) — está diseñado específicamente para newsletters de creadores y pequeñas empresas. La forma más rápida de hacer crecer una lista de correo desde una marca personal: 1. **Crea un lead magnet genuinamente útil.** Una lista de verificación, plantilla, archivo o guía corta que resuelva un problema específico que enfrenta tu audiencia. 2. **Agrega el opt-in encima del pliegue en cada página de contenido.** La ubicación importa más que el texto. 3. **Escribe una secuencia de bienvenida de 3 correos.** El primero entrega el lead magnet. El segundo introduce tu historia. El tercero explica qué enviarás y con qué frecuencia. 4. **Menciona la lista en cada pieza de contenido.** ## Paso 5: Publica consistentemente — la matemática del interés compuesto Si publicas una pieza de formato largo por semana: - **Semanas 1–8:** Casi nadie lo lee. Esto es normal. - **Meses 3–4:** Algunas piezas comienzan a obtener tráfico orgánico. - **Meses 6–9:** El tráfico de búsqueda se compone. Aparecen consultas entrantes. - **Año 2:** Tienes 100 piezas de contenido. Tu nombre aparece en búsquedas y respuestas de IA. El umbral antes del que la mayoría de las personas renuncia es el mes 4. Mi regla: comprométete 6 meses antes de evaluar si está funcionando. ## Cómo pienso sobre la marca visual La marca visual mínima viable: - Una foto de perfil profesional donde tu cara sea claramente visible - Una foto de perfil consistente en todas las plataformas - Un sitio web simple con un tagline claro y opt-in de correo [Canva](/recommends/canva) está bien para gráficos sociales y diseño simple — no contrates un estudio de marca hasta que tengas product-market fit para tu marca personal. ## Errores comunes 1. **Intentar atraer a todos.** Si escribes para "emprendedores," escribes para nadie. 2. **Publicar sin distribución.** Escribir una publicación y esperar tráfico no es una estrategia. 3. **Cambiar tu enfoque cada trimestre.** El mayor asesino del impulso de la marca personal. 4. **Medir métricas de vanidad.** Mide el tamaño de tu lista y tu tasa de conversión, no tus likes. 5. **Esperar hasta ser "suficientemente experto."** No necesitas ser la principal autoridad mundial en tu tema para enseñar a personas que están 2 pasos detrás de ti. ## El stack de marca personal - **Plataforma de email:** [ConvertKit](/recommends/convertkit) - **Investigación SEO:** [Semrush](/recommends/semrush) - **Creación de contenido:** [Claude](/recommends/claude) - **Diseño:** [Canva](/recommends/canva) ## FAQ ### ¿Cuánto tiempo lleva construir una marca personal? Realísticamente, 12–24 meses de publicación consistente antes de tener entrada significativa. Los primeros seis meses son casi completamente invisibles. ### ¿Necesito estar en todas las plataformas sociales? No. La profundidad en una plataforma supera la presencia superficial en cinco. ### ¿Qué es más importante: la calidad del contenido o la frecuencia de publicación? Ambos, pero no igualmente. La calidad establece el piso. La frecuencia determina si obtienes las repeticiones necesarias para mejorar. ### ¿Debo usar mi nombre real o un nombre de marca? Usa tu nombre real. Las marcas personales vinculadas a una persona real sobreviven mejor a los cambios de algoritmo. ### ¿Cómo monetizo una marca personal? Los cuatro caminos confiables: (1) cursos / productos digitales, (2) consultoría y asesoramiento, (3) asociaciones de afiliados, y (4) contenido patrocinado. --- **Relacionado:** [Cómo validar una idea de negocio antes de construirla](/how-to-validate-a-business-idea/) · [Cómo construir una lista de correo desde cero](/how-to-build-an-email-list/) · [Cómo monetizar un newsletter](/how-to-monetize-a-newsletter/) --- ## Cómo darle memoria a un agente de IA: patrones de persistencia de estado para producción Source: https://alejandrorioja.com/es/how-to-add-memory-to-an-ai-agent/ Published: 2026-06-30 Tags: AI Agents TL;DR: Los agentes sin estado — los que olvidan todo al salir del Worker — funcionan bien para tareas únicas. En el momento en que un agente necesita recordar qué pasó ayer, reconocer a un cliente recurrente o construir sobre salidas anteriores, necesitas memoria. Hay tres patrones: memoria de trabajo (contexto en vuelo, vive en KV durante la duración de una ejecución), memoria episódica (qué pasó y cuándo, un registro consultable) y memoria semántica (qué sabes, recuperado mediante búsqueda vectorial o datos estructurados). Conecta el patrón correcto al trabajo correcto. ## Tabla de contenidos _Actualizado junio 2026._ **TL;DR:** Los agentes sin estado — los que olvidan todo al salir del Worker — funcionan bien para tareas únicas. En el momento en que un agente necesita recordar qué pasó ayer, reconocer a un cliente recurrente o construir sobre salidas anteriores, necesitas memoria. Hay tres patrones: memoria de trabajo (contexto en vuelo, vive en KV durante la duración de una ejecución), memoria episódica (qué pasó y cuándo, un registro consultable) y memoria semántica (qué sabes, recuperado mediante búsqueda vectorial o datos estructurados). Conecta el patrón correcto al trabajo correcto. **[Perspectiva del operador]** Me he chocado contra la pared del agente sin estado más de una vez. El agente de respuesta social que seguía presentándose a clientes con los que había hablado 20 veces. El agente de resumen diario que marcaba el mismo problema cuatro días seguidos porque no recordaba haberlo marcado el día anterior. Agregar el tipo correcto de memoria solucionó ambos problemas. Esto es lo que uso. ## Por qué los agentes sin estado siguen fallando Un agente sin estado comienza cada ejecución solo con lo que le pasas explícitamente: el prompt del sistema, el mensaje del usuario y los datos que obtienes en el momento de la invocación. No tiene conciencia de ejecuciones anteriores, usuarios anteriores ni decisiones anteriores. Para una tarea de clasificación única — leer un comentario, devolver una categoría — el estado sin estado es correcto. Es rápido, barato y predecible. La superficie de falla aparece en el momento en que necesitas continuidad: - Un agente orientado al cliente que no reconoce el historial del cliente - Un agente de contenido que recomienda un artículo que ya recomendó la semana pasada - Un agente de moderación que sigue re-escalando un caso resuelto - Un resumen diario que muestra la misma alerta obsoleta indefinidamente Todos estos son síntomas del mismo problema: el agente no tiene forma de llevar contexto entre ejecuciones. ## Tres tipos de memoria El marco que encuentro útil en producción: 1. **Memoria de trabajo** — lo que el agente sabe _ahora mismo_, durante una sola ejecución. Se mantiene en KV o en memoria durante la vida de la invocación. 2. **Memoria episódica** — qué pasó y cuándo. Un registro estructurado que el agente lee al inicio de cada ejecución para orientarse. 3. **Memoria semántica** — lo que sabe sobre el mundo, los clientes o una base de conocimiento. Recuperado mediante consultas estructuradas o búsqueda vectorial cuando es relevante. No siempre necesitas las tres. La mayoría de los agentes que ejecuto necesitan trabajar + episódica. La memoria semántica es la más difícil de construir y solo justifica su lugar cuando la base de conocimiento es demasiado grande para caber en la ventana de contexto. ## Memoria de trabajo: contexto en vuelo La memoria de trabajo es estado que vive durante la duración de una ejecución del agente. La forma más simple son variables en el alcance de la función. La forma más interesante es una clave KV compartida que las subtareas dentro de la misma ejecución leen y escriben. Mi agente de respuesta social usa la memoria de trabajo para acumular contexto mientras procesa un lote de comentarios en un mensaje de cola. Lee el historial de conversación reciente de cada cliente desde KV al inicio, agrega nuevo contexto mientras procesa y escribe de vuelta al final. ```typescript // workers/social-reply.ts async function processComment( comment: SocialCommentEvent, env: Env ): Promise { // Cargar el historial reciente de este cliente desde KV (memoria de trabajo) const historyKey = `customer:${comment.userId}:history`; const rawHistory = await env.AGENT_KV.get(historyKey); const history: ConversationTurn[] = rawHistory ? JSON.parse(rawHistory) : []; // Construir un prompt del sistema contextual a partir del historial const systemPrompt = buildSystemPrompt(history); const response = await anthropic.messages.create({ model: "claude-opus-4-8", max_tokens: 512, system: systemPrompt, messages: [{ role: "user", content: comment.text }], }); const reply = response.content[0].type === "text" ? response.content[0].text : ""; // Actualizar historial — mantener los últimos 10 turnos, TTL 30 días const updatedHistory: ConversationTurn[] = [ ...history.slice(-9), { role: "assistant", content: reply, timestamp: comment.timestamp }, ]; await env.AGENT_KV.put(historyKey, JSON.stringify(updatedHistory), { expirationTtl: 60 * 60 * 24 * 30, }); await postReply(comment, reply, env); } ``` Dos cosas a notar. El historial está limitado a 10 turnos — inyecta una ventana deslizante, no lo dejes crecer sin límite. Y el TTL es de 30 días: si un cliente se calla durante un mes, el historial expira y el agente empieza de nuevo. Ambos son intencionales. ## Memoria episódica: qué pasó y cuándo La memoria episódica es el registro del agente. Un registro estructurado de ejecuciones pasadas que el agente lee al inicio de cada nueva ejecución para no repetirse. Mi agente de resumen diario mostraba las mismas alertas obsoletas cada día porque cada ejecución no tenía conciencia de lo que ya había marcado. La solución: un registro estructurado de alertas pasadas que el agente lee antes de generar el resumen. ```typescript // workers/daily-brief.ts interface AlertLogEntry { id: string; surfacedAt: string; // marca de tiempo ISO resolvedAt?: string; summary: string; } async function buildDailyBrief(env: Env): Promise { const [emails, calendar, tasks] = await Promise.all([ fetchOvernightEmails(env), fetchTodayCalendar(env), fetchTopTasks(env), ]); // Cargar memoria episódica: qué ya ha sido marcado const rawLog = await env.AGENT_KV.get("brief:alert-log"); const alertLog: AlertLogEntry[] = rawLog ? JSON.parse(rawLog) : []; // Filtrar solo alertas recientes y no resueltas const sevenDaysAgo = new Date( Date.now() - 7 * 24 * 60 * 60 * 1000 ).toISOString(); const recentAlerts = alertLog.filter( (e) => e.surfacedAt > sevenDaysAgo && !e.resolvedAt ); const brief = await synthesizeBrief( { emails, calendar, tasks, recentAlerts }, env ); // Actualizar el registro con nuevas alertas marcadas en esta ejecución const newAlerts: AlertLogEntry[] = brief.newAlerts.map((a) => ({ id: crypto.randomUUID(), surfacedAt: new Date().toISOString(), summary: a, })); const updatedLog = [...alertLog, ...newAlerts].slice(-100); // conservar las últimas 100 await env.AGENT_KV.put("brief:alert-log", JSON.stringify(updatedLog)); await writeToWorkspace(brief.content, env); } ``` El agente ahora sabe qué ha dicho antes. Las alertas duplicadas no aparecen en el resumen hasta que el problema subyacente cambia. Cuando marco una alerta como resuelta, desaparece de la lista activa. Este patrón se generaliza: cualquier agente que produce decisiones, marcas o recomendaciones se beneficia de un registro. El registro es barato (unos pocos KB en KV), el beneficio es alto (no más salidas redundantes). ## Memoria semántica: lo que sabes La memoria semántica es la base de conocimiento. Responde "¿qué sabes sobre X?" en el momento de la consulta, en lugar de meter todo en el prompt del sistema de antemano. La forma más simple es una búsqueda estructurada en KV o una base de datos. Mi agente de reservas de Pickleland consulta perfiles de clientes y preferencias de cancha antes de redactar confirmaciones: ```typescript // workers/booking-agent.ts interface CustomerProfile { userId: string; preferredCourts: string[]; experienceLevel: "beginner" | "intermediate" | "advanced"; specialNotes: string; } async function draftConfirmation( booking: BookingEvent, env: Env ): Promise { // Obtener perfil del cliente desde KV (memoria semántica — conocimiento factual) const profileKey = `customer:${booking.userId}:profile`; const rawProfile = await env.AGENT_KV.get(profileKey); const profile: CustomerProfile | null = rawProfile ? JSON.parse(rawProfile) : null; const systemPrompt = profile ? `Redactas confirmaciones de reserva personalizadas. Este cliente prefiere ${profile.preferredCourts.join(", ")}, es un jugador ${profile.experienceLevel}. ${profile.specialNotes}` : "Redactas confirmaciones de reserva para una instalación de pickleball."; const response = await anthropic.messages.create({ model: "claude-haiku-4-5-20251001", max_tokens: 256, system: systemPrompt, messages: [ { role: "user", content: `Redacta una confirmación para: ${JSON.stringify(booking)}`, }, ], }); return response.content[0].type === "text" ? response.content[0].text : ""; } ``` Para bases de conocimiento más grandes — documentación de productos, una base de conocimiento de soporte, cualquier cosa demasiado grande para caber en una ventana de contexto — necesitas un almacén de vectores. El flujo de trabajo es: embeber la consulta, recuperar los k fragmentos más relevantes, inyectarlos en el contexto. Cloudflare Vectorize maneja esto de forma nativa si ya estás en Workers. Para índices más grandes he usado Upstash Vector. La elección depende de la escala, no del principio. La nota honesta sobre la memoria semántica: es la más difícil de las tres de construir y mantener. El índice necesita mantenerse actualizado. La calidad de recuperación varía. Empieza con búsquedas estructuradas — KV, una tabla en D1 — y solo alcanza la búsqueda vectorial cuando el enfoque estructurado no puede cubrir la superficie de conocimiento que necesitas. ## El marco de decisión de memoria Antes de agregar cualquier memoria a un agente, responde tres preguntas: 1. **¿El agente necesita recordar entre ejecuciones?** Si cada invocación es genuinamente independiente — una traducción, una clasificación, una generación única — omite la memoria. Sin estado es más simple y más barato. 2. **¿El agente se está repitiendo o actuando ciego a su propio historial?** Si es así, agrega memoria episódica primero. Es la corrección de menor esfuerzo y cubre la mayoría de las quejas de "el agente sigue haciendo X". 3. **¿El agente trata a todos los usuarios o entidades de forma idéntica cuando no debería?** Si es así, agrega memoria de trabajo (historial del cliente, perfil de usuario) o memoria semántica (un sistema de búsqueda o recuperación). El error que más veo en la práctica: alguien agrega una enorme base de conocimiento (memoria semántica) a un agente que en realidad fallaba porque no tenía memoria episódica — ningún registro de lo que ya había hecho. La complejidad no coincide con el problema. ## Lo que realmente uso en producción En más de 30 agentes: - **Todos ellos** tienen al menos memoria de trabajo — alguna forma de estado dentro de una ejecución, aunque sea solo la ventana de contexto en sí. - **Aproximadamente la mitad** tienen memoria episódica — un registro de ejecuciones pasadas, decisiones o marcas. Esto casi siempre vale la pena agregar. - **Tres o cuatro** tienen memoria semántica real respaldada por un almacén de vectores. Estos son los agentes que responden preguntas contra una base de conocimiento grande y dinámica. Cloudflare KV es mi almacén predeterminado para memoria de trabajo y episódica. Es rápido, barato y está integrado nativamente en Workers — sin cliente adicional, sin credencial separada. La limitación: KV es eventualmente consistente y no es ideal para escrituras de alta frecuencia. Para agentes que escriben estado muchas veces por segundo, uso Durable Objects o una base de datos D1 en su lugar. Para memoria semántica respaldada por vectores, uso Cloudflare Vectorize para índices pequeños a medianos (menos de ~100K vectores) y Upstash Vector para todo lo más grande. Ambos tienen clientes JavaScript de primera clase. ## La conclusión del operador Agrega memoria a un agente solo cuando el comportamiento sin estado esté causando problemas reales — salidas repetidas, puntos ciegos en el historial del cliente, ignorancia de decisiones pasadas. Luego elige la capa correcta: memoria de trabajo para el contexto en ejecución, episódica para lo que sucedió históricamente, semántica para lo que sabes. Empieza con episódica si no estás seguro — corrige el modo de fallo más común con la menor complejidad. No uses una base de datos vectorial hasta que hayas agotado las búsquedas estructuradas. El mejor sistema de memoria es el más simple que hace que el agente se comporte correctamente. --- **Relacionado:** [El stack de agentes que uso para ejecutar más de 30 agentes en producción](/the-agent-stack-i-use-to-run-30-production-agents-no-python/) · [Agentes disparados por eventos vs. programados](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) · [Cómo mido si un agente de IA realmente funciona](/how-i-measure-whether-an-ai-agent-is-actually-working/) **¿Necesitas ayuda para diseñar la memoria de agentes para tu caso de uso?** [Contáctame](/contact/) — diseño sistemas de agentes en producción para equipos operadores. --- ## Cómo construir una lista de correo desde cero: El manual de 2026 Source: https://alejandrorioja.com/es/how-to-build-an-email-list/ Published: 2026-06-27 Tags: Entrepreneurship, Growth TL;DR: Una lista de correo es el único canal de distribución que realmente posees. Empieza con un imán de leads que resuelva un problema específico, coloca tu formulario de suscripción en zona visible y envía una secuencia de bienvenida de 3 correos en cuanto alguien se suscriba. La calidad supera a la cantidad — 1.000 suscriptores comprometidos superan a 10.000 fríos en cualquier momento. ## Tabla de contenidos _Actualizado en junio de 2026._ **TL;DR:** Una lista de correo es el único canal de distribución que realmente posees. Empieza con un imán de leads que resuelva un problema específico, coloca tu formulario de suscripción en zona visible y envía una secuencia de bienvenida de 3 correos en cuanto alguien se suscriba. La calidad supera a la cantidad — 1.000 suscriptores comprometidos superan a 10.000 fríos en cualquier momento. **[Perspectiva del operador]** Todo negocio en el que he participado que construyó un motor de ingresos duradero tenía una cosa en común: una lista. No seguidores. No impresiones. Una lista de personas que pidieron escucharte. Así es exactamente como construirla desde cero. ## El único activo que realmente posees Cualquier otro canal de distribución puede desaparecer. Una actualización del algoritmo de Google elimina los rankings de búsqueda. Un cambio de política de plataforma mata tu alcance en Facebook. Una cuenta de anuncios se suspende sin previo aviso. Tu lista de correo es la excepción. Cuando tienes una lista de correo, controlas la entrega. Ningún algoritmo decide quién ve tu contenido. Ninguna tarifa de plataforma cobra un peaje cada vez que quieres llegar a tu audiencia. Por eso construir una lista de correo es lo primero que le digo a cada fundador — antes del SEO, antes de los anuncios de pago, antes de las redes sociales. ## Paso 1: Elige una plataforma de email Antes de recopilar una sola dirección, necesitas una plataforma para almacenar y enviar. No uses Gmail. No uses tu correo empresarial. Usa una herramienta creada específicamente con la infraestructura de cumplimiento y entregabilidad adecuada. Mis dos recomendaciones para 2026: **[ConvertKit](/recommends/convertkit)** — La mejor para creadores y operadores en solitario. El sistema de etiquetado y segmentación de suscriptores es genuinamente excelente. Gratis hasta 1.000 suscriptores. **[Moosend](/recommends/moosend)** — La mejor para pequeñas empresas que quieren automatización sin el precio de ConvertKit. Constructor de arrastrar y soltar sólido y entregabilidad consistentemente buena. Si empiezas desde cero, ambas tienen niveles gratuitos que cubren tus primeros cientos de suscriptores. Configura la autenticación DKIM, SPF y DMARC en tu dominio antes de enviar cualquier cosa — esto ha sido requerido por Gmail y Yahoo desde 2024 para remitentes de gran volumen, y protege tu reputación de remitente desde el primer día. ## Paso 2: Crea un imán de leads que valga la pena descargar Un imán de leads es lo que ofreces a cambio de la dirección de correo de alguien. El error que comete la mayoría: ofrecer algo genérico. "Suscríbete a nuestro boletín" no es un imán de leads. Es una solicitud de confianza sin nada a cambio. Tu imán de leads debe resolver un problema específico para una persona específica. Cuanto más específico, mejor convierte. **Formatos que funcionan en 2026:** 1. **Hojas de referencia y plantillas** — Un recurso de una página que alguien puede usar inmediatamente. Cuanto más plug-and-play, mejor. 2. **Mini-cursos (3–5 correos)** — Una secuencia corta que enseña una habilidad, entregada automáticamente. Construye la lista y la relación simultáneamente. 3. **Calculadora o hoja de cálculo** — Alto valor percibido. Una herramienta de dimensionamiento de mercado, un modelo de precios, una plantilla de presupuesto. Estos convierten porque ahorran trabajo real. 4. **Datos o investigación exclusivos** — Resultados de encuestas originales o un informe de referencia. Difícil de replicar, alta credibilidad. 5. **Swipe files** — Colecciones de ejemplos reales (texto de anuncios, líneas de asunto, titulares de páginas de aterrizaje). Los profesionales pagan por estos. 6. **Webinar o repetición de capacitación** — Reutiliza una grabación existente como opt-in. Tarda 20 minutos en configurarse. Un requisito innegociable: el imán de leads debe estar directamente relacionado con lo que enviarás por correo. Una plantilla de anuncios de Facebook que captura suscriptores para un boletín B2B SaaS es un desastre de calidad de lista esperando suceder. ## Paso 3: Coloca tus formularios de suscripción donde funcionen La colocación del formulario impulsa la conversión más que el texto. Pon formularios de suscripción donde ya existe la atención: 1. **Sobre el pliegue en tu página de inicio** — No en el pie de página. No en la barra lateral. Sobre el pliegue, con una descripción clara de lo que recibirán. 2. **Al final de cada publicación del blog** — Alguien que leyó toda tu publicación está precalificado. Atrápalo mientras todavía está comprometido. 3. **Popup de intención de salida** — Se activa cuando un visitante va a cerrar la pestaña. Polarizante, pero funciona. 4. **Página de aterrizaje dedicada** — Una página independiente sin navegación. Aquí es donde envías el tráfico de pago. 5. **Mejoras de contenido** — Un recurso que mejora una publicación específica. Una hoja de cálculo de dimensionamiento de mercado dentro de una guía TAM/SAM/SOM convierte 3–5 veces más que una oferta genérica en la misma página. Consejo de texto: lidera con el resultado, no con el formato. "Consigue la guía de 5 páginas" es más débil que "Conoce el tamaño de tu mercado como lo hace un VC." ## Paso 4: Escribe una secuencia de bienvenida En el momento en que alguien se suscribe, tienes su máxima atención. No la desperdicies con silencio. Como mínimo, envía 3 correos: **Correo 1 (inmediato):** Entrega el imán de leads. Confirma para qué se registraron. Establece expectativas sobre lo que viene. **Correo 2 (día 2):** Tu mejor pieza de contenido — una publicación, un estudio de caso, un framework. Sin pitch. Solo prueba de que suscribirse valió la pena. **Correo 3 (día 4–5):** Tu historia de origen y punto de vista. ¿Por qué te importa este tema? ¿Qué crees tú que la mayoría de las personas en tu espacio no creen? Aquí es donde se construye la confianza. A partir de ahí, mantén una cadencia consistente. Semanal es el estándar. Quincenal funciona si no puedes mantener la calidad semana a semana. El peor error es enviar una vez al lanzar y luego desaparecer tres meses. ## Paso 5: Lleva tráfico a tu opt-in Un formulario sin tráfico no convierte a nadie. Los canales de crecimiento más confiables: **Búsqueda orgánica** — Publicaciones de blog que rankean para los problemas que resuelve tu imán de leads. Alguien que busca tu tema y encuentra tu publicación está precalificado para tu oferta. Este es el canal de menor costo y mayor retención. **Redes sociales (orgánico)** — Publicaciones de LinkedIn, hilos de Twitter/X o videos cortos que llevan personas a tu página de opt-in. Cada publicación debe ser un adelanto, no la historia completa. **Intercambios de boletines y co-promociones** — Encuentra boletines en espacios adyacentes e intercambia menciones. Tú promueves su lista; ellos promueven la tuya. Esta es una de las formas más rápidas de crecer de 500 a 5.000 suscriptores. **Apariciones en podcasts como invitado** — Subestimado. Un episodio de 30 minutos enviado a 2.000 oyentes de nicho puede agregar 50–100 suscriptores profundamente interesados que son más propensos a abrir cada correo que envíes. **Anuncios de pago** — No hagas anuncios para una oferta no validada. Consigue que tu página de opt-in convierta orgánicamente primero, luego escala con tráfico de pago. ## Paso 6: Mantén tu lista limpia Una lista de correo se deteriora. Las personas cambian de trabajo, cambian de correo, cambian de intereses. Si no limpias tu lista, tu entregabilidad sufre — lo que significa que incluso los suscriptores comprometidos dejan de ver tus correos. Mejores prácticas: - **Campaña de re-engagement cada 6 meses** — Envía un correo a cualquiera que no haya abierto en 90+ días. Dales una razón para quedarse. Si no se comprometen, elimínalos. - **Elimina los rebotes duros inmediatamente** — Una alta tasa de rebote le dice a los proveedores de bandeja de entrada que tu lista está sucia. - **Segmenta por compromiso** — Etiqueta a los suscriptores activos y fríos por separado. Solo envía campañas sensibles al tiempo a tu segmento activo. Eliminar suscriptores se siente como perder algo. En la práctica, protege a los suscriptores que quieres conservar. ## Advertencias honestas **La construcción lleva tiempo.** Empezando desde cero solo con métodos orgánicos, espera 3–6 meses para llegar a 1.000 suscriptores. Cualquiera que prometa miles en semanas está vendiendo métricas de vanidad o contactos fríos y no comprometidos que no quieres. **El nicho importa.** Las audiencias B2B responden a datos y estudios de caso. Las audiencias de consumidores responden a descuentos y entretenimiento. El imán de leads y la cadencia de contenido deben coincidir con la audiencia. **Los imanes de leads envejecen.** Lo que convierte bien hoy puede ser obsoleto en 18 meses cuando los competidores copien el formato. Planifica actualizar tu imán de leads anualmente. ## Métricas de referencia realistas | Métrica | Promedio de la industria | Bueno | |--------|-----------------|------| | Tasa de opt-in por popup | 2–4% | 5–8% | | Tasa de opt-in por página de aterrizaje | 20–30% | 40–60% | | Tasa de apertura del correo de bienvenida | 50–60% | 70%+ | | Tasa de apertura continua | 20–25% | 35–45% | | Tasa de clics | 2–3% | 5–10% | No optimices estas cifras en los primeros 90 días. Construye la infraestructura, ejecuta el imán de leads, envía consistentemente. Luego itera. ## Actualizado para junio de 2026 **Imanes de leads generados por IA** — Herramientas como Claude pueden redactar una guía PDF de 10 páginas, un swipe file o una plantilla en minutos. La barrera para crear un imán de leads de alta calidad es casi cero. El diferenciador ahora es la especificidad de la promesa y la relevancia para tu audiencia. **Autenticación de Gmail y Yahoo** — Desde 2024, DKIM, SPF y DMARC son requeridos para remitentes que envían correos a más de 1.000 direcciones por día. Tanto [ConvertKit](/recommends/convertkit) como [Moosend](/recommends/moosend) te guían a través de la configuración durante el onboarding. Hazlo antes de necesitarlo. **Tráfico de búsqueda con IA** — Una página de opt-in bien estructurada con un TL;DR claro y una respuesta directa a una consulta de búsqueda puede aparecer en ChatGPT, Perplexity y Google AI Overviews. He visto páginas de aterrizaje de opt-in generar tráfico constante desde la búsqueda con IA sin ningún trabajo de SEO — porque la página responde directamente una pregunta específica. ## Preguntas frecuentes **¿Cuántos suscriptores necesito para monetizar?** No hay un número universal. He visto boletines con 500 suscriptores profundamente comprometidos en un nicho de alta intención superar a listas de 20.000 contactos genéricos. La pregunta es si tus suscriptores tienen un problema y si confían en ti para resolverlo. **¿Debo comprar una lista de correo?** No. Las listas compradas tienen un engagement terrible, te harán marcar como spam y pueden suspender tu cuenta. No hay atajos. **¿Con qué frecuencia debo enviar correos?** Con la frecuencia que puedas mientras mantengas la calidad. Semanal te mantiene en la mente. El mayor error es estar callado meses y reaparecer con un pitch. **¿Doble opt-in o simple?** Doble opt-in en la mayoría de los casos. La confirmación reduce el tamaño de la lista pero mejora dramáticamente el engagement y la entregabilidad. La excepción es cuando envías tráfico de alta intención y verificado desde una fuente específica. **¿Cuál es la mejor plataforma de email para principiantes?** [ConvertKit](/recommends/convertkit) para creadores que construyen una marca personal o negocio de contenido. [Moosend](/recommends/moosend) para pequeñas empresas que quieren asequibilidad y automatización. Cualquiera es mucho mejor que intentar usar Gmail. ## A dónde llevaría esto después La lista de correo no vive aislada. Tus mejores publicaciones deberían tener una mejora de contenido. Tus correos deberían enlazar a guías en profundidad. Tu imán de leads debería resolver exactamente el problema que abordan tus páginas con más tráfico. Ese ciclo — tráfico → opt-in → nurturing → confianza → oferta — es la base de cada negocio online duradero en el que he participado. Si quieres hablar sobre cómo implementar esto para tu situación específica, la [página de contacto](/contact) es el lugar correcto para empezar. --- ## Cómo monetizar un newsletter: 5 modelos de ingresos que realmente funcionan Source: https://alejandrorioja.com/es/how-to-monetize-a-newsletter/ Published: 2026-06-25 Tags: Entrepreneurship, Growth TL;DR: La mayoría de los newsletters fracasan en la monetización porque persiguen el modelo equivocado para su tamaño de lista. Los cinco modelos que funcionan: suscripciones de pago (mejor para autoridad de nicho), patrocinios (mejor después de 5.000+ suscriptores), recomendaciones de afiliados (menor fricción a cualquier tamaño), embudos de cursos y productos (mayor techo de ingresos) y upsells de servicios (camino más rápido al dinero real). Empieza con uno. Añade un segundo solo cuando el primero esté funcionando. ## Table of contents _Actualizado en junio de 2026._ **TL;DR:** La mayoría de los newsletters fracasan en la monetización porque persiguen el modelo equivocado para su tamaño de lista. Los cinco modelos que funcionan: suscripciones de pago (mejor para autoridad de nicho), patrocinios (mejor después de 5.000+ suscriptores), recomendaciones de afiliados (menor fricción a cualquier tamaño), embudos de cursos y productos (mayor techo de ingresos) y upsells de servicios (camino más rápido al dinero real). Empieza con uno. Añade un segundo solo cuando el primero esté funcionando. **[Perspectiva del operador]** Llevo gestionando un newsletter desde antes de que fuera de moda llamarlo "negocio de newsletter". La versión honesta del camino: intenté hacer todo a la vez, gané casi nada, lo reduje a un modelo y empecé a ganar. Esto es lo que he aprendido y lo que veo funcionar de forma consistente en los operadores con los que trabajo. ## Por qué la mayoría de los newsletters nunca gana un euro El problema de monetización suele ser un problema de secuenciación. La gente lanza un newsletter, lo hace crecer lentamente y luego intenta añadir todos los flujos de ingresos a la vez — una suscripción de pago aquí, un slot de patrocinador allá, un enlace de afiliado en cada número. El resultado es un newsletter que parece un centro comercial: todo está a la venta, nada se siente genuino y los lectores se desenganchan. Los newsletters que ganan de forma consistente hacen una cosa bien primero. Prueban que un modelo funciona para su audiencia específica. Luego — y solo entonces — añaden un segundo. El tamaño de tu lista también determina qué modelos son viables. Una lista de 500 suscriptores es la herramienta equivocada para buscar patrocinadores. Una lista de 50.000 suscriptores está dejando dinero significativo sobre la mesa si solo usa enlaces de afiliados. El modelo debe coincidir con la lista. ## Modelo 1: Suscripciones de pago **Mejor para:** Newsletters de autoridad de nicho con una audiencia profesional definida o de alto interés. Las suscripciones de pago son la forma más pura de monetización de newsletters: los lectores pagan directamente por el contenido. Plataformas como Beehiiv y Substack hacen que sea fácil añadir esto a una lista gratuita. Lo que lo hace funcionar: - Un nicho específico y de alto valor donde la información es escasa o ahorra tiempo (análisis financiero, inteligencia del sector, tácticas a nivel operativo) - Una respuesta clara a "¿qué obtiene un suscriptor al pagar que no obtiene gratis?" - Un nivel gratuito que es genuinamente valioso — no una versión diluida, sino un anticipo del enfoque del nivel de pago Lo que lo mata: - Temas generales con poca urgencia ("consejos de marketing", "desarrollo personal") - Lanzar el pago antes de tener pruebas de que los suscriptores gratuitos lean tu contenido de forma consistente Ingresos realistas: 5–20 €/mes por suscriptor. Con un 5% de conversión desde una lista de 2.000 personas, son 100 suscriptores de pago a 10 €/mes = 1.000 € MRR. Pequeño, pero real, y se acumula. ## Modelo 2: Patrocinios y publicidad nativa **Mejor para:** Newsletters con 5.000+ suscriptores y una demografía de audiencia definida. Los patrocinios son el modelo más visible — un slot de número vendido a una marca relevante para tu audiencia. Cuando funciona, funciona bien: 100–500+ € CPM (coste por mil suscriptores) es típico para una audiencia B2B de nicho o de altos ingresos. La restricción honesta: los patrocinadores quieren escala y especificidad. "Tengo 1.000 suscriptores interesados en marketing" no cierra tratos. "Tengo 6.000 suscriptores que son gerentes de marketing en empresas con 10–500 empleados, con una tasa de apertura del 52%" sí lo hace. Cómo llegar allí: 1. **Define tu audiencia** en términos demográficos, no de intereses 2. **Alcanza 5.000 suscriptores** como suelo mínimo de credibilidad antes de buscar patrocinadores 3. **Demuestra engagement** — las tasas de apertura por encima del 40% son el diferenciador real 4. **Construye un media kit** — un PDF de una página con el recuento de suscriptores, tasa de apertura, perfil de audiencia y paquetes de patrocinio 5. **Empieza con inbound** — lista en marketplaces de patrocinio antes de construir un proceso de ventas outbound Verificación de CPM: si tu lista convierte al 45% de tasa de apertura y vendes un slot de patrocinador por número a 200 € CPM, una lista de 5.000 suscriptores genera 1.000 € por número patrocinado. A cuatro números por mes, son 4.000 €/mes de un solo slot de patrocinador. Con dos slots, 8.000 €/mes. La matemática funciona — a escala. ## Modelo 3: Recomendaciones de afiliados **Mejor para:** Cualquier tamaño de lista, cualquier nicho donde genuinamente uses herramientas y servicios. El marketing de afiliados es el modelo de menor fricción para empezar: recomiendas productos que realmente usas, los lectores hacen clic y ganas una comisión en las compras. Sin relaciones de patrocinadores que gestionar, sin producto que construir, sin nivel de pago que mantener. La restricción clave es la confianza. Las recomendaciones de afiliados solo convierten cuando la recomendación es genuinamente útil y de fuente creíble. Una sección de "mejores selecciones" llena de productos que nunca has usado rendirá por debajo de lo esperado — o peor, dañará la lista. Lo que funciona: - Recomendar herramientas que usas en tu propio stack (para mí: [ConvertKit](/recommends/convertkit) para la gestión de email, [Semrush](/recommends/semrush) para SEO e investigación de contenido) - Colocación contextual — mencionar la herramienta donde es relevante para el contenido, no en un bloque fijo de "patrocinador de este número" que los lectores aprenden a saltarse - Dar una opinión real: lo que te gusta, lo que no y para quién no es adecuado Techo de ingresos: las comisiones de afiliados varían — las herramientas SaaS suelen pagar un 20–40% recurrente en suscriptores convertidos, lo que se acumula bien. Una lista de 1.000 suscriptores donde el 2% de los lectores convierte en un SaaS de 50 €/mes al 30% de comisión = 300 €/mes recurrentes, creciendo con cada nueva inscripción que permanece. ## Modelo 4: Embudo de curso y producto digital **Mejor para:** Operadores con autoridad docente en un dominio específico. El newsletter es la parte superior del embudo; el curso o producto digital es el evento de conversión. Los lectores que confían en ti lo suficiente como para abrir cada número son los leads más cualificados para un producto de pago que les enseña algo que sabes. Este es el modelo con el mayor techo de ingresos cuando se combina con una lista modesta. Un curso de 497 € vendido al 2% de una lista de 5.000 personas son 49.700 € por lanzamiento. A tres lanzamientos por año con crecimiento de la lista, esto se acumula agresivamente. Lo que requiere: - Autoridad docente genuina en un dominio específico — no solo "conozco el marketing" sino "he hecho crecer tres empresas B2B usando este playbook de crecimiento específico" - Contenido que demuestre la autoridad semana a semana (no solo enlaces curados — tus frameworks originales y casos de estudio) - Una secuencia de lanzamiento para la que la lista ha sido preparada — no un email frío de "compra mi curso" de una lista que solo recibe contenido Este es el modelo en el que más me apoyo en mi propio trabajo. El newsletter construye la confianza; el curso la convierte. ## Modelo 5: Upsells de servicios **Mejor para:** Newsletters en fase inicial donde el operador ofrece consultoría, coaching o servicios done-for-you. Este modelo es el camino más rápido a ingresos reales con tamaños de lista pequeños, y es el más infrautilizado. El newsletter te posiciona como el experto; el servicio es el experto en acción. Si 500 personas leen tu newsletter sobre growth marketing y publicas un número al mes que demuestra tu pensamiento, 1–2 de esos 500 lectores levantarán periódicamente la mano y preguntarán si haces consultoría. Si no lo ofreces, has dejado ingresos sobre la mesa. Cómo hacerlo explícito: - Añade una línea al pie de tu newsletter: "Trabajo con un pequeño número de clientes por trimestre en [resultado específico]. Responde a este email si te gustaría explorar eso." - Menciona resultados de clientes (anonimizados) en números relevantes — no como presunción, sino como prueba de que los frameworks funcionan en la práctica - Mantén la capacidad intencionalmente ajustada — la escasez no es fabricada aquí, es real; solo tienes tanto tiempo Realidad de ingresos: un cliente de consultoría a 5.000 €/mes y un newsletter de 200 personas tiene mejor economía que 50.000 suscriptores ganando 0,01 €/suscriptor en ingresos de afiliados dispersos. No esperes a la escala para empezar aquí. ## Cómo elegir el modelo correcto El framework de decisión: | Tamaño de lista | Mejor modelo inicial | Segundo modelo a añadir | |----------------|---------------------|------------------------| | 0–1.000 | Upsells de servicios | Recomendaciones de afiliados | | 1.000–5.000 | Afiliados + lista de espera de curso | Suscripciones de pago | | 5.000–20.000 | Patrocinios | Lanzamiento de curso | | 20.000+ | Patrocinios + curso | Nivel de pago | Una restricción que no cambia a ningún tamaño: elige uno primero. La dispersión de modelos mata la conversión en todos los modelos simultáneamente. ## El stack del operador de newsletter Herramientas que uso y recomiendo para construir un negocio de newsletter: - **Plataforma de email:** [ConvertKit](/recommends/convertkit) — etiquetado de suscriptores, segmentación y secuencias de automatización que separan compradores de lectores - **Investigación SEO y de temas:** [Semrush](/recommends/semrush) — identifica qué busca tu audiencia objetivo antes de escribir sobre ello - **Diseño:** [Canva](/recommends/canva) — media kit, assets de portada de curso y contenido social sin diseñador - **Pagos:** Stripe — para niveles de suscripción de pago o checkouts de cursos ## La conclusión del operador Un newsletter es el activo de contenido con mayor apalancamiento que puedes construir en 2026: la atención en la bandeja de entrada del email es escasa y valiosa de una manera que los feeds sociales no lo son. Pero el activo solo se convierte en ingresos cuando eliges un modelo que se adapta a tu tamaño de lista, lo ejecutas con recomendaciones genuinas y autoridad real, y resistes el impulso de dispersarte en cada método de monetización a la vez. Empieza con el modelo que se adapte a donde estás hoy. Cuando funcione — de forma consistente, con resultados acumulativos — añade el siguiente. --- **Relacionado:** [Cómo validar una idea de negocio antes de construirla](/how-to-validate-a-business-idea/) · [Guía de estrategias de growth marketing](/growth-marketing-strategies-guide/) · [6 mejores servicios de email marketing para pequeñas empresas](/6-best-email-marketing-services-for-small-business/) --- ## Cómo Construir Tu Primer Servidor MCP: Guía Práctica Source: https://alejandrorioja.com/es/how-to-build-your-first-mcp-server/ Published: 2026-06-23 Tags: AI Agents TL;DR: MCP (Model Context Protocol) es cómo le das a Claude acceso estructurado a herramientas y datos externos — bases de datos, archivos, APIs — sin saturar la ventana de contexto. El servidor es más sencillo de lo que parece: instala el SDK, define tus herramientas con JSON schema, implementa los manejadores y conecta vía stdio. Puedes tener a Claude llamando tus herramientas personalizadas en menos de 30 minutos. ## Tabla de contenidos _Actualizado junio 2026._ **TL;DR:** MCP (Model Context Protocol) es cómo le das a [Claude](/recommends/claude) acceso estructurado a herramientas y datos externos — bases de datos, archivos, APIs — sin saturar la ventana de contexto. El servidor es más sencillo de lo que parece: instala el SDK, define tus herramientas con JSON schema, implementa los manejadores y conecta vía stdio. Puedes tener a Claude llamando tus herramientas personalizadas en menos de 30 minutos. **[Perspectiva de operador]** Conecto herramientas nuevas a mis agentes regularmente, y MCP es ahora el camino estándar para hacerlo limpiamente. Una vez construido el servidor, cualquier cliente compatible — Claude Desktop, Claude Code, cualquier aplicación que use el SDK de Anthropic — puede usarlo sin cambios en el código que llama. Ese es el valor: construir una vez, reutilizar en todo. ## Qué es MCP en realidad El **Model Context Protocol** es un protocolo abierto que estandariza cómo los modelos de IA se conectan a contexto externo y herramientas. Piénsalo como un estándar USB-C para integraciones de IA: antes de él, cada aplicación que quería que Claude leyera una base de datos o llamara una API tenía que inventar su propia instalación. Con él, construyes un servidor MCP y cualquier cliente compatible puede usarlo. MCP define tres cosas que un servidor puede ofrecer: - **Herramientas** — funciones que Claude puede llamar (leer un archivo, consultar una BD, enviar un mensaje de Slack) - **Recursos** — datos que Claude puede leer (documentos, filas de base de datos, árboles de archivos) - **Prompts** — plantillas de prompts reutilizables que el host puede inyectar Para la mayoría de casos de uso operativos, estás construyendo **servidores de herramientas**. Los recursos y prompts vienen después, una vez que tienes lo básico funcionando. La arquitectura es cliente-servidor, con el cliente (Claude Desktop, Claude Code, tu aplicación personalizada) controlando todo. El servidor es pasivo — simplemente escucha solicitudes de llamadas de herramientas y devuelve resultados. El cliente decide cuándo llamar a qué herramienta basándose en el output de Claude. ## Las tres piezas de todo servidor MCP Todo servidor MCP que construyas tiene la misma estructura: 1. **El objeto servidor** — declara el nombre, versión y capacidades de tu servidor (herramientas, recursos, prompts) 2. **Definiciones de herramientas** — una lista de herramientas con nombres, descripciones y esquemas JSON para sus entradas 3. **Manejadores de solicitudes** — las funciones que se ejecutan cuando Claude llama a una herramienta Eso es todo. No se necesita base de datos, stack HTTP ni capa de auth para empezar. El servidor mínimo tiene menos de 30 líneas de TypeScript. ## Prerrequisitos (2 minutos) - **Node.js 18+** — verifica con `node --version` - **TypeScript 5+** (incluido como dependencia de desarrollo) - Un cliente MCP para probar — Claude Desktop es gratuito y la forma más fácil de ver tu servidor funcionando No se necesita clave API de Anthropic para ejecutar un servidor MCP. La clave API vive en el cliente (Claude Desktop), no en tu servidor. ## Paso 1: Configurar el proyecto (3 minutos) ```bash mkdir my-mcp-server && cd my-mcp-server npm init -y npm install @modelcontextprotocol/sdk npm install -D typescript tsx @types/node ``` Agrega a `package.json`: ```json { "type": "module", "scripts": { "build": "tsc", "dev": "tsx src/index.ts" } } ``` Crea `tsconfig.json`: ```json { "compilerOptions": { "target": "ES2022", "module": "Node16", "moduleResolution": "Node16", "outDir": "./build", "strict": true }, "include": ["src/**/*"] } ``` ## Paso 2: Escribir el servidor mínimo (5 minutos) Crea `src/index.ts`: ```typescript import { Server } from "@modelcontextprotocol/sdk/server/index.js"; import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js"; import { CallToolRequestSchema, ListToolsRequestSchema, } from "@modelcontextprotocol/sdk/types.js"; const server = new Server( { name: "my-mcp-server", version: "1.0.0" }, { capabilities: { tools: {} } } ); // Declara qué herramientas ofrece este servidor server.setRequestHandler(ListToolsRequestSchema, async () => ({ tools: [ { name: "get_word_count", description: "Cuenta las palabras en un bloque de texto.", inputSchema: { type: "object", properties: { text: { type: "string", description: "El texto en el que contar palabras", }, }, required: ["text"], }, }, ], })); // Maneja las llamadas de herramientas del cliente server.setRequestHandler(CallToolRequestSchema, async (request) => { const { name, arguments: args } = request.params; if (name === "get_word_count") { const { text } = args as { text: string }; const count = text.trim().split(/\s+/).filter(Boolean).length; return { content: [{ type: "text", text: `Conteo de palabras: ${count}` }], }; } throw new Error(`Herramienta desconocida: ${name}`); }); // Conectar vía stdio — así es como Claude Desktop habla con el servidor const transport = new StdioServerTransport(); await server.connect(transport); ``` Este es el servidor completo. Registra una herramienta (`get_word_count`) y la implementa. La estructura es lo que importa. ## Paso 3: Compilar y registrar en Claude Desktop (5 minutos) Compila TypeScript: ```bash npm run build ``` Ahora regístralo en el archivo de configuración de Claude Desktop. En **macOS**: `~/Library/Application Support/Claude/claude_desktop_config.json` En **Windows**: `%APPDATA%\Claude\claude_desktop_config.json` Si el archivo no existe, créalo: ```json { "mcpServers": { "my-mcp-server": { "command": "node", "args": ["/ruta/absoluta/a/my-mcp-server/build/index.js"] } } } ``` Usa la ruta absoluta. Reinicia Claude Desktop después de guardar. Verás un ícono de martillo (🔨) en el campo de entrada — eso significa que Claude ha descubierto tus herramientas. ## Paso 4: Construir una herramienta útil El conteo de palabras es ilustrativo. Aquí hay una herramienta más útil: leer archivos de un directorio de proyecto, que es lo que uso para agentes de inyección de contexto que resumen bases de código, changelogs o archivos de configuración. ```typescript import { readFileSync, readdirSync } from "fs"; import { join, extname } from "path"; const ALLOWED_EXTENSIONS = [".md", ".txt", ".ts", ".json", ".yaml"]; const PROJECT_DIR = process.env.PROJECT_DIR ?? process.cwd(); ``` La lógica es la misma: define las herramientas con esquemas JSON precisos, implementa los manejadores, valida entradas para prevenir path traversal, y retorna texto al cliente. ## Los errores que cometí (para que no los cometas) **La ruta debe ser absoluta.** Las rutas relativas en el config de Claude Desktop no se resuelven como esperas. Usa siempre la ruta completa `/home/usuario/...`. **Stdio significa que no puedes usar `console.log`.** Claude Desktop se comunica con tu servidor por stdin/stdout. Un `console.log` de depuración corrompe el stream JSON-RPC. Usa stderr: ```typescript process.stderr.write(`Debug: ${message}\n`); ``` **Reinicia Claude Desktop después de cada cambio de config.** Los servidores MCP se cargan al inicio. Un archivo de config editado no hace nada hasta que cierras y reabres la app. **Las descripciones de herramientas son el producto.** Claude decide si llamar tu herramienta basándose en el campo `description`. Una descripción vaga significa que Claude no sabrá cuándo usarla. Una precisa significa que Claude la alcanza en el momento correcto. Invierte más tiempo en las descripciones que en la implementación. ## Cómo uso servidores MCP en producción El patrón stdio funciona excelente para Claude Desktop y Claude Code (local). Para agentes en producción — los [30+ que ejecuto en Cloudflare Workers](/the-agent-stack-i-use-to-run-30-production-agents-no-python/) — uso la API de tool-use del SDK de Anthropic directamente, porque necesito la flexibilidad de enrutar a [Haiku vs Sonnet](/ai-agent-cost-math-when-haiku-beats-sonnet) por paso. Los patrones que uso en producción: 1. **Herramientas de desarrollo local** — servidores MCP para Claude Code que exponen herramientas específicas del proyecto 2. **Inyección de contexto** — servidores MCP que precargan documentos relevantes sin copiar archivos manualmente 3. **Puente prototipo-a-API** — construyo MCP primero (más rápido para iterar), luego migro la lógica a SDK tool-use para producción ## Qué construir después Una vez que la estructura del servidor hace clic, las herramientas útiles son las que acceden al contexto externo de Claude: - **Lector de base de datos** — ejecuta una consulta SQL de solo lectura y devuelve resultados como JSON - **Lector de Slack** — obtiene los últimos N mensajes de un canal - **Lector de GitHub** — lista PRs abiertas, lee un archivo en un commit específico - **Wrapper de API interna** — llama tu propia API REST con encabezados de auth integrados ## Preguntas frecuentes ### ¿Necesito una clave API de Anthropic para construir un servidor MCP? No. Tu servidor MCP no llama a la API de Anthropic. Solo responde solicitudes de llamadas de herramientas del cliente. La clave API vive en el cliente, no en el servidor. ### ¿Puede mi servidor MCP llamar APIs externas? Sí — el manejador es solo código TypeScript asíncrono. Puedes consultar una API del clima, consultar una base de datos, escribir en un archivo. Al servidor no le importa qué hace el manejador internamente. ### ¿Cuál es la diferencia entre transporte stdio y HTTP? Stdio es para servidores locales — misma máquina que Claude Desktop o Claude Code. HTTP con SSE es para servidores remotos que puedes desplegar como servicio web. Empieza con stdio; es más simple de depurar. ### ¿Cómo sabe Claude cuándo llamar mi herramienta? Claude decide basándose en el campo `description` de la herramienta y el contexto de la conversación. Si Claude sigue ignorando tu herramienta, perfecciona la descripción. --- ## Cómo validar una idea de negocio antes de crearla Source: https://alejandrorioja.com/es/how-to-validate-a-business-idea/ Published: 2026-06-20 Tags: Entrepreneurship, Growth TL;DR: La mayoría de las ideas de negocio fracasan no por una mala ejecución, sino por saltarse la validación. El camino más rápido: confirma que el problema existe mediante la demanda de búsqueda y evidencia en foros, audita a la competencia para probar que alguien ya está ganando dinero, construye la prueba de humo más pequeña posible y obtén un compromiso — un depósito, una inscripción en lista de espera, una carta de intención — antes de construir cualquier cosa. Si no puedes conseguir que una sola persona se comprometa, la idea no está lista. ## Table of contents _Actualizado en junio de 2026._ **TL;DR:** La mayoría de las ideas de negocio fracasan no por una mala ejecución, sino por saltarse la validación. El camino más rápido: confirma que el problema existe mediante la demanda de búsqueda y evidencia en foros, audita a la competencia para probar que alguien ya está ganando dinero, construye la prueba de humo más pequeña posible y obtén un compromiso — un depósito, una inscripción en lista de espera, una carta de intención — antes de construir cualquier cosa. Si no puedes conseguir que una sola persona se comprometa, la idea no está lista. **[Perspectiva del operador]** He visto este patrón docenas de veces en fundadores con los que he trabajado y en mis propios proyectos: la idea suena convincente, el fundador está apasionado, la ejecución es sólida — y luego lanzan al silencio. No porque construyeron lo incorrecto, sino porque se saltaron el único paso que se los habría dicho antes de pasar seis meses en ello. Aquí está el framework de validación que uso y recomiendo. ## Por qué la mayoría de los esfuerzos de validación fallan El modo de fallo obvio es ninguna validación en absoluto — construir primero, hacer preguntas después. Pero la trampa más sutil es el teatro de validación: hacer encuestas, hablar con amigos, recopilar respuestas vagas de "¡gran idea!" y llamar a eso señal. Las encuestas mienten. La gente es educada. Preguntado "¿pagarías 50 $ por esto?" en un contexto hipotético, la respuesta casi siempre es sí. La única señal que importa es el compromiso: alguien que realmente te da dinero, tiempo o una carta de intención escrita. Todo lo demás es reducción de ruido, no validación. ## Paso 1: Confirma que el problema realmente existe a escala Antes de validar tu solución, valida que el problema es real y que la gente lo busca. **La demanda de búsqueda es el proxy más rápido.** Escribe tu problema en Google. Mira las sugerencias de autocompletado, la sección "La gente también pregunta" y las páginas mejor posicionadas. Si no hay resultados, nadie está buscando — y un negocio que resuelve un problema que nadie busca gastará toda su energía en educación en lugar de conversión. Usa una herramienta de palabras clave como [Semrush](/recommends/semrush) para comprobar el volumen mensual de búsquedas real. Un problema con 1.000–10.000 búsquedas mensuales en tu mercado objetivo es viable. Un problema con 20 búsquedas por mes es un producto de nicho con un problema de distribución. **La evidencia en foros es una capa cualitativa adicional.** Busca en Reddit, Quora, grupos de Facebook de nicho y comunidades de Discord tu problema. ¿Están las personas quejándose activamente de él? ¿Buscando soluciones? ¿Alternativas? La frustración real es un tesoro — significa que el dolor es lo suficientemente fuerte como para motivar a la gente a buscar ayuda públicamente. Si no puedes encontrar 20 hilos en foros de personas reales que describan el problema, sé escéptico. ## Paso 2: Audita a la competencia — prueba de que el dinero ya existe Un instinto común de fundador: "no hay competencia, así que dominaré el mercado." Esto casi siempre está equivocado. No hay competencia generalmente significa no hay mercado. La competencia es prueba de que los clientes existen y pagarán. Busca en Google tu categoría de solución. ¿Quién está posicionando? ¿Qué prometen sus páginas de aterrizaje? ¿Qué cobran? Lee sus testimonios y reseñas — especialmente las negativas. Las reseñas negativas son una hoja de ruta del producto: te muestran exactamente lo que el mercado quiere pero no está obteniendo. Si encuentras 3–5 competidores establecidos con productos reales y clientes reales, esa es una señal saludable. Si encuentras cero, profundiza más antes de concluir que el mercado no existe — o trátalo como una señal de alerta roja. **Preguntas clave a responder:** 1. ¿Quiénes son los 3–5 principales actores? 2. ¿Qué cobran? 3. ¿Qué están criticando los reseñadores? 4. ¿Hay un hueco de posicionamiento que pueda ocupar? ## Paso 3: Construye la prueba de humo más pequeña posible Una vez que sabes que el problema existe y hay dinero en el mercado, construye el artefacto mínimo necesario para probar si *tu* versión obtiene tracción. Esto no es un producto completo. Es un mecanismo de captura de señales. **Opción A: Página de aterrizaje con captura de email.** Un sitio de una página que describe el problema y la solución, con un CTA de "Únete a la lista de espera" o "Obtén acceso anticipado". La tasa de conversión te dice si tu posicionamiento resuena. Herramientas como Webflow, Carrd o incluso una página pública de Notion funcionan bien — no lo sobrecomplejes. **Opción B: Preventa.** Un flujo de pago real con dinero real. Esta es la señal de mayor calidad. Si alguien te da dinero por algo que aún no existe, cree en la solución. Incluso un depósito reembolsable funciona. **Opción C: MVP conserje.** Haz la cosa manualmente antes de automatizarla. Consultoría en lugar de SaaS. Una hoja de cálculo personalizada en lugar de una herramienta de software. Un boletín curado manualmente en lugar de uno generado por IA. Sirves a un puñado de clientes con fuerza bruta, aprendes exactamente lo que valoran y luego construyes el producto alrededor de eso. ## Paso 4: Obtén un compromiso antes de construir Este es el portón que separa la validación real del pensamiento desiderativo. Define qué significa "compromiso" para tu idea antes de ejecutar la prueba de humo: - **SaaS / software:** Una preventa a precio con descuento, o una carta de intención firmada - **Contenido / medios:** Suscriptores de email que hicieron clic para unirse (no solo seguidores) - **Servicios / consultoría:** Una llamada de descubrimiento pagada o una propuesta firmada - **Producto físico:** Un depósito o un pedido anticipado en Kickstarter Si no puedes conseguir que al menos una persona se comprometa — incluso con descuento, incluso con garantía de devolución de dinero — la idea no está lista. Eso no es fracaso; eso es el sistema funcionando. Te ahorró meses de tiempo de desarrollo. ## Paso 5: Establece un umbral de aprobado/reprobado antes de empezar La trampa es esta: ejecutas tu prueba de humo, obtienes resultados tibios y te convences de proceder de todos modos. "El texto de la página de aterrizaje no era bueno." "No lo promoví suficiente." "Solo necesita más tiempo." Para. Antes de ejecutar la prueba, escribe el umbral: > "Si obtengo 50 inscripciones en la lista de espera en 14 días con 0 $ en anuncios pagados, lo construyo. Si no alcanzo 50, no lo construyo — ya sea que cambie el posicionamiento o mate la idea." Escríbelo. Díselo a un amigo. Hazlo público si puedes. Luego cúmplelo. El número es arbitrario; lo que importa es que decides de antemano y no mueves los postes de la portería cuando los datos llegan fríos. ## Errores comunes de validación 1. **Preguntar a la gente si lo compraría.** Casi siempre dicen sí para ser educados. La única pregunta que cuenta es: "¿Lo compras ahora?" 2. **Validar con amigos y familia.** Están apoyándote. No son tus clientes. 3. **Resolver tu propio problema sin comprobar si otros lo tienen.** Tu problema podría ser único para ti. Comprueba los foros. 4. **Llamar respuestas de encuestas validación.** Una encuesta puede generar ideas. No puede validar la demanda. Solo el dinero o el compromiso genuino pueden hacerlo. 5. **Esperar información perfecta.** La validación es obtener suficiente señal para dar el siguiente paso, no eliminar la incertidumbre por completo. ## Qué señales significan "adelante" Estás buscando una combinación de: 1. Volumen de búsqueda superior a 1.000 búsquedas mensuales para la palabra clave del problema principal 2. Actividad de la competencia — 3+ actores reales cobrando dinero real 3. Al menos 20 hilos en foros o comunidades que muestren frustración activa con el problema 4. Una tasa de conversión de prueba de humo superior al 5 % en tráfico dirigido 5. Al menos una persona se compromete — paga, firma o deposita — sin que tengas que suplicarle Cumple los cinco y tienes una dirección viable. Cumple dos o tres y tienes una señal que vale la pena refinar. Cumple cero y necesitas una idea o audiencia fundamentalmente diferente. ## El stack de validación Las herramientas que uso y recomiendo para este proceso: - **Demanda de búsqueda:** [Semrush](/recommends/semrush) — volumen de palabras clave, análisis de la competencia y brechas de contenido en un solo lugar - **Investigación en foros:** Reddit, Quora, grupos de Facebook de nicho, comunidades de Discord - **Página de aterrizaje:** Carrd (gratis, rápido) o Webflow para más control de diseño - **Captura de email / lista de espera:** Kit (ConvertKit) para empezar a construir la lista mientras validas - **Pagos:** Stripe — enlaza directamente a un checkout antes de construir el producto - **Analytics:** Google Analytics en tu página de prueba de humo para rastrear el comportamiento real ## La conclusión del operador Lo más caro que puedes construir es un producto que nadie quiere. La validación no se trata de eliminar el riesgo — se trata de fallar rápido en papel en lugar de fallar lento en producción. Ejecuta la prueba de humo, obtén un compromiso, establece el umbral antes de empezar y respeta el resultado. Si la señal está ahí, lo sabrás. Si no lo está, también lo sabrás. --- **Relacionado:** [Cómo construir un negocio rentable](/how-to-build-profitable-business/) · [Guía de estrategias de marketing de crecimiento](/growth-marketing-strategies-guide/) · [Cómo convertirse en emprendedor](/how-to-become-an-entrepreneur/) --- ## Prompt caching con la Claude API: reduce tus costos de entrada sin cambiar de modelo Source: https://alejandrorioja.com/es/prompt-caching-cut-your-claude-costs-without-switching-models/ Published: 2026-06-18 Updated: 2026-06-18 Tags: AI Agents, Operations TL;DR: El prompt caching reduce el costo de las entradas grandes y estables —tu system prompt, las definiciones de herramientas, los ejemplos few-shot— a aproximadamente el 10% del precio de entrada normal en solicitudes repetidas. El mecanismo es una coincidencia de prefijo: coloca un marcador cache_control al final de tu contenido estable y mantén todo lo volátil después de él. El error que destruye las tasas de aciertos de caché es dejar que un timestamp o un UUID se cuele en el prefijo. ## Table of contents _Actualizado en junio de 2026._ **TL;DR:** El prompt caching reduce el costo de las entradas grandes y estables —tu system prompt, las definiciones de herramientas, los ejemplos few-shot— a aproximadamente el 10% del precio de entrada normal en solicitudes repetidas. El mecanismo es una coincidencia de prefijo: coloca un marcador `cache_control` al final de tu contenido estable y mantén todo lo volátil después de él. El error que destruye las tasas de aciertos de caché es dejar que un timestamp o un UUID se cuele en el prefijo. **[Lectura para operadores]** Manejo más de 100 agentes entre mi marca de consultoría y Pickleland. El mayor renglón de gasto no es el nivel del modelo, sino la frecuencia con la que reenvío el mismo system prompt de 4.000 tokens en cada solicitud. El prompt caching redujo ese costo a casi nada en los agentes de alta frecuencia sin tocar el modelo ni la calidad de la salida. Aquí te explico exactamente cómo funciona y dónde están las trampas. ## Qué hace realmente el prompt caching Cada llamada a la API de [Claude](/recommends/claude) envía tokens. Sin caché, cada token de tu solicitud —system prompt, definiciones de herramientas, ejemplos few-shot y el mensaje del usuario— se cobra a la tarifa de entrada normal. Con caché, un prefijo de esos tokens se almacena en los servidores de Anthropic después de la primera solicitud. En las solicitudes posteriores que comparten ese prefijo exacto, pagas un precio de *lectura* de caché en lugar de volver a procesarlos desde cero. La diferencia de costo es real: - **Escritura de caché:** ~1,25× el precio base de entrada (TTL de 5 minutos) o ~2× (TTL de 1 hora) - **Lectura de caché:** ~0,1× el precio base de entrada - **Punto de equilibrio:** 2 solicitudes con TTL de 5 minutos, 3 solicitudes con TTL de 1 hora Una vez que superas el punto de equilibrio —lo cual ocurre rápido en cualquier agente que se ejecuta más de unas pocas veces al día— cada acierto de caché adicional es un descuento de ~90% sobre esos tokens. ## La regla de coincidencia de prefijo Esta es la única regla de la que se desprende todo lo demás: **la clave de caché es una coincidencia de prefijo de tu prompt renderizado**. Los servidores de Anthropic almacenan el contenido renderizado desde el inicio de tu prompt hasta el marcador `cache_control`. Para que ocurra un acierto de caché en la siguiente solicitud, cada token desde el inicio del prompt hasta ese marcador debe ser idéntico, byte por byte. El orden de renderizado para la coincidencia de prefijo es: tools → system → messages. Así que tu arreglo de herramientas se hashea primero, luego el bloque system, y después los mensajes en orden. Lo que esto significa en la práctica: el contenido estable debe ir primero. Si tu system prompt hace referencia a algo dinámico —una fecha actual, un ID de usuario, un ID de rastreo de solicitud— y aparece *antes* del marcador `cache_control`, la caché fallará en cada solicitud porque el prefijo cambia constantemente. ## Sobre qué poner un marcador de caché Los objetivos de mayor impacto son: **1. Tu system prompt** Los system prompts suelen ser el bloque estable más grande. Una persona de agente detallada, una lista de reglas de comportamiento, un conjunto de instrucciones de formato de salida: todo esto es idéntico en cada invocación del mismo agente. Márcalo: ```typescript import Anthropic from "@anthropic-ai/sdk"; const client = new Anthropic(); const response = await client.messages.create({ model: "claude-opus-4-8", max_tokens: 1024, system: [ { type: "text", text: `You are a content operations agent for alejandrorioja.com. Your job is to draft blog posts in Alejandro's voice: direct, practitioner, first-person, numbered lists, honest caveats. No hedging. No filler. Every section must earn its place. [... 2000 more tokens of stable instructions ...]`, cache_control: { type: "ephemeral" }, }, ], messages: [ { role: "user", content: "Draft a post about prompt caching.", }, ], }); ``` El `cache_control: { type: "ephemeral" }` en el bloque system le indica a Claude que cachee todo hasta ese bloque, incluyéndolo. El arreglo `messages` es volátil —distinto en cada solicitud— y queda fuera del límite de la caché. **2. Definiciones de herramientas** Si tu agente usa herramientas, esas definiciones pueden ser considerables. Un esquema de herramienta bien documentado, con descripción, nombres de parámetros y valores enum, puede llegar a 500–1.000 tokens por herramienta. Con 5 herramientas, eso son hasta 5.000 tokens que pagas por reprocesar en cada llamada: ```typescript const response = await client.messages.create({ model: "claude-opus-4-8", max_tokens: 1024, tools: [ { name: "search_airtable", description: "Search the Airtable content queue...", input_schema: { type: "object", properties: { query: { type: "string" } } }, }, // ... more tools ... { name: "post_to_kit", description: "Schedule a broadcast via the Kit API...", input_schema: { /* ... */ }, // Mark the last tool to cache the entire tools array } as Anthropic.Tool & { cache_control: { type: "ephemeral" } }, ], system: "...", messages: [...], }); ``` Marca la *última* herramienta del arreglo. La coincidencia de prefijo cubrirá el arreglo completo de herramientas a partir de ese punto. **3. Ejemplos few-shot en messages** Si pasas ejemplos few-shot estáticos como mensajes iniciales en el arreglo `messages`, esos también se pueden cachear. Estrúcturalos como los primeros N mensajes y marca el último turno de ejemplo: ```typescript const messages: Anthropic.MessageParam[] = [ { role: "user", content: [ { type: "text", text: "Here are examples of posts in my voice:\n\n[Example 1...]\n\n[Example 2...]", cache_control: { type: "ephemeral" }, } as Anthropic.TextBlockParam & { cache_control: { type: "ephemeral" } }, ], }, { role: "assistant", content: "Understood. I'll follow that voice.", }, // The actual user turn follows — this is volatile, no cache marker { role: "user", content: actualUserRequest, }, ]; ``` ## Qué NO cachear (los invalidadores silenciosos) Estas son las cosas que parecen estables pero no lo son, y que arruinarán tu tasa de aciertos en silencio. La API no te avisará. Simplemente verás `cache_creation_input_tokens` en cada solicitud y te preguntarás por qué. **Timestamps en el system prompt.** El error más común con diferencia: ```typescript // This invalidates the cache on every request const system = `You are an agent. Current time: ${new Date().toISOString()}`; ``` Mueve los timestamps al mensaje del usuario, que es donde corresponden: ```typescript // Stable system prompt — cacheable const system = `You are an agent. Use the current time provided by the user.`; // Volatile user message — not cached const userMessage = `Current time: ${new Date().toISOString()}. Run the daily brief.`; ``` **UUIDs aleatorios e IDs de rastreo.** El mismo problema. Si inyectas un ID de rastreo en el bloque system para tus logs, cada solicitud recibe un prefijo nuevo. **Serialización JSON no determinista.** Si serializas un objeto dentro del system prompt y el orden de las claves no está garantizado, la cadena renderizada puede diferir aunque los datos subyacentes sean los mismos. Serializa con un orden de claves estable o usa una cadena de plantilla. **Selección dinámica de ejemplos few-shot.** Si eliges los ejemplos few-shot según la consulta actual y los colocas en el prefijo cacheado, has hecho que el prefijo "estable" dependa de la consulta. O te comprometes con ejemplos fijos para la capa de caché, o mueves los ejemplos dinámicos al turno de mensaje sin cachear. ## Verificando tu tasa de aciertos de caché Cada respuesta incluye metadatos de uso. Revísalos: ```typescript const response = await client.messages.create({ /* ... */ }); console.log({ inputTokens: response.usage.input_tokens, cacheRead: response.usage.cache_read_input_tokens, cacheWrite: response.usage.cache_creation_input_tokens, outputTokens: response.usage.output_tokens, }); ``` En la primera solicitud: `cache_creation_input_tokens` será distinto de cero y `cache_read_input_tokens` será 0. Esa es la escritura. En un acierto de caché: `cache_read_input_tokens` será distinto de cero y `cache_creation_input_tokens` será 0. Esa es la lectura. Si ves `cache_creation_input_tokens` en cada solicitud, tu prefijo está cambiando. Agrega una sentencia de log que imprima los primeros 200 caracteres de tu system prompt renderizado antes de cada llamada: un timestamp flotante saltará a la vista de inmediato. ## El TTL de 1 hora: cuándo vale la pena el costo extra de escritura El TTL por defecto es de 5 minutos. Si tu agente se ejecuta a baja frecuencia —menos de una vez cada 5 minutos— estarás pagando costos de escritura de caché en la mayoría de las solicitudes sin obtener lecturas. ```typescript // Opt into a 1-hour TTL cache_control: { type: "ephemeral", ttl: "1h" } ``` La escritura con TTL de 1 hora cuesta ~2× el precio base de entrada en lugar de 1,25×. La cuenta: si estás acertando la caché 3 o más veces por hora, el TTL de 1 hora ahorra dinero. Si tu agente se ejecuta una vez al día (como mi resumen diario), ni siquiera el TTL de 1 hora ayudará: pagas costos de escritura cada vez. En ese caso, el beneficio de la caché es modesto a menos que el system prompt sea enorme. Mi agente de resumen diario tiene un system prompt de 3.000 tokens pero se ejecuta una vez al día. La caché no ayuda. Mi agente de newsletter se ejecuta docenas de veces por sesión mientras redacta: la caché ahorra de forma sustancial. ## Pre-calentamiento: hacer que la primera solicitud sea barata Si sabes que se avecina un pico de tráfico —un trabajo por lotes, el lanzamiento de una API— puedes pre-calentar la caché con una solicitud ficticia de bajo costo: ```typescript // Pre-warm: write the cache at near-zero output cost await client.messages.create({ model: "claude-opus-4-8", max_tokens: 1, // minimal output system: [{ type: "text", text: stableSystemPrompt, cache_control: { type: "ephemeral" } }], messages: [{ role: "user", content: "ping" }], }); // Now the real requests read from cache ``` Esto es útil sobre todo para el procesamiento por lotes, donde levantas muchas solicitudes en paralelo y quieres que cada una acierte una caché caliente en lugar de competir por escribirla. ## Prompt caching en bucles agénticos En un bucle agéntico de múltiples turnos, el historial de la conversación crece en cada turno. La caché es lo bastante inteligente para manejar esto: usa una ventana de retrospección de 20 bloques, buscando el prefijo coincidente más largo dentro de los últimos 20 bloques de contenido. La implicación práctica: mantén tu contenido estable (system prompt, definiciones de herramientas) anclado en la parte superior. El historial de conversación creciente al final del arreglo `messages` no romperá la coincidencia de prefijo de los bloques estables: están antes del contenido volátil, y la coincidencia de prefijo empieza desde arriba. En la práctica, mis agentes estructuran los turnos así: ``` System (cached) → Tools (cached) → Few-shot (cached) → Turn 1 → Turn 2 → ... → Current turn ``` La caché cubre todo hasta el marcador del few-shot. El historial de turnos creciente posterior se reprocesa cada vez, pero eso está bien: esos tokens son específicos de la sesión y pequeños en comparación con el prefijo estable. ## Cómo se ve en la factura Toma un agente de alta frecuencia: 100 llamadas al día, system prompt de 4.000 tokens, precios de Sonnet. Sin caché: - 100 × 4.000 tokens × $3/1M = **$1,20/día** Con caché (TTL de 5 min, asumiendo 50 llamadas/hora en el pico): - 1 escritura cada 5 minutos × $3,75/1M × 4.000 tokens = ~$0,02/día en escrituras - ~98 lecturas/día × $0,30/1M × 4.000 tokens = **$0,12/día en lecturas** Eso es una reducción de aproximadamente 90% en esos tokens de entrada. A escala —1.000 llamadas al día— la diferencia se compone aún más. Y esto se suma a cualquier ahorro por enrutamiento de modelos de la [matemática de Haiku vs Sonnet](/ai-agent-cost-math-when-haiku-beats-sonnet): la caché funciona en todos los niveles. ## La conclusión del operador El prompt caching es la optimización de costos más fácil de la Claude API: un campo adicional en los bloques de contenido que ya estás escribiendo. La restricción es la disciplina en torno a la estabilidad del prefijo: nada dinámico antes del marcador de caché. Si logras mantener tu system prompt, tus herramientas y cualquier ejemplo estático libres de contenido volátil, pagarás ~10% del costo de entrada normal en cada acierto de caché. Para agentes de alta frecuencia con prompts estables grandes, esto es una palanca más grande que cambiar de nivel de modelo. --- **Relacionado:** [Matemática de costos de agentes de IA: cuándo Haiku le gana a Sonnet](/ai-agent-cost-math-when-haiku-beats-sonnet/) · [Agentes disparados por eventos vs. agentes programados](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) · [Las 5 herramientas de IA que realmente uso para manejar mi negocio](/the-5-ai-tools-i-actually-use-to-run-my-business-2026-operator-stack/) --- ## Primeras impresiones de Claude Fable 5: la visión de un operador Source: https://alejandrorioja.com/es/claude-fable-5-first-impressions/ Published: 2026-06-12 Updated: 2026-06-12 Tags: AI Agents TL;DR: Fable 5 es el modelo más capaz de Anthropic y se nota en trabajo de agentes difícil y de largo horizonte, pero no es la actualización por defecto. Cuesta más por token, usa un nuevo tokenizer que infla tu conteo de tokens ~30%, ejecuta thinking siempre activo que no puedes desactivar y puede rechazar solicitudes a nivel de clasificador. Para la mayoría de las cargas de trabajo, Opus 4.8 sigue siendo la opción correcta. Recurre a Fable 5 cuando la tarea sea genuinamente difícil. ## Tabla de contenidos _Actualizado en junio de 2026._ **TL;DR:** Fable 5 es el modelo más capaz de Anthropic y se nota en trabajo de agentes difícil y de largo horizonte, pero no es la actualización por defecto. Cuesta más por token, usa un nuevo tokenizer que infla tu conteo de tokens ~30%, ejecuta thinking siempre activo que no puedes desactivar y puede rechazar solicitudes a nivel de clasificador. Para la mayoría de las cargas de trabajo, Opus 4.8 sigue siendo la opción correcta. Recurre a Fable 5 cuando la tarea sea genuinamente difícil. **[Lectura del operador]** Opero más de 30 agentes en producción entre una marca de consultoría y una instalación de pickleball, así que un nuevo modelo insignia no es un benchmark para mí: es una partida del presupuesto y una migración. Esto es lo que cambió cuando realmente conecté Fable 5 a algunos de ellos, y dónde dejé Opus 4.8 en su lugar. ## Qué es Fable 5 en realidad [Claude](/recommends/claude) Fable 5 es el modelo más capaz que Anthropic ha lanzado a gran escala. Está orientado al extremo más exigente del espectro: razonamiento profundo y trabajo de agentes de largo horizonte, esas ejecuciones en las que un agente tiene que sostener un plan a lo largo de docenas de llamadas a herramientas sin perder el hilo. La superficie de la API es casi idéntica a la de Opus 4.7/4.8, lo que facilitó las pruebas. Ventana de contexto de 1M de tokens por defecto, hasta 128K tokens de salida por solicitud. Si has construido algo sobre la línea reciente de Opus, la forma de la solicitud te resultará familiar. Las diferencias están en los detalles, y es en los detalles donde viven el dinero y las sorpresas. Una nota sobre nomenclatura para que no te confundas: **Mythos 5** es el mismo modelo (mismas capacidades, mismo precio, mismo comportamiento), disponible solo a través del programa Project Glasswing de Anthropic. Si no estás en ese programa, el modelo que buscas es `claude-fable-5`. Todo lo de abajo aplica a ambos. ## Dónde es genuinamente mejor Le lancé primero mi tarea de agente más difícil: una ejecución de investigación y síntesis en varios pasos que lee un montón de fuentes, contrasta afirmaciones y escribe un informe con citas. Este es el tipo de trabajo donde los modelos más débiles se desvían: pierden la pista de qué afirmación vino de qué fuente unas diez llamadas a herramientas después. Fable 5 sostuvo el hilo. La síntesis fue más ajustada, las citas se mantuvieron unidas a las afirmaciones correctas y detectó dos contradicciones entre fuentes que mi versión con Opus 4.8 había estado promediando silenciosamente. En razonamiento largo y estructurado es un avance real, no una mejora marginal de benchmark. Ese es el argumento honesto a su favor. Si el modo de falla de tu agente es "se desmorona en el 10% difícil", Fable 5 reduce esa brecha. Si tu agente resume boletines o redacta publicaciones para redes sociales, no notarás la diferencia, y pagarás por una capacidad que no estás usando. ## La trampa de costos que nadie te advierte Aquí está la que te va a morder si lees las notas de la versión por encima. Fable 5 viene con un **nuevo tokenizer**, y el mismo contenido se tokeniza en aproximadamente **30% más tokens** que en la línea de Opus. Léelo de nuevo, porque se acumula con el precio. Fable 5 ya tiene un precio por encima del nivel de Opus de entrada ($10 por millón de tokens de entrada, $50 por millón de salida). Ahora súmale una inflación de tokens de ~30% sobre cada prompt y cada respuesta. Una carga de trabajo sin cambios —mismos prompts, mismas salidas— puede costar significativamente más después de migrar, antes de que hayas cambiado una sola cosa de lo que hace el agente. Así que no reutilices tus números antiguos. Tus configuraciones de `max_tokens`, tus presupuestos de ventana de contexto, tus estimaciones de costo por ejecución: todos se midieron con un tokenizer diferente. La buena noticia: el endpoint de conteo de tokens devuelve los conteos bajo **ambos** tokenizers cuando pasas `model: "claude-fable-5"`, así que puedes medir el delta en tus prompts reales antes de cambiar nada. ```bash # Measure the tokenizer delta on YOUR prompt before migrating. # The response includes input_tokens (new) AND input_tokens_prior_tokenizer (old). curl https://api.anthropic.com/v1/messages/count_tokens \ -H "x-api-key: $ANTHROPIC_API_KEY" \ -H "anthropic-version: 2023-06-01" \ -H "content-type: application/json" \ -d '{ "model": "claude-fable-5", "messages": [{"role":"user","content":""}] }' ``` Lo ejecuté primero sobre mis prompts más pesados. El delta no fue uniforme —varía según el contenido—, pero "presupuesta ~30% más, luego suma el sobreprecio" fue el modelo mental correcto. ## El thinking siempre está activo, y no puedes apagarlo En Fable 5, el thinking adaptativo está siempre en ejecución. El único cambio nuevo que rompe compatibilidad frente a la línea de Opus: si envías un `thinking: {type: "disabled"}` explícito, obtienes un 400. La solución es simple —basta con omitir el parámetro `thinking` por completo—, pero si tenías código que desactivaba explícitamente el thinking para llamadas baratas y rápidas, ese código ahora da error. Tampoco recibes de vuelta la cadena de razonamiento en bruto. Fable 5 la protege: recibes bloques `thinking` normales, y puedes pedir un resumen legible con `display: "summarized"`, pero el razonamiento sin filtrar nunca se expone. Para la mayoría de las aplicaciones esto no es problema: lee el resumen si necesitas visibilidad. Donde importa es en los **agentes multi-turno**: cuando continúas una conversación en el mismo modelo, tienes que devolver los bloques de thinking **sin modificar**. Si los descartas o los editas, el turno se rompe. Si estás construyendo bucles de agentes, trata los bloques de thinking como tokens opacos que arrastras hacia adelante de forma textual. ## Los rechazos ahora son un problema de flujo de control Este es el cambio que más afecta cómo escribes el código alrededor del modelo. Fable 5 ejecuta clasificadores de seguridad sobre las solicitudes entrantes, dirigidos principalmente a la biología de investigación y a la mayor parte del contenido de ciberseguridad. Cuando se rechaza una solicitud, obtienes un **HTTP 200 exitoso** con `stop_reason: "refusal"`: ni un error, ni una excepción. El arreglo `content` puede venir vacío. Si tu código hace `response.content[0].text` sin revisar primero `stop_reason`, va a fallar el día en que se rechace una solicitud. Y el trabajo adyacente benigno —herramientas de seguridad legítimas, tareas de ciencias de la vida— puede ocasionalmente provocar un falso positivo, así que esto no es solo un problema para quienes hacen cosas turbias. La regla es: **ramifica según `stop_reason`, nunca según `stop_details`.** ```typescript const res = await client.messages.create({ model: "claude-fable-5", max_tokens: 1024, messages, }); if (res.stop_reason === "refusal") { // classifiers declined — content is empty or partial. Don't read content[0]. await handleRefusal(res); } else { console.log(res.content[0].text); } ``` Para producción, hay un camino más limpio: un parámetro `fallbacks` del lado del servidor (en beta) que reintenta automáticamente una solicitud rechazada en `claude-opus-4-8` en el mismo viaje de ida y vuelta, con un recálculo de precio tipo crédito aplicado. Si ejecutas agentes sin supervisión, conéctalo para que un único rechazo por falso positivo no deje sin salida una ejecución completa. Esta es la misma lección que sigo reaprendiendo sobre los agentes que [siguen fallando en producción](/why-your-ai-agent-keeps-failing-in-production-and-how-to-fix-it/): que el modelo se vuelva más inteligente no elimina la necesidad de manejar sus casos límite, solo los reubica. ## Dos detalles más de migración Un par de cosas más pequeñas que a mí me costaron tiempo, para que a ti no te lo cuesten: - **Sin prefill del asistente.** Si dirigías la salida prellenando el último turno del asistente, ese patrón ya no existe. Usa salidas estructuradas (`output_config.format`) o instrucciones en el prompt del sistema en su lugar. - **Se requiere retención de datos de 30 días.** Fable 5 no está disponible bajo retención de datos cero. Si estás en ZDR por motivos de cumplimiento, Fable 5 queda descartado y Opus 4.8 sigue siendo tu techo. Verifica esto *antes* de planear una migración, no después. ## ¿Deberías migrar de verdad? Esta es mi decisión como operador después de convivir con él. **Fable 5 no es el objetivo por defecto de "actualizar al modelo más reciente"; Opus 4.8 lo es.** Eso sorprende a la gente, pero es el encuadre correcto. Opus 4.8 es un cambio de ID de modelo respecto a 4.7 sin nuevos cambios que rompan compatibilidad, es más barato y, para la abrumadora mayoría del trabajo de agentes, es indistinguible en calidad de salida. Fable 5 se gana su lugar en las tareas genuinamente difíciles: agentes de largo horizonte que tienen que mantenerse coherentes a lo largo de muchos pasos, razonamiento profundo de múltiples fuentes, las ejecuciones donde la falla que intentas eliminar es sutil. Para esas, la capacidad es real y vale el sobreprecio. Para todo lo demás —redacción de contenido, clasificación, enrutamiento, resumen— estás pagando más tokens a un precio más alto por una calidad que no puedes percibir. Terminé ejecutando ambos. Mi agente de investigación y síntesis pasó a Fable 5. Todo lo demás se quedó en Opus 4.8. Esa división es justamente el punto: elige el modelo según el trabajo, no según la moda. Si operas una flota de agentes, aplica la misma disciplina sobre la que escribí en [mi stack de operador 2026](/the-5-ai-tools-i-actually-use-to-run-my-business-2026-operator-stack/): enruta el trabajo difícil al modelo caro y deja de pagar de más por el trabajo fácil. ## La conclusión del operador Prueba Fable 5 en tu única tarea más difícil antes de tocar cualquier otra cosa: ahí es donde rinde, y si ahí no mueve la aguja, no lo hará en ningún lado. Ejecuta el contador de tokens contra tus prompts reales para que la inflación de tokenizer de ~30% y el sobreprecio no te sorprendan en la factura. Agrega una verificación de `stop_reason: "refusal"` (o el fallback del lado del servidor a Opus 4.8) en cualquier punto donde Fable 5 toque producción. Luego enruta deliberadamente: Fable 5 para el 10% difícil, Opus 4.8 para el resto. El mejor modelo no es el más capaz, es el que está ajustado al trabajo. --- ## La guía definitiva para principiantes sobre agentes de IA: Cowork, Codex y las herramientas que realmente hacen el trabajo Source: https://alejandrorioja.com/es/ai-agents-for-beginners-cowork-codex-guide/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Productivity, AI TL;DR: Los agentes de IA son el paso más allá de los chatbots: les das un objetivo en español llano y ellos hacen el trabajo — leen tus archivos, redactan, organizan, escriben y ejecutan código. Cowork es la rampa de entrada sin código; Codex y Claude Code son para quienes trabajan con una base de código. La habilidad que importa es escribir una instrucción clara y bien delimitada, no aprender a programar. ## Table of contents _Actualizada junio de 2026._ **TL;DR:** Los agentes de IA son el paso más allá de los chatbots: les das un objetivo en lenguaje llano y ellos hacen el trabajo — leen tus archivos, redactan, organizan, escriben y ejecutan código, y verifican su propio resultado. **Cowork** es la rampa de entrada sin código para personas no técnicas; **Codex** y **Claude Code** son para quienes trabajan con una base de código. La única habilidad que importa es escribir una instrucción clara y bien delimitada — no aprender a programar. **[Nota del autor]** Gestiono más de 30 agentes con código en mi día a día, pero la mayoría de las personas no necesitan código para capturar el 80% del valor. Necesitan un buen prompt y un lugar donde ejecutarlo. Esta guía es la introducción que le daría a un amigo inteligente que nunca ha escrito una línea de código. ## Qué es realmente un "agente de IA" Un chatbot responde una pregunta. Un **agente** completa una tarea. La diferencia es que un agente puede tomar acciones en un bucle — leer un documento, decidir qué hacer a continuación, escribir un archivo, ejecutar un comando, verificar el resultado, corregir lo que está mal — sin que tú guíes cada paso. En concreto: no le preguntas "¿cómo limpio esta hoja de cálculo?" Le dices "aquí está la hoja — elimina los duplicados, corrige los formatos de fecha y marca las filas con correos electrónicos faltantes", y el agente lo hace y te entrega el archivo limpio. Ese cambio — de *consejo* a *trabajo terminado* — es exactamente el punto. ## Las dos familias de herramientas Hay dos puertas de entrada a este mundo, y solo necesitas la que se ajusta a tu trabajo. ### Puerta 1: Agentes sin código (empieza aquí si no programas) **Claude Cowork** es un espacio de trabajo donde le das a Claude un objetivo más los materiales — archivos, enlaces, notas — y produce el resultado que tú revisas y usas: un borrador, un resumen, un plan, una hoja de cálculo limpia. Tú escribes instrucciones, no código. Piensa en "un asistente muy capaz que lee rápido y nunca se cansa", no en "una herramienta de programación". Este es el punto de partida correcto para marketers, fundadores, operadores, escritores, analistas — cualquiera cuyo trabajo sea principalmente documentos, investigación y decisiones. ### Puerta 2: Agentes de programación (úsalos en cuanto haya una base de código de por medio) **OpenAI Codex** y **Claude Code** son agentes que viven donde se construye el software — una terminal, un IDE o la nube. Describes un cambio ("añade un interruptor de modo oscuro", "corrige este test que falla", "migra este archivo a la nueva API") y el agente edita el código, lo ejecuta e itera hasta que funciona. Tú sigues revisando todo; el agente hace el tipeo. No necesitas ser un ingeniero senior para usarlos. Muchos no desarrolladores usan agentes de programación para lanzar sitios web pequeños, automatizar hojas de cálculo como scripts y corregir errores en herramientas que no escribieron. Pero hay una curva de aprendizaje real, así que la mayoría de los principiantes se benefician más comenzando en la Puerta 1 y cruzando la Puerta 2 cuando se encuentren con una tarea que genuinamente necesite código. ## Tu primer resultado (hazlo hoy) Elige una tarea pequeña y molesta que hagas con frecuencia. Buenos primeros candidatos: - Convertir una transcripción de reunión desordenada en notas limpias más una lista de puntos de acción. - Resumir un PDF largo en 5 puntos clave y 3 preguntas que vale la pena hacer. - Reescribir un borrador de correo electrónico para que sea claro, cálido y tenga menos de 120 palabras. Luego usa la estructura que hace que los agentes sean confiables en lugar de impredecibles — **rol → entrada → instrucción exacta → restricción → una verificación**: > Eres mi asistente. Aquí tienes una [transcripción de reunión / PDF / borrador de correo] pegada abajo. Haz esto: [conviértelo en notas limpias con una lista en negrita de "Puntos de acción" / resúmelo en 5 puntos + 3 preguntas de seguimiento / reescríbelo para que sea claro, cálido y tenga menos de 120 palabras]. Mantén mi voz. Hazme una pregunta si algo es ambiguo antes de empezar. > > [pega tu contenido aquí] Eso es todo. Acabas de delegar una tarea. La estructura es el juego completo — y funciona de manera idéntica tanto en Cowork, ChatGPT como en un agente de programación. ## El prompt de cuatro partes que hace confiables a los agentes Los principiantes creen que el secreto es una frase mágica. No lo es. Es la especificidad. Toda instrucción confiable para un agente tiene cuatro partes: 1. **Rol** — quién es el agente para esta tarea ("Eres mi asistente de investigación"). 2. **Contexto** — los materiales y el *porqué* ("Me estoy preparando para una llamada de ventas con un fundador fintech"). 3. **Tarea** — la acción exacta y delimitada ("Extrae tres hechos recientes sobre rondas de financiación y redacta dos preguntas de apertura"). 4. **Restricciones + una verificación** — formato, extensión, tono, y una instrucción para preguntar antes de asumir ("Solo viñetas, cita fuentes, hazme una pregunta aclaratoria si la empresa es ambigua"). Instrucción vaga, resultado vago. Cuanto más puede *hacer* un agente, más importa tu claridad — un chatbot que malinterpreta desperdicia una oración; un agente que malinterpreta desperdicia una tarde de trabajo que tienes que deshacer. ## Errores de principiante que evitar - **Tratarlo como un buscador.** No hagas preguntas de una sola línea. Dale trabajo real con archivos reales. - **Omitir la restricción.** "Escríbeme un plan" te da un muro de texto. "Escríbeme un plan de una página con tres fases y un responsable por tarea" te da algo utilizable. - **No pedir una verificación.** Añade "hazme una pregunta si algo es ambiguo" y captarás malentendidos *antes* de que el agente empiece, no después. - **Dejar que los agentes de programación corran sin supervisión en código importante.** Revisa el diff. Los agentes son rápidos y mayormente acertados, pero "mayormente" está haciendo trabajo en esa frase — mantén a un humano en el bucle en todo lo que se publique. - **Saltar a la Puerta 2 demasiado pronto.** Si tu tarea son documentos y decisiones, no necesitas abrir una terminal. ## Cómo elegir tu primera herramienta - **Tu trabajo son documentos, investigación y redacción** → empieza con **Cowork** (o el producto de chat que ya pagas, usado en modo agente). - **Quieres construir o corregir software** → **Claude Code** u **OpenAI Codex**. - **Quieres trabajo recurrente sin intervención** (un resumen diario, un informe semanal) → avanza a **[tareas programadas](https://alejandrorioja.com/how-to-use-claude-scheduled-tasks/)** una vez que hayas perfeccionado el prompt manualmente. ## Agentes de IA para principiantes — Preguntas frecuentes 2026 ### ¿Necesito saber programar para usar agentes de IA? No. Los agentes sin código como Claude Cowork están diseñados para usuarios no técnicos — escribes instrucciones en lenguaje llano. Los agentes de programación como Codex y Claude Code sí implican una curva de aprendizaje, pero incluso estos los usan cada vez más personas que no se consideran programadores. Empieza sin código, pasa al código solo cuando una tarea lo requiera. ### ¿Cuál es la diferencia entre un chatbot y un agente de IA? Un chatbot responde preguntas; un agente completa tareas. El agente puede tomar una secuencia de acciones — leer, decidir, actuar, verificar, corregir — en un bucle, produciendo trabajo terminado en lugar de consejos. En la práctica el mismo producto a menudo hace ambas cosas; el "modo agente" es el comportamiento de agente. ### ¿Es Cowork mejor que Codex? Son para trabajos distintos, no mejores ni peores. Cowork es un espacio de trabajo sin código para documentos, investigación y operaciones. Codex (y Claude Code) son agentes de programación para construir y corregir software. Elige el que se ajuste a tu tarea. ### ¿Cómo obtengo buenos resultados de un agente de IA? Especificidad. Usa la estructura de cuatro partes: rol, contexto, tarea exacta y restricciones más una verificación. Dale materiales reales, indícale el formato que quieres y pídele que señale ambigüedades antes de empezar. Las instrucciones claras importan más que cualquier "prompt mágico". ### ¿Es seguro dejar que los agentes de IA funcionen solos? Para tareas de bajo riesgo y reversibles (redactar, resumir, organizar), sí — revisa el resultado y sigue adelante. Para cualquier cosa que cambie sistemas reales (publicar código, enviar mensajes, eliminar datos), mantén a un humano en el bucle y revisa antes de que actúe. La reversibilidad es la prueba correcta: cuanto más fácil sea deshacer algo, más autonomía puede tener con seguridad. **Lecturas relacionadas:** [Cómo aparecer citado en las respuestas de ChatGPT](https://alejandrorioja.com/how-to-get-cited-in-chatgpt-answers/) · [El manual de llms.txt](https://alejandrorioja.com/llms-txt-playbook/) · [Cómo usar las tareas programadas de Claude](https://alejandrorioja.com/how-to-use-claude-scheduled-tasks/) --- **¿Quieres ayuda para poner agentes a trabajar en tu negocio?** Construyo sistemas de agentes de IA para equipos operativos — [contáctame](https://alejandrorioja.com/contact/) o lee más sobre [cómo pienso en esto](https://alejandrorioja.com/seo-tips/). --- ## ¿Cómo gana dinero Anthropic? El modelo de negocio de Claude explicado Source: https://alejandrorioja.com/es/how-does-anthropic-make-money/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Business, AI TL;DR: Anthropic vende acceso a sus modelos de IA Claude a través de cinco canales principales: una API basada en uso (pagas por token), suscripciones para consumidores (Claude Pro y Max), planes empresariales (licencias Team y Enterprise), Claude Code para desarrolladores, y distribución a través de marketplaces cloud como Amazon Bedrock y Google Vertex. La API y el negocio empresarial — no la app para consumidores — son los mayores generadores de ingresos. ## Table of contents _Actualizado junio de 2026._ **TL;DR:** Anthropic vende acceso a sus modelos de IA Claude a través de cinco canales principales: una **API basada en uso** (pagas por token), **suscripciones para consumidores** (Claude Pro y Max), **planes empresariales** (licencias Team y Enterprise), **Claude Code** para desarrolladores, y **distribución a través de marketplaces cloud** como Amazon Bedrock y Google Vertex AI. La API y el negocio empresarial — no la app de chat para consumidores — son los mayores generadores de ingresos. **[Nota del operador]** Construyo sobre la API de Anthropic a diario, así que veo el negocio desde dentro del medidor. Lo que hay que entender: Anthropic es una empresa B2B con una puerta de entrada para consumidores. La app de chat que usas es marketing y una línea de ingresos; el dinero real está en los desarrolladores y las empresas que miden tokens a través de la API y pagan por licencias a escala. ## Qué es Anthropic Anthropic es una empresa de seguridad e investigación en IA, fundada en 2021, que desarrolla la familia de grandes modelos de lenguaje **Claude**. Vende esos modelos — y las herramientas a su alrededor — a consumidores, desarrolladores y empresas. Es una empresa privada, fuertemente respaldada por inversores estratégicos, entre ellos Amazon y Google, que además actúan como socios de cloud y distribución. El producto es inteligencia como servicio: no compras un software en caja, sino que alquilas acceso a un modelo que lee, escribe, razona y actúa en tu nombre. Cada canal a continuación es un envoltorio diferente alrededor de ese mismo activo central. ## ¿Cómo gana dinero Anthropic? ### 1. La API (basada en uso, el motor principal) La base del negocio. Desarrolladores y empresas llaman a Claude a través de una API y pagan **por token** — aproximadamente, por fragmento de texto de entrada y salida. El precio escala con la capacidad del modelo: - **Claude Opus** (el nivel más capaz) tiene el precio más alto — del orden de unos pocos dólares por millón de tokens de entrada y varias veces eso para la salida. - **Claude Sonnet** (el trabajador equilibrado) se ubica en el medio. - **Claude Haiku** (el nivel rápido y económico) es el de menor precio, para tareas simples de alto volumen. Los tokens de salida cuestan más que los de entrada, y funciones como contexto largo, caché de prompts y procesamiento por lotes tienen su propio precio. La dinámica clave: **los ingresos escalan directamente con el uso**. Una startup que integra Claude en su producto y crece hasta millones de usuarios genera más ingresos de API cada mes sin que Anthropic firme un nuevo contrato. Este modelo basado en uso es la razón por la que los laboratorios de IA hablan de ingresos en "tasa de ejecución" creciendo tan rápido — se compone con el propio crecimiento de los clientes. ### 2. Suscripciones para consumidores (Claude Pro y Max) Las apps de Claude (web, escritorio, móvil) son gratuitas para probar, con niveles de pago para quienes las usan intensamente: - **Claude Pro** — una tarifa mensual fija para límites de uso más altos, acceso a los mejores modelos y funciones como contexto más amplio y acceso prioritario. - **Claude Max** — un nivel de mayor precio para usuarios avanzados que superan los límites de Pro, con un margen de uso sustancialmente mayor. Esta es la parte más visible de Anthropic pero, para una empresa cuyos clientes son principalmente otras empresas, es una porción menor que las líneas de API y enterprise. Su valor estratégico es como embudo y superficie de marca tanto como fuente de ingresos. ### 3. Enterprise (licencias Team y Enterprise) Donde está gran parte del dinero duradero. Las empresas compran Claude para sus empleados en base a **licencias por usuario**, con planes diseñados para organizaciones: - **Team** — para empresas más pequeñas: uso agrupado, facturación centralizada, funciones de colaboración. - **Enterprise** — para grandes organizaciones: mayor seguridad y cumplimiento, inicio de sesión único, ventanas de contexto más amplias, controles de administrador y garantías de uso. Los contratos empresariales son recurrentes, se expanden con el tiempo (más licencias, más uso) y vienen con el tipo de costos de cambio que hacen que los ingresos sean recurrentes. Este es el movimiento SaaS clásico superpuesto sobre el modelo. ### 4. Claude Code (herramientas para desarrolladores) **Claude Code** es la herramienta de codificación agéntica de Anthropic — un agente que escribe, edita y ejecuta código en tu terminal, IDE o la nube. Se monetiza a través de los mismos rieles de suscripción y uso (está incluido en los niveles Pro/Max/Team/Enterprise y se mide contra tu plan). Estratégicamente hace dos cosas: es una línea de ingresos por derecho propio, y genera mucho uso de tokens de alto valor, ya que los agentes de codificación consumen una gran cantidad de capacidad del modelo. ### 5. Distribución en marketplaces cloud (AWS, Google y más) Anthropic no solo vende Claude directamente — también distribuye a través de las grandes plataformas cloud: - **Amazon Bedrock** y **Claude Platform on AWS** — los clientes que ya están en AWS acceden a Claude a través de la infraestructura y la facturación de Amazon. - **Google Vertex AI** y **Microsoft Foundry** — la misma idea en Google Cloud y la plataforma de Microsoft. Estos canales llegan a las empresas donde ya viven su gasto en cloud y sus procesos de adquisición, lo que reduce la fricción para adoptar Claude. Los ingresos se comparten con la plataforma, pero el alcance es enorme — y las profundas inversiones de Amazon y Google hacen que estas alianzas sean estratégicas, no solo comerciales. ### 6. La plataforma de agentes emergente Cada vez más, Anthropic vende no solo llamadas a modelos sin procesar sino **infraestructura de agentes** — servicios gestionados donde Anthropic ejecuta el bucle del agente y aloja el entorno en el que los agentes ejecutan tareas. A medida que más clientes pasan de "hacerle una pregunta al modelo" a "hacer que un agente haga el trabajo", esta capa de nivel superior se convierte en un nuevo lugar para capturar valor sobre el núcleo de pago por token. ## ¿Es rentable Anthropic? Anthropic es privada y no publica estados financieros auditados, pero el panorama público es el mismo que el de sus pares: **los ingresos crecen extremadamente rápido**, mientras la empresa gasta sumas enormes en cómputo (entrenamiento y servicio de modelos) y talento de investigación. Como otros laboratorios de IA de frontera, está en una fase de inversión intensa donde el crecimiento de la línea superior, no el beneficio actual, es el titular. La apuesta que hacen los inversores es que los ingresos basados en uso siguen componiendo a medida que la IA se entreteje en más software, eventualmente superando el costo del cómputo. ## Cómo se compara con OpenAI Las formas son similares — ambos monetizan a través de suscripciones para consumidores, una API basada en uso, licencias empresariales y herramientas para desarrolladores. Las diferencias están en el énfasis y las alianzas: Anthropic apuesta fuerte por la API de desarrolladores/enterprise y está respaldada por Amazon y Google; OpenAI tiene una mayor presencia en consumidores y una profunda alianza con Microsoft. Si quieres ver el otro lado de la comparación, visita [cómo gana dinero OpenAI](https://alejandrorioja.com/how-does-openai-make-money/). ## Modelo de ingresos de Anthropic — FAQ 2026 ### ¿Cuál es la principal fuente de ingresos de Anthropic? La **API basada en uso** y los **contratos empresariales** son los mayores impulsores. Desarrolladores y empresas pagan por token para llamar a Claude, y las organizaciones compran planes por usuario para sus equipos. La suscripción de Claude para consumidores es el producto más visible pero una parte menor de los ingresos que las líneas de negocio. ### ¿Cómo funciona el precio de la API de Claude? Pagas por token — entrada y salida medidas en fragmentos de texto. Los modelos más capaces (Opus) cuestan más por token que los equilibrados (Sonnet) o los rápidos (Haiku), y los tokens de salida cuestan más que los de entrada. Funciones como contexto largo, caché de prompts y procesamiento por lotes tienen su propio precio. Los ingresos escalan directamente con cuánto usan los clientes los modelos. ### ¿Cotiza Anthropic en bolsa? No. Anthropic es una empresa privada respaldada por inversores estratégicos y de capital de riesgo, entre ellos Amazon y Google. Sus acciones no están disponibles en bolsas de valores públicas y no hay una OPV confirmada. ### ¿Gana dinero Anthropic con la app gratuita de Claude? No directamente con los usuarios gratuitos — el nivel gratuito es un embudo. El dinero llega cuando los usuarios gratuitos actualizan a **Pro** o **Max**, cuando los equipos compran **licencias enterprise** y especialmente cuando los desarrolladores construyen sobre la **API**. El trabajo de la app gratuita es el alcance y la marca; los niveles de pago y la API son donde convierte. ### ¿Quiénes son los mayores clientes de Anthropic? Principalmente otras empresas: compañías de software que integran Claude en sus productos a través de la API, y empresas que despliegan Claude para sus empleados. La distribución en marketplaces cloud a través de AWS, Google y Microsoft también atrae a grandes clientes empresariales que compran a través de sus proveedores cloud existentes. **Lectura relacionada:** [Cómo gana dinero OpenAI](https://alejandrorioja.com/how-does-openai-make-money/) · [La guía para principiantes de agentes de IA](https://alejandrorioja.com/ai-agents-for-beginners-cowork-codex-guide/) · [Cómo aparecer citado en las respuestas de ChatGPT](https://alejandrorioja.com/how-to-get-cited-in-chatgpt-answers/) --- ## La versión corta Anthropic alquila acceso a sus modelos Claude. Los desarrolladores pagan por token a través de la API, los consumidores pagan mensualmente por Pro y Max, las empresas pagan por licencia para Team y Enterprise, los ingenieros usan Claude Code en esos mismos planes, y los gigantes cloud (AWS, Google, Microsoft) revenden Claude a empresas a través de sus marketplaces. Es un negocio B2B con una puerta de entrada para consumidores — y el medidor, no la app de chat, es donde está el dinero. --- ## ¿Cómo gana dinero OpenAI? El modelo de negocio de ChatGPT y la API Source: https://alejandrorioja.com/es/how-does-openai-make-money/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Business, AI TL;DR: OpenAI genera dinero de cuatro maneras principales: suscripciones a ChatGPT (Plus, Pro, Team, Enterprise, Edu), una API de pago por token donde los desarrolladores pagan por uso, grandes contratos empresariales y su alianza con Microsoft (distribución más un acuerdo de reparto de ingresos). A diferencia de la mayoría de los laboratorios de IA, el negocio de suscripciones de consumidores de OpenAI es su línea de ingresos más grande: la escala de ChatGPT es el motor. ## Table of contents _Actualizado en junio de 2026._ **TL;DR:** OpenAI genera dinero de cuatro maneras principales: **suscripciones a ChatGPT** (Plus, Pro, Team, Enterprise, Edu), una **API de pago por token** donde los desarrolladores pagan por uso, grandes **contratos empresariales** y su **alianza con Microsoft** (distribución más un acuerdo de reparto de ingresos). A diferencia de la mayoría de los laboratorios de IA, el negocio de suscripciones de consumidores de OpenAI es su línea de ingresos más grande: la enorme escala de ChatGPT es el motor. **[Lectura para operadores]** OpenAI es el inverso de una empresa de IA empresarial típica: primero construyó un fenómeno de consumo y luego un negocio para desarrolladores y empresas. Los cientos de millones de usuarios de ChatGPT son tanto la marca como la máquina de generar efectivo. Todos los demás en este espacio desearían tener ese nivel de alcance inicial. ## Qué es OpenAI OpenAI es la empresa de investigación en IA detrás de **ChatGPT** y la familia de modelos **GPT**, además de productos como el modelo de video Sora, la generación de imágenes y el agente de programación Codex. Fundada en 2015, alcanzó la fama generalizada cuando ChatGPT se lanzó a finales de 2022 y se convirtió en uno de los productos de consumo de más rápido crecimiento en la historia. Su estructura es inusual: comenzó como una organización sin fines de lucro y creó un brazo con fines de lucro limitado para recaudar el enorme capital que requiere el entrenamiento de modelos de frontera. No cotiza en bolsa y tiene una profunda alianza de varios años con **Microsoft** que proporciona cómputo, distribución y capital. El producto, como el de cualquier laboratorio de IA, es inteligencia como servicio, vendida en canales de consumo, desarrolladores y empresas. ## ¿Cómo gana dinero OpenAI? ### 1. Suscripciones a ChatGPT (la línea más grande) Esto es lo que diferencia a OpenAI de sus pares. ChatGPT es de uso gratuito, con niveles de pago que convierten una fracción de su enorme base de usuarios en ingresos recurrentes: - **ChatGPT Plus** — una tarifa mensual fija por acceso a los mejores modelos, límites más altos y funciones premium. El nivel para el mercado masivo. - **ChatGPT Pro** — un nivel de precio más alto para usuarios avanzados que desean el máximo uso y la configuración de modelos más capaz. - **ChatGPT Team** — planes por asiento para pequeñas empresas, con espacios de trabajo compartidos y herramientas de administración. - **ChatGPT Enterprise** — para grandes organizaciones: seguridad avanzada, cumplimiento normativo, SSO, mayor contexto y garantías de uso. - **ChatGPT Edu** — una versión adaptada para universidades y escuelas. Dado que ChatGPT alcanza cientos de millones de usuarios semanales, incluso una tasa de conversión de un dígito bajo a planes de pago genera un negocio de suscripciones enorme. Esta escala de consumidores es la ventaja definitoria de OpenAI, y se reporta que las suscripciones son su mayor fuente de ingresos. ### 2. La API (pago por uso, para desarrolladores) Los desarrolladores y las empresas integran los modelos de OpenAI en sus propios productos y pagan **por token** — por fragmento de texto (o imagen o audio) procesado. Los precios escalan con la capacidad del modelo: los modelos de razonamiento insignia cuestan más por token que los más pequeños, rápidos y económicos, y la salida tiene un precio más alto que la entrada. La API convierte a cada empresa que construye sobre GPT en un cliente medido cuya factura crece con su propio uso. Es la misma dinámica de crecimiento compuesto de la que depende cada laboratorio de IA: una startup que integra OpenAI y escala a millones de usuarios genera más ingresos de la API cada mes sin necesidad de un nuevo contrato. ### 3. Contratos empresariales Más allá de la API de autoservicio y los planes Team, OpenAI firma grandes acuerdos personalizados con empresas grandes: uso masivo, capacidad dedicada, soporte personalizado y compromisos de seguridad y cumplimiento normativo. Estos son recurrentes, se expanden con el tiempo y son pegajosos una vez que una empresa construye flujos de trabajo críticos sobre los modelos. Este movimiento empresarial coexiste con el negocio de consumidores y es una importante área de crecimiento. ### 4. La alianza con Microsoft Microsoft es el socio estratégico más importante de OpenAI. La relación funciona en varios ejes: - **Cómputo** — La nube Azure de Microsoft proporciona gran parte de la infraestructura en la que OpenAI entrena y sirve modelos. - **Distribución** — Los modelos de OpenAI se ofrecen a través de las plataformas de Microsoft (servicios de IA de Azure, productos Copilot), poniendo GPT frente a la gigantesca base de clientes empresariales de Microsoft. - **Reparto de ingresos** — Las dos empresas comparten ingresos bajo su acuerdo comercial, y Microsoft ha invertido fuertemente en OpenAI. Esta alianza es en parte capital, en parte comercialización: le da a OpenAI acceso a empresas a las que le llevaría años vender directamente. ### 5. Productos nuevos y adyacentes OpenAI sigue expandiendo la superficie que puede monetizar: - **Codex** — su herramienta de programación agéntica, monetizada a través de suscripciones y uso de la API (y un motor de consumo intensivo de tokens). - **Sora** — generación de video, ofrecida dentro de los niveles de pago y como producto independiente. - **Generación de imágenes y otras modalidades** — incluidas en las suscripciones y medidas a través de la API. - **Un ecosistema de desarrolladores y agentes** — GPTs personalizados, una plataforma de agentes y herramientas que permiten a las empresas construir sobre los modelos de OpenAI. Cada uno de estos es otro envoltorio alrededor del mismo activo central, orientado a capturar más de lo que los usuarios y desarrolladores están dispuestos a pagar. ## ¿Es rentable OpenAI? OpenAI es privada y no publica estados financieros auditados. El panorama ampliamente reportado: **los ingresos son muy grandes y crecen rápido**, pero también lo son los costos — entrenar modelos de frontera y servir a cientos de millones de usuarios consume cantidades asombrosas de cómputo. Como sus pares, OpenAI está en una fase de inversión intensa donde la prioridad es el crecimiento y la capacidad, no la ganancia a corto plazo. La apuesta es que la escala más la creciente adopción empresarial eventualmente supere los costos de cómputo. ## Cómo se compara con Anthropic Los bloques de construcción son similares — suscripciones de consumidores, una API de pago por uso, acuerdos empresariales, herramientas de programación — pero el énfasis difiere. La ventaja definitoria de OpenAI es la **escala de consumidores** (ChatGPT) y su alianza con **Microsoft**; Anthropic se inclina más hacia la **API para desarrolladores y empresas** y cuenta con el respaldo de Amazon y Google. Para el otro lado de la comparación, consulta [cómo gana dinero Anthropic](https://alejandrorioja.com/how-does-anthropic-make-money/). ## Modelo de ingresos de OpenAI — Preguntas frecuentes 2026 ### ¿Cuál es la mayor fuente de ingresos de OpenAI? **Las suscripciones a ChatGPT.** Dado que ChatGPT alcanza cientos de millones de usuarios, sus niveles de pago (Plus, Pro, Team, Enterprise, Edu) constituyen la línea de ingresos más grande de OpenAI — un perfil inusual para un laboratorio de IA, la mayoría de los cuales ganan más de APIs y empresas que de consumidores. ### ¿Cómo genera dinero la API de OpenAI? Los desarrolladores pagan **por token** para usar los modelos de OpenAI en sus propias aplicaciones — por fragmento de texto, imagen o audio procesado. Los modelos más capaces cuestan más por token, y la salida tiene un precio más alto que la entrada. Los ingresos crecen automáticamente a medida que crece el propio uso de los clientes. ### ¿Cotiza OpenAI en bolsa? ¿Puedo comprar acciones de OpenAI? No. OpenAI es una empresa privada y sus acciones no están disponibles en bolsas públicas. La mayoría de las personas no pueden invertir directamente. Microsoft tiene una participación importante a través de su alianza, pero eso no es lo mismo que OpenAI siendo pública. ### ¿Cómo le genera dinero a OpenAI la alianza con Microsoft? Microsoft proporciona cómputo Azure, distribuye los modelos de OpenAI a través de sus productos y nube a una enorme base empresarial, y las dos empresas comparten ingresos bajo su acuerdo comercial. Microsoft también ha invertido fuertemente en OpenAI. Es tanto una fuente de financiamiento como un canal de distribución. ### ¿Gana dinero OpenAI con los usuarios gratuitos de ChatGPT? No directamente — el nivel gratuito es un embudo. Los ingresos llegan cuando los usuarios gratuitos se actualizan a **Plus** o **Pro**, cuando las empresas compran asientos **Team** o **Enterprise**, y cuando los desarrolladores construyen sobre la **API**. El papel del producto gratuito es el alcance; los niveles de pago y la API lo convierten. **Lecturas relacionadas:** [Cómo gana dinero Anthropic](https://alejandrorioja.com/how-does-anthropic-make-money/) · [Cómo gana dinero SpaceX](https://alejandrorioja.com/how-does-spacex-make-money/) · [La guía para principiantes sobre agentes de IA](https://alejandrorioja.com/ai-agents-for-beginners-cowork-codex-guide/) --- ## La versión corta OpenAI convierte la enorme base de usuarios de ChatGPT en ingresos por suscripción (Plus, Pro, Team, Enterprise), cobra a los desarrolladores por token a través de su API, firma grandes acuerdos empresariales y se apoya en Microsoft para cómputo, distribución e ingresos compartidos. Su característica definitoria es la escala de consumidores: la mayoría de los laboratorios de IA monetizan primero a los desarrolladores; OpenAI construyó un fenómeno de consumidores y un negocio detrás de él. --- ## ¿Cómo gana dinero SpaceX? Lanzamientos, Starlink y la pregunta del IPO Source: https://alejandrorioja.com/es/how-does-spacex-make-money/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Business TL;DR: SpaceX gana dinero de tres formas: servicios de lanzamiento (vendiendo viajes a órbita en cohetes Falcon reutilizables), Starlink (internet satelital para consumidores, empresas, marítimo/aviación y gobierno) y contratos gubernamentales (tripulación y carga NASA, módulos de aterrizaje lunar, lanzamientos de seguridad nacional). Starlink es ahora el mayor motor de ingresos. SpaceX sigue siendo privada; un IPO de SpaceX en sí no es inminente, aunque una futura escisión de Starlink ha sido mencionada durante mucho tiempo. ## Table of contents _Actualizado junio de 2026._ **TL;DR:** SpaceX gana dinero de tres formas: **servicios de lanzamiento** (vendiendo viajes a órbita en cohetes Falcon reutilizables), **Starlink** (internet satelital para consumidores, empresas, marítimo/aviación y gobierno) y **contratos gubernamentales** (tripulación y carga NASA, módulos de aterrizaje lunar, lanzamientos de seguridad nacional). Starlink es ahora el mayor motor de ingresos. SpaceX sigue siendo privada; un IPO de SpaceX en sí no es inminente, aunque una futura escisión de Starlink ha sido mencionada durante mucho tiempo y repetidamente enfriada. **[Lectura del operador]** SpaceX es el ejemplo moderno más claro de una empresa que usó una ventaja en tecnología dura (cohetes reutilizables) para construir un negocio de economía software (internet satelital) sobre ella. El negocio de lanzamiento gana el derecho a existir; Starlink es donde está el dinero recurrente y escalable. Esa es toda la historia en una oración. ## Qué es SpaceX SpaceX (Space Exploration Technologies Corp.) diseña, construye y opera cohetes y naves espaciales, y opera la red de internet satelital Starlink. Fundada en 2002 con el objetivo a largo plazo de hacer a la humanidad multiplanetaria, se convirtió en el proveedor de lanzamientos dominante del mundo haciendo algo que nadie más hizo a escala: aterrizar y reutilizar la primera etapa de un cohete orbital, lo que derrumbó el costo de llegar al espacio. Esa ventaja de costo es el motor de todo lo demás. Un lanzamiento barato, frecuente y confiable es lo que hace económicamente posible una constelación de más de 7.000 satélites — y la constelación es lo que convierte un negocio de lanzamiento irregular y basado en proyectos en uno de ingresos recurrentes. ## ¿Cómo gana dinero SpaceX? ### 1. Servicios de lanzamiento El negocio original. SpaceX vende lanzamientos a tres tipos de clientes: - **Operadores de satélites comerciales** — empresas que necesitan una carga útil en órbita pagan por un lanzamiento dedicado o un lugar en una misión de **rideshare** (muchos satélites pequeños en un cohete, con precio por kilogramo). - **Gobierno y fuerzas armadas** — cargas útiles de seguridad nacional y misiones científicas, a menudo con una prima por confiabilidad y garantía. - **Otras empresas espaciales** — incluyendo, cada vez más, competidores que aún dependen de SpaceX porque es el viaje más barato y disponible. La economía unitaria funciona gracias a la **reutilización**: el mismo propulsor de primera etapa vuela muchas veces, por lo que el costo marginal de un lanzamiento está muy por debajo del precio. Falcon 9 es el caballo de batalla; Falcon Heavy maneja las cargas más pesadas. ### 2. Starlink (la máquina de ingresos recurrentes) Starlink es una constelación de miles de satélites en órbita baja terrestre que proporcionan internet de alta velocidad a lugares donde la banda ancha terrestre no puede llegar o no llega. Es ahora la parte de SpaceX que parece un negocio de suscripción real, con varias capas: - **Consumidor** — los hogares pagan por un plato (hardware) más una suscripción mensual. - **Empresa y movilidad** — planes de mayor precio para empresas, sector marítimo (barcos, yates) y **aviación** (acuerdos de Wi-Fi en vuelo con aerolíneas). - **Gobierno** — incluido **Starshield**, la variante orientada a la defensa vendida a clientes militares y gubernamentales. - **Directo a celular** — asociaciones con operadores de telefonía móvil para proporcionar conectividad satelital directamente a teléfonos ordinarios en zonas sin cobertura. Starlink combina ventas de hardware (el terminal) con ingresos mensuales recurrentes (la suscripción) entre millones de suscriptores — la forma clásica de maquinilla y hojas, a escala planetaria. Por eso la mayoría de las estimaciones ahora sitúan a Starlink por delante de los lanzamientos como la mayor línea de ingresos de SpaceX. ### 3. Contratos gubernamentales Un segmento distinto y muy grande que se superpone con los lanzamientos pero que merece separarse: - **NASA** — SpaceX transporta astronautas a la Estación Espacial Internacional bajo el programa **Commercial Crew** (Crew Dragon) y la reabastece con **Cargo Dragon**. También ganó un contrato para construir un sistema de aterrizaje lunar basado en **Starship** para las ambiciones lunares de la NASA. - **Seguridad nacional** — contratos de lanzamiento recurrentes para cargas útiles de defensa e inteligencia. Estos contratos son de alto valor, plurianuales y financian gran parte del desarrollo que beneficia al sector comercial. ### 4. Starship (el motor del futuro, aún no un centro de ganancias) Starship es el vehículo de elevación superpesada totalmente reutilizable de SpaceX — el reemplazo a largo plazo del Falcon y la clave tanto para las misiones lunares/a Marte como para la siguiente generación más grande de satélites Starlink. Hoy es un centro de costos financiado por los otros tres negocios. Si alcanza vuelos de rutina, reduce drásticamente el costo de lanzamiento nuevamente y permite un despliegue de Starlink mucho mayor — esa es la apuesta que realmente hacen los inversores. ## ¿Es SpaceX rentable? SpaceX es privada y no publica estados financieros auditados, por lo que cualquier cifra precisa es una estimación. El panorama ampliamente reportado: los lanzamientos son rentables por misión gracias a la reutilización, y Starlink cruzó hacia un flujo de caja positivo a medida que su base de suscriptores creció. La empresa reinvierte enormes sumas en el desarrollo de Starship, por lo que la "ganancia" depende en gran medida de cómo se trate ese I+D. La dirección de avance — ingresos recurrentes crecientes de Starlink sobre un negocio de lanzamiento dominante — es lo que sustenta la enorme valoración privada de la empresa. ## La pregunta del IPO Esta es la parte que todos preguntan, así que aquí está la versión honesta. **No se espera que SpaceX salga a bolsa pronto.** Elon Musk ha dicho repetidamente que prefiere mantener SpaceX privada mientras Starship y el programa a Marte son intensivos en capital y de horizonte largo — la presión trimestral del mercado público no encaja con una misión de décadas. En cambio, SpaceX proporciona liquidez a empleados e inversores tempranos a través de **ofertas de venta periódicas** (la empresa facilita la venta de acciones a un precio fijo), lo que permite a las personas cobrar sin una cotización pública. Esas ventas secundarias son las que producen las cifras de valoración de los titulares — SpaceX ha sido valorada en cientos de miles de millones de dólares en rondas recientes. **Un IPO de escisión de Starlink ha sido mencionado durante mucho tiempo** — el propio Musk sugirió hace años que Starlink podría eventualmente salir a bolsa una vez que sus ingresos fueran suaves y predecibles. Pero también ha enfriado repetidamente los plazos a corto plazo. A partir de 2026, Starlink no ha salido a bolsa y no hay fecha confirmada. Trate cualquier titular de "fecha de IPO de Starlink" con escepticismo a menos que provenga de la propia empresa. ## Conclusión El modelo de SpaceX es una pila: el lanzamiento reutilizable crea una ventaja de costo, esa ventaja hace que Starlink sea económicamente posible, Starlink convierte todo en un negocio de ingresos recurrentes, y los contratos gubernamentales financian el trabajo de frontera (Starship) que restablece la curva de costos nuevamente. Se mantiene privada por elección, usando ofertas de venta en lugar de un IPO — y el camino más probable a los mercados públicos es una futura cotización de Starlink, no SpaceX en su conjunto, cuando la empresa decida que es el momento adecuado. ## Modelo de ingresos de SpaceX — Preguntas frecuentes 2026 ### ¿Cuál es la mayor fuente de ingresos de SpaceX? La mayoría de las estimaciones ahora sitúan a **Starlink** por delante de los servicios de lanzamiento como la mayor línea de ingresos de SpaceX, impulsada por millones de suscripciones de consumidores, empresas, movilidad y gobierno, además de ventas de hardware de terminales. Los servicios de lanzamiento siguen siendo grandes y muy rentables por misión, pero el modelo recurrente de Starlink escala más rápido. ### ¿Cotiza SpaceX en bolsa? ¿Puedo comprar acciones de SpaceX? No. SpaceX es una empresa privada y sus acciones no están disponibles en bolsas de valores públicas. La mayoría de las personas no pueden invertir directamente; el acceso generalmente se limita a empleados e inversores acreditados que participan en rondas privadas u ofertas de venta. Tenga cuidado con las ofertas de "acciones de SpaceX" que sugieran lo contrario. ### ¿Saldrán a bolsa SpaceX o Starlink? No se espera que SpaceX salga a bolsa en el corto plazo — Musk ha dicho que quiere mantenerla privada durante la fase intensiva en capital de Starship/Marte. Un IPO de **Starlink** se ha discutido durante años como posibilidad una vez que sus ingresos sean predecibles, pero a partir de 2026 no hay fecha confirmada. Cualquier afirmación de "fecha de IPO" específica debe tratarse con escepticismo a menos que sea de la empresa. ### ¿Cómo gana dinero Starlink? Starlink cobra a los clientes por un plato satelital (hardware) más una suscripción mensual, en niveles de consumidor, empresarial, marítimo, aviación y gobierno — incluido el Starshield orientado a la defensa y las asociaciones de operadores de directo a celular. Es un modelo de maquinilla y hojas: hardware por adelantado, ingresos recurrentes después. ### ¿Cómo ayuda la reutilización a las ganancias de SpaceX? Aterrizar y volver a volar el mismo propulsor de cohete muchas veces reduce el costo marginal de cada lanzamiento muy por debajo del precio cobrado. Esa ventaja de costo es lo que hace de SpaceX el proveedor de lanzamiento más barato y lo que hace económicamente viable desplegar una constelación Starlink de varios miles de satélites. **Lectura relacionada:** [Cómo gana dinero Uber](https://alejandrorioja.com/how-does-uber-make-money/) · [Cómo gana dinero Shopify](https://alejandrorioja.com/how-shopify-makes-money/) · [Cómo gana dinero PayPal](https://alejandrorioja.com/how-does-paypal-make-money/) --- ## La versión corta SpaceX vende viajes a órbita de forma económica porque reutiliza sus cohetes, luego usa esa ventaja de costo para operar Starlink — un negocio de suscripción de internet satelital que ahora es su mayor fuente de ingresos — mientras los contratos gubernamentales financian el Starship de próxima generación. Se mantiene privada a propósito; un IPO de Starlink, no uno de SpaceX, es la ruta eventual más probable a los mercados públicos. --- ## Cómo usar las tareas programadas de Claude: automatiza trabajos recurrentes con cron Source: https://alejandrorioja.com/es/how-to-use-claude-scheduled-tasks/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Productivity, AI TL;DR: Las tareas programadas convierten un prompt de Claude en un trabajo recurrente: se ejecuta según un horario tipo cron, realiza el trabajo y entrega el resultado. Usa la app de Claude para prompts personales recurrentes (un resumen matutino, un resumen semanal) y las rutinas de Claude Code o los despliegues de Managed Agents para automatización de desarrolladores que corre en la nube. La ventaja está en automatizar trabajo que de otro modo harías a mano cada día o cada semana. ## Table of contents _Actualizado junio de 2026._ **TL;DR:** Las tareas programadas convierten un prompt de Claude en un trabajo recurrente: se ejecuta según un horario tipo cron, realiza el trabajo y entrega el resultado. Usa la **app de Claude** para prompts personales recurrentes (un resumen matutino, un resumen semanal) y las **rutinas de Claude Code** o los **despliegues de Managed Agents** para automatización de desarrolladores que corre en la nube. La ventaja está en automatizar el trabajo que de otro modo tendrías que rehacer a mano cada día o cada semana. **[Lectura para operadores]** Las automatizaciones de mayor palanca no son espectaculares — son los pequeños trabajos recurrentes que te consumen silenciosamente 20 minutos al día. Una tarea programada es la forma de delegárselos a Claude una sola vez y no volver a pensar en ellos. Yo ejecuto varias: un escaneo matutino de competidores, una revisión nocturna del estado de los PRs, un borrador semanal del pipeline de contenido. Ninguna me tomó más de diez minutos configurar. ## Qué es una tarea programada Una sesión normal de Claude es síncrona: tú escribes, responde, estás presente. Una **tarea programada** es asíncrona y recurrente: defines un prompt (o todo un flujo de trabajo de agente) más un horario, y Claude lo ejecuta por su cuenta — a las 7 AM cada día hábil, cada lunes, cada hora — y te entrega el resultado cuando termina. Por dentro es un cron job con un LLM en el centro. No estás escribiendo código para conectar APIs; estás describiendo el resultado en lenguaje natural y dejando que el agente determine los pasos cada vez que se dispara. ## Los tres lugares donde las configurarás No hay un solo botón — hay tres superficies, según quién seas. ### 1. La app de Claude (para todos) Las apps de Claude para consumidores soportan tareas recurrentes: guardas un prompt y una cadencia, Claude la ejecuta según el horario y te notifica con el resultado. Este es el camino sin código — ideal para un briefing diario, una búsqueda de investigación recurrente, un trabajo de "resume mis newsletters no leídas cada mañana". Si no eres desarrollador, aquí empiezas. ### 2. Rutinas de Claude Code (para quienes viven en la terminal) Si usas **Claude Code**, puedes programar un prompt o un slash command para que se ejecute con cadencia cron como un agente en la nube — una "rutina". Corre del lado del servidor en tu repositorio o espacio de trabajo, así que funciona incluso cuando tu laptop está cerrada. Usos típicos: supervisar pull requests abiertos, ejecutar una pasada de lint-y-corrección nocturna, generar un borrador de post cada mañana para revisión. Tú defines el horario y la tarea; Claude Code gestiona la ejecución y el registro de ejecuciones. ### 3. Despliegues de Managed Agents (para desarrolladores que construyen productos) Para equipos que construyen sobre la Claude API, los **despliegues programados** ejecutan un agente en un horario cron recurrente — cada disparo lanza una sesión que hace el trabajo de forma autónoma (un escaneo de cumplimiento nocturno, un informe semanal, un monitor por hora). Obtienes un registro de ejecución por disparo para auditar éxitos y fallos. Esta es la versión programática y de nivel producción de la misma idea. ## Cómo pensar el horario Los tres usan el mismo modelo mental — **qué tarea, con qué frecuencia, qué hacer con el resultado**: 1. **La tarea** — escríbela como escribirías cualquier buen prompt de agente: rol, contexto, acción exacta, restricciones y una verificación. Una tarea programada no puede hacerte una pregunta aclaratoria a mitad de la ejecución, así que debe estar *totalmente especificada de antemano*. Esta es la mayor diferencia respecto al uso interactivo. 2. **La cadencia** — diaria, semanal, por hora, solo días hábiles, una hora específica en tu zona horaria. Hazla coincidir con la velocidad a la que realmente cambia la cosa subyacente; un resumen "diario" de una fuente que se actualiza semanalmente son ejecuciones desperdiciadas. 3. **La entrega** — dónde aterriza el resultado (una notificación, un archivo, un mensaje, un borrador). Decide esto de antemano para que la salida sea útil en el momento en que llega. ## Patrones que realmente valen la pena - **El resumen matutino.** "Cada día hábil a las 7 AM, extrae lo último sobre [temas], resume las tres cosas que importan y envíame un briefing de 5 bullets." Reemplaza 20 minutos de búsqueda manual. - **El informe semanal.** "Cada lunes, compila [métricas] en un resumen de una página con lo que cambió y por qué." Convierte una tarea recurrente en una revisión. - **El trabajador nocturno.** Una rutina de código que ejecuta un trabajo largo y bien especificado mientras duermes — un refactor, una pasada de tests, una limpieza de datos — para que te despiertes con un resultado revisable. - **El monitor.** "Cada hora, verifica [cosa]; solo escríbeme si [condición] es verdadera." Las mejores automatizaciones son en su mayoría silenciosas y hablan solo cuando importa. ## Consejos de configuración basados en uso en producción - **Sobre-especifica el prompt.** No es posible hacer preguntas aclaratorias a mitad de la ejecución. Indica el formato, las fuentes, las restricciones y qué hacer en casos extremos. - **Empieza con una prueba manual.** Ejecuta el prompt exacto una vez a mano. Si produce lo que quieres de forma interactiva, prográmalo. Si no, corrige el prompt primero — programar un mal prompt solo produce resultados malos de forma confiable. - **Ajusta la cadencia a la tasa de cambio.** No ejecutes por hora algo que se actualiza semanalmente. - **Mantén las salidas como borradores cuando el riesgo es alto.** Para cualquier cosa que salga al mundo — un post publicado, un email enviado — haz que la tarea produzca un *borrador* para tu revisión, no una acción en vivo. Reserva el "solo hazlo" completamente autónomo para trabajo de bajo riesgo y reversible. - **Monitorea las primeras ejecuciones.** Los trabajos programados se van desfasando — una fuente cambia de formato, un feed se queda en silencio. Revisa los primeros registros de ejecución, luego confía en él. ## Tareas programadas de Claude — Preguntas frecuentes 2026 ### ¿Qué son las tareas programadas de Claude? Son trabajos recurrentes: defines un prompt o flujo de trabajo de agente más un horario tipo cron, y Claude lo ejecuta automáticamente — diariamente, semanalmente, por hora — entregando el resultado sin que estés frente al teclado. Existen en las apps de Claude para consumidores (para prompts personales recurrentes), en Claude Code (como rutinas en la nube) y en la Claude API (como despliegues de Managed Agents). ### ¿Necesito ser desarrollador para usarlas? No. La app de Claude soporta tareas recurrentes sin código — solo un prompt guardado y una cadencia. Las rutinas de Claude Code y los despliegues de Managed Agents son las versiones para desarrolladores orientadas a automatizar flujos de código y producto. ### ¿En qué se diferencia una tarea programada de un chat normal de Claude? Un chat normal es interactivo — estás ahí para responder preguntas de seguimiento. Una tarea programada es autónoma y recurrente, por lo que el prompt debe estar totalmente especificado de antemano; Claude no puede pausar para hacerte una pregunta a mitad de la ejecución. Se dispara según el horario, completa el trabajo y te entrega el resultado. ### ¿Cuál es una buena primera tarea programada? Un resumen matutino. "Cada día hábil a las 7 AM, resume lo último sobre [tus temas] en cinco bullets." Es de bajo riesgo, fácil de verificar e inmediatamente reemplaza una tarea manual recurrente — la plantilla perfecta para aprender el flujo de trabajo antes de automatizar algo más grande. ### ¿Puede una tarea programada tomar acciones reales, como enviar emails? Sí, pero sé deliberado. Para trabajo reversible y de bajo riesgo, déjala actuar. Para cualquier cosa orientada al exterior o difícil de deshacer, haz que la tarea produzca un borrador que apruebes en lugar de dispararse automáticamente — especialmente en ejecuciones sin supervisión. La reversibilidad es la prueba correcta para saber cuánta autonomía conceder. **Lectura relacionada:** [La guía para principiantes de los agentes de IA](https://alejandrorioja.com/ai-agents-for-beginners-cowork-codex-guide/) · [Cómo gana dinero Anthropic](https://alejandrorioja.com/how-does-anthropic-make-money/) · [Cómo aparecer citado en las respuestas de ChatGPT](https://alejandrorioja.com/how-to-get-cited-in-chatgpt-answers/) --- **¿Quieres un sistema de agentes programados que gestione tu trabajo recurrente?** Eso es exactamente lo que construyo — [contáctame](https://alejandrorioja.com/contact/). --- ## Matemática de Costes de Agentes de IA: Cuándo Haiku Gana a Sonnet (y Cuándo No) Source: https://alejandrorioja.com/es/ai-agent-cost-math-when-haiku-beats-sonnet/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: Elegir Claude Haiku en lugar de Sonnet puede reducir drásticamente el coste por llamada, pero solo cuando la tarea tolera una tasa de éxito menor. La métrica real no es el coste por llamada, sino el coste por resultado exitoso, incluyendo reintentos y limpieza humana. Enruto por tarea, no por defecto. ## Tabla de contenidos _Actualizado junio 2026._ **TL;DR:** Elegir Claude Haiku en lugar de Sonnet puede reducir el coste por llamada en un orden de magnitud, pero solo cuando la tarea tolera la menor tasa de éxito de Haiku. La métrica que importa es el **coste por resultado exitoso** — coste de la llamada más reintentos más limpieza humana — no el precio de etiqueta por token. Enruto por tarea, y una parte significativa de mis pasos de alto volumen corren en Haiku mientras que las decisiones de criterio se quedan en Sonnet. **Lectura del operador:** Manejo más de 100 agentes, y la inferencia es una partida real. Pero he visto equipos "ahorrar dinero" forzando todo al modelo más barato y luego pagar el coste en reintentos, escalaciones y clientes enfadados. La matemática de costes solo funciona cuando mides todo el embudo. El modelo más barato no es el que tiene el menor precio por token. Es el que tiene el menor coste total para hacer el trabajo bien. Esos son números distintos, y la brecha entre ellos es donde se tuercen la mayoría de las decisiones de coste de agentes. ## La economía de tokens, dicha sin rodeos Anthropic cobra por Claude por millón de tokens, facturando entrada y salida por separado, con la salida costando varias veces más que la entrada. Los números exactos cambian con el tiempo, así que consulta los precios actuales de Anthropic — pero es la **estructura** lo que impulsa la decisión: - **Haiku** es el nivel barato y rápido — con diferencia, el menor coste por token de la familia. - **Sonnet** se sitúa en el medio — notablemente más caro que Haiku, notablemente más barato que Opus. - **Opus** es el nivel premium para el razonamiento más difícil. De aquí se siguen dos cosas. Primera, los tokens de salida dominan el coste en tareas generativas, así que un modelo que es verboso cuesta más incluso al mismo precio por token. Segunda, la brecha de precio por token entre Haiku y Sonnet es lo bastante grande como para que en un paso de alto volumen se note absolutamente en la factura. Ese es el argumento *a favor* de Haiku. Ahora el argumento en contra. ## La métrica que realmente importa: coste por resultado exitoso El coste por llamada es un número de vanidad. Esta es la fórmula que de verdad uso: ``` coste_por_exito = (coste_llamada × intentos) + coste_limpieza ÷ tasa_de_exito ``` Donde `intentos` contabiliza los reintentos, y `coste_limpieza` es el coste esperado de que un humano arregle los fallos que se cuelan. Mira lo que esto le hace a la comparación. Supón que Haiku cuesta aproximadamente una décima parte de Sonnet por llamada. Si Haiku tiene éxito el 80% de las veces en una tarea y Sonnet el 98%, el ahorro por llamada parece enorme. Pero si cada fallo de Haiku dispara un reintento y 1 de cada 10 todavía necesita un humano que cuesta dinero real, el término de limpieza puede engullir el ahorro en tokens. En una tarea de bajo riesgo y alto volumen, la matemática favorece a Haiku abrumadoramente. En una tarea donde un fallo le envía un correo al cliente equivocado, puede invertirse por completo. No puedes tomar esta decisión sin medir la tasa de éxito por modelo — que es exactamente lo que te da un [arnés de evaluación](/the-eval-harness-i-use-to-ship-ai-agents/). Ejecuta el mismo conjunto de evaluación contra ambos modelos y lee las tasas de éxito desde la misma vara de medir. ## Dónde gana Haiku de forma decisiva Haiku es la elección correcta cuando la tarea es **estrecha, estructurada y verificable**: - **Clasificación y enrutamiento** — "¿este mensaje entrante es una reserva, una queja o spam?" Tres categorías, fácil de verificar, corre constantemente. Haiku todo el día. - **Extracción con un esquema** — sacar una fecha, un nombre, un importe de un texto, validado con Zod. Si la salida se parsea, casi con certeza está bien. - **Reescrituras cortas y formateo** — ajustes de tono, resumir una entrada que ya sabes buena, normalizar datos. - **Filtrado de primera pasada** — Haiku tría, y solo los casos ambiguos se escalan a Sonnet. Este es el patrón de mayor apalancamiento. El hilo común: el coste de un error de Haiku es bajo y el error es barato de detectar. Cuando la verificación es barata y el riesgo es bajo, gana el modelo barato. ## Dónde Sonnet se gana su precio Sonnet (y a veces Opus) vale la pena cuando la tarea es **abierta, de múltiples pasos o cara de equivocar**: - **Bucles de agente multiherramienta** donde una llamada de herramienta equivocada se propaga en cascada. Una mayor fiabilidad de razonamiento se compone a lo largo de los pasos — los patrones de orquestación que cubro en [orquestación multiagente](/multi-agent-orchestration-patterns-queues-state-handoffs/) dependen de que el modelo no pierda el hilo. - **Generación de cara al cliente** donde una salida mala cuesta confianza, no solo un reintento. - **Cualquier cosa donde la verificación sea difícil en sí misma.** Si no puedes saber de forma barata si la salida es correcta, no puedes permitirte un modelo que se equivoca con frecuencia. Un fallo aquí no cuesta un reintento — cuesta un reembolso, un cliente perdido, o mi tiempo. Frente a eso, la prima por token es un error de redondeo. ## La regla de enrutamiento que de verdad despliego No elijo un modelo por agente. Enruto por **tarea** dentro del agente, normalmente con un clasificador barato que decide qué modelo posterior maneja el trabajo: ```typescript function pickModel(task: Task): string { // Barato, verificable, de alto volumen → Haiku if (task.type === "classify" || task.type === "extract") { return "claude-haiku"; } // Abierto o de cara al cliente → Sonnet if (task.customerFacing || task.steps > 2) { return "claude-sonnet"; } return "claude-sonnet"; // por defecto, la opción segura } ``` Hay dos principios codificados aquí. **Por defecto, el modelo seguro**, no el barato — optimizas el coste *hacia abajo* desde una base que funciona, nunca la fiabilidad *hacia arriba* desde una rota. Y **escala, no apuestes**: deja que Haiku maneje el 80% fácil y entrega el 20% difícil a Sonnet. Ese híbrido casi siempre gana a correr todo en cualquiera de los dos modelos por separado. También está el caché de prompts para añadir encima: si tu prompt de sistema es grande y reutilizado, el caché reduce sustancialmente el coste de entrada independientemente del nivel, lo que a veces hace que Sonnet sea lo bastante barato como para que la cuestión de Haiku sea irrelevante. ## Un ejemplo trabajado de mi propio stack Toma un paso de triaje de mensajes entrantes de alto volumen. Corre miles de veces, la tarea es una clasificación de tres vías, y un fallo solo significa que el elemento aterriza en una cola de revisión — barato de detectar, bajo riesgo. Esa es una tarea de Haiku de manual, y sacarla de Sonnet redujo significativamente el coste de ese paso sin un impacto medible en el resultado que importaba. Ahora toma el paso que redacta la respuesta real al cliente. Menor volumen, abierto, y un mal borrador saliendo cuesta confianza. Ese se queda en Sonnet. Mismo agente, dos modelos, enrutados por riesgo. Vigilo el coste por ejecución y las métricas de éxito de ambos, como describo en [cómo mido si un agente de IA realmente funciona](/how-i-measure-whether-an-ai-agent-is-actually-working/) — y solo empujo un paso a un nivel inferior después de que la evaluación diga que el modelo más barato mantiene la tasa de éxito. ## FAQ ### ¿Es Claude Haiku siempre más barato que Sonnet en la práctica? Por token, sí — por un amplio margen. Por resultado exitoso, no siempre. Si la menor tasa de éxito de Haiku dispara reintentos y limpieza humana, el coste total puede superar al de Sonnet en tareas donde los errores son caros de detectar o arreglar. ### ¿Cómo decido entre Haiku y Sonnet para una tarea dada? Puntúa la tarea en dos ejes: cuán verificable es la salida y cuán costoso es un error. El trabajo barato de verificar, de bajo riesgo y alto volumen va a Haiku; el trabajo abierto, de cara al cliente o difícil de verificar va a Sonnet. Enruta por tarea, no por agente. ### ¿Cuál es la única métrica de coste que debo seguir? Coste por resultado exitoso — coste de la llamada por intentos más coste de limpieza esperado, dividido por la tasa de éxito. El precio por llamada por sí solo esconde reintentos y tiempo humano, que es donde los modelos baratos se vuelven caros sin que te des cuenta. ### ¿Puedo usar ambos modelos en un agente? Sí, y normalmente deberías. El patrón más fuerte es una primera pasada barata (Haiku clasifica o filtra) que escala solo los casos ambiguos a Sonnet. Ese híbrido normalmente gana a correr todo en un solo nivel. --- ## Cómo Depurar un Agente de IA en Producción (Guía de Campo) Source: https://alejandrorioja.com/es/how-to-debug-an-ai-agent-in-production/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: Depurar un agente de IA en producción consiste sobre todo en aislar qué capa falló — prompt, herramienta, modelo u orquestación. Registro cada paso con un ID de traza, reproduzco las entradas exactas y biseco. En mis agentes, ~70% de los 'bugs de IA' resultan ser bugs de fontanería, no del modelo. ## Tabla de contenidos _Actualizado junio 2026._ **TL;DR:** Depurar un agente de IA en producción consiste sobre todo en aislar qué capa falló — prompt, llamada a herramienta, salida del modelo u orquestación. Registro cada paso con un ID de traza, reproduzco las entradas exactas y biseco a partir de ahí. En mis agentes, aproximadamente el 70% de lo que parece un "bug de IA" resulta ser fontanería: un resultado de herramienta malformado, una entrada truncada, una excepción silenciosamente tragada. **Lectura del operador:** Ejecuto más de 100 agentes en producción — flujos de reserva para Pickleland, pipelines de contenido, clasificadores de bandeja de entrada. Se rompen como se rompe todo el software, más unas cuantas formas nuevas. Esta es la guía de campo que ojalá hubiera tenido: cómo encontrar la capa que falla sin mirar fijamente un muro de tokens. Cuando un agente se comporta mal en producción, el instinto es culpar al modelo. "Claude alucinó." A veces es cierto. Normalmente no. El modelo es una capa en una pila de cinco o seis, y el bug está mucho más a menudo en la capa que escribiste tú que en la que envió Anthropic. Esta publicación es la forma sistemática en que lo encuentro. ## Haz cada ejecución trazable antes de depurar nada No puedes depurar lo que no puedes ver. Lo de mayor apalancamiento que puedes hacer — antes de que aparezca cualquier bug específico — es adjuntar un ID de traza a cada ejecución del agente y registrar cada paso que da. Un "paso" es cualquier cosa que cruza un límite: el disparador entrante, cada llamada al modelo (con el array completo de mensajes), cada llamada a herramienta (con argumentos), cada resultado de herramienta y la salida final. Regístralos como JSON estructurado indexado por el ID de traza. ```typescript function logStep(traceId: string, step: string, payload: unknown) { console.log(JSON.stringify({ traceId, step, // "trigger" | "model_call" | "tool_call" | "tool_result" | "output" ts: Date.now(), payload, })); } ``` En Cloudflare Workers los envío a una cola y a una tabla; localmente van a stdout. La regla es absoluta: si un paso no está registrado, no ocurrió en lo que respecta a la depuración. Esto refleja la instrumentación que describo en [el stack de agentes que uso](/the-agent-stack-i-use-to-run-30-production-agents-no-python/) — el ID de traza es la columna vertebral de la que cuelga todo lo demás. ## Aísla la capa: prompt, herramienta, modelo u orquestación Una vez que tienes una traza, depurar se convierte en una bisección. Hay cuatro capas y el bug vive en exactamente una de ellas la mayor parte del tiempo. ### 1. La capa de entrada (el culpable más común) Extrae el array `messages` exacto que entró en la llamada al modelo que falló. No una reconstrucción — el payload literal del registro. Luego léelo como lo haría un extraño. La mitad de mis bugs de "el modelo ignoró las instrucciones" en realidad son: - Un resultado de herramienta que volvió como `"[object Object]"` porque algo se serializó mal a string. - Una entrada truncada a media frase porque reventó la ventana de contexto y un corte ingenuo la partió. - Una variable que se interpoló como `undefined` y envenenó silenciosamente el prompt. Si la entrada está mal, el modelo hizo su trabajo a la perfección sobre basura. Arregla la fontanería. ### 2. La capa de herramientas Si la entrada se ve limpia, comprueba si una herramienta devolvió un error que el agente trató como éxito. Un clásico: una API devuelve `200` con un cuerpo de `{ "error": "rate limited" }`, tu wrapper de herramienta no comprueba el cuerpo, y el agente actúa con confianza sobre un mensaje de error. Registra los resultados de herramienta en crudo y verifica su forma. ### 3. La capa del modelo Solo después de descartar 1 y 2 sospecho del modelo. Incluso entonces, "bug del modelo" normalmente significa "mi prompt es ambiguo." Toma la entrada exacta que falló, ponla en un script puntual contra el mismo modelo y temperatura, y mira si se reproduce. Si lo hace, el arreglo es trabajo de prompt o una [eval más ajustada](/the-eval-harness-i-use-to-ship-ai-agents/), no un cambio frenético de modelo. ### 4. La capa de orquestación Si un solo paso está bien de forma aislada pero la ejecución multipaso falla, el bug está en el traspaso — estado perdido entre pasos, una condición de carrera, un reintento que volvió a ejecutar una acción no idempotente. Estos son los más desagradables y cubro los patrones en [patrones de orquestación multiagente](/multi-agent-orchestration-patterns-queues-state-handoffs/). ## Reproduce el no-determinismo en lugar de pelearte con él Lo que hace que los agentes se sientan indepurables es el no-determinismo: la misma entrada produce salidas diferentes entre ejecuciones. Puedes domarlo. Primero, **fija lo que puedas.** Pon `temperature: 0` mientras depuras. No hará a Claude totalmente determinista, pero estrecha mucho la varianza para que puedas distinguir un bug real del ruido de muestreo. Segundo, **ejecútalo N veces.** Si un fallo se reproduce 1 de cada 20 ejecuciones, repite la entrada exacta 50 veces y captura cada salida. Ahora tienes una muestra, no una anécdota. Un bug que se dispara el 5% de las veces es un bug real — solo necesitas volumen para verlo. ```bash for i in $(seq 1 50); do node replay.mjs --trace=abc123 >> runs.jsonl done # luego cuenta los fallos grep -c '"status":"fail"' runs.jsonl ``` Tercero, **compara las ejecuciones que pasan y las que fallan.** Con la temperatura fijada y la misma entrada, una diferencia en la salida significa una diferencia en la entrada que aún no has detectado — una marca de tiempo en el prompt, un resultado de herramienta que varía, un documento recuperado que cambió. ## Construye un arnés de reproducción para dejar de depurar en producción Depurar reactivando el agente en vivo es lento y arriesgado — envía correos reales, reserva pistas reales. En su lugar, captura la traza y reprodúcela offline. El arnés de reproducción carga una traza registrada, reconstruye las entradas exactas de cualquier paso y vuelve a ejecutar solo ese paso contra el modelo. Como registraste el array completo `messages`, no necesitas el sistema aguas arriba en absoluto. Esto convierte un ida y vuelta de 10 minutos en producción en un bucle local de 2 segundos, y es la mayor aceleración de mi flujo de depuración. Un buen arnés de reproducción también te deja **mutar y reejecutar**: cambia una línea del prompt del sistema, reproduce las mismas 50 trazas que fallaron y mira cuántas pasan ahora. Ese es el puente de la depuración a la eval — una vez que tienes un corpus de trazas que fallan, tienes el inicio de un conjunto de regresión. ## Vigila las métricas que de verdad predicen las roturas Algunos fallos nunca lanzan una excepción. El agente se ejecuta, devuelve algo plausible y hace silenciosamente lo incorrecto. Para atrapar esos vigilas métricas de comportamiento, no solo tasas de error: - **Tasa de éxito de llamadas a herramienta** por herramienta. Una caída aquí a menudo precede a un fallo visible. - **Validez del esquema de salida** — qué % de salidas parsean contra la estructura esperada. Valido cada salida con Zod y alerto cuando la validez baja. - **Longitud del bucle** — número medio de pasos por ejecución. Un pico repentino normalmente significa que el agente está atascado reintentando. - **Coste por ejecución** — un bucle desbocado aparece como un pico de coste antes de aparecer como una queja. (Cuando el coste importa, vale la pena conocer las [matemáticas de Haiku vs Sonnet](/ai-agent-cost-math-when-haiku-beats-sonnet).) Sigo estas igual que sigo todo lo demás — mira [cómo mido si un agente de IA realmente funciona](/how-i-measure-whether-an-ai-agent-is-actually-working/). La métrica que atrapa un fallo silencioso vale por diez que atrapan los ruidosos. ## La lista de triaje de 5 minutos Cuando un agente se rompe y voy contra reloj, ejecuto esto en orden: 1. **Consigue el ID de traza** de la ejecución que falló. 2. **Lee la entrada exacta** del paso que falló. ¿Está bien formada? (Resuelve ~50% de los casos aquí.) 3. **Comprueba los resultados de herramienta** en esa traza buscando errores disfrazados de éxito. 4. **Reproduce el paso offline** a `temperature: 0`. ¿Se reproduce? 5. **Si se reproduce,** es un problema de prompt/modelo — arregla y reejecuta el corpus de trazas. **Si no,** es no-determinismo o un bug de estado/orquestación — repítelo 50× para caracterizarlo. El aislamiento disciplinado le gana al prompting ingenioso siempre. El modelo rara vez es el problema; el sistema a su alrededor normalmente sí lo es. ## FAQ ### ¿Cómo depuro un agente de IA que falla solo a veces? Captura la entrada exacta de una traza registrada y reprodúcela más de 50 veces a temperatura 0. Los fallos intermitentes son bugs reales con bajas tasas de disparo — el volumen convierte la anécdota en una muestra reproducible que puedes comparar y arreglar. ### ¿El bug suele estar en el modelo o en mi código? En mis agentes de producción, aproximadamente el 70% de los aparentes "bugs de IA" son fontanería: resultados de herramienta malformados, entradas truncadas, excepciones tragadas o estado perdido entre pasos. Descarta las capas de entrada y herramienta antes de sospechar del modelo. ### ¿Cuál es el mínimo de registro que necesito para depurar agentes? Un ID de traza en cada ejecución, más registros estructurados del disparador, cada llamada al modelo (array completo de mensajes), cada llamada a herramienta y su resultado en crudo, y la salida final. Si un paso no está registrado, no puedes depurarlo. ### ¿Cómo dejo de depurar contra la producción en vivo? Construye un arnés de reproducción que cargue una traza registrada y vuelva a ejecutar cualquier paso individual offline usando las entradas capturadas. Convierte un ida y vuelta lento y arriesgado en producción en un bucle local rápido y se convierte en la semilla de tu conjunto de regresión. --- ## Cómo Medir si la Búsqueda con IA Realmente te Está Enviando Tráfico Source: https://alejandrorioja.com/es/how-to-measure-ai-search-traffic/ Published: 2026-06-08 Tags: GEO, Analytics TL;DR: La mayoría del tráfico de búsqueda con IA aparece como un goteo de referencias de chatgpt.com, perplexity.ai y claude.ai — pero el efecto mayor es oscuro: la gente lee la respuesta de la IA y nunca hace clic. Yo mido ambos, usando los referentes para los clics y el aumento de búsquedas de marca para la influencia. ## Tabla de contenidos _Actualizado junio 2026._ **TL;DR:** La mayoría del tráfico de búsqueda con IA llega como un fino flujo de referencias de `chatgpt.com`, `perplexity.ai` y `claude.ai` — fácil de contar una vez que sabes dónde mirar. Pero el efecto mayor es **oscuro**: la gente lee la respuesta de la IA, absorbe tu marca y nunca hace clic. Yo rastreo los clics con segmentos de referente y la influencia con el aumento de búsquedas de marca, los cambios en el tráfico directo y la monitorización de citas. Contar solo los clics infravalora gravemente la búsqueda con IA. **Lectura del operador:** Dirijo un motor de contenido y vigilo sus analíticas a diario. La pregunta "¿me está enviando tráfico la búsqueda con IA?" tiene una respuesta frustrante: sí, pero la mayor parte del valor no aparece en tu informe de sesiones. Aquí explico cómo mido la parte que sí aparece e infiero la que no. Todos quieren un solo número: "¿cuánto tráfico me está enviando ChatGPT?". La respuesta honesta es que la búsqueda con IA produce dos efectos muy diferentes, y necesitas dos mediciones distintas. Si los confundes, o entrarás en pánico (los clics parecen ínfimos) o te engañarás a ti mismo (te perderás el impacto real). ## Efecto 1: Referencias directas — contables, y menores de lo que esperarías Cuando alguien hace clic en una cita dentro de ChatGPT, Perplexity o una respuesta de Claude, tu analítica registra un referente. Son sesiones reales y atribuibles. En GA4 o cualquier herramienta de analítica, construye un segmento que capture los motores de IA: ``` session source matches any of: chatgpt.com chat.openai.com perplexity.ai claude.ai gemini.google.com copilot.microsoft.com ``` Guárdalo como un canal de "Búsqueda con IA" y obsérvalo en el tiempo. Algunas salvedades que pillan a la gente: - **Los referentes se filtran.** Algunas superficies de IA eliminan o distorsionan el referente, así que una parte de los clics genuinos de IA acaban en "Directo". Tu recuento de referencias es un suelo, no la verdad. - **El volumen es bajo respecto a las impresiones de la respuesta.** Los motores de IA responden la pregunta en la página; solo la minoría curiosa hace clic. Un puñado de referencias diarias puede corresponder a muchísimas más personas que te vieron citado. Así que el segmento de referencias es necesario pero insuficiente. Te dice que la búsqueda con IA está enviando *algo* de tráfico. Infravalora gravemente la influencia. ## Efecto 2: Influencia oscura — la mitad mayor y más difícil de ver La verdadera acción es de cero clics. Alguien le hace una pregunta a ChatGPT, tu marca aparece en la respuesta como fuente recomendada, y nunca hace clic — simplemente te recuerda. Eso aparece más tarde como una **búsqueda de marca** o una **visita directa**, atribuida a nada. Es la misma dinámica que hacía frustrante medir los fragmentos destacados, amplificada. No puedes medir la influencia oscura directamente, pero puedes triangularla: 1. **Volumen de búsquedas de marca.** Rastrea las búsquedas de tu nombre/marca en Google Search Console a lo largo del tiempo. Si empiezas a ser citado por motores de IA y tus impresiones de marca suben sin una campaña que las acompañe, ese aumento es una huella de la influencia de la IA. 2. **Tendencia del tráfico directo.** Un aumento sostenido de sesiones "Directas" que no sigue ninguna campaña a menudo refleja referencias de IA despojadas de su referente más gente que te escribe directamente tras una mención de IA. 3. **Conversiones asistidas.** Mira si las sesiones de búsqueda con IA, aunque sean raras, aparecen como el *primer* contacto en recorridos que convierten. Un canal diminuto por último clic puede ser significativo por primer contacto. Ninguno de estos es un número limpio. Juntos te dicen si la mitad oscura se está moviendo. ## Rastrea citas, no solo clics Esta es la métrica que más me importa para la búsqueda con IA, y no está en tu analítica en absoluto: **¿me están citando, y para qué consultas?** Mantén una lista de las 20-40 consultas que importan para tu negocio y pásalas por ChatGPT, Perplexity y Claude de forma programada — semanalmente es suficiente. Registra, para cada consulta y motor: ¿estás citado, y en qué posición? Este es el equivalente GEO del seguimiento de posiciones, y es el indicador adelantado. Las citas se mueven *antes* que el tráfico posterior y el aumento de marca, así que aquí es donde ves si tu [trabajo de GEO para negocios locales](/geo-for-local-business-getting-a-brick-and-mortar-cited-by-ai-search/) está dando resultado. Construí un pequeño agente que ejecuta estas comprobaciones y registra los resultados — el tipo de cosa que es trivial una vez que tienes un stack de agentes. Si prefieres hacerlo a mano, una hoja de cálculo y una pasada semanal de 30 minutos funciona bien para empezar, o usa un verificador especializado como [mentioned.at](https://mentioned.at) si no quieres construir tú mismo el agente. La metodología refleja mi [prueba de citas de ChatGPT vs Google](/chatgpt-search-vs-google-50-term-test/), solo que ejecutada de forma continua en lugar de una sola vez. ## Construye el panel: cuatro números, semanalmente No me ahogo en métricas. Para la búsqueda con IA vigilo cuatro cosas y las reviso semanalmente: 1. **Sesiones de referencia de IA** — los clics contables del segmento de referente. Tendencia, no valor absoluto. 2. **Cobertura de citas** — % de mis consultas rastreadas donde estoy citado en los tres motores. El indicador adelantado. 3. **Impresiones de búsqueda de marca** — desde Search Console, como proxy de la influencia oscura. 4. **Conversiones procedentes de IA** — aunque sean pocas, si las sesiones de IA llegan a iniciar un recorrido que convierte. Si la cobertura de citas sube mientras las sesiones de referencia se mantienen planas, eso *no* es un fracaso — normalmente significa que la mitad oscura está creciendo y el número de búsqueda de marca debería seguirla. Si la cobertura de citas cae, esa es una advertencia temprana para actuar antes de que se mueva cualquier número de tráfico. Esta es la misma disciplina de "medir el indicador adelantado" que aplico a los agentes en [cómo mido si un agente de IA realmente funciona](/how-i-measure-whether-an-ai-agent-is-actually-working/). ## Qué hacer con los números La medición solo es útil si cambia lo que haces. El manual de jugadas: - **¿Cobertura de citas baja para una consulta que te importa?** Eso es un problema de contenido + [schema](/schema-markup-for-ai-engines-the-types-that-punch-above-their-weight/). La página o no existe, o no está estructurada para la extracción, o no es lo bastante autoritativa para entrar en la respuesta. - **¿Citado pero sin tráfico de referencia?** Esperado y correcto — la búsqueda con IA está haciendo trabajo de marca, no de clics. No lo "arregles" persiguiendo clics; apuéstate por ser la fuente citada. - **¿Referencias de un motor pero no de otros?** Los motores divergen mucho en fuentes (medí ~40% de solapamiento entre ChatGPT y Google). Ser citado por uno no te consigue los otros — trabaja la cobertura de cada motor por separado. ## Una nota sobre la honestidad en la atribución Resiste la tentación de reclamar una precisión que no tienes. La medición de la búsqueda con IA en 2026 es triangulación, no atribución. Cualquiera que te venda un número limpio de "ChatGPT te trajo X dólares" está exagerando lo que se puede saber, porque los referentes se filtran y el efecto mayor es de cero clics por diseño. La postura correcta: cuenta lo que puedes contar, vigila los proxies para lo que no puedes, y toma decisiones según la tendencia. La tendencia es fiable incluso cuando el número absoluto no lo es. ## Preguntas frecuentes ### ¿Cómo veo el tráfico de ChatGPT o Perplexity en GA4? Construye un canal/segmento que coincida con los dominios de los motores de IA — chatgpt.com, chat.openai.com, perplexity.ai, claude.ai, gemini.google.com, copilot.microsoft.com — como fuente de sesión. Eso captura las referencias de clic, aunque algunas se despojan a "Directo", así que trata el recuento como un suelo. ### ¿Por qué es tan bajo mi tráfico de referencia de búsqueda con IA? Porque la búsqueda con IA es mayormente de cero clics — el motor responde en la página y solo una minoría hace clic. Los recuentos bajos de referencia a menudo coinciden con impresiones de citas mucho mayores. Mide las citas y el aumento de búsquedas de marca para ver la parte que las referencias se pierden. ### ¿Cuál es el mejor indicador adelantado para la búsqueda con IA? La cobertura de citas: el porcentaje de tus consultas críticas para el negocio rastreadas donde estás citado en ChatGPT, Perplexity y Claude. Se mueve antes que el tráfico y el aumento de marca, así que te dice pronto si tu trabajo de GEO está dando resultado. ### ¿Puedo obtener atribución exacta de ingresos de la búsqueda con IA? No, no de forma fiable en 2026. Los referentes se filtran a Directo y la mayor parte del impacto es de cero clics por diseño. Trata la medición de la búsqueda con IA como triangulación — cuenta los clics, vigila los proxies de búsqueda de marca y tráfico directo, y decide según la tendencia, no según una cifra en dólares de falsa precisión. --- ## Patrones de Orquestación Multiagente: Colas, Estado y Traspasos Source: https://alejandrorioja.com/es/multi-agent-orchestration-patterns-queues-state-handoffs/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: Los sistemas multiagente fiables no dependen de prompts ingeniosos — dependen de la aburrida disciplina de los sistemas distribuidos: colas durables entre agentes, estado mantenido fuera del modelo y traspasos idempotentes que sobreviven a los reintentos. El modelo es el trabajador; la cola es la columna vertebral. ## Tabla de contenidos _Actualizado junio 2026._ **TL;DR:** Los sistemas multiagente fiables no se ganan con prompts ingeniosos — se ganan con la aburrida disciplina de los sistemas distribuidos. Pon una **cola** durable entre agentes, mantén el **estado fuera del modelo** y haz que cada **traspaso sea idempotente** para que un reintento no actúe dos veces. El modelo es el trabajador; la cola es la columna vertebral. Acierta en esos tres y la orquestación deja de dar miedo. **Lectura del operador:** La mayoría de mis más de 100 agentes son de un solo paso. Los que no lo son — los pipelines que clasifican, luego enriquecen, luego actúan — solo se volvieron fiables cuando dejé de pensar en "cadena de prompts" y empecé a pensar en "cola de trabajos con trabajadores LLM". Esto es arquitectura, no ingeniería de prompts. "Multiagente" suena a que los agentes se hablan entre sí. En la práctica, la versión fiable es lo contrario: los agentes no se comunican directamente en absoluto. Dejan mensajes en una cola y recogen trabajo de una cola, y la orquestación vive en la fontanería entre ellos. Estos son los patrones que aguantan en producción. ## Patrón 1: Pon una cola durable entre cada agente El primer instinto es llamar al agente B directamente desde dentro del agente A. No lo hagas. Las llamadas directas acoplan a los dos: si B es lento, A se bloquea; si B falla, el trabajo de A se pierde; si necesitas escalar B, no puedes sin tocar A. En su lugar, A termina su trabajo y **encola un mensaje** para B. B es un trabajador separado que vacía la cola a su propio ritmo. ```typescript // El agente A termina y traspasa vía la cola — sin llamada directa a B await env.ENRICH_QUEUE.send({ traceId, type: "enrich", payload: classifierResult, }); // El trabajo de A está hecho. B lo recogerá de forma independiente. ``` En Cloudflare uso Workers Queues exactamente para esto — las mismas primitivas detrás de [el stack de agentes que uso](/the-agent-stack-i-use-to-run-30-production-agents-no-python/). La cola te da cuatro cosas gratis: **buffering** (B puede estar caído sin perder trabajo), **reintentos** (los mensajes fallidos se reentregan), **contrapresión** (un pico se encola en lugar de provocar una caída) y **desacoplamiento** (escala o redespliega B sin tocar A). Cada una de esas es algo que de otro modo tendrías que construir a mano y equivocarte. ## Patrón 2: Mantén el estado fuera del modelo, siempre El bug multiagente más común es asumir que el modelo recuerda algo entre pasos. No lo hace. Cada llamada al modelo es sin estado; la única memoria es lo que pones en el prompt. Así que la fuente de verdad para "dónde está este trabajo en el pipeline" debe vivir en una base de datos, no en una conversación. Mantengo un único registro de trabajo que cada agente lee y actualiza: ```typescript interface JobState { traceId: string; stage: "classified" | "enriched" | "acted" | "done" | "failed"; data: Record; attempts: number; updatedAt: number; } ``` Cada agente hace el mismo bucle: **leer** el estado del trabajo, hacer su trabajo, **escribir** el nuevo estado, encolar la siguiente etapa. El modelo nunca retiene el estado — recibe la porción relevante como entrada y devuelve un resultado. Esto es lo que hace al sistema reanudable: si un trabajador muere a mitad de un trabajo, el registro de estado todavía dice exactamente dónde estaban las cosas, y el mensaje de cola reentregado retoma desde ahí. También hace que la depuración sea manejable, porque la tabla de estado es un registro consultable del recorrido de cada trabajo — la misma mentalidad de instrumentación de [cómo mido si un agente está funcionando](/how-i-measure-whether-an-ai-agent-is-actually-working/). ## Patrón 3: Haz que cada traspaso sea idempotente Las colas garantizan la entrega *al menos una vez*, no exactamente una vez. Eso significa que un mensaje puede entregarse dos veces — cortes de red, reintentos, redespliegues. Si la acción de tu agente no es idempotente, una doble entrega actúa dos veces: dos correos de confirmación, dos reservas, dos cargos. Esta es la clase de bug de orquestación más desagradable, y es la que los equipos descubren en producción. La solución es hacer que las acciones sean idempotentes con una clave: ```typescript async function handleEnrich(msg: QueueMessage, env: Env) { const job = await getJob(env, msg.traceId); if (job.stage !== "classified") { // Ya procesado más allá de esta etapa — es una entrega duplicada. Omitir. return; } const result = await enrich(job.data); await advanceJob(env, msg.traceId, "enriched", result); await env.ACT_QUEUE.send({ traceId: msg.traceId, type: "act" }); } ``` La verificación de etapa hace que la operación sea segura de ejecutar dos veces: la segunda entrega ve que el trabajo ya ha avanzado y no hace nada. Para efectos secundarios externos (enviar un correo, cobrar una tarjeta), pasa una clave de idempotencia a la API descendente para que *ella* también deduplique. Asume que cada mensaje se entregará dos veces y diseña de modo que eso sea inofensivo — porque eventualmente lo será. ## Patrón 4: Orquestador vs coreografía — elige deliberadamente Hay dos maneras de cablear el flujo, y la elección correcta depende de la complejidad. **Coreografía** (lo que uso por defecto): cada agente conoce solo el siguiente paso y lo encola. El flujo emerge de la cadena. Simple, descentralizada, fácil de extender — añade una etapa insertando una cola. La desventaja es que ningún lugar único describe el flujo completo, así que un pipeline complejo puede volverse difícil de razonar. **Orquestación** (un coordinador central): un orquestador es dueño del flujo, llama a cada agente por turno y decide qué sigue en función de los resultados. Todo el flujo vive en un lugar legible y la lógica de ramificación es explícita. El coste es un componente central que debe ser él mismo durable — si el propio estado del orquestador no está externalizado (Patrón 2), se convierte en el punto único de fallo. Mi regla: **coreografía hasta que la ramificación se vuelva compleja, luego un orquestador durable.** Un pipeline lineal de tres etapas es coreografía. Un flujo con enrutamiento condicional, fan-out paralelo y uniones quiere un orquestador cuyo estado viva en la base de datos para que pueda reanudarse tras una caída. ## Patrón 5: Fan-out, fan-in sin perder piezas Cuando un trabajo genera N subtareas paralelas (enriquecer 50 registros, resumir 20 documentos) y necesitas esperar a todas antes de continuar, necesitas una **unión** (join). El truco es un contador en el estado del trabajo: 1. El padre encola N mensajes hijos y escribe `expected: N, completed: 0` en el registro del trabajo. 2. Cada hijo hace su trabajo e **incrementa atómicamente** `completed`. 3. El hijo que sube `completed` hasta igualar `expected` encola la siguiente etapa. El incremento atómico es crítico — sin él, dos hijos que terminan simultáneamente pueden ambos creer que no son el último, y la unión nunca se dispara. Usa un contador que el datastore pueda incrementar atómicamente, o una transacción. Este patrón te permite paralelizar el medio costoso de un pipeline (a menudo trabajo barato para Haiku — ver las [matemáticas de coste de Haiku vs Sonnet](/ai-agent-cost-math-when-haiku-beats-sonnet)) manteniendo una unión limpia al final. ## Lo que me saltaría No necesitas un framework de agentes pesado para hacer nada de esto. Las colas, una tabla de estado y las claves de idempotencia son primitivas que toda plataforma ya tiene. He visto a equipos recurrir a frameworks multiagente elaborados para obtener funciones que una cola te da gratis, y heredar una caja negra más difícil de depurar que la fontanería que reemplazó. Empieza con las aburridas primitivas. Recurre a un framework solo cuando hayas sentido un dolor específico que él resuelva. El resumen: los agentes son trabajadores sin estado, las colas son la columna vertebral durable, el estado vive en una base de datos y cada traspaso es seguro de ejecutar dos veces. Ese es todo el juego. ## Preguntas frecuentes ### ¿Los agentes deben llamarse directamente entre sí o pasar por una cola? Por una cola. Las llamadas directas acoplan a los agentes — el fallo o la lentitud de uno se propaga al otro, y no puedes escalar ni redesplegar de forma independiente. Una cola durable te da buffering, reintentos, contrapresión y desacoplamiento gratis. ### ¿Dónde debe vivir el estado multiagente? Fuera del modelo, en una base de datos, como un registro de trabajo que cada agente lee y actualiza. Las llamadas al modelo son sin estado, así que la fuente de verdad para el progreso del pipeline debe ser externa — eso es lo que hace al sistema reanudable tras una caída. ### ¿Cómo evito que un agente actúe dos veces sobre el mismo trabajo? Haz que los traspasos sean idempotentes. Verifica la etapa del trabajo antes de actuar y no hagas nada si ya ha avanzado, y pasa claves de idempotencia a las APIs externas. Las colas entregan al menos una vez, así que asume que cada mensaje puede llegar dos veces y diseña de modo que los duplicados sean inofensivos. ### ¿Necesito un framework multiagente? Normalmente no. Las colas durables, una tabla de estado y las claves de idempotencia cubren la mayoría de las necesidades de producción con primitivas que tu plataforma ya proporciona. Adopta un framework solo cuando te encuentres con un problema concreto que él resuelva de forma única, no por defecto. --- ## El Harness de Evals que Uso para Lanzar Agentes de IA Sin Miedo Source: https://alejandrorioja.com/es/the-eval-harness-i-use-to-ship-ai-agents/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: Lanzar agentes sin miedo viene de una sola cosa: un harness de evals. Un conjunto fijo de casos de prueba calificados, puntuados automáticamente (aserciones más un juez LLM), ejecutado antes de cada cambio de prompt o modelo. Si la puntuación se mantiene, lanzas. El conjunto de pruebas se construye a partir de fallos reales de producción. ## Tabla de contenidos _Actualizado junio 2026._ **TL;DR:** La razón por la que puedo cambiar un prompt o intercambiar un modelo en un agente en vivo sin contener la respiración es una sola cosa: un **harness de evals**. Un conjunto fijo de casos de prueba calificados, puntuados automáticamente — aserciones duras donde puedo escribirlas, un juez LLM donde no puedo — ejecutado antes de cada cambio. Si la puntuación se mantiene, lanzo. Si baja, no lo hago. El conjunto de pruebas no es sintético; se construye a partir de fallos reales de producción, así que cada bug se convierte en una prueba de regresión permanente. **Lectura del operador:** A lo largo de más de 100 agentes, la diferencia entre los que toco con confianza y los que me dan miedo es si tienen evals. Sin un harness de evals, cada ajuste de prompt es una apuesta. Un harness de evals convierte "creo que esto es mejor" en "esto es medible: 4 puntos mejor y no rompió nada." Ese es todo el desbloqueo. No lanzarías código sin pruebas. La gente lanza agentes sin evals constantemente, y luego se preguntan por qué un "diminuto ajuste de prompt" rompió producción. Un harness de evals es la suite de pruebas para software no determinista. Aquí está el que realmente ejecuto. ## Empieza con un conjunto de pruebas construido a partir de fallos reales El harness es tan bueno como sus casos de prueba, y los mejores casos de prueba vienen de producción, no de tu imaginación. Cada vez que un agente falla en el mundo real, capturo la entrada exacta (registro cada ejecución con un ID de traza — ver [cómo depurar un agente en producción](/how-to-debug-an-ai-agent-in-production)) y la convierto en un caso de eval: ```typescript interface EvalCase { id: string; input: AgentInput; // la entrada exacta de producción expected?: string; // verdad de referencia, cuando existe assertions: Assertion[]; // comprobaciones duras que deben pasar rubric?: string; // para el juez LLM, cuando la salida es abierta } ``` Dos prácticas importan aquí. **Extrae de producción**, para que tus evals prueben lo que realmente se rompe, no lo que adivinaste que podría. Y **cubre el abanico** — el camino feliz, los casos límite, las entradas adversariales y las entradas vacías/malformadas que causan fallos silenciosos. Un conjunto de pruebas de 30 a 50 casos bien elegidos atrapa mucho más que 500 perezosos. Prefiero tener 40 casos que cada uno represente un modo de fallo real que mil que prueben todos el mismo camino fácil. ## Puntúa con aserciones primero, un juez LLM después No toda salida necesita un modelo que la califique. Recurro al evaluador más barato que funcione. **Aserciones duras** para todo lo estructurado. ¿La salida se parsea como JSON válido? ¿Contiene el campo requerido? ¿La fecha extraída está dentro del rango? ¿Llamó a la herramienta correcta con los argumentos correctos? Estas son deterministas, gratuitas e inequívocas — escribe tantas como puedas. ```typescript const assertions: Assertion[] = [ (out) => isValidJSON(out), (out) => parse(out).category in ALLOWED_CATEGORIES, (out) => parse(out).confidence >= 0 && parse(out).confidence <= 1, ]; ``` **Un juez LLM** para el resto abierto — tono, utilidad, "¿esto realmente respondió la pregunta?". Aquí le das a un modelo la entrada, la salida y una rúbrica, y le pides que puntúe. Dos reglas mantienen honesto al juez: haz la rúbrica **específica** (una escala de 1 a 5 con anclas descritas supera a "califica la calidad"), y usa un **modelo fuerte como juez** — juzgar es una tarea de razonamiento, así que este es un lugar donde con gusto pago por Sonnet incluso cuando el agente en sí corre con Haiku según las [matemáticas de costos](/ai-agent-cost-math-when-haiku-beats-sonnet). Una rúbrica vaga o un juez débil te da ruido que parece señal. ## Ejecuta el harness antes de cada cambio El harness existe para responder una pregunta: *¿este cambio hizo al agente mejor o peor?* Así que lo ejecuto antes de cada edición de prompt, intercambio de modelo o cambio de herramienta. ```bash # línea base en main npm run eval -- --suite=booking-agent > baseline.json # haz el cambio, luego re-ejecuta npm run eval -- --suite=booking-agent > candidate.json # compara npm run eval:diff baseline.json candidate.json ``` El diff muestra la puntuación agregada, el pasa/falla por caso y — crucialmente — **qué casos específicos regresaron.** Un agregado que sube mientras tres casos se rompen silenciosamente no es una mejora; es un trueque que quiero ver y aprobar, no uno que se cuela. Vigilar el diff por caso es como evitas "arreglé una cosa, rompí otras dos," el modo de fallo que hace que la gente le tenga miedo a sus propios prompts. ## Establece una compuerta de regresión y deja que bloquee Una vez que confías en el harness, conéctalo al camino hacia producción como una compuerta. Mi regla es contundente: **un cambio que baja la puntuación por debajo del umbral de la línea base no se lanza.** No "lo revisaré después" — está bloqueado, igual que una prueba de CI que falla. ```typescript const PASS_THRESHOLD = 0.90; // el 90% de los casos debe pasar if (candidate.passRate < PASS_THRESHOLD || candidate.passRate < baseline.passRate) { throw new Error(`Eval regression: ${candidate.passRate} < ${baseline.passRate}`); } ``` Esto es lo que convierte los evals de un lujo opcional en lo que te permite moverte rápido. La compuerta es lo que hace que "lanzar sin miedo" sea literalmente cierto: el peor caso para un mal cambio es una ejecución de eval en rojo, no un incidente en producción. Y como el conjunto de pruebas crece cada vez que algo se rompe, la compuerta se vuelve más estricta y más protectora con el tiempo por sí sola. ## Ten en cuenta el no-determinismo en la puntuación Una sutileza que hace tropezar a la gente: la misma entrada puede puntuar diferente entre ejecuciones porque el modelo muestrea de forma distinta. Si ejecutas cada caso una sola vez, verás regresiones fantasma — un caso que "se rompió" que en realidad es solo ruido de muestreo. Dos mitigaciones. Ejecuta los evals a **`temperature: 0`** para reducir la varianza (no la eliminará del todo). Y para los casos que has visto parpadear, **ejecútalos N veces y toma la tasa de aprobación**, no un único pasa/falla. Un caso que pasa 9 de 10 está en mejor forma que uno que pasa 5 de 10 aunque ambos puedan mostrar una sola ejecución en verde. Este es el mismo principio de volumen-sobre-anécdota que uso cuando [depuro fallos intermitentes](/how-to-debug-an-ai-agent-in-production) — una ejecución es una opinión, cincuenta ejecuciones son datos. ## Cierra el ciclo con monitoreo de producción El harness de evals prueba contra casos conocidos. Producción lanza casos novedosos. Así que el ciclo es: monitorea el comportamiento en vivo, atrapa un nuevo modo de fallo, conviértelo en un caso de eval, arréglalo, y ahora está permanentemente protegido. El lado del monitoreo — rastrear la tasa de éxito, la validez de la salida y el costo por ejecución en tráfico en vivo — es lo que cubro en [cómo mido si un agente de IA realmente funciona](/how-i-measure-whether-an-ai-agent-is-actually-working/). Los evals y el monitoreo son dos mitades del mismo sistema: el monitoreo encuentra los bugs, los evals se aseguran de que sigan muertos. Ese ciclo de retroalimentación es el verdadero producto. Cualquier conjunto de evals individual se vuelve obsoleto; un *proceso* que convierte cada fallo de producción en una prueba permanente se vuelve más fuerte cada semana. Así es como un agente pasa de "da miedo tocarlo" a algo que refactorizaré un viernes por la tarde sin pestañear. ## Preguntas frecuentes ### ¿Qué entra en un conjunto de evals para un agente de IA? Entradas reales de producción convertidas en casos calificados — camino feliz, casos límite, entradas adversariales y malformadas — cada uno con aserciones duras y, para salidas abiertas, una rúbrica de juez LLM. De 30 a 50 casos extraídos de fallos reales superan a cientos de casos sintéticos que prueban todos el camino fácil. ### ¿Debería usar un LLM para calificar las salidas del agente? Usa aserciones duras dondequiera que la salida sea estructurada (JSON válido, campo correcto, llamada a la herramienta correcta) — son gratuitas y deterministas. Reserva un juez LLM para cualidades abiertas como el tono y la utilidad, con una rúbrica específica y un modelo juez fuerte para obtener señal, no ruido. ### ¿Cómo evito que un cambio de prompt rompa producción silenciosamente? Ejecuta el harness de evals antes de cada cambio y compara con una línea base, vigilando las regresiones por caso, no solo la puntuación agregada. Luego condiciona los despliegues al resultado para que cualquier cambio que baje del umbral de la línea base se bloquee como una prueba que falla. ### ¿Cómo manejo el no-determinismo en los evals? Ejecuta a temperatura 0 para reducir la varianza, y para los casos que parpadean, ejecútalos varias veces y puntúa la tasa de aprobación en lugar de una sola ejecución. Un caso que pasa 9 de 10 veces está más sano que uno que pasa 5 de 10, incluso si una sola ejecución muestra ambos en verde. --- ## Cómo Automatizar tu Newsletter con un Agente de IA Source: https://alejandrorioja.com/es/how-to-automate-your-newsletter-with-an-ai-agent/ Published: 2026-06-06 Updated: 2026-06-17 Tags: AI Agents, Growth TL;DR: Un agente de Claude lee mi cola de contenido, elige el ángulo más fuerte de la semana, redacta un newsletter con mi voz, segmenta la lista por nivel de engagement y programa el envío a través de la API de Kit — todo sin que yo abra un editor. Reviso una vista previa renderizada y presiono aprobar. El trabajo creativo difícil es mío; la ejecución mecánica es del agente. ## Tabla de contenidos _Actualizado junio 2026._ **TL;DR:** Un agente de Claude lee mi cola de contenido, elige el ángulo más fuerte de la semana, redacta un newsletter con mi voz, segmenta la lista por nivel de engagement y programa el envío a través de la API de Kit — todo sin que yo abra un editor. Reviso una vista previa renderizada y presiono aprobar. El trabajo creativo difícil es mío; la ejecución mecánica es del agente. **[Lectura del operador]** Un newsletter que se envía de forma consistente supera a uno que es "mejor" pero que se publica cuando llega la inspiración. La restricción era la sobrecarga de ejecución, no las ideas. Tenía ideas; no tenía el ancho de banda para formatear, programar y segmentarlas cada semana. El agente eliminó esa brecha. ## El verdadero cuello de botella en la mayoría de los flujos de newsletter La mayoría de los consejos de automatización de newsletters se enfocan en lo incorrecto: secuencias de bienvenida, automatizaciones, lógica de etiquetado. Están bien, pero no resuelven el problema de creación semana a semana. El verdadero freno es este: sabes lo que quieres decir, pero sentarte a formatearlo, escribir las variantes del asunto, elegir el segmento correcto y programarlo en el momento adecuado cuesta 2-3 horas de cambio de contexto por semana. Multiplícalo por 52 semanas y habrás pasado una semana laboral completa simplemente *enviando* newsletters. El agente maneja cada paso después de "sé cuál es el ángulo de esta semana." ## El stack que estoy usando - **[Kit](/recommends/convertkit)** (anteriormente ConvertKit) — la plataforma de email. Excelente API, sólido etiquetado de suscriptores, analítica limpia. La API amigable con agentes fue lo que me convenció. - **Claude (Anthropic SDK)** — la capa de generación - **Cloudflare Workers** — disparador programado (se ejecuta cada martes a las 8am CT) - **Airtable** — cola de contenido y bandeja de aprobación Si no estás en Kit, el mismo patrón funciona con cualquier plataforma que tenga una API REST para crear y programar transmisiones. ## Paso 1: La cola de contenido El agente necesita una fuente de verdad sobre "de qué estamos escribiendo." La mía es una tabla de [Airtable](/recommends/airtable) con columnas: - `Topic` — el ángulo o la pregunta - `Status` — Queue / Approved / Sent - `Tier` — si esto es para todos los suscriptores o solo para los más comprometidos - `Notes` — cualquier restricción (evitar este tono, incluir este enlace, etc.) Cada semana, paso 10 minutos añadiendo 2-3 temas a la cola. Esa es mi aportación creativa. El resto es el trabajo del agente. ## Paso 2: El agente de borrador ```typescript // workers/newsletter-agent/index.ts import Anthropic from "@anthropic-ai/sdk"; import Airtable from "airtable"; const client = new Anthropic(); const VOICE_SYSTEM = `You are writing a weekly newsletter for Alejandro Rioja's subscribers. His audience: founders and operators interested in AI agents, SEO, and growing a one-person business. Voice: direct, first-person, practitioner. No hype, no "exciting times," no excessive bullet lists. Structure every newsletter as: 1. One-sentence hook (the problem or observation) 2. The core insight (3–5 paragraphs, no headers, conversational) 3. One concrete action the reader can take this week 4. A short sign-off (2 sentences max) Subject line: specific, outcome-oriented, under 50 chars. No clickbait. Return JSON: { "subject": "...", "preheader": "...", "body": "..." }`; async function getNextTopic(): Promise<{ id: string; topic: string; notes: string; tier: string }> { const base = new Airtable({ apiKey: process.env.AIRTABLE_API_KEY }).base(process.env.AIRTABLE_BASE_ID!); const records = await base("Newsletter Queue") .select({ filterByFormula: "{Status} = 'Queue'", sort: [{ field: "Created", direction: "asc" }], maxRecords: 1 }) .firstPage(); if (!records.length) throw new Error("Queue is empty. Add topics."); const r = records[0]; return { id: r.id, topic: r.get("Topic") as string, notes: (r.get("Notes") as string) ?? "", tier: (r.get("Tier") as string) ?? "all" }; } async function draftNewsletter(topic: string, notes: string): Promise<{ subject: string; preheader: string; body: string }> { const msg = await client.messages.create({ model: "claude-sonnet-4-6", max_tokens: 2048, system: VOICE_SYSTEM, messages: [{ role: "user", content: `Write this week's newsletter on: "${topic}". Additional notes: ${notes || "none"}` }], }); const text = (msg.content[0] as any).text.replace(/```json\n?/, "").replace(/```/, "").trim(); return JSON.parse(text); } async function scheduleWithKit(draft: { subject: string; preheader: string; body: string }, tier: string): Promise { const segmentId = tier === "engaged" ? process.env.KIT_ENGAGED_SEGMENT_ID : null; const sendAt = new Date(); sendAt.setDate(sendAt.getDate() + ((4 - sendAt.getDay() + 7) % 7)); // next Thursday sendAt.setHours(9, 0, 0, 0); // 9am CT const payload: any = { broadcast: { subject: draft.subject, content: draft.body, description: draft.preheader, send_at: sendAt.toISOString(), email_layout_template: "minimal", }, }; if (segmentId) payload.broadcast.segment_id = segmentId; const res = await fetch("https://api.kit.com/v4/broadcasts", { method: "POST", headers: { "Content-Type": "application/json", "X-Kit-Api-Key": process.env.KIT_API_KEY! }, body: JSON.stringify(payload), }); const data = await res.json(); return data.broadcast?.id ?? ""; } export default { async scheduled(_event: ScheduledEvent, env: Env) { // Inject env vars Object.assign(process.env, env); const { id, topic, notes, tier } = await getNextTopic(); const draft = await draftNewsletter(topic, notes); const broadcastId = await scheduleWithKit(draft, tier); // Mark as Approved in Airtable (not Sent — human reviews the Kit preview before confirm) const base = new Airtable({ apiKey: env.AIRTABLE_API_KEY }).base(env.AIRTABLE_BASE_ID); await base("Newsletter Queue").update(id, { Status: "Approved", KitBroadcastId: broadcastId }); console.log(`Scheduled broadcast ${broadcastId} for topic: ${topic}`); }, }; ``` ## Paso 3: El paso de aprobación El agente crea la transmisión en estado de borrador de Kit y marca el registro de Airtable como "Approved." Kit me envía una notificación con un enlace de vista previa. Hago clic, lo leo y, si se ve bien, confirmo el envío. Si quiero cambios, edito directamente en Kit. Esta es la puerta que evita que el agente sea completamente autónomo en el correo saliente. Confío en los borradores aproximadamente el 90% de las veces. El 10% que detecto en la revisión — un tono ligeramente incorrecto, una estadística que quiero verificar, un enlace que quiero añadir — vale los 3 minutos de revisión. ## Lo que el agente maneja que nunca más quiero hacer - Escribir variantes de línea de asunto y elegir la mejor - Formatear el texto del preencabezado - Calcular el tiempo de envío correcto (mi audiencia abre los jueves por la mañana; el agente lo sabe) - Segmentar correctamente según el nivel del tema - Registrar todo en Airtable para tener un historial ## Lo que sigo siendo mío La *idea*. El tema en la cola es mío. El ángulo es mío. El agente es un gran ejecutor de un brief claro; no es una capa de estrategia. Si pongo un tema malo en la cola, obtengo un newsletter bien escrito sobre un tema malo. También: la puerta de primera revisión. Cada envío pasa por mis ojos antes de salir. Eso no va a cambiar. ## La conclusión del operador Si estás pasando más de una hora a la semana en mecánicas de newsletter — formateo, programación, segmentación — deberías automatizarlo. La API de Kit es limpia, el disparador cron del Worker es sólido como una roca, y la calidad del borrador de Claude es suficientemente alta como para que apruebe ~90% de los primeros borradores sin cambios. Construye la cola en Airtable, conecta el Worker y vuelve a crear ideas en lugar de ejecutar envíos. --- ## Cómo Posicionarse en la Búsqueda de IA sin Escribir una Sola Publicación Nueva Source: https://alejandrorioja.com/es/how-to-rank-in-ai-search-without-writing-a-single-new-blog-post/ Published: 2026-06-06 Updated: 2026-06-24 Tags: GEO, SEO TL;DR: Los motores de IA citan contenido que responde preguntas directamente, afirma una autoría clara y estructura el conocimiento de una manera que facilita la recuperación. La mayoría de las publicaciones de blog existentes se pueden adaptar para cumplir los tres criterios con ediciones, no reescrituras. El plan: añadir un TL;DR directo, reforzar señales de entidad, añadir esquema FAQ y enviar al llms.txt. El contenido nuevo es opcional; la reestructuración no lo es. ## Tabla de contenidos _Actualizado junio 2026._ **TL;DR:** Los motores de IA citan contenido que responde preguntas directamente, afirma una autoría clara y estructura el conocimiento de una manera que facilita la recuperación. La mayoría de las publicaciones de blog existentes se pueden adaptar para cumplir los tres criterios con ediciones, no reescrituras. El plan: añadir un TL;DR directo, reforzar señales de entidad, añadir esquema FAQ y enviar al llms.txt. El contenido nuevo es opcional; la reestructuración no lo es. **[Lectura del operador]** Ejecuté este proceso en 341 publicaciones existentes antes de escribir un solo artículo nuevo orientado a GEO. Las citas en ChatGPT y Perplexity aumentaron. El contenido nuevo aceleró las ganancias — pero la auditoría de contenido existente fue donde empecé, y rindió frutos más rápido de lo que esperaba. ## Por qué los motores de IA no citan tu contenido existente Antes de escribir cualquier cosa nueva, pregunta: ¿por qué lo que ya tengo no está siendo citado? La respuesta casi nunca es "el contenido no existe." Generalmente es una de estas: 1. **Sin respuesta directa al principio** — la publicación entierra la respuesta en el párrafo 6 2. **Señales de autoría débiles** — sin entidad de autor clara, sin credenciales en el contenido 3. **Ruido estructural** — introducciones largas, secciones irrelevantes, sin jerarquía de encabezados clara 4. **Sin Q&A legible por máquinas** — los motores de IA prefieren pares de pregunta-respuesta estructurados; la mayoría de publicaciones de blog no los tienen 5. **No está en ningún índice legible por IA** — sin llms.txt, sin sitemaps que los rastreadores encuentren Los cinco son solucionables en contenido existente. Ninguno requiere una nueva publicación. ## El proceso de adaptación en cuatro pasos ### Paso 1: Añade un TL;DR directo en las primeras 100 palabras Los motores de IA hacen algo análogo a lo que tú haces cuando escaneas — buscan la respuesta directa antes de profundizar. Si tu publicación empieza con una historia, una pregunta o establecimiento de contexto, el modelo puede que nunca lea lo suficientemente lejos para encontrar tu respuesta real. Solución: Añade un bloque **TL;DR** en las primeras 100 palabras. Formato: conclusión → por qué → restricción o advertencia. De dos a cuatro frases. Sin relleno. Ejemplo antes: > *¿Alguna vez te has preguntado por qué algunos negocios parecen dominar los resultados de búsqueda de Google? En esta publicación, exploraremos las estrategias que usan los sitios mejor posicionados...* Ejemplo después: > **TL;DR:** Tres cosas mueven la aguja para el SEO local en 2026: completitud del Perfil de Negocio de Google, consistencia de citas en directorios y esquema estructurado para tus datos NAP. Tácticas como "publicar todos los días" y "conseguir 100 reseñas rápido" son secundarias a esas tres. El techo es la precisión de tu GBP — arréglalo primero. La reescritura no es más larga. Solo está al principio. ### Paso 2: Refuerza tus señales de entidad Los motores de IA construyen un grafo de conocimiento. Quieren saber: ¿quién escribió esto, de qué trata y el autor es creíble en este tema? Para la entidad del autor: asegúrate de que tu página Acerca de esté enlazada desde cada publicación, tu esquema de autor incluya enlaces `sameAs` a LinkedIn y Twitter, y tu bio de autor en cada publicación mencione credenciales específicas (no "profesional de marketing" — "dirigió SEO para tres empresas SaaS de 0 a 100K visitantes mensuales"). Para la entidad del tema: usa los términos exactos que busca tu audiencia. Si cubres "GEO" (optimización de motores generativos), di "optimización de motores generativos" en algún lugar, no solo la abreviación. Los modelos usan la co-ocurrencia de términos para clasificar el contenido. ### Paso 3: Añade esquema FAQ a cada publicación que responda preguntas El esquema FAQPage es el tipo de esquema de mayor influencia para la cita de GEO porque mapea explícitamente pregunta a respuesta en un formato que los modelos pueden analizar directamente. Toma las 3-5 preguntas que tu publicación responde implícitamente y hazlas explícitas: ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "How long does it take to rank in AI search?", "acceptedAnswer": { "@type": "Answer", "text": "Most sites see initial citation improvements within 4–8 weeks of restructuring existing content for direct answers and adding FAQ schema. Brand-new domains take longer — expect 3–6 months before consistent citations appear." } } ] } ``` Añade esto al `` de tu publicación o a través del campo de esquema de tu CMS. Cada motor de IA principal rastrea y analiza esto. ### Paso 4: Envía a llms.txt y al índice de IA de tu plataforma `llms.txt` es un estándar emergente — un archivo de texto plano en `tusitio.com/llms.txt` que le indica a los rastreadores de IA qué contenido es de alta calidad y cómo priorizarlo. Es análogo a `robots.txt` pero para LLMs. Un llms.txt básico: ``` # llms.txt # alejandrorioja.com — AI agents and GEO for operators ## Priority content - /blog/geo-for-local-business (definitive guide, updated monthly) - /blog/schema-markup-for-ai-engines (technical reference) - /blog/how-to-get-cited-by-chatgpt (step-by-step) ## Author Alejandro Rioja — operator, AI agent builder, GEO practitioner. LinkedIn: https://linkedin.com/in/alejandrorioja ``` Combina esto con un sitemap limpio que incluya marcas de tiempo `lastmod`. Los rastreadores de IA descartan contenido que parece desactualizado. ## Cómo priorizar qué publicaciones adaptar No toda publicación vale la pena adaptar. Enfoca tu primer pase en: 1. **Publicaciones que ya se posicionan en la página 1 para una palabra clave en formato de pregunta** — estas están más cerca de ser citadas; solo necesitan la corrección de estructura 2. **Publicaciones sobre temas en los que eres verificablemente creíble** — los motores de IA ponderan mucho la autoría; una publicación donde tus credenciales son relevantes obtiene un impulso de cita de las señales de entidad 3. **Publicaciones que responden directamente una pregunta vs. publicaciones que informan** — "Cómo hacer X" y "Qué es X" se adaptan mejor que listicles o piezas de opinión Usa los datos de tu Search Console: filtra para consultas que son preguntas (cómo, qué, por qué, mejor manera de). Las publicaciones que se posicionan del 5 al 15 para esas consultas son tus mejores candidatas de adaptación — son relevantes pero aún no lo suficientemente cerca de la cima para ser citadas. ## El error que comete la mayoría Escriben una nueva publicación optimizada para la búsqueda de IA antes de adaptar su archivo existente. El contenido nuevo ayuda, pero las publicaciones existentes tienen antigüedad, backlinks e historial de rastreo de su lado. Una publicación de tres años bien estructurada superará a una nueva publicación sobre el mismo tema durante meses. Haz la adaptación primero. Escribe contenido nuevo donde haya lagunas genuinas — preguntas que tus publicaciones existentes no responden en absoluto. Es cuando lo nuevo es mejor que lo antiguo. ## La conclusión del operador Si tienes más de 20 publicaciones de blog existentes, tu trabajo de GEO comienza con auditoría y adaptación, no con un calendario de contenido. Añade TL;DRs, refuerza señales de entidad, añade esquema FAQ y envía a llms.txt. Haz eso en tus 20 publicaciones principales antes de escribir nada nuevo. Verás mejoras en las citas en semanas, no meses — y tendrás una línea base más limpia para medir si el contenido nuevo realmente mueve la aguja. --- ## Construí una habilidad de Claude que gestiona mis anuncios de Facebook — aquí está el código Source: https://alejandrorioja.com/es/i-built-a-claude-skill-that-runs-my-facebook-ads-heres-the-code/ Published: 2026-06-06 Updated: 2026-06-29 Tags: AI Agents TL;DR: Construí una habilidad de Claude que lee mi cuenta de Meta Ads a través de la Graph API, identifica los anuncios de bajo rendimiento, reescribe el copy en mi voz de marca y crea nuevos conjuntos de anuncios sin que yo toque el Administrador de Anuncios. Todo en menos de 300 líneas de TypeScript. El retorno fue inmediato: reduje el tiempo semanal de gestión de anuncios de ~3 horas a unos 20 minutos. ## Tabla de contenidos _Actualizado junio 2026._ **TL;DR:** Construí una habilidad de Claude que lee mi cuenta de Meta Ads a través de la Graph API, identifica los anuncios de bajo rendimiento, reescribe el copy en mi voz de marca y crea nuevos conjuntos de anuncios sin que yo toque el Administrador de Anuncios. Todo en menos de 300 líneas de TypeScript. El retorno fue inmediato: reduje el tiempo semanal de gestión de anuncios de ~3 horas a unos 20 minutos. **[Lectura del operador]** Gestiono anuncios para Pickleland y para mi marca de consultoría. Dos cuentas, audiencias distintas, fatiga creativa constante. Estaba pasando los domingos por la tarde en el Administrador de Anuncios haciendo cosas que debería hacer un modelo. Así que lo automaticé. ## Por qué dejé de gestionar los anuncios de Facebook manualmente El trabajo real de gestionar anuncios de Facebook se divide en tres tareas: 1. **Monitoreo** — revisar qué conjuntos de anuncios están quemando dinero vs. generándolo 2. **Diagnóstico** — averiguar *por qué* algo tiene bajo rendimiento (¿fatiga creativa? ¿mal targeting? ¿página de destino?) 3. **Iteración** — escribir nuevo copy, crear nuevos conjuntos de anuncios, ajustar presupuestos La tarea 1 es mecánica. La tarea 3 es mayormente mecánica (con una restricción de voz). La tarea 2 requiere juicio — y es la única que se beneficia de tener un humano en el ciclo. Una habilidad de Claude puede hacer el 1 y el 3. Yo reviso los resultados de la tarea 2 antes de que algo se publique. Esa es la arquitectura en la que me decidí. ## La configuración de la Meta Graph API (esta es la parte tediosa) Antes de cualquier código: necesitas una cuenta de Meta Business, un Usuario del Sistema y un token de acceso permanente. El portal de desarrolladores de Facebook es hostil, pero el camino es: 1. Crear una **Meta App** en developers.facebook.com (tipo: Business) 2. Agregar el producto **Marketing API** 3. En tu Portafolio de Negocio → Configuración → Usuarios → Usuarios del Sistema, crear un usuario del sistema y darle el rol `ADVERTISER` en tu cuenta publicitaria 4. Generar un token con estos permisos: `ads_read`, `ads_management`, `business_management` Guarda el token como `META_ACCESS_TOKEN` y el ID de tu cuenta publicitaria (formato: `act_XXXXXXXX`) como `META_AD_ACCOUNT_ID` en tu `.env`. ## La estructura de archivos de la habilidad ``` .claude/skills/fb-ads/ SKILL.md ← instrucciones que Claude lee index.ts ← la implementación real de la herramienta types.ts ← tipos compartidos ``` El `SKILL.md` es lo que le dice a Claude cuándo y cómo usar la habilidad. El mío dice: ```markdown # Facebook Ads Manager Skill Use this skill when the user says "check my ads", "run ads report", "pause underperformers", or "write new ad copy". Never run this without explicit user instruction — it touches live ad spend. ## What it can do - Pull performance data for all active ad sets (last 7 or 30 days) - Flag ad sets with ROAS < 1.5 or CTR < 0.8% as underperformers - Rewrite ad copy for flagged creatives in Ale's voice - Create new ad sets with revised copy (PAUSED by default — you approve before activating) ## What it will NOT do - Change budgets on live ad sets without explicit confirmation - Activate new ad sets automatically - Delete anything ``` La restricción de "nunca activar automáticamente" es innegociable. Esta habilidad crea cosas en estado PAUSADO. Yo reviso y activo manualmente. Cualquier cosa que toque el gasto en vivo necesita un punto de control humano. ## El código TypeScript principal (Los bloques de código se mantienen en inglés — solo se traduce el texto que los rodea.) ## Cómo lo uso día a día La habilidad se invoca desde Claude Code (mi herramienta diaria). Una sesión típica de lunes por la mañana: ``` > check my ads from the last 7 days ``` Claude ejecuta `runAdsReport(7)`, formatea los resultados como una tabla, señala los de bajo rendimiento y pregunta si quiero reescrituras. Digo que sí. Genera el nuevo copy, me muestra ambas versiones lado a lado y crea conjuntos de anuncios PAUSADOS con el nuevo creativo. Los reviso en el Administrador de Anuncios, activo los que me gustan y archivo los perdedores. Tiempo total: 20 minutos. Cero domingos por la tarde en el Administrador de Anuncios. ## Lo que esto no reemplaza La habilidad no puede decirme si un problema de ajuste producto-mercado se está disfrazando de un problema de copy. Si el ROAS es malo en general, es un problema de embudo u oferta, no de titular. Claude reescribirá fielmente el copy en un embudo roto — y las reescrituras no lo salvarán. El paso de diagnóstico sigue siendo mío. Leo el informe, miro los datos del embudo y decido si estamos iterando el creativo o resolviendo algo más arriba. El agente es rápido en todo *excepto* en ese juicio. ## La conclusión del operador Si estás gestionando anuncios manualmente y tocando el Administrador de Anuncios más de dos veces por semana, estás haciendo operaciones que debería hacer un script. La Graph API está bien documentada y el flujo de permisos de Meta, aunque tedioso, es una configuración única. Construye la habilidad en una tarde. El retorno en tiempo recuperado se nota en la primera semana. --- ## Las 5 Herramientas de IA que Realmente Uso para Gestionar mi Negocio (2026) Source: https://alejandrorioja.com/es/the-5-ai-tools-i-actually-use-to-run-my-business-2026-operator-stack/ Published: 2026-06-06 Updated: 2026-06-20 Tags: AI Agents, Growth TL;DR: Cinco herramientas: Claude (capa de operador + programación), Cursor (desarrollo TypeScript), Airtable (columna vertebral de datos para todos los agentes), Kit (newsletter + automatización de email) y Cloudflare Workers (alojamiento de agentes). Todo lo demás que he probado ha sido reemplazado por una de estas o eliminado por completo. Este es el stack que reconstruiría si tuviera que empezar de nuevo hoy. ## Tabla de contenidos _Actualizado junio 2026._ **TL;DR:** Cinco herramientas: Claude (capa de operador + programación), Cursor (desarrollo TypeScript), [Airtable](/recommends/airtable) (columna vertebral de datos para todos los agentes), [Kit](/recommends/convertkit) (newsletter + automatización de email) y Cloudflare Workers (alojamiento de agentes). Todo lo demás que he probado ha sido reemplazado por una de estas o eliminado por completo. Este es el stack que reconstruiría si tuviera que empezar de nuevo hoy. **[Lectura del operador]** Gestiono dos negocios: una marca personal de consultoría en IA (alejandrorioja.com) y Pickleland, una instalación de pádel americano en Pflugerville, TX. Contextos distintos, públicos distintos, operaciones distintas. Estas cinco herramientas gestionan ambas. No las listo porque estén de moda; las listo porque he eliminado sus reemplazos. ## 1. Claude — la capa de operador Claude (a través de Claude Code y el Anthropic SDK) es el cerebro de todo lo que se mueve. Lo uso en tres modos: **Claude Code** es mi herramienta diaria de desarrollo. Escribo TypeScript, construyo agentes, depuro problemas de infraestructura y gestiono contenido — todo desde la interfaz de Claude Code. No es solo autocompletado; es un colaborador que puede leer un archivo de 500 líneas, entender la intención y proponer una refactorización que yo no había considerado. **El Anthropic SDK** impulsa cada agente que he construido. Mi agente de newsletter, mi habilidad de anuncios en Facebook, mi pipeline de contenido, mi generador de tarjetas OG — todo Claude en el backend. La calidad del modelo es suficientemente alta como para que confíe en los primeros borradores aproximadamente el 85% del tiempo. **El juicio de voz y marca de Claude** está infravalorado. Cuando escribo algo que necesita sonar como yo, he descubierto que Claude + un system prompt detallado supera a todos los demás modelos que he probado. El truco es un system prompt específico y con opiniones — no "escribe en tono casual" sino "escribe como Alejandro: directo, practicante, sin exageraciones, numerado, primera persona, con advertencias honestas." Pago por Claude Max. Es la suscripción más usada que tengo, y el ROI no tiene comparación. ## 2. Cursor — donde se escribe el TypeScript Cursor es el IDE. Cambié de VS Code hace aproximadamente un año y no he mirado atrás. El autocompletado por tabulación es suficientemente rápido como para cambiar genuinamente cómo escribo código — pienso en un nivel más alto y dejo que Cursor maneje el boilerplate sintáctico. La vista de diferencias para las sugerencias de IA es limpia. La ventana de contexto multi-archivo significa que puedo pedirle que actualice una función y también actualiza los llamadores. No uso Cursor para decisiones de arquitectura. Todavía las esboza en papel o en Claude. Pero una vez que el diseño está claro, Cursor es el camino más rápido desde el diseño hasta el TypeScript en funcionamiento. El mayor avance: Cursor + Claude Code en paralelo. Uso Claude Code para la planificación de alto nivel y la orquestación de agentes; uso Cursor para el trabajo detallado de implementación. No entran en conflicto — cubren altitudes diferentes. ## 3. Airtable — la columna vertebral de datos Cada agente de IA que ejecuto necesita un lugar desde donde leer y escribir. Ese lugar es [Airtable](/recommends/airtable). Esto es para lo que lo uso en ambos negocios: - **Cola de contenido** — publicaciones y temas de newsletter en progreso, con seguimiento de estado - **Registros de reservas** — reservas de pistas de Pickleland sincronizadas desde el sistema de reservas - **Catálogo de enlaces de afiliados** — más de 105 slugs con metadatos que el agente de contenido lee en el momento de la generación - **Registro de auditoría del agente** — qué se ejecutó, cuándo, qué produjo, cualquier error La API es limpia y rápida. Airtable no es una base de datos para cargas de trabajo de alto rendimiento — pero para tablas secundarias de agentes, colas de revisión y flujos de trabajo de aprobación con intervención humana, es exactamente la herramienta correcta. La interfaz visual significa que puedo inspeccionar cualquier tabla sin escribir una consulta. La alternativa que probé: bases de datos de Notion. La API de Notion es más lenta y el modelo de datos es más torpe para las lecturas de agentes. Airtable gana para datos adyacentes a agentes. ## 4. Kit — newsletter y automatización de email Cambié a [Kit](/recommends/convertkit) (anteriormente ConvertKit) por una razón: la API es realmente buena. La mayoría de las plataformas de email tratan su API como algo secundario. Kit la trata como un producto de primera clase. Puedo crear transmisiones, programar envíos, segmentar por etiqueta y leer análisis — todo programáticamente. Mi agente de newsletter hace todo esto sin que yo toque el compositor. Cosas específicas de Kit que uso: - **API de Transmisiones** — mi agente crea transmisiones programadas de forma programática cada semana - **Etiquetado de suscriptores** — etiqueto suscriptores por comportamiento (abrió los últimos 5 envíos = "comprometido"; no ha abierto en 60 días = "en riesgo") y mi agente apunta a segmentos en consecuencia - **Formularios + páginas de aterrizaje** — limpias, de carga rápida, sin código. No las toco programáticamente; simplemente funcionan. Si estás en Mailchimp o una plataforma heredada: la migración vale la pena. La API de Mailchimp requiere tres llamadas adicionales para hacer lo que Kit hace en una. ## 5. Cloudflare Workers — donde viven los agentes Cada agente programado se ejecuta en Cloudflare Workers. El argumento: despliegue global en el borde, cero arranques en frío en el nivel gratuito y un sistema de activación por cron que realmente funciona. Mis agentes no necesitan un servidor. Necesitan una función programada que se ejecute de manera confiable, pueda hacer llamadas a API externas y cueste casi nada a mi escala. Workers es la respuesta. Lo que tengo ejecutándose en Workers: - **Pipeline de contenido** — genera publicación en inglés, la distribuye a 12 traducciones, genera tarjeta OG - **Agente de newsletter** — redacta y programa el envío semanal - **Monitor de anuncios de Facebook** — lee el rendimiento, marca a los de bajo rendimiento, me notifica - **Reportero de ocupación de Pickleland** — lee datos de reservas, me envía un resumen diario Costo mensual total por todo esto: ~$5. Ese es el plan de Workers de pago. Los agentes se ejecutan de manera confiable en el horario cron; he tenido una falla en seis meses (un problema de DNS en el lado de Meta, no el mío). ## Lo que eliminé y por qué **Zapier** — reemplazado por Workers + las respectivas APIs de plataforma directamente. Zapier añade latencia, cuesta más a escala y tiene un techo que Workers no tiene. **ChatGPT** — la ventana de contexto, el uso de herramientas y la calidad del system prompt de Claude son mejores para el caso de uso del operador. Mantengo una pestaña de ChatGPT para búsquedas rápidas en la web pero no construyo sobre él. **Webflow** — moví mi sitio a Astro + Cloudflare Pages. Más control, mejor rendimiento, proceso de construcción contra el que puedo programar. **Grammarly** — Claude hace todo lo que hace Grammarly y mantiene mejor mi voz. ## La conclusión del operador Las cinco herramientas anteriores no son las más nuevas ni las más discutidas. Son las que aguantaron el uso diario en producción en dos negocios diferentes. Antes de agregar una nueva herramienta a tu stack, pregunta: ¿cuál de estas cinco podría hacer este trabajo? Te sorprenderá con qué frecuencia la respuesta es "una de ellas ya puede." --- ## Por Qué Tu Agente de IA Sigue Fallando en Producción (Y Cómo Arreglarlo) Source: https://alejandrorioja.com/es/why-your-ai-agent-keeps-failing-in-production-and-how-to-fix-it/ Published: 2026-06-06 Updated: 2026-06-26 Tags: AI Agents TL;DR: La mayoría de los fallos de agentes en producción provienen de cinco causas: prompts frágiles que no manejan casos extremos, falta de lógica de reintento para errores de API transitorios, sin observabilidad para ver qué está fallando, bucles descontrolados sin condición de salida y definiciones de herramientas suficientemente ambiguas como para que el modelo elija la equivocada. Los cinco son solucionables sin cambiar modelos ni frameworks. ## Tabla de contenidos _Actualizado junio 2026._ **TL;DR:** La mayoría de los fallos de agentes en producción provienen de cinco causas: prompts frágiles que no manejan casos extremos, falta de lógica de reintento para errores de API transitorios, sin observabilidad para ver qué está fallando, bucles descontrolados sin condición de salida y definiciones de herramientas suficientemente ambiguas como para que el modelo elija la equivocada. Los cinco son solucionables sin cambiar modelos ni frameworks. **[Lectura del operador]** Tengo más de 30 agentes en producción. He tenido todos estos fallos. Los que me quemaron más tiempo no fueron los exóticos — fueron los fallos de infraestructura aburridos que pensé que había manejado. ## Fallo 1: Prompts frágiles que se rompen con entradas de casos extremos Un prompt que funciona en tus casos de prueba fallará con entradas que no anticipaste. Eso no es una limitación del modelo — es un problema de escritura de instrucciones. **Síntomas:** El agente produce resultados sin sentido, llama a la herramienta equivocada o genera JSON malformado cuando la entrada es ligeramente diferente a lo que probaste. **Causa raíz:** Tu system prompt describe solo el camino feliz. No le dice al modelo qué hacer cuando los datos faltan, están malformados o son ambiguos. **Solución:** Añade manejo explícito de casos extremos a tu system prompt: ``` If the input data is missing a required field, return: { "status": "error", "reason": "missing_field", "field": "" } Do NOT attempt to infer or hallucinate missing values. If you are uncertain which tool to call, call no tool and return: { "status": "clarification_needed", "question": "..." } ``` El modelo sigue instrucciones explícitas para casos extremos de manera confiable. El error es asumir que generalizará las instrucciones del camino feliz para manejar los casos complicados. ## Fallo 2: Sin lógica de reintento para errores transitorios de API Cada API externa que llama tu agente fallará en algún momento. La API de Claude, la Meta Graph API, tu base de datos — todas devuelven errores 5xx, se agota el tiempo de espera o limitan la velocidad. Si tu agente no tiene lógica de reintento, un error transitorio mata toda la ejecución. **Síntomas:** Las ejecuciones del agente fallan aleatoriamente en diferentes pasos. Los registros muestran un 503 o 429 sin intento posterior. **Solución:** Envuelve cada llamada externa en un reintento con retroceso exponencial: ```typescript async function withRetry(fn: () => Promise, retries = 3, baseDelayMs = 500): Promise { for (let attempt = 0; attempt <= retries; attempt++) { try { return await fn(); } catch (err: any) { const isTransient = err.status === 429 || err.status >= 500 || err.code === "ECONNRESET"; if (!isTransient || attempt === retries) throw err; const delay = baseDelayMs * Math.pow(2, attempt) + Math.random() * 100; await new Promise((r) => setTimeout(r, delay)); } } throw new Error("unreachable"); } // Usage const result = await withRetry(() => client.messages.create({ ... })); ``` Tres reintentos con retroceso exponencial maneja ~99% de los fallos transitorios. Añade esto a cada llamada externa y la mitad de tus fallos aleatorios desaparecerán. ## Fallo 3: Sin observabilidad — no puedes ver qué está fallando Este es el modo de fallo más común en producción y el que más tiempo cuesta depurar: el agente falla silenciosamente o produce resultados incorrectos, y no tienes idea de dónde en la cadena salió mal. **Síntomas:** Sabes que algo está mal pero no puedes identificar el paso. Añades declaraciones `console.log` y vuelves a ejecutar manualmente intentando reproducir. **Solución:** Registro estructurado en cada paso, con un ID de ejecución que traza toda la ejecución: ```typescript function createLogger(runId: string, agentName: string) { return { step: (step: string, data: object) => console.log(JSON.stringify({ runId, agent: agentName, step, ts: new Date().toISOString(), ...data })), error: (step: string, err: unknown) => console.error(JSON.stringify({ runId, agent: agentName, step, error: String(err), ts: new Date().toISOString() })), }; } const log = createLogger(crypto.randomUUID(), "newsletter-agent"); log.step("fetch_topic", { topicId: topic.id, topic: topic.name }); // ... do work ... log.step("draft_complete", { subject: draft.subject, wordCount: draft.body.split(" ").length }); ``` Si estás en Cloudflare Workers, estos registros van a Logpush o Workers Tail. Si estás ejecutando localmente o en un VPS, canaliza a un agregador de registros. El JSON estructurado significa que puedes filtrar por `runId` para ver exactamente qué sucedió en una sola ejecución. ## Fallo 4: Bucles descontrolados sin condición de salida Los bucles agénticos — donde el modelo llama a herramientas e itera hasta que se cumple una condición — pueden ejecutarse para siempre si esa condición nunca se cumple o el modelo la identifica incorrectamente. **Síntomas:** El agente gasta cientos de dólares en costos de API antes de agotar el tiempo de espera. O ejecuta la misma llamada de herramienta una y otra vez sin progresar. **Solución:** Siempre ten un límite de iteración duro y una verificación de progreso: ```typescript const MAX_ITERATIONS = 10; let iterations = 0; let lastToolCallName = ""; let sameToolCallCount = 0; while (true) { iterations++; if (iterations > MAX_ITERATIONS) { log.error("loop", { reason: "exceeded_max_iterations" }); break; } const response = await client.messages.create({ ... }); // Detect stuck loops: same tool called 3x in a row const toolCall = response.content.find(b => b.type === "tool_use"); if (toolCall?.name === lastToolCallName) { sameToolCallCount++; if (sameToolCallCount >= 3) { log.error("loop", { reason: "stuck_loop", tool: toolCall.name }); break; } } else { sameToolCallCount = 0; lastToolCallName = toolCall?.name ?? ""; } if (response.stop_reason === "end_turn") break; } ``` Esto captura tanto los modos de fallo de "se ejecutó demasiado tiempo" como de "giró en el lugar". El límite debe ser lo suficientemente generoso para el camino feliz pero lo suficientemente ajustado para limitar el radio de explosión. ## Fallo 5: Definiciones de herramientas ambiguas que el modelo resuelve mal Si le das al modelo dos herramientas con descripciones superpuestas, a veces llamará a la equivocada. Esto es especialmente común con herramientas como `search_database` vs `get_record` o `send_email` vs `create_draft`. **Síntomas:** El modelo llama a la categoría correcta de herramienta pero elige la específica equivocada. O llama a una herramienta en el contexto equivocado (usando una herramienta de escritura cuando solo era apropiada la lectura). **Solución:** Haz las descripciones de herramientas mutuamente excluyentes y añade explícitamente "cuándo NO usar esto": ```typescript const tools = [ { name: "get_subscriber", description: "Fetch a single subscriber record by email. Use ONLY when you have a specific email address. Do NOT use for searching or listing subscribers.", input_schema: { ... } }, { name: "search_subscribers", description: "Search subscribers by tag, segment, or status. Use when you need to find subscribers matching a criteria — NOT when you have a specific email address.", input_schema: { ... } } ]; ``` La cláusula "NO usar cuando X" es la parte que la mayoría omite. Es la parte más importante. Los modelos son mejores siguiendo restricciones negativas explícitas que infiriéndolas de descripciones positivas. ## Una cosa más: prueba tus agentes con entradas malas La mayoría de los agentes se prueban solo con entradas limpias de camino feliz. La producción tiene entradas sucias: cadenas vacías, campos nulos, casos extremos de Unicode, respuestas de API que devuelven 200 pero con un esquema inesperado. Añade una suite de pruebas que ejercite explícitamente: - Entradas vacías o nulas - Entradas en la longitud máxima que esperarías - Entradas con caracteres especiales o texto no ASCII - APIs externas devolviendo formas de respuesta inesperadas Si tu agente se rompe con alguna de estas, arréglalo antes de que salga en vivo. El entorno de producción encontrará cada suposición que hayas hecho. ## La conclusión del operador La mayoría de los fallos de agentes en producción son problemas de infraestructura disfrazados de problemas de modelo. Antes de cambiar modelos, añade reintentos, registro estructurado, límites de bucle y manejo explícito de casos extremos a tus prompts. Arregla las definiciones de herramientas ambiguas. Luego prueba con entradas malas. Haz todo eso antes de culpar al modelo — en mi experiencia, el modelo suele ser lo último que necesita cambio. --- ## Cómo Construir Tu Primer Agente de IA en 15 Minutos Source: https://alejandrorioja.com/es/how-to-build-your-first-ai-agent-in-15-minutes/ Published: 2026-06-02 Updated: 2026-06-20 Tags: AI Agents TL;DR: No necesitas un framework, un curso ni un doctorado. Necesitas Node.js, el SDK de Anthropic y 25 líneas de TypeScript. Este tutorial construye un agente real y funcional — un resumidor de contenido estructurado que puedes desplegar en Cloudflare en la misma sesión. El único requisito previo es una clave de API gratuita. ## Tabla de contenidos _Actualizado junio 2026._ **TL;DR:** No necesitas un framework, un curso ni un doctorado. Necesitas Node.js, el SDK de Anthropic y 25 líneas de TypeScript. Este tutorial construye un agente real y funcional — un resumidor de contenido estructurado que puedes desplegar en Cloudflare en la misma sesión. El único requisito previo es una clave de API gratuita. **[Lectura del operador]** Lo que más escucho de fundadores que quieren automatizar con IA es "primero necesito aprender más". No es cierto. El patrón de agente es simple, y la forma más rápida de entenderlo es construir uno. Aquí está el camino exacto que tomaría si empezara desde cero hoy. ## Por qué la mayoría de los tutoriales de "construye un agente de IA" te fallan O bien usan Python (bien para ingenieros de ML, fricción para todos los demás), esconden el código real detrás de un framework como LangChain, o construyen algo demasiado abstracto para conectarlo con tu trabajo real. Este tutorial hace tres cosas de forma diferente: 1. **Solo TypeScript** — si alguna vez has escrito JavaScript, puedes seguir esto 2. **Sin framework** — verás cada línea de código que toca el modelo 3. **Un resultado útil** — construirás un resumidor estructurado que realmente puedes usar en correos de clientes, reseñas o notas de reuniones ## Qué vas a construir Un **agente resumidor de contenido**: pega cualquier bloque de texto y recibe de vuelta un resumen estructurado en un formato consistente. Una petición HTTP de entrada, un resumen limpio de salida. Por qué este como primer proyecto: el patrón — prompt de sistema + entrada de usuario → salida estructurada — es la base de cada agente que ejecuto. Cambia el prompt de sistema y tienes un respondedor de preguntas, un reescritor de tono, un clasificador o un generador de borradores. Aprende esto una vez y habrás aprendido el 80% de lo que los agentes en producción realmente hacen. ## Requisitos previos (2 minutos) - **Node.js 18+** — verifica con `node --version`. Instálalo desde nodejs.org si lo necesitas. - **Una clave de API de Anthropic** — regístrate en [Claude](/recommends/claude), consigue una clave desde la consola. El plan gratuito funciona. - Una terminal y un editor de texto. Sin Docker. Sin entorno virtual. Sin `pip install` nada. ## Paso 1: Crear el proyecto (2 minutos) ```bash mkdir my-first-agent && cd my-first-agent npm init -y npm install @anthropic-ai/sdk npm install -D tsx typescript ``` Añade un script a `package.json` para poder ejecutar el agente fácilmente: ```json { "scripts": { "agent": "tsx agent.ts" } } ``` ## Paso 2: Escribir el agente (5 minutos) Crea `agent.ts` y pega esto: ```typescript import Anthropic from "@anthropic-ai/sdk"; const client = new Anthropic({ apiKey: process.env.ANTHROPIC_API_KEY, }); const SYSTEM_PROMPT = `You are a precise content summarizer. When given any block of text, return a structured summary in this exact format: **One-line summary:** **Key points:** - - - **Action item (if any):** Be specific. No filler. Under 150 words total.`; async function summarize(text: string): Promise { const message = await client.messages.create({ model: "claude-haiku-4-5", max_tokens: 512, system: SYSTEM_PROMPT, messages: [{ role: "user", content: text }], }); const block = message.content[0]; if (block.type !== "text") throw new Error("Unexpected response type"); return block.text; } const sample = ` Hey team — following up on the Q2 review meeting. We agreed to push the launch to July 15th instead of June 30th due to the payment integration delay. Marketing needs the new landing page copy by June 20th or we can't start the email campaign. Budget for the launch campaign is confirmed at $8,000. Please confirm receipt. `; const result = await summarize(sample); console.log(result); ``` ## Paso 3: Ejecutarlo (1 minuto) ```bash ANTHROPIC_API_KEY=sk-ant-... npm run agent ``` Salida esperada: ``` **One-line summary:** Launch pushed to July 15th due to payment delay; landing page copy needed by June 20th to unblock email campaign. **Key points:** - Launch date moved from June 30th to July 15th - Landing page copy deadline: June 20th (blocks email campaign) - Campaign budget confirmed at $8,000 **Action item (if any):** Confirm receipt and deliver landing page copy by June 20th. ``` Eso es un agente de IA funcional. Entrada real, prompt de sistema personalizado, salida estructurada. Todo el asunto son 30 líneas de código. ## Paso 4: Personalízalo para tu caso de uso El prompt de sistema es lo único que hace que este agente sea tuyo. Aquí tienes tres alternativas listas para usar: **Clasificador de reseñas de clientes:** ```text Classify this customer review as POSITIVE, NEGATIVE, or MIXED. Then extract the main complaint or praise in one sentence. Format: SENTIMENT: