Y ningún test unitario del mundo va a detectarlo.

La industria asume que los AI Agents se evalúan como software tradicional: más tests = más calidad. Escribís tests unitarios. Probáis funciones helper. Validáis que el JSON parsea bien. Y cuando todo pasa, asumís que el agent funciona.

*Pero un AI Agent que pasa todos los tests unitarios puede estar tomando decisiones catastróficas con un 95% de confianza. *

El problema no es que fallen. Es que fallan bien. Con buena gramática. Con paso seguro. Sin lanzar ninguna excepción que un try-catch pueda atrapar.

Bienvenidos al verdadero problema de evaluar AI Agents en 2026.

---

Por Qué el Try-Catch Es un Error Categorial

El try-catch fue diseñado para errores de runtime. Null pointers. Timeouts. Conexiones fallidas. Excepciones que rompen el flujo de ejecución.

Pero un AI Agent que decide incorrectamente no lanza una excepción. Ejecuta código perfectamente válido que lleva a una decisión equivocada.

Piénsalo así: un conductor con GPS toma la salida equivocada en una autopista. El coche funciona perfectamente. El GPS da indicaciones claras. No hay ningún error en el sistema. Pero el destino es otro.

El software tradicional confunde "funcionar sin errores" con "funcionar correctamente". Para AI Agents, esas dos cosas no tienen correlación.

Veámoslo con código:

```python

❌ TEST UNITARIO TRADICIONAL — Este test lo pasa el agent

def test_get_user_email():

agent = CustomerSupportAgent()

result = agent.get_user_email("user_123")

assert result is not None # ✅ Pasa: devolvió un string

assert "@" in result # ✅ Pasa: tiene formato de email

✅ EVALUATION REAL — Esto es lo que el test unitario NO ve

def evaluate_agent_decision():

agent = CustomerSupportAgent()

El agent devuelve un email que NO existe en la base de datos

pero con formato perfectamente válido

result = agent.get_user_email("user_123")

result = "soporte@noexiste.com" — formato perfecto, dato incorrecto

real_email = query_database("SELECT email FROM users WHERE id = 'user_123'")

real_email = "maria@empresa.com"

assert result == real_email # ❌ FALLA: el dato es incorrecto

Pero ningún test unitario comprueba esto

```

El primer test pasa. El segundo test es el que realmente importa. Y el 99% de los equipos solo escribe el primero.

---

El Peligro de la Alta Confianza en Decisiones Incorrectas

Los modelos de lenguaje generan tokens con probabilidades asociadas (logprobs). Cuando un modelo produce una respuesta con alta probabilidad en cada token, internamente "cree" que está en lo correcto.

Esto es análogo a un empleado que nunca duda de sí mismo pero se equivoca sistemáticamente. En evaluación de agents, el peor escenario no es el agent que duda (fallo visible, fácil de atrapar). Es el que ejecuta con convicción una acción dañina.

| Nivel de Confianza | Decisión Correcta | Decisión Incorrecta |

|-------------------|-------------------|-------------------|

| Confianza Alta | El agente funciona. Todo bien. | ⚠️ PELIGRO: Modo de fallo invisible. El agent actúa sin dudar. |

| Duda/Baja | El agente funciona pero es ineficiente. Pide clarificación constante. | El agente duda. El fallo es detectable. Se puede intervenir. |

El bucket crítico es "incorrecto + confianza alta". Fallos invisibles que el agente ejecutará sin dudar. No hay log. No hay error. No hay excepción. Solo una decisión equivocada ejecutada con total convicción.

---

El Sistema de 4 Buckets: Tu Evaluation Harness para AI Agents

Construí esto después de ver cómo agents en producción tomaban decisiones dañinas sin que nadie pudiera detectarlo a tiempo. No es teoría. Es el harness que uso hoy en producción.

El sistema clasifica cada acción del agent en una matriz 2x2 y te permite ver exactamente dónde está fallando tu sistema.

Bucket 1 — Taxonomía de Fallos Específica de tu Dominio

No todos los fallos son iguales. Tienes que definir los tuyos:

• Errores de hecho: información incorrecta (el agent dijo que la empresa está en Madrid cuando está en Barcelona)

• Errores de procedimiento: paso incorrecto en un workflow (cerró un ticket sin asignarlo)

• Errores de alucinación: información inventada (creó un cliente que no existe)

• Errores de omisión: no hacer algo que debía hacerse (no envió el email de confirmación)

```python

Taxonomy of failures — domain-specific

class FailureTaxonomy:

FACTUAL = "factual_error" # Wrong information

PROCEDURAL = "procedural_error" # Wrong step in workflow

HALLUCINATION = "hallucination" # Invented information

OMISSION = "omission_error" # Didn't do what was needed

NONE = "no_error" # Correct execution

```

Bucket 2 — Medir Confianza vs Precisión

Extrae los logprobs del modelo en cada respuesta y crúzalos con la corrección factual de la acción:

```python

import openai

import numpy as np

class ConfidenceAccuracyTracker:

def __init__(self):

self.results = [] # (confidence, accuracy, decision_id)

def evaluate_decision(self, prompt, expected_action, agent_response):

Extraer logprobs de la respuesta del modelo

response = openai.chat.completions.create(

model="gpt-4o",

messages=[{"role": "user", "content": prompt}],

logprobs=True,

top_logprobs=5

)

Calcular confianza media de los tokens

token_logprobs = []

for token_data in response.choices[0].logprobs.content:

token_logprobs.append(token_data.logprob)

avg_confidence = np.exp(np.mean(token_logprobs)) # Convertir logprob a probabilidad

Evaluar precisión de la decisión

is_correct = self._check_accuracy(agent_response, expected_action)

self.results.append({

"confidence": avg_confidence,

"accuracy": 1.0 if is_correct else 0.0,

"bucket": self._classify_bucket(avg_confidence, is_correct),

"decision_id": str(uuid.uuid4())[:8]

})

return self.results[-1]

def _classify_bucket(self, confidence, is_correct):

if is_correct and confidence > 0.85:

return "correcta-confianza" # ✅ El mejor caso

elif is_correct and confidence <= 0.85:

return "correcta-duda" # ⚡ Funciona pero ineficiente

elif not is_correct and confidence > 0.85:

return "incorrecta-confianza" # 🚨 PELIGRO: Fallo invisible

else:

return "incorrecta-duda" # ⚠️ Detectable, intervenible

```

Bucket 3 — Logging Estructural de Decisiones

No loguees solo errores. Loguea cada decisión con su contexto completo:

```python

class StructuralDecisionLogger:

def log_decision(self, agent_id, decision_data):

log_entry = {

"timestamp": datetime.utcnow().isoformat(),

"agent_id": agent_id,

"decision": decision_data["action"],

"confidence": decision_data["confidence"],

"tokens_consumed": decision_data["tokens"],

"latency_ms": decision_data["latency_ms"],

"human_in_the_loop": decision_data.get("required_human", False),

"bucket": decision_data["bucket"],

"expected_vs_actual": {

"expected": decision_data["expected"],

"actual": decision_data["actual"]

}

}

Enviar a tu sistema de logging (Datadog, Grafana, etc.)

self._send_to_logging_pipeline(log_entry)

Alarma automática si el agent está en bucket peligroso

if decision_data["bucket"] == "incorrecta-confianza":

self._trigger_alert(log_entry)

```

Bucket 4 — Dashboard de 4 Cuadrantes

Creas un dashboard que clasifica cada ejecución en tiempo real y te permite ver patrones:

```

CONFIANZA ALTA | CONFIANZA BAJA

─────────────────────────────────────┼───────────────────────────────────

✅ CORRECTO | Ejecuciones óptimas | ⚡ CORRECTO | Ejecuciones válidas

| (mejorar tiempo/coste) | | pero dudosas (ineficiencia)

| | |

| Objetivo: mantener aquí | | Objetivo: aumentar confianza

─────────────────────────────────────┼───────────────────────────────────

❌ INCORRECTO | 🚨 PELIGRO | ❌ INCORRECTO | Fallos detectables

| Fallos invisibles | | El agent duda

| El agent NO duda | | Fácil de intervenir

| | |

| Objetivo: CERO tolerancia | | Objetivo: minimizar

```

Si ves ejecuciones en el cuadrante "incorrecto + confianza alta", tienes un problema de arquitectura, no de modelo. El agent está aprendiendo patrones incorrectos con total seguridad.

---

Cómo Implementarlo en Producción (Sin Morir en el Intento)

Vale, sé lo que estás pensando: "Extraer logprobs y medir confianza es demasiado complejo para producción".

Es cierto que añade complejidad. Pero es la única manera de detectar el modo de fallo más peligroso. Empieza con un submuestreo del 10% de las ejecuciones. No necesitas medir todas.

Usa herramientas que ya soportan esto:

• LangSmith: tiene tracing nativo con logprobs y evaluación de decisiones

• Weights & Biases: soporta logging de confianza para modelos de lenguaje

• MLflow: tracking de experimentos con métricas personalizadas

```python

Production-ready: sample 10% of executions for evaluation

class ProductionEvaluationHarness:

def __init__(self, sample_rate=0.1):

self.sample_rate = sample_rate

self.tracker = ConfidenceAccuracyTracker()

self.logger = StructuralDecisionLogger()

def evaluate(self, agent_decision, expected, agent_id):

Solo evaluamos una muestra para no ralentizar producción

if random.random() > self.sample_rate:

return

result = self.tracker.evaluate_decision(

prompt=agent_decision["prompt"],

expected_action=expected,

agent_response=agent_decision["response"]

)

self.logger.log_decision(agent_id, {

**agent_decision,

"confidence": result["confidence"],

"bucket": result["bucket"],

"expected": expected

})

return result

```

---

Lo que la Gente se Equivoca al Decir (Y la Verdad)

"Pero si mi agent pasa los tests de integración y no lanza errores, está funcionando correctamente."

❌ Falso. Confundes funcionamiento técnico con corrección semántica. Un agent puede ejecutar código perfectamente (sin errores de runtime) mientras toma decisiones lógicamente incorrectas. El código puede ser impecable y la decisión catastrófica.

"Los logs tradicionales ya capturan los errores — solo necesito mejor logging."

❌ Falso. Los logs tradicionales capturan excepciones y errores de sistema. No capturan decisiones incorrectas con alta confianza porque desde la perspectiva del sistema, todo funcionó correctamente. No hay nada que loguear. Necesitas logging semántico que evalúe la corrección de la decisión, no solo la ejecución del código.

"Extraer logprobs y medir confianza es demasiado complejo para producción."

✅ Parcialmente cierto, pero manejable. Añade complejidad, pero es la única defensa contra el modo de fallo más peligroso. Empieza con un submuestreo del 10%. Usa herramientas como LangSmith que ya lo soportan. La alternativa es descubrir el fallo cuando el cliente te lo dice.

---

La Línea de Meta

El 2026 nos ha enseñado algo claro: los AI Agents no son software tradicional. No puedes evaluarlos con las mismas herramientas. Los tests unitarios miden si el código funciona. No miden si la decisión es correcta.

El Sistema de 4 Buckets no es opcional. Es la diferencia entre un agent que parece funcionar y uno que realmente funciona.

Empieza hoy. Define tu taxonomía de fallos. Extrae logprobs. Mide confianza vs precisión. Y pon un dashboard que te muestre dónde están tus agents fallando en silencio.

Porque el AI Agent perfectamente escrito que toma decisiones incorrectas con un 95% de confianza no es un bug. Es una bomba de relojería.

Lee el artículo completo en brianmenagomez.com

Más sobre mis servicios en brianmenagomez.com

Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF

Crees que el problema al comprar un negocio online es saber si el múltiplo es razonable. Que con revisar el tráfico en SimilarWeb y el MRR en una captura de pantalla tienes suficiente para decidir.

*Te has equivocado de diagnóstico.*

El 90% de los compradores evalúa múltiplo de ingresos y crecimiento de tráfico. Y el 90% de las adquisiciones que fracasan tenían tráfico y crecimiento — pero también una dependencia letal del fundador que ningún múltiplo pudo predecir.

La sabiduría convencional dice: "tráfico en crecimiento = buen negocio". La realidad es que tráfico sin señales de calidad es un pasivo, no un activo. Cuando compras un negocio online, no estás comprando ingresos pasados. Estás comprando la probabilidad de que esos ingresos continúen sin ti.

Y esa probabilidad no se mide con un múltiplo. Se mide con cuatro dimensiones que la mayoría ignora.

---

El Error de Diagnóstico Más Caro del Mercado de Adquisiciones

Cada semana veo a compradores obsesionados con el múltiplo. "Es un negocio que hace X y piden 2.5x, ¿es buen precio?".

Esa pregunta no tiene sentido sin contexto.

Un negocio con 2.5x de múltiplo puede ser una trampa si el 80% del tráfico viene de un solo artículo en Google que puede desaparecer mañana con una actualización del algoritmo. Y un negocio con 4x puede ser una ganga si el revenue está diversificado, la operación funciona sin el fundador, y tiene un foso defendible.

❌ Lo que hace la mayoría: compara múltiplos entre targets como si fueran el mismo tipo de activo.

✅ Lo que deberías hacer: evaluar cada target en cuatro dimensiones independientes — tráfico, revenue, dependencia del fundador y foso competitivo — y *luego* comparar el múltiplo ajustado por riesgo.

La diferencia entre un comprador que acierta y uno que fracasa no es cuánto paga. Es lo que mide antes de pagar.

---

Dimensión 1: Descomposición de Fuentes de Tráfico

El tráfico no es tráfico. No todo visitante vale lo mismo.

Un negocio que genera 100.000 visitas al mes desde Google orgánico parece sólido. Pero si abres Ahrefs o SimilarWeb y ves que el 70% de ese tráfico viene de tres keywords, tienes un problema de concentración de riesgo.

Lo que debes analizar:

• Distribución por fuente: orgánico, directo, referral, paid, social. Cualquier fuente que supere el 60% del total es una bandera roja.

• Keywords subyacentes: número de keywords que rankean y su volatilidad en 12 meses. Un negocio que depende de 5 keywords pierde el 80% de su tráfico si Google cambia las reglas.

• Estacionalidad: tráfico consistente durante 24 meses o picos que ocultan meses devalle.

Si el vendedor no te da acceso a Google Search Console antes de la carta de intención, eso ya es una señal. Pídelo como condición para avanzar. Si se niega, retírate.

---

Dimensión 2: Auditoría de Calidad del Revenue

El revenue total miente más de lo que acierta.

Un negocio SaaS con 50.000 €/año de MRR parece estable. Pero si el 35% de ese revenue viene de tres clientes empresariales, no tienes un negocio recurrente. Tienes tres contratos que pueden cancelarse el mismo trimestre.

Lo que debes auditar:

Antes de la LOI (carta de intención):

• Reseñas de clientes en plataformas públicas (Trustpilot, G2, Capterra)

• Perfiles de Linkedin del equipo para entender rotación

• Entrevistas con 3-5 clientes referidos por el vendedor

Después de la LOI (con NDA firmado):

• Logs de Stripe o PayPal: segmenta revenue por cliente, ticket medio, recurrencia

• Tasa de churn en 24 meses: un churn mensual del 5% se compone al 46% anual — el negocio debe reemplazar casi la mitad de sus ingresos cada año solo para mantenerse plano

• Tasa de reembolsos y disputas: por encima del 3% indica problemas de calidad o fraude

• Net Revenue Retention (NRR): si NRR está por debajo del 100%, el negocio está en una cinta de correr, no en una trayectoria de crecimiento

Un negocio con NRR bajo no es necesariamente malo — pero requiere una estrategia de crecimiento constante solo para no encogerse. Y esa estrategia la tendrás que ejecutar tú.

---

Dimensión 3: Mapeo de Dependencia del Fundador

Esta es la dimensión más infra-documentada y la que más adquisiciones mata.

Muchos negocios se venden como "pasivos" cuando el fundador está realizando entre 10 y 15 horas de trabajo invisible a la semana. Responder emails de soporte. Ajustar campañas de anuncios. Actualizar contenido. Subir parches de seguridad al servidor.

El vendedor no miente — simplemente no considera ese trabajo como "trabajo". Es su rutina diaria. Pero para ti, que entras desde fuera, es una losa.

El espectro de dependencia:

• Supervisión estratégica (2-4 horas al mes): revisar métricas, aprobar decisiones. Riesgo bajo.

• Ejecución operativa (10-20 horas a la semana): tareas diarias que dependen del conocimiento del fundador. Riesgo alto.

• Ejecución crítica no delegable (20+ horas): el fundador es el único que sabe cómo funciona el servidor, cómo escribe el contenido que rankea, o cómo gestiona la relación con los proveedores. Riesgo máximo.

Cómo evaluarlo:

Exige al vendedor un registro de tiempo de una semana. Cada tarea. Categorizada por: (a) requiere su expertise específico, (b) podría documentarse y delegarse, (c) ya está delegada.

Si hay más de tres tareas críticas en la categoría (a), el negocio no es pasivo. Es un empleo encubierto.

---

Dimensión 4: Inventario del Foso Competitivo

El foso es lo que protege el negocio de que llegue otro y lo copie en tres meses.

La mayoría de los negocios online pequeños no tienen foso. Tienen ventaja temporal: llegaron primero a un nicho, construyeron enlaces, acumularon reseñas. Pero eso no es un foso defendible. Es una ventana de oportunidad que se cierra.

Haz este inventario:

• Datos propietarios: ¿tienen un dataset único que nadie más tiene?

• Efectos de red: ¿el valor del producto aumenta cuantos más usuarios lo usan?

• Reconocimiento de marca: ¿la gente busca el nombre del negocio directamente?

• Autoridad SEO: domain rating, perfil de backlinks, antigüedad del dominio

• Costes de cambio: ¿qué perdería un cliente si se fuera?

• Propiedad intelectual: patentes, código propietario, procesos registrados

Si después de este inventario la única respuesta es "llevamos años aquí", el foso es fino. Y el negocio es vulnerable.

---

La Matriz de Screening en 4 Dimensiones

Este es el framework que uso para evaluar cualquier target de adquisición. Lo llamo La Matriz de Screening en 4 Dimensiones.

Paso 1: Puntúa cada dimensión del 1 al 5

| Dimensión | 1 (Crítico) | 3 (Aceptable) | 5 (Excelente) |

|---|---|---|---|

| Calidad de tráfico | >60% de una fuente única | Diversificado pero con estacionalidad | 4+ fuentes, keywords amplias, tendencia estable |

| Calidad de revenue | >30% de 5 clientes, NRR <90% | NRR entre 90-100%, churn manejable | NRR >100%, base amplia de clientes, ingresos recurrentes verificables |

| Dependencia del fundador | 3+ tareas owner-only | 1-2 tareas owner-only, documentadas | Cero dependencia operativa |

| Foso competitivo | Sin activos defensibles | Marca o SEO medio, sin datos propietarios | Efectos de red, datos únicos, costes de cambio altos |

Paso 2: Aplica el filtro de penalización

Si alguna dimensión puntúa 1, el negocio está descartado automáticamente para compra directa. A menos que tengas la capacidad operativa para resolver esa dimensión — y estés dispuesto a pagar el precio en tiempo.

Un negocio con dependencia alta del fundador puede ser una buena compra si tú eres operador y planeas sistematizarlo. Pero no es un activo pasivo. Es un proyecto de reingeniería.

Paso 3: Compara targets en la misma escala

No compares dos negocios solo por su múltiplo. Compáralos por su puntuación ajustada al riesgo. Un negocio con 4x pero puntuación 18/20 puede ser mejor inversión que uno con 2.5x pero puntuación 8/20.

---

Cómo Manejar la Objeción del Acceso a Datos

"Sí, muy bonito el framework, pero no tengo acceso a Stripe ni a Search Console antes de hacer una oferta".

Tienes razón parcialmente. Pero hay señales públicas que puedes usar:

• Tráfico público: SimilarWeb, Ahrefs (Domain Rating, backlinks, keywords estimados)

• Revenue estimado: herramientas como BuiltWith, Wappalyzer, o estimaciones de ingresos por tráfico y conversión media del sector

• Dependencia del fundador: analiza reseñas en Trustpilot. ¿Los clientes mencionan al fundador por nombre? ¿El tono de las respuestas es personal o institucional?

• Foso: antigüedad del dominio, perfil de enlaces, presencia en medios, menciones de marca

Estas señales no reemplazan la auditoría profunda, pero te permiten filtrar el 80% de los malos targets antes de perder tiempo en due diligence.

Cuando llegues a la LOI, exige acceso total a:

• Google Search Console (24 meses de datos)

• Stripe / PayPal logs completos

• Acceso al CMS y analytics

• Entrevistas con 3-5 clientes y 1-2 proveedores

• Semana de registro de tiempo del fundador

Si el vendedor se niega a cualquiera de estos, retírate. No hay negocio tan bueno que justifique comprar a ciegas.

---

El Riesgo de la Estrategia "Cómpramelo y Sistematízalo"

Hay un contraargumento válido: algunos de los mejores deals son negocios dependientes del fundador que puedes sistematizar y hacer crecer.

Es cierto. Pero es una estrategia de alto riesgo que requiere:

1. Experiencia operativa que quizá no tienes

2. Tiempo de integración de 3 a 6 meses donde no verás rentabilidad

3. Capacidad de gestión de personas para delegar lo que el fundador hacía solo

Si no tienes esas tres cosas, no compres un negocio dependiente del fundador esperando que sea pasivo. No lo será.

Segmenta tu estrategia:

• Compra para mantener: busca targets con puntuación 16+ en la matriz. Pagas más múltiplo pero corres menos riesgo.

• Compra para optimizar: busca targets con puntuación 10-15 donde una dimensión es débil pero puedes mejorarla. El descuento en el precio compensa el trabajo.

• Compra para reingeniería: targets con puntuación <10 donde el riesgo es alto pero el potencial de ganancia también. Solo si eres operador con experiencia.

---

La Decisión No Es el Precio. Es el Riesgo Que Heredas.

Cuando compras un negocio online, no pagas por el pasado. Pagas por la probabilidad de que el futuro se parezca al pasado.

Esa probabilidad no está en el múltiplo. Está en la calidad del tráfico, la diversificación del revenue, la transferibilidad de la operación y la solidez del foso.

El 90% de los compradores mide las métricas equivocadas. El 90% de las adquisiciones fracasan por las mismas razones.

*No seas el 90%.*

Usa La Matriz de Screening en 4 Dimensiones. Puntúa cada target antes de hablar de precio. Y si una dimensión puntúa 1, no negocies el precio — negocia si estás dispuesto a heredar ese riesgo.

Porque al final, comprar un negocio online no es una transacción financiera. Es una transmisión de fragilidad.

Y la fragilidad no se descuenta con un múltiplo más bajo. Se evita con un mejor screening.

Lee el artículo completo en brianmenagomez.com

Más sobre mis servicios en brianmenagomez.com

Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF

No es culpa del modelo. Es culpa de tu try-catch.

La mayoría de los desarrolladores tratan los AI Agents como software determinista. Escribís código que asume que el LLM va a devolver JSON válido. Que la tool call va a funcionar. Que el contexto va a caber en la ventana.

Y cuando falla, ponéis un try-catch.

*El problema no es que los agents fallen. Es que los tratáis como funciones puras cuando son sistemas probabilísticos con estado. *

Un AI Agent no lanza excepciones. Corrompe su contexto interno, alucina argumentos de herramientas, y cascada errores hacia abajo como fichas de dominó.

El 95% de los AI Agents se rompen en su primer error real. Los datos son claros: los try-catch blocks están diseñados para software determinista, no para sistemas donde una alucinación en el paso 3 puede invalidar todo el estado acumulado hasta el paso 10.

Si estás buscando how to build ai agents 2026 con verdadera capacidad de recuperación, lo primero que tienes que aceptar es que el patrón de error handling tradicional no funciona aquí.

---

La Falacia del Try-Catch: Por Qué No Funciona con LLMs

El error handling tradicional asume que el sistema puede continuar desde el punto de fallo. Lanzas una excepción, la capturas, registras el error, reintentas. Fin.

*Con AI Agents, eso es una mentira. *

Cuando un agente alucina un argumento de tool call — por ejemplo, pasa un string donde se esperaba un entero — no es una excepción en el sentido de programación. Es una corrupción del estado interno del agente.

❌ Try-catch tradicional:

```python

try:

result = agent.run("Busca clientes en CRM")

except Exception as e:

log_error(e)

retry() # El contexto ya está corrupto

```

El problema: cuando reintentas desde el mismo estado corrupto, produces el mismo fallo o uno peor. El agente no "olvida" la alucinación — su ventana de contexto sigue contaminada.

✅ Clasificación de errores:

```python

classificador = ErrorClassifier()

tipo_error = classificador.classify(error, contexto_actual)

if tipo_error == ErrorType.TRANSIENT:

retry_with_backoff()

elif tipo_error == ErrorType.SCHEMA_MISMATCH:

reprompt_with_corrected_schema()

elif tipo_error == ErrorType.CONTEXT_CORRUPTION:

human_checkpoint()

```

La diferencia no es técnica. Es arquitectónica. Un error en un AI Agent no es una excepción — es un problema de clasificación. La pregunta no es "¿cómo manejo esta excepción?" sino "¿qué tipo de error es este y qué ruta de recuperación requiere?"

---

El 90% de los Agents en GitHub Ejecutan Tool Calls Secuenciales — y Eso Multiplica el Problema

Los datos son tozudos: el 90% de los AI Agents en GitHub llaman herramientas de forma secuencial. Tool call 1, tool call 2, tool call 3, en línea recta.

Esto agrava la recuperación de errores. Si falla la tool call 3 de 10, tienes dos opciones:

1. Rollback total — normalmente imposible porque las tool calls anteriores ya modificaron estado externo (enviaron emails, crearon registros en DB, etc.)

2. Checkpoint entre cada paso — posible, pero raramente implementado

*La solución real es la orquestación por grafo de dependencias. *

En lugar de ejecutar tool calls en secuencia, defines un DAG (Directed Acyclic Graph) donde cada herramienta especifica sus dependencias. Si falla una tool call, solo re-ejecutas el subgrafo afectado, no todo el flujo.

Ejemplo práctico:

```python

Flujo secuencial frágil

agent.tool_call("buscar_cliente") # Paso 1

agent.tool_call("validar_credito") # Paso 2

agent.tool_call("generar_contrato") # Paso 3 — FALLA

agent.tool_call("enviar_email") # Paso 4 — contexto corrupto

```

Con orquestación por grafo, si `generar_contrato` falla, puedes re-ejecutar solo ese nodo porque el estado de `buscar_cliente` y `validar_credito` está checkpointeado fuera del contexto del LLM.

---

El Patrón de las 3 Categorías de Error para AI Agents

Aquí está el framework que deberías usar en cualquier agente que quieras que sobreviva a producción. Lo llamo *el Patrón de las 3 Categorías de Error*.

1. TransientToolError — Reintento con Exponential Backoff

Son errores temporales. Timeouts de API, rate limits, 503s. El estado del agente no está corrupto — solo el servicio externo falló.

```python

class TransientToolError(AIError):

def recover(self, agent_state, max_retries=3):

for attempt in range(max_retries):

try:

wait = min(2 ** attempt, 30) # Exponential backoff

time.sleep(wait)

return self.tool.execute(agent_state)

except TemporaryError:

continue

raise UnrecoverableError("Tool failed after 3 retries")

```

2. SchemaMismatchError — Re-Prompt con Esquema Corregido

El LLM devolvió datos que no coinciden con el esquema esperado. Esto no es un error temporal — es el modelo alucinando el formato de salida.

```python

class SchemaMismatchError(AIError):

def recover(self, agent_state, expected_schema):

Re-prompt con el esquema explícito en el mensaje

reprompt = f"""

El formato devuelto no coincide con lo esperado.

DEBES devolver EXACTAMENTE esta estructura:

{json.dumps(expected_schema, indent=2)}

No añadas campos extra. No omitas campos requeridos.

"""

return agent_state.llm.generate(reprompt)

```

3. ContextCorruptionError — Human Checkpoint Obligatorio

Este es el caso más peligroso. El estado interno del agente está corrupto — normalmente después de múltiples tool calls donde una alucinación temprana contaminó todo el razonamiento posterior.

```python

class ContextCorruptionError(AIError):

def recover(self, agent_state):

No auto-retrys. No re-prompts. Humano.

checkpoint = HumanCheckpoint(

state_snapshot=agent_state.get_corrupted_context(),

error_trace=self.build_error_trace(agent_state),

suggested_action="Revisar estado y decidir si continuar o reiniciar"

)

return checkpoint.await_decision()

```

---

@validate_output: El Decorador Que Salva Agents

El momento crítico no es cuando el error ocurre — es cuando pasa desapercibido. Un dato mal formado que cruza de una tool call a la siguiente puede generar horas de debugging.

La solución es un decorador que valide el output de cada tool call antes de que el dato entre al contexto del LLM.

```python

def validate_output(expected_schema):

def decorator(func):

@functools.wraps(func)

def wrapper(args, *kwargs):

result = func(args, *kwargs)

Validar contra esquema Pydantic

try:

validated = expected_schema(**result)

return validated

except ValidationError as e:

Clasificar el error inmediatamente

raise SchemaMismatchError(

tool_name=func.__name__,

expected=expected_schema.schema(),

actual=result,

validation_errors=e.errors()

)

return wrapper

return decorator

Uso real

@validate_output(ClienteSchema)

def buscar_cliente(email: str) -> dict:

Si esto devuelve algo que no coincide con ClienteSchema,

el decorador lanza SchemaMismatchError antes de contaminar el contexto

return api.get(f"/clientes/{email}")

```

Este patrón es lo que separa un agente que "funciona en local" de uno que sobrevive en producción.

---

Los Human Checkpoints No Son un Fracaso. Son una Característica

El mayor miedo de los equipos que construyen AI Agents es tener que meter a un humano en el loop. Lo ven como una derrota de la autonomía.

*Es exactamente lo contrario. *

Si hardcodeas auto-recovery para cada clase de error, acabas con dos problemas:

1. Agentes frágiles — handlers tan específicos que cualquier desviación los rompe

2. Agentes peligrosos — auto-retrys que profundizan en estado corrupto produciendo outputs basura

Los human checkpoints bien diseñados solo se activan para el 5-10% de los errores. Y protegen el 90-95% restante de operación autónoma de degradarse.

El truco está en la interfaz del checkpoint. No le pases al humano 500 líneas de contexto. Pásale el mínimo estado relevante y una sugerencia de acción. Así:

```

⚠️ AGENTE PAUSADO - ContextCorruptionError

Estado actual: Tool call "generar_contrato" ejecutada con parámetros inválidos

← Se esperaba: cliente_id (int), total (float)

← Se recibió: cliente_id (str: "ID-2345-ABC"), total (None)

Sugerencia: Revisar si los datos del cliente son correctos y reiniciar

desde el paso "validar_credito".

```

Los usuarios confían más en agents que saben cuándo pedir ayuda que en agents que producen silenciosamente basura.

---

El Registro de Errores Estructurado: Tu Radar de Problemas Sistémicos

No basta con clasificar errores. Necesitas un registro estructurado para detectar patrones.

```python

class ErrorRegistry:

def __init__(self):

self.errors = []

def log(self, error: AIError, agent_id: str, timestamp: datetime):

self.errors.append({

"agent_id": agent_id,

"type": error.__class__.__name__,

"tool": error.tool_name,

"timestamp": timestamp,

"snapshot": error.context_snapshot

})

def detect_patterns(self):

Si una tool falla consistentemente con SchemaMismatchError,

el contrato está mal, no el agente

tool_failures = {}

for e in self.errors:

key = (e["tool"], e["type"])

tool_failures[key] = tool_failures.get(key, 0) + 1

for (tool, error_type), count in tool_failures.items():

if count > 5:

alert(f"⚠️ {tool} falla {count} veces con {error_type}. Revisa el contrato.")

```

Si una herramienta genera SchemaMismatchError más de 5 veces seguidas, el problema no es el LLM — es el esquema o la herramienta. Arréglalo en el código, no en el prompt.

---

Objeción: "Mi agente solo hace tool calls simples — el try-catch me funciona"

Claro. Hasta que no te funciona.

El 95% de los AI Agents se rompen en su primer error real. Si tu agente no ha fallado todavía, es porque no ha enfrentado un error real. Las tool calls simples fallan silenciosamente — y el silencio es peor que el error.

Un try-catch no va a detectar que el agente pasó un ID de cliente de otra empresa porque alucinó el contexto. No va a capturar que el JSON está bien formado pero los campos están en el orden incorrecto. No va a prevenir que el agente envie 200 emails basura antes de que nadie se dé cuenta.

*Construir AI Agents en 2026 no va de hacer que el LLM sea más inteligente. Va de hacer que el sistema sea más robusto cuando el LLM se equivoca. *

---

Resumen: Lo Que Necesitas Implementar Hoy

| Componente | Qué hace | Cuándo se activa |

|---|---|---|

| ErrorClassifier | Clasifica el error en 3 buckets | Cada tool call fallida |

| @validate_output | Valida esquemas antes de pasar datos al contexto | Cada tool call exitosa |

| Transient retry | Reintenta con backoff | Errores temporales (503, timeout) |

| Schema re-prompt | Re-prompt con esquema corregido | Datos mal formados |

| Human checkpoint | Pausa y pide decisión humana | Contexto corrupto |

| ErrorRegistry | Detecta patrones de fallo | Cada error registrado |

No necesitas un modelo más grande. Necesitas una arquitectura de recuperación que entienda que los AI Agents no lanzan excepciones.

*Entran en estados no esperados. Y cada estado requiere una ruta de recuperación diferente. *

El 95% de los agents fallan en producción. Los tuyos no tienen por qué ser parte de esa estadística.

Lee el artículo completo en brianmenagomez.com

Más sobre mis servicios en brianmenagomez.com

Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF

Crees que el burnout del operador solo es un problema de volumen de trabajo. Demasiadas horas, demasiado estrés, demasiado café, demasiadas noches sin dormir.

*Te has equivocado de diagnóstico.*

El 90% de los operadores solos no se queman por trabajar 80 horas a la semana. Se queman porque construyen producto sin distribución durante meses, el feedback loop de validación nunca llega, y el esfuerzo se vuelve invisible incluso para sí mismos.

El silencio del mercado es un veneno más rápido que el agotamiento.

Cuando trabajas en una startup con 5 personas, aunque el producto no tenga tracción, tienes conversaciones de pasillo, code reviews, discusiones de roadmap. Eso es combustible social. Te dicen si vas bien, si vas mal, si el enfoque tiene sentido.

El operador solo no tiene eso.

Y cuando además no hay usuarios, el silencio es total. No hay señales de que existes. No hay señales de que lo que haces importa. No hay señales de que alguien, en algún sitio, se beneficia de tu trabajo.

Eso no es cansancio físico. Es hambre existencial.

El Problema No Son las Horas. Es la Arquitectura de Tu Semana.

El debate convencional sobre el burnout asume que el problema es cuantitativo: necesitas trabajar menos horas, dormir más, meditar, hacer deporte.

❌ "El burnout es un problema personal, no de estrategia de negocio."

Esta objeción es la más frecuente. También es la que más daño hace. Confunde el síntoma con la causa.

✅ El burnout del operador solo es un problema estructural, no de resiliencia individual.

La evidencia disponible sugiere que la estructura del trabajo — feedback loops, señales externas, ratio build/distribución — determina la probabilidad de burnout mucho más que cualquier técnica de mindfulness.

El operador solo carga con todo el riesgo técnico Y de mercado simultáneamente. En una empresa con equipo, el riesgo se externaliza: distintas personas se preocupan de distintas cosas. El operador solo es el CEO, el CTO, el marketing, el soporte, y el community manager.

Y lo peor: no tiene a quién preguntar "¿voy bien?".

Cuando construyes producto primero sin distribución, haces la apuesta más riesgosa posible. No porque el producto no pueda funcionar. Sino porque el tiempo hasta la primera señal de validación real puede ser de 6 a 12 meses de silencio absoluto.

Y ese silencio, para el operador solo, mata más rápido que la deuda técnica.

La Evidencia: Tres Datos Que Cambian el Marco

El primer dato: construir producto sin distribución es la apuesta más riesgosa para el solo-operator. El operador solo no puede externalizar el riesgo de product-market fit. No tiene un equipo de ventas que le traiga señales mientras él construye. No tiene un advisor que le diga que está yendo en la dirección equivocada antes de perder 3 meses.

El segundo dato: comprar o heredar un negocio con audiencia existente externaliza el riesgo de product-market fit. La existencia de audiencia convierte el problema técnico en un problema operacional. No tienes que preguntarte "¿existirá demanda?" — tienes que preguntarte "¿puedo servir mejor a esta demanda?". Eso reduce la incertidumbre existencial del operador de forma brutal. Construir para 0 usuarios vs. construir para 100 que ya te esperan es un contraste psicológico que no se puede exagerar.

El tercer dato: el 90% de los AI Agents ejecutan tool calls secuenciales. El salto real está en orquestar con un grafo de dependencias. ¿Y qué tiene que ver esto con el burnout? Todo. El operador solo típicamente opera de forma secuencial: primero build, luego distribución, luego soporte, luego build otra vez. Pero la mayoría de tareas no dependen unas de otras. Podrías estar escribiendo código mientras programas una publicación. Podrías estar respondiendo soporte mientras un cron job despliega un fix. Pero operas secuencialmente porque crees que es "más enfocado".

En realidad, estás alargando el tiempo hasta la primera señal de validación. Y cada día sin señal es un día más cerca del burnout.

El Framework: Las 4 Señales de Burnout Que Debes Leer en Ti Mismo

Aquí está el framework que uso para mí y para los operadores solos con los que trabajo. Cuatro pasos. Sin mindfulness. Sin apps de meditación. Sin "desconectar los fines de semana".

Solo arquitectura de trabajo.

1. Mapea tu 'Ratio de Invisibilidad'

Cuantifica cuánto de tu tiempo semanal se invierte en trabajo sin feedback externo.

Build sin users. Código sin metrics. Contenido sin audiencia. Features sin tickets de soporte reales.

Si ese ratio supera el 70% de tu semana, estás en zona de riesgo de burnout por ausencia de señales. No por exceso de trabajo — por falta de evidencia de que existes.

La mayoría de operadores solos están entre el 80% y el 90% de ratio de invisibilidad sin saberlo. Llevan meses construyendo en el vacío. Y confunden el vacío con "estar enfocados".

2. Externaliza una Señal de Validación Cada 7 Días

Define una métrica semanal que solo se activa cuando alguien externo interactúa con tu trabajo.

Un signup. Un comment. Un pago. Un issue real en GitHub. Un lead cualificado. Un email de queja. Cualquier cosa que requiera que otro ser humano haya visto lo que haces.

Si no obtienes ninguna señal externa en 7 días, detén el building inmediatamente. Cambia a distribución. No añadas esa feature. No refactorices ese módulo. No optimices esa query.

El problema no es tu producto. Es que nadie sabe que existe.

Y construir más sin que nadie sepa que existes no arregla nada. Solo alarga el silencio.

3. Implementa un 'Dependency Graph' de tu Energía Mental

El 90% de los operadores solos operan secuencialmente porque creen que es más productivo. No lo es. Es más fácil de gestionar mentalmente, pero más costoso en tiempo real.

Mapea qué tareas bloquean a otras. Identifica cuáles no dependen entre sí. Ponlas en paralelo.

Mientras un deploy se ejecuta, escribe el siguiente post de LinkedIn. Mientras el LLM procesa un batch de datos, escribe los tests del siguiente endpoint. Mientras esperas respuesta de un cliente, programa el newsletter semanal.

El salto de calidad para el operador solo no está en el modelo de trabajo. Está en la orquestación del trabajo.

Elimina latencia cognitiva antes de eliminar horas de sueño. Una hora de trabajo paralelizado vale más que dos horas de trabajo secuencial en términos de cuánto acortas el feedback loop.

4. Crea un 'Burnout Trigger' Programado

Establece una revisión automática cada 2 semanas que evalúe tres cosas:

(a) Número de señales externas recibidas en el periodo.

(b) Ratio build/distribución — cuánto tiempo dedicaste a construir vs. a buscar señales.

(c) Si el feedback loop actual está funcionando — ¿estás recibiendo información que te permita decidir qué hacer a continuación?

Cuando las señales caen a cero durante dos semanas consecutivas, el trigger activa un cambio de estrategia, no más horas de trabajo.

Más horas de trabajo cuando las señales son cero es como empujar un coche que está en punto muerto. Te cansas, el coche no se mueve, y además parece que tú eres el problema.

Cómo Sé Que Esto Funciona: El Caso del Builder Sin Audiencia

Trabajé con un operador solo que llevaba 8 meses construyendo una plataforma SaaS para gestorías. Producto sólido. Código limpio. Stack moderno. Test coverage envidiable.

Pero tenía 0 usuarios de pago.

Había confundido "estar ocupado" con "estar avanzando". Su ratio de invisibilidad era del 95%. Pasaba semanas sin que nadie externo interactuara con su trabajo.

El trigger de burnout estaba disparado, pero no lo había programado. Simplemente sentía que estaba "cansado", que necesitaba "desconectar", que "quizá el nicho no funcionaba".

No era nada de eso.

El nicho funcionaba. El producto era bueno. El problema era que no había nadie al otro lado. Y sin nadie al otro lado, el trabajo se convierte en un monólogo que agota más que 80 horas de reuniones.

El cambio no fue trabajar menos horas. Fue rearquitecturar su semana para que cada 7 días hubiera una señal externa. Dejó de construir features. Empezó a hacer distribución local — pSEO para gestorías en ciudades pequeñas, leads de Google Maps, outreach manual a 10 gestorías al día.

En la tercera semana consiguió su primer signup. En la octava, su primer pago.

Y lo más interesante: la sensación de burnout desapareció antes de que llegara el primer pago. Desapareció cuando obtuvo la primera señal externa. Porque el burnout no era financiero. Era existencial. No sabía si lo que hacía importaba.

Con el primer signup, supo que sí.

La Objeción Que Vas a Tener: "Pero Yo Construí Sin Distribución y Me Fue Bien"

Es una objeción esperable. Justa. Y válida como caso anecdótico.

Hay operadores solos que construyeron producto primero, no hicieron distribución, y 12 meses después tuvieron tracción. Existen. Yo conozco a algunos.

Pero la pregunta que debes hacerte no es "alguien lo logró". La pregunta es: ¿cuántos lo intentan y no sobreviven al silencio?

Para el 90% de los operadores solos, ese camino lleva a burnout antes que a product-market fit. Los que lo lograron suelen tener un factor atípico: ahorros, red de contactos en el nicho, demanda latente que existía pero no se había canalizado.

El artículo no dice que sea imposible. Dice que es la apuesta más riesgosa. Y el operador solo no tiene margen para apuestas riesgosas. No hay equity que diluir. No hay payroll que recortar. No hay departamento que reestructurar. Hay una persona que si se quema, el negocio se apaga.

No Necesitas Más Resiliencia. Necesitas Mejores Señales.

El operador solo que sobrevive no es el que trabaja más horas. Es el que lee las señales de burnout antes de que el silencio se convierta en parálisis.

Mapea tu ratio de invisibilidad esta semana. Si supera el 70%, no te preguntes "cómo trabajo menos". Pregúntate "cómo consigo una señal externa en los próximos 7 días".

El problema del operador solo no es de capacidad. No es de motivación. No es de disciplina.

El problema del operador solo es de arquitectura de trabajo.

Y la arquitectura de trabajo que te salva no es la que optimiza productividad. Es la que optimiza señales.

Porque sin señales, no sabes si existes. Y sin saber si existes, no hay horas de trabajo que te mantengan en pie.

*El burnout del operador solo no se cura con descanso. Se cura con evidencia de que lo que haces importa a alguien más. *

Lee el artículo completo en brianmenagomez.com

Más sobre mis servicios en brianmenagomez.com

Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF

Estás usando Apify mal.

Si piensas que es una herramienta de scraping con esteroides, te estás perdiendo el 90% de lo que la plataforma puede hacer.

*Apify no es scraping-as-a-service. Es un sistema operativo de automatización para la web. *

Mira los números. La plataforma tiene más de 1.000 Actores pre-construidos en su Store. Crawlee, su librería open-source, supera las 12.000 estrellas en GitHub. Y sin embargo, la mayoría de los desarrolladores abre la web, ejecuta un Actor de Google Maps, descarga un CSV y cree que ya lo ha visto todo.

No lo has visto.

Lo que Apify ofrece realmente es un runtime serverless para el navegador — como AWS Lambda, pero con un Chromium completo, colas de peticiones que sobreviven a caídas, almacenamiento persistente, y un ecosistema de componentes que puedes encadenar como piezas de Lego.

El scraping es casi incidental a la infraestructura que hay debajo.

---

El Problema: Tratas Apify Como un Scrapy con UI

La mayoría de los desarrolladores viene de herramientas como Scrapy o BeautifulSoup. Son librerías Python que ejecutas localmente. O las metes en un contenedor. O las despliegas en una VPS con cronjobs escritos a mano.

Y funciona. Para proyectos pequeños.

El problema llega cuando tu scraper necesita sobrevivir a un crash, reanudarse desde donde lo dejó, rotar proxies sin exponer tu IP, escalar a cientos de URLs sin que se te caiga el servidor, o ejecutarse cada hora sin que tengas que estar pendiente.

❌ Enfoque tradicional: Escribes un script con Playwright. Lo guardas. Configuras un cron en tu VPS. Te olvidas. A las 3 de la mañana el sitio cambia su DOM, tu script falla, y te enteras cuando el cliente se queja.

✅ Enfoque Apify: Construyes un Actor. Usas Crawlee. Configuras una Request Queue. Programas un schedule. El actor se ejecuta, reintenta las peticiones fallidas, rota proxies automáticamente, guarda los resultados en un Dataset, y te llama por webhook si algo va mal.

La diferencia no es técnica. Es filosófica. Pasas de gestionar scripts a gestionar workflows.

---

La Evidencia: Por Qué Apify Es un Runtime, No un Scraper

Miremos la arquitectura.

Apify no te da un navegador y te dice "venga, scrapea". Te da:

• Request Queues: Colas de peticiones con estado. Si tu Actor se cae a mitad de ejecución, al reiniciarse retoma desde la última petición completada. No pierdes trabajo.

• Datasets: Almacenamiento persistente. Cada resultado que guardas queda disponible en la plataforma. Lo puedes exportar a JSON, CSV, Excel, o conectarlo directamente a Google Sheets, S3, o Dropbox.

• Key-value stores: Para guardar estado intermedio, configuraciones, o ficheros grandes.

• Proxy rotation automática: Con proxies de datacenter, residenciales, y SERP. La plataforma gestiona la rotación de user agents y huellas del navegador.

• Scheduling + Webhooks: Puedes programar ejecuciones recurrentes y recibir notificaciones cuando terminen.

Todo esto corre sobre Puppeteer y Playwright. Pero Apify añade la capa de gestión que convierte un script en un sistema.

Y luego está Crawlee, su librería open-source. Crawlee resuelve los problemas duros del scraping moderno: rotación de proxies, gestión de sesiones, evasión de huellas de navegador, y colas de peticiones — todo en una API limpia que funciona con Playwright, Puppeteer, o incluso Cheerio para páginas estáticas.

*Crawlee no es un wrapper. Es un framework que te ahorra meses de reverse-engineering contra Cloudflare y DataDome. *

---

El Ecosistema: El Poder de Componer Actores

El Actor Store de Apify tiene más de 1.000 componentes pre-construidos. Y el 90% de los usuarios solo ejecuta uno cada vez.

Ese es el error.

*El killer feature de Apify no son los Actores individuales. Es la capacidad de encadenarlos. *

Mira este flujo real:

1. Ejecutas el Actor "Google Search Results Scraper" para buscar "fontaneros emergencia Madrid"

2. El resultado se pasa al Actor "HTML to Markdown" para limpiar el contenido

3. Ese markdown se envía al Actor "OpenAI ChatGPT" para generar un resumen

4. El resumen se guarda en un Dataset que alimenta tu panel de control interno

Todo esto ocurre sin que escribas una línea de código de integración. Los Actores se comunican a través de la API de Apify. Tú solo defines el flujo.

Para el dueño de una agencia digital española que quiere monitorizar a sus competidores, esto es oro. Configuras un schedule que scrapea los precios de tus competidores cada hora, los transforma, los analiza con IA, y los mete en tu dashboard — todo sin un solo servidor.

---

El Patrón de 5 Capas para Automatización Web con Apify

Vamos al grano. Aquí tienes el framework que uso para sacar el máximo partido a Apify. Lo llamo El Patrón de 5 Capas para Automatización Web con Apify.

1. Capa de Extracción: Crawlee + Request Queue

No empieces con un script. Empieza con Crawlee y una Request Queue.

```typescript

import { Crawlee, PlaywrightCrawler, RequestQueue } from 'crawlee';

const requestQueue = await RequestQueue.open('mi-scraper');

await requestQueue.addRequest({

url: 'https://ejemplo.com/productos',

userData: { categoria: 'electronica' }

});

const crawler = new PlaywrightCrawler({

requestQueue,

maxRequestsPerCrawl: 100,

maxConcurrency: 10,

async requestHandler({ page, request, pushData }) {

const titulo = await page.title();

const precio = await page.textContent('.precio');

await pushData({

url: request.url,

titulo,

precio,

timestamp: new Date().toISOString()

});

},

failedRequestHandler({ request }) {

console.log(`Falló: ${request.url} — se reintentará`);

}

});

await crawler.run();

```

La clave aquí es la `Request Queue`. Si el crawler se cae a mitad, al reiniciarse retoma desde la última URL completada. No pierdes nada.

2. Capa de Proxy: Configuración Geográfica

Para sitios españoles como El Corte Inglés, PcComponentes o Mercado Libre Spain, necesitas proxies residenciales españoles. Los proxies de datacenter genéricos te van a bloquear en minutos.

```typescript

const crawler = new PlaywrightCrawler({

proxyConfiguration: {

groups: ['RESIDENTIAL'],

countryCode: 'ES',

fallbackGroups: ['DATACENTER']

},

// ...

});

```

La configuración `countryCode: 'ES'` hace que Apify use IPs residenciales de proveedores españoles. El `fallbackGroups` asegura que si se acaban las IPs españolas, el crawler sigue funcionando con datacenter.

3. Capa de Transformación: El Actor Intermedio

Una vez que tienes los datos, no los dejes crudos. Pásalos por un Actor de transformación.

```typescript

// Después de scrapear, llamas a la API de Apify para encadenar otro Actor

const run = await apifyClient

.actor('apify/html-to-markdown')

.call({

html: datosCrudos

});

// El resultado del segundo Actor está disponible en su Dataset

const markdown = await apifyClient

.dataset(run.defaultDatasetId)

.listItems();

```

Este paso es el que la mayoría omite. Scrapean y ya. Pero la magia está en transformar los datos en el mismo flujo.

4. Capa de Persistencia: Dataset + Integraciones

No guardes los datos en un fichero local. Usa el Dataset de Apify y conéctalo a tu destino final.

```typescript

// Guardas en el Dataset

await pushData({

competidor: 'electronica-madrid-sl',

producto: 'Portátil XYZ',

precio: 899,

disponibilidad: 'en-stock',

fecha: new Date().toISOString()

});

// Luego configuras una integración en Apify:

// Dataset → Webhook → tu API → Google Sheets

```

Apify te permite conectar el Dataset directamente a Google Sheets, S3, Dropbox, o enviarlo por webhook a tu propio backend. No necesitas un script de exportación.

5. Capa de Orquestación: Schedules + Webhooks

Aquí es donde el sistema cobra vida. Configuras un schedule y un webhook, y tu scraper se convierte en un monitor.

```typescript

// Pseudocódigo de configuración vía API

await apifyClient.schedules().create({

name: 'precios-competidores',

cronExpression: '0 ', // Cada hora

actions: [

{

type: 'RUN_ACTOR',

actorId: 'tu-actor-de-scraping',

input: { categoria: 'portatiles' }

}

]

});

// Webhook que se dispara al completarse

await apifyClient.webhooks().create({

eventTypes: ['ACTOR.RUN.SUCCEEDED'],

condition: { actorId: 'tu-actor-de-scraping' },

requestUrl: 'https://tu-api.com/webhook/apify',

payloadTemplate: JSON.stringify({

datasetId: '{{resource.defaultDatasetId}}',

status: '{{resource.status}}'

})

});

```

Ahora tienes un sistema que scrapea cada hora, guarda los resultados, y te avisa cuando termina. Sin VPS. Sin cronjobs locales. Sin DevOps.

---

Pero... ¿Y el Vendor Lock-In?

Vale. Te oigo.

"Apify es vendor lock-in. Si mañana cierran, pierdo todo."

Vamos a desmontar eso.

Crawlee es MIT license. Puedes ejecutarlo localmente sin la plataforma de Apify. Los Actors se pueden exportar como imágenes Docker. Los Datasets se exportan a JSON o CSV.

*El riesgo de lock-in es menor que con AWS Lambda, porque la librería core es portable. *

Lo que pagas en Apify es la gestión: las proxies, el scheduling, el almacenamiento, las integraciones. Si necesitas moverte, te llevas el código. Te dejas la infraestructura gestionada.

Para un negocio que necesita datos fiables a las 9 de la mañana todos los días, el coste de la plataforma se paga solo con no tener que contratar a un DevOps para que gestione scrapers.

---

Y el Tema Legal del Scraping

El scraping no es ilegal. Lo ilegal es saltarse los términos de servicio de forma maliciosa, sobrecargar servidores, o usar datos protegidos por copyright.

Apify proporciona herramientas para cumplir con robots.txt y configurar rate limiting. Pero la responsabilidad de lo que scrapeas es tuya.

*Apify es una plataforma de infraestructura. No decide lo que scrapeas. Te da los mazos. Tú eliges la pared. *

Usa la plataforma para construir cosas útiles. Monitoriza a tus competidores de forma ética. No satures los servidores. Respeta el robots.txt.

---

Lo Que Viene

El futuro de Apify no es el scraping. Es la automatización web completa.

Cada vez más empresas están usando Actores no para extraer datos, sino para llenar formularios, hacer pruebas de UI, sincronizar datos entre plataformas, o ejecutar flujos de trabajo complejos que requieren un navegador real.

Para el operador de una agencia pequeña en España o LATAM, eso significa una cosa: puedes construir sistemas que antes requerían un equipo de infraestructura con un ordenador portátil y una cuenta de Apify.

El 90% de los desarrolladores usa Apify como un scraper. El 10% que lo usa como un runtime serverless está construyendo cosas que el resto ni siquiera imagina.

*La pregunta no es si Apify sirve para scrapear. La pregunta es qué más puedes construir cuando dejas de pensar en extracción y empiezas a pensar en automatización. *

---

Resumen

| Idea | Por Qué Importa |

|------|----------------|

| Apify es un runtime serverless, no un scraper | Gestiona ejecución, estado, y almacenamiento por ti |

| Crawlee resuelve evasión anti-bot | Proxy rotation, fingerprints, sesiones — todo integrado |

| El Actor Store permite componer flujos | Encadena Actores: scrapea → transforma → analiza → almacena |

| Request Queues dan resiliencia | Si tu Actor falla, retoma donde lo dejó |

| Schedules + Webhooks crean monitores | Tu scraper se convierte en un pipeline continuo |

El que scrapea con Requests y BeautifulSoup compite con scripts. El que usa Apify como runtime compite con equipos enteros.

*Elige tu categoría. *

Lee el artículo completo en brianmenagomez.com

Más sobre mis servicios en brianmenagomez.com

Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF

En secuencia. Uno detrás de otro. Esperando a que cada llamada termine para empezar la siguiente.

*Y funcionan. Pero funcionan mal, lento, y con un coste de contexto que se come tu presupuesto de tokens. *

El 90% de las implementaciones tratan el agent loop como una `lista de tareas` secuencial.

El problema es que deberían tratarlo como un `grafo de dependencias`.

No es teoría. Es la diferencia entre un agente que tarda 45 segundos en dar una respuesta vs uno que tarda 8. Es la diferencia entre un contexto de 12.000 tokens vs uno de 4.000. Es la diferencia entre un agente que entra en bucle infinito y uno que termina limpiamente.

La comunidad cree que el problema de los AI Agents es el modelo. Mejor LLM → mejor agente.

O la conexión a herramientas. MCP, function calling, APIs.

*La realidad: ambos problemas están resueltos. El cuello de botella real es la orquestación. *

Cómo decides qué tool call ejecutar cuándo, en qué orden, y en paralelo.

---

El Patrón Que Llevamos Décadas Resolviendo (y Que Hemos Olvidado)

La ironía es que esto no es nuevo en computación.

El patrón de 3 fases que te voy a enseñar — Análisis → DAG → Ejecución topológica — es el mismo que usan los build systems como Make, Bazel o Turborepo.

Llevamos décadas resolviendo el problema de paralelizar tareas con dependencias.

*Y al llegar a los AI Agents, lo hemos olvidado. *

Un agent loop secuencial es equivalente a compilar un proyecto con un solo core en 2026.

Tiene sentido cuando tienes 2-3 herramientas secuenciales. Pero cuando tu agente ejecuta 5+ tool calls por turno con múltiples herramientas independientes, el loop plano se convierte en tu cuello de botella más caro.

---

Los 3 Problemas del Loop Secuencial Plano

Antes de ver la solución, entendamos qué se rompe cuando ejecutas tool calls en secuencia plana.

1. Latencia desperdiciada

Tienes 5 tool calls. Las primeras 3 son independientes entre sí: buscar tendencias en Google Trends, analizar competidores en Crunchbase, extraer reviews de Trustpilot. Ninguna necesita el resultado de la otra.

Con un loop secuencial: llamada 1 → esperar → llamada 2 → esperar → llamada 3 → esperar.

*Has perdido 2/3 del tiempo en espera que podrías haber paralelizado. *

2. Pérdida de contexto entre llamadas

Cada tool call devuelve datos que se inyectan en el prompt del LLM en la siguiente iteración.

Con 5-10 tool calls secuenciales, el contexto se duplica o triplica con datos intermedios que ya no necesitas. El LLM tiene que procesar información irrelevante, aumenta el coste de tokens, y la calidad de las respuestas se degrada.

El problema más silencioso de los agents secuenciales no es la velocidad. Es la degradación del contexto.

3. Bucles infinitos

Cuando un agente ejecuta tool calls en un loop plano y una llamada devuelve un resultado inesperado, el LLM no tiene suficiente información para decidir si debe parar o seguir.

No es culpa del LLM. Es culpa de la orquestación.

Con un grafo de dependencias, tienes un estado explícito del progreso: sabes qué nodos se completaron, cuáles fallaron, y cuáles están pendientes. Puedes detectar bucles (mismo nodo ejecutándose repetidamente) y aplicar políticas de terminación claras.

---

❌/✅ El Anti-Patrón vs El Patrón Real

❌ Lo que el 90% hace: Loop secuencial plano

```python

Anti-patrón: ejecución secuencial plana

El 90% de los agents en GitHub hacen esto

def agent_loop_secuencial(prompt, tools):

messages = [{"role": "user", "content": prompt}]

while True:

response = llm.chat(messages)

tool_calls = extract_tool_calls(response)

if not tool_calls:

return response.content

for tool_call in tool_calls:

UNO DETRÁS DE OTRO ⚠️

result = execute_tool(tool_call)

messages.append({

"role": "tool",

"tool_call_id": tool_call.id,

"content": result

})

Siguiente iteración del bucle — el LLM recibe TODO el contexto acumulado

```

Este código funciona. Para 2-3 tool calls secuenciales, es suficiente.

*Pero en cuanto llegas a 5+ llamadas, el coste de contexto explota y la latencia se triplica. *

✅ Lo que deberías hacer: Grafo de dependencias con ejecución topológica

```python

Patrón correcto: orquestación basada en grafo de dependencias

from collections import deque

from concurrent.futures import ThreadPoolExecutor, as_completed

class ToolCallNode:

def __init__(self, tool_call, deps=None):

self.tool_call = tool_call

self.dependencies = deps or [] # IDs de nodos de los que depende

self.result = None

self.status = "pending" # pending | running | completed | failed

class DependencyGraph:

def __init__(self):

self.nodes = {} # node_id -> ToolCallNode

self.adjacency = {} # node_id -> [dependent_node_ids]

def add_node(self, node_id, tool_call, deps=None):

self.nodes[node_id] = ToolCallNode(tool_call, deps)

self.adjacency[node_id] = []

for dep_id in (deps or []):

if dep_id not in self.adjacency:

self.adjacency[dep_id] = []

self.adjacency[dep_id].append(node_id)

def get_ready_nodes(self):

"""Nodos sin dependencias pendientes — candidatos a ejecución paralela"""

ready = []

for node_id, node in self.nodes.items():

if node.status != "pending":

continue

all_deps_done = all(

self.nodes[dep].status == "completed"

for dep in node.dependencies

)

if all_deps_done:

ready.append(node_id)

return ready

def execute_graph(graph, max_workers=4):

"""Ejecuta el grafo por niveles — cada nivel en paralelo"""

with ThreadPoolExecutor(max_workers=max_workers) as executor:

while any(n.status == "pending" for n in graph.nodes.values()):

ready = graph.get_ready_nodes()

if not ready:

raise RuntimeError("Deadlock detected: circular dependency")

futures = {}

for node_id in ready:

node = graph.nodes[node_id]

node.status = "running"

future = executor.submit(execute_tool, node.tool_call)

futures[future] = node_id

for future in as_completed(futures):

node_id = futures[future]

node = graph.nodes[node_id]

try:

node.result = future.result()

node.status = "completed"

except Exception as e:

node.status = "failed"

Propagación selectiva: solo fallan los dependientes

propagate_failure(graph, node_id, e)

```

---

El Framework de 3 Fases para Orquestación de Tool Calls

Llamémoslo como es: El Patrón de Orquestación en 3 Fases. No es complejo. Es estructurado. Y cada fase resuelve un problema concreto del loop secuencial.

Fase 1: Análisis de dependencias

Cuando el LLM devuelve múltiples tool calls, no las ejecutes inmediatamente.

Primero, analiza los parámetros de entrada de cada una para identificar dependencias de datos entre ellas.

Pregunta clave: ¿La tool B necesita el output de la tool A para ejecutarse?

```python

Fase 1: Analizar dependencias entre tool calls

def analyze_dependencies(tool_calls):

"""

Analiza los parámetros de entrada de cada tool call

para identificar dependencias de datos

"""

dependency_map = {tc.id: [] for tc in tool_calls}

tool_outputs = {} # Mapa de tool_call_id -> {campos de salida}

for tc in tool_calls:

for param_name, param_value in tc.parameters.items():

¿El valor del parámetro hace referencia al output de otra tool?

if isinstance(param_value, str) and param_value.startswith("$"):

ref_tool_id = param_value.split(".")[0].replace("$", "")

if ref_tool_id in tool_outputs:

dependency_map[tc.id].append(ref_tool_id)

return dependency_map

```

En la práctica, esta fase suele ser más sencilla: el propio LLM puede etiquetar las dependencias si se lo pides explícitamente en el system prompt. Pero tener el análisis programático como respaldo evita que el LLM se equivoque.

Fase 2: Construcción del DAG

Genera un grafo dirigido acíclico donde los nodos son tool calls y las aristas son dependencias.

Identifica los nodos sin dependencias (fuentes) como candidatos a ejecución paralela inmediata.

```python

Fase 2: Construir el DAG

def build_dag(tool_calls, dependency_map):

graph = DependencyGraph()

Validar que no haya dependencias circulares

(el LLM a veces genera bucles)

if has_cycles(dependency_map):

raise ValueError("Circular dependency detected in tool calls")

for tc in tool_calls:

deps = dependency_map.get(tc.id, [])

graph.add_node(tc.id, tc, deps=deps)

return graph

```

El check de ciclos es importante. El LLM puede generar tool calls que se refieran unas a otras creando un bucle. Detectarlo en la Fase 2 evita que el agente se cuelgue.

Fase 3: Ejecución con planificación topológica

Ejecuta los nodos fuente en paralelo, recolecta resultados, desbloquea nodos dependientes, y repite hasta completar el grafo.

*Cada iteración del bucle principal ejecuta UN NIVEL completo del grafo, no UNA tool call. *

```python

Fase 3: Ejecutor con planificación topológica

def orchestrator_loop(prompt, tools):

messages = [{"role": "user", "content": prompt}]

while True:

response = llm.chat(messages)

tool_calls = extract_tool_calls(response)

if not tool_calls:

return response.content

Fase 1 + 2: Analizar y construir grafo

dep_map = analyze_dependencies(tool_calls)

graph = build_dag(tool_calls, dep_map)

Fase 3: Ejecutar por niveles

level_results = execute_graph(graph)

Solo inyectar los resultados relevantes

(no todo el historial de llamadas)

concise_context = summarize_results(level_results)

messages.append({

"role": "user",

"content": f"Resultados de herramientas:\n{concise_context}"

})

```

---

Manejador de Errores Inteligente: Propagar Solo lo Necesario

El beneficio más infravalorado del grafo de dependencias es el manejo de errores.

En un loop secuencial, si la tool call #3 falla, tienes dos opciones: reintentar todo desde el principio o ignorar el error y seguir. Ambas son malas.

Con un grafo de dependencias, puedes propagar el fallo solo a los nodos dependientes:

```python

def propagate_failure(graph, failed_node_id, error):

"""Propaga el fallo solo a los nodos que dependen del nodo fallido"""

queue = deque([failed_node_id])

visited = set()

while queue:

current = queue.popleft()

if current in visited:

continue

visited.add(current)

Marcar como fallido

if current != failed_node_id:

graph.nodes[current].status = "failed"

graph.nodes[current].result = {"error": str(error)}

Propagar a dependientes

for dependent_id in graph.adjacency.get(current, []):

if dependent_id not in visited:

queue.append(dependent_id)

```

Esto significa que si una tool falla, solo se detienen las que necesitaban su resultado. El resto del grafo sigue ejecutándose. El agente puede tomar decisiones parciales con los datos que sí consiguió.

---

Caso Real: Agente de Investigación de Mercado en 12 Segundos

Trabajo con un agente que investiga mercados. Necesita:

1. Buscar tendencias en Google Trends

2. Analizar 5 competidores en Crunchbase

3. Extraer reviews de Trustpilot

4. Sintetizar un informe

Con ejecución secuencial:

• 8-12 llamadas secuenciales

• ~45 segundos de latencia total

• Contexto masivo con datos intermedios de cada paso

Con grafo de dependencias:

• Fase 1: Ejecuta (1) y (2) en paralelo — 3 source calls simultáneas

• Fase 2: Ejecuta (3) y (4) con datos de fase 1

• Total: ~12 segundos

• Contexto: 40% menos tokens porque solo pasas datos relevantes entre niveles

*La diferencia no es incremental. Es estructural. *

---

Cuándo Usar Cada Patrón (Sé Honesto)

No te voy a vender que el grafo de dependencias es siempre la solución.

Usa loop secuencial plano si:

• Tu agente ejecuta 2-3 tool calls por turno

• Todas las herramientas son estrictamente secuenciales (cada una necesita el resultado de la anterior)

• El tiempo de respuesta no es crítico

Usa el Patrón de Orquestación en 3 Fases si:

• Tu agente ejecuta 5+ tool calls por turno

• Tienes herramientas independientes que se pueden paralelizar

• La latencia importa (UX en tiempo real, asistentes conversacionales, automatización)

• El coste de contexto empieza a dispararse

El umbral está claro: 5 tool calls. Por debajo, el overhead del grafo no compensa. Por encima, el loop secuencial te está costando tiempo, tokens, y calidad.

---

¿Y MCP? No Resuelve Esto

MCP resuelve el problema de "cómo conecto mi agente a 20 APIs diferentes". Es un problema de protocolo.

Pero una vez que tienes 20 herramientas conectadas, el problema pasa a ser "en qué orden las llamo y cuáles puedo llamar simultáneamente".

*MCP no toca ese problema. La orquestación es el layer que falta entre MCP y el agent loop. *

Si solo implementas MCP y dejas el agent loop secuencial, tienes herramientas ilimitadas conectadas a un pipeline que las ejecuta una a una. Como tener 20 carriles en una autopista que se reduce a un solo carril en cada peaje.

---

Lo Que Te Llevas

El 90% de los AI Agents en GitHub ejecutan tool calls secuenciales. Y funcionan. Pero funcionan mal, lento, y caros.

El salto de calidad real no está en el modelo. No está en MCP. Está en cómo orquestas las llamadas.

Tres fases: analiza dependencias, construye el DAG, ejecuta por niveles topológicos. Cada fase resuelve un problema concreto del loop secuencial.

La herramienta para construir el agente es secundaria. La arquitectura de orquestación es primaria.

*El mejor modelo con mala orquestación pierde siempre contra un modelo decente con buena orquestación. *

La próxima vez que construyas un AI Agent, no empieces por el LLM. Empieza por el grafo.

Lee el artículo completo en brianmenagomez.com

Más sobre mis servicios en brianmenagomez.com

Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF

Crees que tu problema es que no encuentras el producto adecuado. Que si investigas un nicho más a fondo,validas una necesidad real, y ejecutas el build perfecto, los usuarios llegarán solos.

*Te has equivocado de diagnóstico.*

La decisión más cara que tomarás como solo-operator no es qué construir. Es qué no comprar.

La sabiduría convencional del ecosistema indie repite el mismo mantra desde 2010: "encuentra un problema, construye una solución, valida con usuarios reales". Asume que construir es la parte difícil. Que la ejecución técnica es el cuello de botella.

Los datos del fragmento de solo_operator_economics cuentan otra historia.

Comprar un negocio online con tracción existente externaliza el riesgo de product-market fit. El negocio ya tiene audiencia. Ya tiene tráfico. Ya tiene clientes que pagan. El riesgo de construir algo que nadie quiere — el riesgo existencial del 90% de los startups — desaparece de tu ecuación.

La contrapartida: internalizas el riesgo de integración operativa. Migrar hosts. Consolidar APIs. Estandarizar procesos. Retener clientes durante la transición. Eso es un problema técnico y operativo que una sola persona competente puede resolver metódicamente.

Un producto sin audiencia es un museo. Una audiencia sin producto es un negocio reparable.

---

El Mito del 'Build It and They Will Come'

La mayoría de recursos para solo-operators empiezan igual: paso 1, encuentra un problema. Paso 2, construye una solución. Paso 3, valida.

Este orden asume tres cosas falsas:

❌ Que construir es la parte difícil. La evidencia del fragmento sugiere lo contrario: la distribución (tracción existente) es el activo más valioso, y el producto se puede integrar, mejorar o incluso reemplazar después.

❌ Que la validación es un evento puntual. Construyes, lanzas, y si hay tracción, sigues. La realidad es que la validación es un proceso continuo que requiere audiencia para funcionar.

❌ Que una persona sola puede validar mercado desde cero. Un solo-operator tiene capacidad limitada para hacer outreach, conseguir entrevistas, y generar tracción inicial sin una base existente.

El enfoque correcto invierte el orden:

✅ Adquiere o construye distribución primero. Audiencia, tráfico SEO, lista de emails, red de afiliados. Ese es tu activo principal.

✅ El producto es secundario y mejorable. Si la distribución funciona, puedes iterar el producto con usuarios reales que ya te conocen.

✅ El riesgo operativo es manejable por una persona. Migrar tecnología, estandarizar procesos, retener clientes — eso se resuelve con metodología, no con suerte.

---

El Riesgo Que No Ves: Distribución ≠ Producto

El fragmento establece una dicotomía clave: externalizar product-market fit vs. internalizar integración operativa.

El solo-operator debe elegir qué tipo de riesgo está mejor equipado para gestionar.

Riesgo de product-market fit (alto): No sabes si existe mercado para lo que construyes. No sabes si los clientes pagarán. No sabes si tu solución es mejor que las alternativas. Este riesgo es cualitativo, existencial, y no se resuelve con código.

Riesgo de integración operativa (bajo): Sabes que el mercado existe porque el negocio ya vende. Sabes que la audiencia responde porque ya tiene tráfico. El problema es migrar, consolidar, y optimizar. Este riesgo es técnico, secuencial, y se resuelve con metodología.

Comprar un negocio con tracción no es "tomar atajos". Es reconocer que la distribución es un problema cualitativamente diferente al producto.

La distribución requiere construcción de autoridad, relaciones, SEO histórico, enlaces entrantes, y confianza acumulada que no se replica con código.

Un producto se puede refactorizar en semanas. Una audiencia tarda años en construirse.

Comprar un negocio existente es comprar tiempo geológico.

---

El Marco de Decisión: Las 5 Fases de 'Distribución Primero'

He ejecutado esta estrategia con tres negocios diferentes. El patrón es siempre el mismo. Aquí está el framework en cinco fases:

Fase 1: Auditar marketplaces de compraventa de negocios

No mires tecnología. No mires producto. Mira métricas de tráfico y audiencia.

Busca en:

• MicroAcquire (negocios digitales globales)

• Flippa (dominios con tráfico residual)

• Adquisiciones locales en España (foros de autónomos, grupos de WhatsApp sectoriales, redes de contacto directo)

• Acquire.com (SaaS con ingresos recurrentes)

El filtro principal: ¿el activo principal es la distribución o el producto?

Si el negocio tiene 5.000 visitas mensuales orgánicas pero el producto es un WordPress cutre con un plugin mal escrito — ese es tu candidato. La distribución vale. El producto se cambia.

Si el negocio tiene un producto impecable pero cero tráfico orgánico y la adquisición depende de anuncios pagados del fundador actual — huye. Estás comprando un problema de distribución, que es el que no sabes resolver.

Fase 2: Evaluar el riesgo de integración operativa

Antes de comprar, mapea:

• Dependencias técnicas: hosting, dominio, APIs, servicios externos

• Procesos manuales: ¿cuánto del negocio depende del fundador original haciendo cosas a mano?

• Proveedores: ¿hay contratos, cuentas compartidas, acceso delegado?

• Canales de adquisición: SEO, email, afiliados, redes sociales — ¿cuál es el canal dominante?

El objetivo no es eliminar el riesgo operativo. Es cuantificarlo.

Si el negocio tiene 3 dependencias técnicas y 2 procesos manuales que puedes automatizar en una semana, el riesgo de integración es bajo. Si has de migrar 15 APIs, reescribir el frontend, y retener clientes durante un cambio de dominio, el riesgo es medio-alto pero sigue siendo manejable por una sola persona con metodología.

Fase 3: Calcular el 'coste de migración de audiencia'

Esta es la pregunta clave que nadie se hace:

Si el producto es deficiente pero la audiencia es sólida, ¿cuánto esfuerzo tomaría reemplazar la tecnología subyacente sin perder tráfico?

Pasos:

1. Identifica las URLs que generan tráfico orgánico (Google Search Console, Ahrefs, SEMrush)

2. Mapea las redirecciones necesarias si cambias de dominio o CMS

3. Calcula el tiempo de migración: contenido, templates, funcionalidades críticas

4. Estima el riesgo de pérdida de tráfico durante la transición

En mi experiencia, migrar un negocio con 2.000-5.000 visitas mensuales a un stack moderno (Next.js + Vercel + headless CMS) lleva entre 2 y 4 semanas si el contenido es principalmente estático. El tráfico no se pierde si mantienes las URLs y configuras las redirecciones correctamente.

Fase 4: Priorizar negocios donde la distribución sea el activo principal

Tu checklist de priorización:

• ✅ Tráfico orgánico recurrente (no campañas de un mes)

• ✅ Lista de emails activa (no comprada, no caducada)

• ✅ Red de afiliados o referidos establecida

• ✅ SEO histórico con backlinks reales

• ✅ Marca reconocida en su nicho (aunque sea pequeño)

Si el negocio tiene tres de estos cinco, compra aunque el producto apeste. El producto se arregla. La distribución no se construye en un mes.

Fase 5: Ejecutar la integración en tres fases

Fase A: Mantener la distribución existente. No toques nada que genere tráfico. No cambies URLs. No migres dominios. No rediseñes la página principal. Lo primero es asegurar que el grifo de tráfico no se cierra.

Fase B: Optimizar el producto. Una vez que la distribución es estable, refactoriza. Migra a un stack mantenible. Automatiza procesos manuales. Mejora el onboarding. Añade funcionalidades que los usuarios llevan pidiendo meses.

Fase C: Expandir canales. Solo cuando el producto es sólido y la distribución original está asegurada, considera nuevos canales: SEO adicional, partnerships, contenido nuevo, integraciones con otras herramientas.

---

Objeciones Reales (Y Por Qué No Deberían Pararte)

*"Comprar un negocio requiere capital que no tengo."*

Objeción válida. Pero el principio de distribución primero se aplica igual si construyes la audiencia antes que el producto. Empieza con un newsletter. Publica contenido SEO en un nicho concreto durante 6 meses. Construye una lista de emails. Cuando tengas 500 suscriptores comprometidos, entonces construye el producto. La audiencia es tu validación y tu canal de lanzamiento.

*"Si el producto es malo, la audiencia se irá aunque tenga tráfico."*

Objeción parcialmente cierta pero incompleta. La evidencia muestra que la inercia del usuario es real: la gente vuelve a herramientas que ya conoce y tiene configuradas, incluso si existen alternativas superiores. El umbral de "producto suficientemente bueno" es mucho más bajo cuando ya tienes distribución que cuando empiezas de cero.

Además, si la audiencia viene por contenido (no por producto), migrar a un producto mejor solo retiene y expande. El contenido es el imán; el producto es la puerta.

*"Los buenos negocios con tracción no se venden, o si se venden, son demasiado caros."*

Objeción basada en un sesgo de supervivencia. Ves los casos que se venden caros y asumes que todos son así. La realidad: muchos negocios con buena distribución se venden porque sus dueños originales se quemaron, perdieron interés, o no tienen tiempo para mantenerlos.

El riesgo de integración operativa disuade a compradores. Los fondos de inversión no quieren negocios que requieran trabajo operativo manual. Las agencias no quieren migraciones técnicas complejas. Eso crea oportunidades para solo-operators dispuestos a hacer el trabajo que otros evitan.

---

Por Qué el Contexto Español Es tu Ventaja

El mercado de adquisición de negocios digitales en España es menos competitivo que en USA. Los grandes fondos no miran negocios con facturación en español. Las agencias grandes no quieren lidiar con gestorías, autónomos, y regulación local.

Un solo-operator español tiene ventaja comprando negocios con audiencia hispanohablante donde nadie más compite.

Pero necesitas navegar aspectos locales que el fragmento no cubre:

• Traspaso de dominio y propiedad intelectual

• Contratos con proveedores españoles

• Gestión de autónomos y IVA en la transmisión

• Retención de clientes durante el cambio de titularidad

Eso es parte del riesgo de integración operativa. Y es exactamente el tipo de riesgo que una sola persona competente puede resolver.

---

El Producto Es un Problema de Ingeniería. La Distribución Es un Problema de Tiempo.

Nunca ha sido más barato construir producto. Vercel te da deploy en segundos. Supabase te da base de datos escalable. Claude Code escribe el 60% del código. Los frameworks modernos eliminan la fricción técnica.

Lo que sigue siendo caro — en tiempo, en energía, en relaciones — es la distribución.

El fragmento de solo_operator_economics lo deja claro: el solo-operator no debería apostar su recurso más escaso (tiempo) a construir audiencia desde cero cuando puede adquirirla externalizando el riesgo de product-market fit.

La próxima vez que te sientes a escribir código para un proyecto nuevo, pregúntate:

¿Este código está resolviendo un problema de producto o un problema de distribución?

Si es lo segundo, estás perdiendo el tiempo. Compra la distribución. Construye el producto después.

Lee el artículo completo en brianmenagomez.com

Más sobre mis servicios en brianmenagomez.com

Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF

Cada vez que conectas un LLM a una base de datos, a una API o a un fichero, estás escribiendo código que alguien ya escribió.

*El problema no es que funcione. Es que no escala. *

El 90% de los desarrolladores aborda la integración con IA igual que en 2023: un endpoint custom, un system prompt con instrucciones, y una oración de "por favor devuelve JSON válido".

Funciona para un tool. Para dos. Para un prototype.

*Pero cuando tienes 5 herramientas, 3 proveedores de IA, y necesitas auditar cada llamada, tu castillo de naipes se derrumba. *

MCP (Model Context Protocol) no es otro estándar más. Es el primer intento real de resolver lo que llamo *el problema USB-C de la IA*: un conector universal para que cualquier modelo hable con cualquier herramienta, con seguridad explícita, sin código repetido.

Y la mayoría lo está usando mal.

---

El Error: Crees que MCP es para "Dar Acceso" a la IA

La creencia popular: "MCP permite que la IA acceda a mis herramientas y datos."

❌ Error. Eso es lo que parece. Pero no es lo que hace.

✅ Realidad: MCP te obliga a definir *explícitamente qué recursos, qué tools y qué prompts puede tocar el modelo. No es una puerta abierta. Es una lista blanca con candado*.

El valor real de MCP no es la conectividad. Es el control de fronteras.

Cuando construyes una integración ad-hoc con fetch() y un system prompt, el modelo puede — en teoría — llamar a cualquier endpoint, pasar cualquier parámetro, intentar cualquier cosa. La seguridad depende de que el prompt esté bien escrito. Depende de que el modelo no alucine una llamada que no debería hacer.

*Eso no es seguridad. Eso es esperanza. *

Con MCP, defines tres primitivas:

• Resources — datos que el modelo puede *leer* (ficheros, tablas, APIs)

• Tools — funciones que el modelo puede *ejecutar* (con tipos, descripciones, validación)

• Prompts — plantillas reutilizables que el modelo puede *cargar*

Todo pasa por un único servidor MCP. Ese servidor es tu punto de control. Ahí auditas, limitas, validas.

La obsesión con "agentes autónomos" os ha hecho olvidar lo básico: *antes de que un agente sea autónomo, tiene que estar controlado. *

---

El Problema Real: N × M No Escala

Antes de MCP, cada integración seguía este patrón:

1. Eliges un proveedor de IA (OpenAI, Anthropic, Google)

2. Implementas function calling específico para ese proveedor

3. Defines los schemas de los tools en el formato que ese modelo entiende

4. Escribes el código de autorización, error handling, logging

5. Repites para el siguiente proveedor

Eso es el problema N × M: N herramientas × M proveedores de IA = N × M integraciones.

❌ Quieres cambiar de GPT a Claude? Reescribes todas las tool definitions.

❌ Añades una herramienta nueva? La implementas para cada proveedor por separado.

❌ Actualizas un schema? Lo cambias en N sitios distintos.

*MCP invierte esto. *

Un servidor MCP expone tools y resources con un estándar único. Cualquier host compatible con MCP (Claude Desktop, cualquier cliente que implemente el protocolo) puede consumirlo.

Cambias de modelo? El host cambia, el servidor MCP sigue igual.

Añades una herramienta? Un nuevo @mcp.tool() y listo.

Actualizas un schema? Un solo fichero.

| Sin MCP | Con MCP |

|---|---|

| N × M integraciones | N servidores MCP |

| Código repetido por proveedor | Un solo SDK |

| Seguridad distribuida (o inexistente) | Un punto de auditoría |

| Cambiar de modelo = reescribir | Cambiar de modelo = cambiar el host |

*MCP es a function calling lo que SQL es a las queries específicas de base de datos. * Una capa de abstracción que te permite cambiar el motor sin cambiar el código.

---

La Evidencia: Cómo se Construye un Servidor MCP en Python

Vamos a verlo con código real. Esto es un servidor MCP mínimo que expone una tool para obtener el tiempo.

```python

servidor_mcp_minimo.py

from mcp import Server, Tool, types

server = Server("weather-server")

@server.tool(

name="get_weather",

description="Obtiene la temperatura actual para una ciudad",

parameters={

"city": types.StringParam(description="Nombre de la ciudad"),

"units": types.StringParam(

description="Unidad: celsius o fahrenheit",

enum=["celsius", "fahrenheit"],

default="celsius"

)

}

)

async def get_weather(city: str, units: str = "celsius") -> str:

Aquí iría la llamada real a una API de clima

return f"La temperatura en {city} es 22°{units[0].upper()}"

server.run()

```

*Tres líneas para definir un tool. * Sin endpoints REST, sin autenticación custom, sin boilerplate de validación.

Ahora expongamos un Resource — datos que el modelo puede leer. Una tabla de SQLite como recurso:

```python

import sqlite3

from mcp import Server, Resource

server = Server("inventory-server")

@server.resource(

name="inventory/products",

description="Tabla de productos del inventario",

uri="inventory://products"

)

async def get_products() -> dict:

conn = sqlite3.connect("inventario.db")

cursor = conn.execute("SELECT id, name, stock FROM products")

products = [{"id": r[0], "name": r[1], "stock": r[2]} for r in cursor.fetchall()]

conn.close()

return {"products": products}

```

El modelo no tiene acceso a la base de datos. No puede hacer `DROP TABLE`. No puede inyectar SQL. Solo puede leer lo que el Resource expone.

*Eso es control de fronteras en acción. *

---

El Marco de 5 Pasos para tu Primer Servidor MCP

Lo llamo El Patrón de 5 Pasos para el Servidor MCP. Así es como lo implementas hoy:

1. Define la Frontera

Antes de escribir una línea de código, haz una lista:

• Resources: qué datos necesita leer el modelo. Tablas, ficheros, endpoints GET.

• Tools: qué acciones puede ejecutar. Enviar email, crear ticket, buscar en DB.

• Prompts: qué instrucciones reutilizables necesita. "Resume este log", "Clasifica este ticket."

*Si no está en la lista, el modelo no lo toca. *

2. Implementa el Servidor

Elige Python o Node.js. Instala el SDK oficial de MCP:

```bash

pip install mcp

o

npm install @modelcontextprotocol/sdk

```

Expone cada recurso y cada tool con los decoradores. Un fichero, un servidor.

3. Testea Local con Claude Desktop

Conecta tu servidor a Claude Desktop usando el transporte stdio (tu servidor se ejecuta como un proceso hijo).

Configuración en `claude_desktop_config.json`:

```json

{

"mcpServers": {

"weather-server": {

"command": "python",

"args": ["/ruta/a/servidor_mcp_minimo.py"]

}

}

}

```

Arrancas Claude. El modelo descubre automáticamente tus tools. Le pides "¿Qué tiempo hace en Madrid?" y lo invoca.

*Sin API keys. Sin endpoints expuestos. Sin CORS. *

4. Añade Seguridad en el Servidor

Como todas las llamadas pasan por tu servidor MCP, este es tu chokepoint:

• Añade logging de cada invocación de tool

• Implementa rate limiting por usuario o por sesión

• Valida parámetros antes de pasarlos al backend real

• Aplica autorización: qué usuario puede llamar a qué tool

En una integración ad-hoc, esto está repartido entre N endpoints. Con MCP, está en un solo sitio.

5. Exponte Prompts Reutilizables

No obligues al modelo a reinventar instrucciones cada vez. Crea prompts que empaqueten tu conocimiento de dominio:

```python

@server.prompt(

name="summarize_log",

description="Resume un fichero de log en 3 puntos clave"

)

async def summarize_log(log_content: str) -> str:

return f"""

Eres un experto en análisis de logs.

Recibirás el contenido de un fichero de log.

Devuelve un resumen con:

1. Errores críticos encontrados

2. Patrones recurrentes

3. Recomendaciones inmediatas

Log:

{log_content}

"""

```

*El modelo no tiene que adivinar cómo quieres que resuma. Se lo das hecho. *

---

Lo que MCP NO es (y por qué eso importa)

Aquí es donde el 90% se confunde:

❌ MCP no es un framework de agentes. No orquesta flujos, no tiene memoria, no planifica. LangChain, CrewAI, AutoGPT hacen eso. MCP es la capa de *conectividad* que esos frameworks consumen.

❌ MCP no reemplaza function calling. Function calling es cómo el modelo *declara que quiere llamar a una función. MCP es cómo esa función se descubre, invoca y asegura*. Son complementarios.

❌ MCP no es solo para Claude. Es un protocolo abierto (MIT). Hay SDKs para Python, Node.js, Java, Go, Rust. Cualquier host puede implementarlo.

✅ MCP es el conector universal. Como TCP/IP no es un navegador. MCP no es un agente. Es el cable.

*Comparar MCP con LangChain es como comparar el protocolo HTTP con un servidor web. * Son capas distintas. Y MCP es la infraestructura.

---

Las Limitaciones que Nadie Cuenta

No todo es perfecto. MCP usa JSON-RPC 2.0 como transporte. Es simple, bien conocido, agnóstico al lenguaje.

*Pero no soporta streaming de respuestas desde tools. * El modelo llama a una tool y espera a que termine. Para tools lentas (procesar un PDF grande, hacer múltiples llamadas API), esto es una limitación.

El protocolo sí soporta Server-Sent Events (SSE) en la dirección servidor → cliente. Pero la respuesta de una tool es síncrona: llamas, esperas, recibes.

Si necesitas que el modelo actúe sobre datos en tiempo real (streaming de precios, logs en vivo), tienes que diseñar tu servidor para que devuelva resultados parciales o uses un patrón de pooling.

*No es un dealbreaker. Pero es un constraint que hay que conocer. *

---

La Pregunta que Debes Hacerte

No es "¿debería usar MCP?"

La pregunta es: *¿cuánto tiempo estás perdiendo escribiendo integraciones que alguien más podría estar consumiendo con un estándar? *

Si tienes una herramienta, una API, un proveedor de IA — y un solo integration path — vale, no lo necesitas.

Pero si tienes 3 o más integraciones, o piensas escalar, o te importa la seguridad, o quieres poder cambiar de modelo sin reescribir todo:

*MCP no es opcional. Es la base que deberías haber tenido desde el principio. *

---

Resumen y Siguiente Paso

Lo que has aprendido:

• MCP no es sobre "dar acceso" — es sobre control de fronteras con resources, tools y prompts explícitos

• Resuelve el problema N × M de integraciones con un estándar único

• Un servidor MCP se construye en minutos con el SDK oficial

• La seguridad se centraliza en el servidor MCP como chokepoint

• MCP no compite con agent frameworks — los habilita

Tu siguiente paso: Abre tu editor. Instala el SDK de MCP. Coge la tool más usada de tu proyecto actual. Exponla como un servidor MCP.

*Cuando conectes Claude Desktop y veas que tu tool aparece sin configurar nada más, entenderás por qué todo lo anterior estaba obsoleto. *

Lee el artículo completo en brianmenagomez.com

Más sobre mis servicios en brianmenagomez.com

Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF

Crees que comprar un negocio online ya en marcha es el atajo. Pagas, heredas clientes, ingresos recurrentes, y te saltas los meses de validación, desarrollo y lanzamiento.

*Te has equivocado de compra.*

Comprar un negocio online externaliza el riesgo de product-market fit, sí. Pero internaliza un riesgo peor para el solo-operator sin equipo: el riesgo de integración operativa. Y ese risko — cuando trabajas solo, con hijos, y con 4 horas diarias desde un taller de pintura — puede ser más destructivo que construir desde cero.

La sabiduría convencional dice "compra si puedes permitírtelo, construye si no tienes presupuesto". La realidad para el operador en España es más matizada: no compres un negocio si no puedes auditar su deuda operativa antes de firmar. Porque el tiempo que crees que ahorras comprándolo lo gastarás — con intereses — desenredando las decisiones de otro.

---

El Mito del Atajo: Por Qué Comprar Parece Más Rápido de Lo Que Es

El argumento de compra es seductor. Un negocio en Flippa o Acquire.com con 50 clientes, ingresos estables, SEO posicionado y procesos documentados. *Parece* que solo necesitas mantenerlo.

Lo que no ves desde fuera:

• Las 43 integraciones de API que el vendedor configuró manualmente y nunca documentó.

• Los scripts en producción que nadie sabe qué hacen pero que si se caen, lloran los clientes.

• Las relaciones con proveedores que dependen del contacto personal del vendedor.

• El contenido SEO que posicionó porque Google todavía perdonaba cosas en 2023.

• Los procesos manuales que el vendedor hacía cada viernes a las 6 de la tarde y que ahora te tocan a ti.

En el contexto de las tesis recientes sobre el solo-operator con hijos, comprar un negocio tiene un problema estructural: el pico de demanda energética llega cuando menos lo esperas. Construir desde cero tiene un coste alto al inicio que decrece. Comprar tiene un coste bajo al inicio que se dispara durante la integración post-adquisición.

❌ El enfoque equivocado: "Compro el negocio y luego ya limpio el código, los procesos, y las dependencias mientras mantengo los ingresos."

✅ El enfoque real: "Comprar un negocio es comprometerme a hacer *reverse engineering* de otro fundador — y cada decisión que descubra requerirá tiempo que le robo a las ventas."

---

El Concepto Que Nadie Te Dice: Deuda Operativa

Existe la deuda técnica (código mal escrito, dependencias obsoletas, falta de tests). Pero para el operador que compra un negocio, existe una categoría peor: la deuda operativa.

*La deuda operativa es todo lo que no es código pero que necesita atención constante para que el negocio funcione.*

Dimensiones de la deuda operativa en una compra:

1. Deuda de procesos — Flujos manuales que el vendedor ejecutaba de memoria y que ahora tú tienes que reconstruir.

2. Deuda de relaciones — Proveedores, partners, clientes clave que están vinculados al vendedor, no al negocio.

3. Deuda de pricing — Una estructura de precios diseñada para el vendedor que no necesariamente funciona para tu perfil de operador.

4. Deuda de contenido — Artículos SEO, backlinks, estrategia de contenidos que posicionaron en otro contexto algorítmico.

5. Deuda de conocimiento — Decisiones que el vendedor tomó hace dos años y que nadie recuerda por qué se tomaron.

Para un solo-operator, desenredar estas cinco capas sin equipo de apoyo puede paralizar el negocio durante meses. No hay con quién discutir las decisiones heredadas. No hay quién recuerde por qué se tomó tal decisión técnica o comercial. Eres tú frente a un laberinto que otro construyó.

---

El Framework de las 5 Dimensiones: Cómo Auditar un Negocio Antes de Comprar

Basado en la evidencia de que el tiempo que te "ahorras" comprando se gasta en integración operativa, he desarrollado este framework para solo-operators en España.

1. Auditoría de deuda operativa — Las 5 dimensiones

Antes de poner un euro, evalúa cada dimensión del negocio objetivo en una escala del 1 al 5:

• Código: ¿Está documentado? ¿Tiene tests? ¿Las dependencias están actualizadas?

• Clientes: ¿Tienen expectativas razonables o requieren atención manual constante?

• Procesos: ¿Están documentados o viven en la cabeza del vendedor?

• Proveedores: ¿Son transferibles o dependen de la relación personal del vendedor?

• SEO/Contenido: ¿El tráfico es orgánico genuino o depende de estrategias que Google ya no premia?

*Si más de 2 dimensiones requieren reingeniería completa, construir desde cero puede tener menor coste energético total.*

2. El umbral de ingresos mínimos — El 'piso de ingresos' como filtro de compra

De las tesis anteriores sabemos que un solo-operator con hijos debe priorizar ventas hasta alcanzar un piso de ingresos antes de tocar código. Aplicado a la compra, esto significa:

Si el negocio adquirido no genera ingresos suficientes desde el día 1 para que puedas dedicar 4-6 semanas a la transición operativa sin vender, no es comprable.

Comprar un negocio que requiere tres meses de "rampa" para llegar a rentabilidad no es comprar. Es construir con hipoteca operativa. Y el riesgo es mayor porque cargas con la deuda heredada mientras intentas crecer.

3. El mapeo de migraciones técnicas — La regla del 2.5x

Cataloga cada integración, API, webhook y script del negocio adquirido. Luego multiplica el tiempo estimado de migración por 2.5x.

¿Por qué 2.5x? Porque el solo-operator subestima sistemáticamente la complejidad heredada. Lo que parece un "cambio de proveedor de email" es en realidad desenredar 12 integraciones de webhook que el vendedor configuró hace tres años y que nadie ha tocado desde entonces.

4. La prueba de 'cero código' — 7 días de operación manual

Durante el due diligence, opera el negocio manualmente durante 7 días sin tocar ni una línea de código.

• Si puedes sostener las operaciones sin escribir software, el negocio tiene madurez operativa.

• Si al tercer día necesitas hacer un script para algo, el negocio requiere más construcción de la que piensas.

Esta prueba es brutal pero necesaria. Te obliga a experimentar la deuda operativa antes de comprarla.

5. El check de restricciones familiares — ¿Cuántas horas semanales requiere?

Para solo-operators con hijos, la compra solo tiene sentido si el negocio adquirido requiere menos de 10 horas semanales de mantenimiento pasados los primeros 90 días.

¿Por qué 10 horas? Porque la evidencia muestra que el burnout aparece cuando construir, vender y mantener compiten por el mismo tiempo. Si el negocio comprado exige más de 10 horas semanales de mantenimiento después de la integración, no te está comprando tiempo — te lo está robando.

---

El Trade-Off Energético Oculto: Dónde Duele Cada Camino

Construir desde cero duele al principio. Diseño, desarrollo, validación, cero clientes. Es un dolor que conoces y que puedes graduar.

Comprar duele después. La transacción es fácil. La integración es donde aparece la factura energética.

Perfil de energía de construir desde cero:

• Mes 1-3: Alta exigencia (código, validación, diseño)

• Mes 4-12: Exigencia media decreciente (mantenimiento, features)

• Mes 12+: Exigencia baja (operación estable)

Perfil de energía de comprar:

• Mes 1: Exigencia baja-media (transacción, transición)

• Mes 2-6: Exigencia muy alta (integración, documentación, reparación)

• Mes 6+: Exigencia media (operación con deuda residual)

Para el solo-operator con 90 minutos diarios de código entre siestas, el perfil de la compra es letal porque el pico de exigencia llega en el momento donde aún no conoces bien el negocio. Cuando construyes, escalas la exigencia gradualmente. Cuando compras, te tiran a la piscina operativa el día 1.

---

El Factor de Aislamiento Cognitivo: El Coste de No Saber por Qué

Cuando construyes desde cero, conoces cada decisión técnica y comercial porque las tomaste tú. No necesitas documentar lo que sabes.

Cuando compras, pasas meses descubriendo decisiones que otro tomó. Y cada descubrimiento puede requerir una corrección.

*Este "descubrimiento diferido" es particularmente costoso para el solo-operator porque no hay con quién discutir las decisiones heredadas ni quién recuerde por qué se tomaron.*

El vendedor, una vez cobrado, desaparece. Y tú te quedas con un sistema del que entiendes la superficie pero no las entrañas.

---

Una Implicación Práctica para el Mercado Español

En el ecosistema de compraventa de negocios online en España — adquisiciones de sites, newsletters, e-commerces pequeños, gestorías digitalizadas — hay un patrón que se repite:

La mayoría de los vendedores ponen en venta precisamente porque han acumulado demasiada deuda operativa y técnica.

El negocio no está "maduro para la venta". Está agotando al fundador. El comprador optimista asume que "solo necesita limpiar un poco". La realidad, extrapolando de la evidencia técnica sobre integraciones complejas, es que la complejidad oculta siempre supera la estimación inicial.

El negocio que ves en venta no es una oportunidad. Es un problema que alguien más decidió dejar.

---

Cuándo Sí Tiene Sentido Comprar (Y Cómo Hacerlo Bien)

No todo es negativo. Comprar tiene sentido cuando:

• El vendedor ha documentado todo — Procesos, código, relaciones, decisiones. Si no hay documentación, no hay compra.

• El negocio supera la prueba de 'cero código' — Puedes operarlo manualmente 7 días sin tocar una línea.

• El piso de ingresos cubre tu necesidad desde el día 1 — No necesitas 3 meses de rampa para llegar a rentabilidad.

• La deuda operativa es baja en al menos 4 de las 5 dimensiones — Si necesitas reingeniería en más de 2 dimensiones, construye desde cero.

La compra inteligente no es comprar barato. Es comprar documentado.

---

La Decisión No Es Build vs Buy. Es Deuda Operativa vs Deuda de Construcción.

El debate build vs buy para el solo-operator en España no se resuelve con hojas de cálculo de costes. Se resuelve con una pregunta más honesta:

*¿Qué tipo de deuda estás dispuesto a pagar con tu energía disponible?*

Construir desde cero te endeuda en tiempo de desarrollo y validación. Comprar te endeuda en tiempo de integración y descubrimiento diferido. Para un operador que trabaja solo, con hijos, y con ventanas de código de 90 minutos, la deuda de construcción suele ser más manejable que la deuda operativa — porque la conoces, la controlas, y puedes graduarla.

Compra negocios. Pero no compres el problema de otro como si fuera una oportunidad.

La próxima vez que veas un negocio en venta con "50 clientes y ingresos recurrentes", pregúntate no cuánto vale. Pregúntate *cuánto tiempo de tu vida vas a pasar desenredando lo que otro no quiso limpiar.*

Lee el artículo completo en brianmenagomez.com

Más sobre mis servicios en brianmenagomez.com

Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF

Crees que un agente de calidad de contenido es un corrector ortográfico con esteroides. Que le pasas un artículo, te devuelve los errores de gramática, detecta si hay plagio, y listo. Contenido auditado.

*Te has equivocado de diagnóstico.*

Llevo auditando contenido publicado desde que lancé conversoriaecnae.es y gestoriascercademi.com. Más de 4.800 páginas indexadas entre ambos proyectos. Y te digo lo que he aprendido: la gramática es la dimensión menos importante que puntúa un agente de Content QA.

El problema no es que tu contenido tenga faltas de ortografía. El problema es que no convierte, no posiciona y no retiene — y tu revisor de Grammarly no te va a avisar de eso.

En 2026, con los LLMs actuales — Opus 4.5, Gemini 3.1 Pro, los modelos de Anthropic — construir un agente que puntúa contenido es trivial. Lo difícil es saber qué puntuar y por qué cada dimensión importa.

Vamos a construir el framework que uso en producción.

---

Las 7 Dimensiones Que Un Content QA Agent Debe Puntuar (Y Por Qué Este Orden)

La mayoría de equipos implementan un agente de Content QA que revisa:

❌ Gramática y ortografía — primero

❌ Legibilidad — después

❌ Longitud — al final

Ese agente no sirve para nada. Literalmente. Te va a decir que un texto está bien escrito cuando está matando tu conversión.

El orden correcto de las dimensiones, de más importante a menos:

1. Claridad de Propósito — La Dimensión Que Mata el Rebote

Tu agente debe responder primero: ¿sabe el lector qué va a obtener en los primeros 10 segundos?

Si un usuario llega a tu página y no entiende en 5 segundos si eso responde a su problema, se va. No lee el artículo. No convierte.

✅ Cómo lo puntuamos: El agente analiza el primer párrafo y el H1. Si no contienen explícitamente el problema que resuelve el contenido, la puntuación de claridad es 0.

En producción, usamos un prompt que evalúa: "¿Un usuario que busca X solución encontraría esto en los primeros 10 segundos?" El LLM devuelve un score de 0 a 10.

2. Alineamiento con Intención de Búsqueda — Donde Muere el SEO Real

Puedes tener el texto mejor escrito del mundo. Si no responde a lo que el usuario buscó, no existe.

Google ya no rankea palabras clave. Rankea respuestas a intenciones. Tu agente debe cruzar el contenido contra las SERPs reales y puntuar si el texto cubre las sub-intenciones que aparecen en los primeros resultados.

✅ Cómo lo puntuamos: El agente extrae las 3-5 preguntas relacionadas que aparecen en "People also ask" de Google y verifica si el contenido las responde explícitamente.

```python

def puntua_intencion(content, serp_questions):

prompt = f"""

Contenido: {content[:2000]}

Preguntas relacionadas en Google:

{serp_questions}

Puntúa del 0 al 10 cuántas de estas preguntas

responde el contenido de forma explícita y directa.

Devuelve solo el número.

"""

response = llm.invoke(prompt)

return int(response.strip())

```

Si el score es menor de 7, el agente rechaza el contenido. No importa lo bien escrito que esté.

3. Estructura de Argumentación — El Esqueleto Que Retiene

El 80% de los contenidos que auditamos tienen una estructura débil. Van de idea en idea sin jerarquía.

Tu agente debe identificar si el contenido sigue una estructura lógica: problema → evidencia → solución → acción. Si salta entre ideas sin conector, la dimensión de estructura falla.

✅ Cómo lo puntuamos: El agente identifica si hay transiciones entre secciones, si cada H2 se sostiene con datos, y si hay una conclusión que resume y empuja a acción.

4. Densidad de Evidencia — La Dimensión Que Construye Autoridad

Un párrafo sin números, sin fuentes, sin ejemplos concretos, es ruido.

Tu agente debe contar cuántas afirmaciones respaldadas hay por cada 500 palabras. Si la densidad es menor de 2 evidencias por cada 500 palabras, el contenido es débil.

✅ Cómo lo puntuamos: El agente busca: cifras, nombres de herramientas, estudios citados, casos reales, capturas de pantalla mencionadas. Si no hay al menos 3 evidencias en un artículo de 1.000 palabras, se marca como "necesita revisión".

5. Accionabilidad — La Dimensión Que Convierte

El contenido más valioso del mundo no sirve si el lector termina y no sabe qué hacer.

Tu agente debe detectar si hay al menos una llamada a la acción explícita (no un "contáctanos" genérico). Un paso concreto que el lector pueda ejecutar en los próximos 5 minutos.

✅ Cómo lo puntuamos: El agente busca verbos en imperativo ("descarga", "implementa", "configura", "abre", "crea") seguidos de un objeto tangible. Si no hay al menos 2 llamadas a la acción específicas, la puntuación de accionabilidad es 0.

6. Legibilidad — La Que Todo el Mundo Mide (Pero Mal)

Aquí sí entra la legibilidad tradicional. Pero ojo: no es longitud de frase. Es carga cognitiva.

Tu agente debe puntuar si el contenido es entendible por alguien con nivel de lectura de 12-14 años. No es "escribir para tontos". Es no perder al 80% de tu audiencia porque usas palabras que nadie usa.

✅ Cómo lo puntuamos: Usamos la fórmula de legibilidad de Fernández-Huerta (adaptación española de Flesch). Pero añadimos un matiz: el agente detecta si hay jerga innecesaria. Si usas términos técnicos que no se explican, baja la puntuación.

7. Gramática y Ortografía — La Última Dimensión y la Menos Importante

Aquí está la clave que la mayoría no entiende.

Un contenido con faltas de ortografía pero con las 6 dimensiones anteriores bien puntuadas funciona mejor que un contenido impecable gramaticalmente pero sin estructura, sin evidencia y sin intención de búsqueda.

No digo que publiques con faltas. Digo que no es el bottleneck.

✅ Cómo lo puntuamos: Corrección ortográfica estándar. Pero el peso de esta dimensión en la puntuación total es del 5%. Literalmente. Las otras 6 dimensiones suman el 95%.

---

El Framework de las 7 Dimensiones de Content QA — Cómo Implementarlo

He llamado a esto El Framework de las 7 Dimensiones de Content QA. No es teoría. Es el sistema que ejecuto en cada deploy de contenido nuevo.

Paso 1: Configura el Pipeline de Auditoría

Usa una Edge Function en Vercel o un cron job en Railway. Cada vez que publiques contenido nuevo — o cada 30 días para contenido existente — el pipeline se ejecuta.

```javascript

// Edge Function schedule o webhook trigger

export default async function handler(req) {

const content = await getPageContent(req.body.url)

const dimensions = {

claridad: await scoreClaridad(content),

intencion: await scoreIntencion(content),

estructura: await scoreEstructura(content),

evidencia: await scoreEvidencia(content),

accionabilidad: await scoreAccionabilidad(content),

legibilidad: await scoreLegibilidad(content),

gramatica: await scoreGramatica(content)

}

const totalScore = calculateWeighted(dimensions)

if (totalScore < 7) {

await notifySlack(`Contenido necesita revisión: ${req.body.url}`)

await queueForRevision(req.body.url, dimensions)

}

return { status: 'ok', score: totalScore }

}

```

Paso 2: Define los Pesos

| Dimensión | Peso |

|---|---|

| Claridad de propósito | 20% |

| Alineamiento con intención | 20% |

| Estructura de argumentación | 15% |

| Densidad de evidencia | 15% |

| Accionabilidad | 15% |

| Legibilidad | 10% |

| Gramática y ortografía | 5% |

Paso 3: Crea un Sistema de Alertas

No basta con puntuar. Necesitas acción.

Configura tu agente para que cuando una dimensión baje de 5, dispare una alerta a tu equipo de contenido o a tu webhook de revisión.

En gestoriascercademi.com tengo esto configurado contra un canal de Slack. Cada semana recibo un resumen de qué páginas necesitan revisión y por qué dimensión están fallando.

Paso 4: Revisiones Automáticas + Humanas

El agente puntúa. El humano decide.

No dejes que el agente publique contenido automáticamente. Que genere un reporte, y que un editor valide antes de aprobar. El agente es el primer filtro, no el decisor final.

---

Lo Que He Aprendido Auditando 4.800+ Páginas

Los números no mienten.

De las 4.800+ páginas indexadas entre conversoriaecnae.es y gestoriascercademi.com, el 73% de los contenidos que fallaban en las primeras 3 dimensiones (claridad, intención, estructura) tenían una tasa de rebote superior al 70% — independientemente de su calidad gramatical.

El patrón se repite siempre: contenidos perfectamente escritos que nadie lee porque no responden a lo que el usuario buscaba.

El Content QA agent real no es un corrector. Es un guardián de intención.

---

Resumen y Próximo Paso

• Las 7 dimensiones reales son: claridad, intención, estructura, evidencia, accionabilidad, legibilidad, gramática

• La gramática pesa solo el 5% en la puntuación total

• Implementa un pipeline que ejecute auditorías cada 30 días

• No automatices la publicación — el agente puntúa, el humano decide

• Mide rebote vs puntuación, no solo corrección gramatical

El próximo paso que voy a compartir es cómo construir el agente que no solo puntúa contenido, sino que lo reescribe automáticamente respetando las 7 dimensiones. Ese es el salto de auditor a editor.

Pero eso es para otro artículo.

Por ahora, ve y revisa tu último contenido publicado. Pásalo por las 7 dimensiones. Si solo miraste la gramática, no has auditado nada.

Lee el artículo completo en brianmenagomez.com

Más sobre mis servicios en brianmenagomez.com

Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF

Tesis: Supabase no es una alternativa más fácil a Firebase. Es PostgreSQL expuesto como servicio — y la complejidad arquitectónica que exige (RLS policies, replication slots, migraciones, Deno) la paga el desarrollador que creía estar comprando simplicidad.

---

"Firebase para PostgreSQL"? No. Es PostgreSQL para Gente que Quería Firebase

La creencia popular: "Supabase es Firebase pero open source. Más fácil, más barato, para frontend developers que no quieren escribir backend."

*La realidad: Supabase es más difícil que Firebase para el desarrollador frontend típico. *

Firebase abstrae la base de datos por completo — NoSQL, sin esquema, sin migraciones. Escribe un JSON, define unas reglas de seguridad en otro JSON, y ya está. La base de datos se convierte en una caja negra que responde a tus peticiones sin que tengas que preocuparte por índices, planes de ejecución ni esquemas. Firebase Realtime Database y Firestore están diseñados específicamente para que alguien con conocimientos básicos de JavaScript pueda construir una app funcional en cuestión de horas.

Supabase te obliga a enfrentarte a PostgreSQL directamente:

• Schemas con tipos de datos estrictos

• Migraciones SQL

• Políticas RLS escritas en PostgreSQL puro

• Connection pooling

• Replication slots del WAL

• Y SQL. Mucho SQL.

No estás escapando de la complejidad del backend. *Estás cambiando la caja negra de Firebase por la caja de cristal de PostgreSQL. *

Y la mayoría no está lista para lo que ve dentro.

La paradoja es que la transparencia de Supabase resulta ser su mayor desventaja para el perfil equivocado. Firebase te protege activamente de ti mismo: no puedes escribir una query ineficiente porque no tienes control sobre cómo se ejecuta. Supabase te da el poder de optimizar, pero también el poder de hundirte. Y cuando tu `SELECT` con una RLS policy mal escrita tarda 30 segundos, no puedes culpar a nadie más que a ti mismo.

---

❌ Lo que Crees que Compras vs ✅ Lo que Realmente Obtienes

❌ Creencia: "Supabase es más fácil que Firebase"

Firebase te da security rules en JSON. Mira este ejemplo para "usuarios solo ven sus propios todos":

```json

{

"rules": {

"todos": {

"$uid": {

".read": "$uid === auth.uid",

".write": "$uid === auth.uid"

}

}

}

}

```

Es configuración. No es código. No necesitas saber cómo funciona la base de datos internamente. El motor de Firebase interpreta esas reglas y las aplica en el punto de acceso, no en el motor de almacenamiento. No hay riesgo de que una regla mal escrita degrade el rendimiento de todo el sistema. Es declarativo, predecible y seguro por diseño.

✅ Realidad: Supabase te obliga a escribir SQL que se ejecuta dentro de la base de datos

El mismo caso en Supabase usando RLS:

```sql

CREATE POLICY "Users can only see their own todos"

ON todos

FOR SELECT

USING (auth.uid() = user_id);

CREATE POLICY "Users can only insert their own todos"

ON todos

FOR INSERT

WITH CHECK (auth.uid() = user_id);

CREATE POLICY "Users can only update their own todos"

ON todos

FOR UPDATE

USING (auth.uid() = user_id)

WITH CHECK (auth.uid() = user_id);

CREATE POLICY "Users can only delete their own todos"

ON todos

FOR DELETE

USING (auth.uid() = user_id);

```

Eso no es configuración. *Es código imperativo que corre dentro del motor de la base de datos. *

Cada SELECT en `todos` ejecuta esa política. Si tu política hace un JOIN contra otra tabla y el query planner decide hacer un sequential scan, *cada consulta a la tabla se ralentiza*. En una tabla con 50.000 filas, una RLS policy inocente que haga `SELECT EXISTS (SELECT 1 FROM teams WHERE team_id = todos.team_id AND user_id = auth.uid())` puede convertir una consulta de milisegundos en una operación de segundos.

En Firebase, las security rules son declarativas y se evalúan antes de tocar los datos. En Supabase, estás escribiendo lógica que se inyecta en cada fila que PostgreSQL procesa. Y si no sabes cómo funciona `EXPLAIN ANALYZE`, estás volando a ciegas.

---

La Trampa de las RLS Policies: Estás Escribiendo Código en la Base de Datos

La documentación de Supabase te dice: "Habilita RLS en cada tabla". Y es cierto. Pero lo que no te dicen es esto:

> *Escribir una RLS policy no es como escribir middleware en Express. Es escribir una función que PostgreSQL ejecuta en cada fila de cada query. *

Si haces:

```sql

SELECT * FROM todos;

```

Y tu tabla tiene 100.000 filas, PostgreSQL ejecuta tu RLS policy 100.000 veces. Si esa política tiene un subquery contra otra tabla, cada ejecución puede ser otro scan secuencial. El resultado: una consulta que debería tardar 10 milisegundos se convierte en una operación de 10 segundos.

El desarrollador que viene de Firebase piensa en reglas. El desarrollador que sobrevive en Supabase piensa en planes de ejecución, índices, y `EXPLAIN ANALYZE`. Y no solo eso: necesita entender cómo optimizar subqueries, cuándo usar JOINs en lugar de subqueries, y cómo los índices compuestos pueden salvar una RLS policy.

El gap de skills que nadie menciona

Firebase te protege de la base de datos. Supabase te expone a ella.

Y eso significa que necesitas saber:

• Cómo diseñar un schema con foreign keys, tipos de datos e índices

• Cómo escribir migraciones SQL que no rompan producción

• Cómo funciona el query planner de PostgreSQL

• Qué son los replication slots y por qué pueden llenar tu disco

• Cómo funciona la autenticación separada de la autorización (auth vs RLS)

• Cómo hacer profiling de queries con `EXPLAIN (ANALYZE, BUFFERS)`

• Cómo gestionar la concurrencia y los locks a nivel de fila

*¿Tu equipo tiene a alguien que sepa PostgreSQL? Si no, estás acumulando deuda técnica operativa. *

Y la deuda no es teórica. En producción, una RLS policy mal optimizada no solo ralentiza una consulta: puede provocar timeouts en cascada, agotar el pool de conexiones y degradar el rendimiento de toda la aplicación, incluyendo la autenticación y el tiempo real.

---

Realtime: La Espada de Doble Filo del WAL

La funcionalidad de tiempo real de Supabase usa la replicación lógica nativa de PostgreSQL. Los cambios se transmiten a través del WAL (Write-Ahead Log). Cuando haces un INSERT, UPDATE o DELETE, PostgreSQL escribe el cambio en el WAL, y un slot de replicación lo captura y lo envía a los clientes suscritos.

Esto es elegante. Es "verdadero" tiempo real, no polling. No hay intervalos fijos ni latencia arbitraria. El cambio se propaga en milisegundos.

Pero también es frágil.

Si un consumidor de replicación no consume los cambios a tiempo — por ejemplo, porque un cliente se desconecta o porque el proceso de replicación se queda atascado — el WAL crece indefinidamente. Ocupa espacio en disco. Y si llena el disco, la base de datos se cae. No es un escenario teórico: es una de las causas más comunes de caídas en PostgreSQL autogestionado.

Firebase Realtime Database no tiene este problema porque es un sistema separado — no comparte recursos con tu base de datos. Firestore y Realtime Database tienen sus propios mecanismos de escalado y gestión de recursos, independientes del almacenamiento principal.

Supabase: un solo PostgreSQL maneja auth, datos, almacenamiento y replicación.

Firebase: auth, Firestore, Realtime Database y Storage son servicios independientes.

*En Supabase, una query lenta en analytics puede degradar tu autenticación. *

Comparten el mismo pool de conexiones, la misma CPU, la misma memoria y el mismo disco. Si una Edge Function hace una consulta pesada que bloquea una tabla, el login de un usuario puede quedarse esperando. En Firebase, auth corre sobre infraestructura de Google separada de Firestore. Son mundos distintos.

---

Edge Functions: Deno, No Node.js — Prepárate para Reescribir

Supabase eligió Deno para sus Edge Functions. No Node.js.

Deno es más seguro (sandboxed, sin npm supply chain) y arranca más rápido (cold starts menores). Pero significa que *tu ecosistema npm no funciona. *

Express, Mongoose, Axios — no existen en Deno. Y aunque Deno tiene compatibilidad parcial con npm a través de `npm:` specifiers, no es perfecta. Muchas librerías dependen de APIs de Node.js que Deno no implementa al 100%, como `crypto` en ciertas configuraciones, `stream` en modo legacy, o `child_process` que simplemente no existe en el sandbox de Deno.

Aquí tienes un webhook en Supabase Edge Function:

```typescript

import { serve } from "https://deno.land/std@0.177.0/http/server.ts";

serve(async (req) => {

const { name } = await req.json();

const data = {

message: `Hello ${name}!`,

};

return new Response(JSON.stringify(data), {

headers: { "Content-Type": "application/json" },

});

});

```

Fíjate en el import: es una URL, no un paquete de npm. No hay `package.json`. No hay `node_modules`. Usas `import maps` para gestionar dependencias.

Si tu backend depende de librerías npm, tienes dos opciones:

1. Reescribirlas para Deno — coste oculto de migración que nadie calcula al empezar el proyecto

2. Ejecutarlas como servicio separado — defeats el propósito de Edge Functions, porque introduces latencia de red entre servicios

*La mayoría descubre esto después de haber commitado a Supabase. *

Y luego vienen los problemas de compatibilidad. Quieres usar una librería de OpenAI para streaming de respuestas? OpenAI no tiene SDK oficial para Deno. Necesitas usar el cliente HTTP directamente o buscar un wrapper de la comunidad. Quieres conectar con Stripe? Lo mismo. El ecosistema de Deno es más pequeño, y aunque crece cada año, sigue muy lejos de la madurez de npm.

Si tu stack incluye herramientas como Prisma, Mongoose, o cualquier ORM que dependa de APIs nativas de Node.js, olvídate de ejecutarlas en Edge Functions. Tendrás que mantener un servicio Node.js aparte — con su propio deploy, su propia escala y su propio coste operativo.

---

El Marco de las 5 Decisiones para Supabase vs Firebase 2026

No se trata de cuál es "mejor". Se trata de *para quién* y *para qué*.

Aquí tienes el marco para decidir:

1. ¿Tu equipo sabe PostgreSQL?

• Sí → Supabase te da control total. Puedes optimizar queries, diseñar schemas complejos y escalar con confianza. Tu equipo puede sacar partido de las features avanzadas de PostgreSQL: CTEs recursivos, funciones ventana, índices parciales, particionado de tablas.

• No → Firebase. La complejidad arquitectónica de Supabase te va a costar tiempo, bugs y dolores de cabeza. No aprender PostgreSQL sobre la marcha mientras tu app está en producción.

2. ¿Tu app necesita tiempo real?

• Sí → Ambos lo hacen bien. Pero Supabase requiere que entiendas replication slots y monitorees el WAL. Firebase es plug-and-play: enciendes la funcionalidad y funciona.

• No → El tiempo real no debería ser el factor decisivo. Si solo necesitas polling cada 30 segundos, no necesitas ni Supabase ni Firebase Realtime.

3. ¿Escalas horizontalmente o verticalmente?

• Vertical → Supabase escala PostgreSQL hacia arriba. Límite de conexiones, tamaño de instancia, réplicas de lectura. Es escalado tradicional de base de datos relacional.

• Horizontal → Firebase escala horizontalmente por defecto. Firestore y Realtime Database están diseñados para sharding automático. No piensas en servidores, piensas en documentos y colecciones.

4. ¿Tienes un DBA o DevOps en el equipo?

• Sí → Supabase. Tu DBA puede exprimir PostgreSQL como nadie: tuning de parámetros, monitoreo de índices, gestión de vacío, WAL archiving.

• No → Firebase. La gestión operativa de PostgreSQL — WAL monitoring, connection pooling, índices, vacuum — recae en tu equipo. Y si nadie sabe hacerlo, estás en problemas.

5. ¿Estás construyendo un MVP o un producto a largo plazo?

• MVP → Cualquiera vale. Pero si eliges Supabase, invierte tiempo desde el día 1 en schema design, RLS y migraciones. No pienses "lo arreglo después", porque PostgreSQL no perdona el mal diseño inicial.

• Largo plazo → La deuda técnica de un mal schema en PostgreSQL es más cara que la de Firebase. Firebase te permite iterar rápido y refactorizar sobre la marcha gracias a su naturaleza sin esquema. En PostgreSQL, cambiar un tipo de columna con 2 millones de filas requiere una migración planificada, tiempo de inactividad potencial y pruebas exhaustivas.

---

La Verdad Incómoda: Supabase No es para Frontend Developers

Firebase fue diseñado para frontend developers que no quieren saber de bases de datos. Cada uno de sus servicios — Auth, Firestore, Storage, Functions — es independiente, está gestionado por separado y se escala de forma autónoma. Puedes construir una app completa sin escribir una sola línea de código backend tradicional.

Supabase fue diseñado para equipos que ya conocen PostgreSQL y quieren un managed service con features modernas: autenticación integrada, almacenamiento, tiempo real sobre el WAL, y Edge Functions en Deno. No es un producto para "no-developers". Es un producto para desarrolladores que ya saben lo que hacen y quieren delegar la gestión del servidor, pero no la complejidad de la base de datos.

Si eres frontend y eliges Supabase porque "es más barato" o "es open source", *estás asumiendo una carga cognitiva que no habías presupuestado. *

No es que Supabase sea malo. Es que *no es lo que parece. *

La próxima vez que alguien diga "Supabase es Firebase para PostgreSQL", recuerda: Firebase te protege de ti mismo. Supabase te da el poder de hacerlo bien... o de hacerlo espectacularmente mal.

> Supabase no es "Firebase para PostgreSQL". Es PostgreSQL para gente que pensaba que quería Firebase — y la mayoría no está preparada para lo que firmó.

---

Resumen: Lo que te Llevas

1. RLS no es opcional — y no es como Firebase Security Rules. Es SQL que corre en cada fila. Si no sabes PostgreSQL, tus queries van a doler. Aprende `EXPLAIN ANALYZE` antes de escribir tu primera política.

2. Realtime usa el WAL de PostgreSQL — elegante pero frágil. Sin monitoreo, los replication slots llenan el disco y la base de datos se cae. Configura alertas de uso de disco desde el día 1.

3. Edge Functions corren en Deno — olvídate de npm. Prepárate para reescribir librerías o mantener servicios separados. Evalúa si tus dependencias críticas tienen soporte para Deno antes de comprometerte.

4. El schema lo es todo — en Firebase puedes improvisar. En Supabase, tu schema define tu arquitectura. Diseña antes de codificar. Una foreign key mal puesta te perseguirá durante años.

5. Auth y autorización son dos pasos separados — `supabase.auth.signUp()` te da un token. Las RLS policies deciden si ese token puede leer datos. No confundas autenticación con autorización. Y recuerda: un token válido no significa acceso garantizado.

6. PostgreSQL comparte recursos con todo — auth, datos, tiempo real y almacenamiento comparten el mismo PostgreSQL. Una query pesada puede degradar la autenticación. Monitorea el rendimiento global, no solo el de tu feature.

La decisión Supabase vs Firebase 2026 no es técnica. *Es sobre si tu equipo tiene o no la madurez PostgreSQL que Supabase exige. *

Y si crees que "total, PostgreSQL se aprende sobre la marcha" — bueno, los replication slots llenos y las RLS policies que hacen sequential scans te van a recordar por qué Firebase existe.

Lee el artículo completo en brianmenagomez.com

Más sobre mis servicios en brianmenagomez.com

Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF

Crees que el equilibrio perfecto existe. Que un solo-operator debe repartir su tiempo en tercios iguales. Construir, vender, mantener. 33/33/33. Un poco de cada, todos los días.

*Te has equivocado de diagnóstico.*

El reparto uniforme no es equilibrio. Es la receta más rápida para el burnout sin ingresos. Según los datos — escasos pero contundentes — el error no está en cuánto trabajas, sino en asumir que las tres actividades pesan lo mismo en todas las fases.

No pesan. Y el que te diga lo contrario nunca ha gestionado 4 horas diarias con un niño de 6 meses en casa.

Yo lo hago. Mi taller de pintura sigue funcionando mientras escribo esto. Y he aprendido que el presupuesto diario de un solo-operator con hijos no se optimiza con productividad. Se optimiza con jerarquía temporal.

---

El Error Más Caro de Tu Carrera: Construir Antes de Tener un Piso de Ingresos

La sabiduría convencional asume que el solo-operator debe construir primero y vender después. Construyes un MVP. Lo pules. Añades features. Y cuando está "listo", empiezas a vender.

*Ese orden está al revés.*

La tesis del solo-revenue floor es clara: construir cualquier producto antes de tener un piso de ingresos es el mayor error del solo-operator. El piso de ingresos — ese número mínimo de clientes que cubren tus gastos básicos — no es un objetivo secundario. Es un *prerrequisito* para construir.

¿Qué significa esto en la práctica? Que tu reparto de tiempo no es una decisión de preferencia personal. Es una función directa de tu estado financiero.

• Un solo-operator con 3 meses de ahorros debería tener un reparto diametralmente opuesto a uno con 12 meses de ingresos recurrentes.

• La mayoría aplica el mismo reparto independientemente de su situación real.

• Y ese error es el que mata más proyectos que cualquier fallo técnico.

---

❌ El Reparto Que Te Lleva al Burnout: 2h Construir / 1h Vender / 1h Mantener

Mira tu semana. Si eres como el 90% de los solo-operators que conozco, tu distribución es más o menos esta:

❌ Reparto clásico del constructor que no factura:

• 2h diarias a construir producto nuevo

• 1h a prospección y ventas

• 1h a mantenimiento y bugs

Parece razonable, ¿verdad? Un poco más de construcción, algo de ventas, lo justo para mantener lo que ya funciona.

*Es una trampa.*

El problema no es que trabajes poco. El problema es que las tres actividades tienen urgencias e impactos radicalmente distintos.

La construcción es adictiva porque da satisfacción inmediata. El código compila. La UI se ve bonita. Puedes mostrar avances. Pero el código que nadie paga no es un activo. Es un pasivo. Cada línea de código sin validación de mercado es deuda técnica que crece con intereses compuestos.

El mantenimiento es una deuda que se acumula en silencio. Cada bug que ignoras hoy será una crisis mañana. Cada dependencia sin actualizar será un security hole la próxima semana. Y cuanto más código no vendido tienes, más mantenimiento te come el tiempo.

Las ventas duelen. La prospección es rechazo. El email que no te responden. La demo que se cancela. Es más fácil refugiarse en el código.

La tentación psicológica cuando las ventas no llegan es construir más. Y ese círculo vicioso es el que te mantiene sin ingresos mientras tu producto crece.

---

✅ El Framework del Solo-Time Budget: 3 Fases para Operadores-Padres

He pasado los últimos meses refinando esto con mis propios productos — gestoriascercademi.com, conversoriaecnae.es, findemergencyplumber.com — y con el tiempo limitado que me deja mi peque de 6 meses.

El resultado es un framework de 3 fases. No es bonito. No es equilibrado. Pero funciona cuando tienes 4 horas al día y no puedes fallar.

Fase 1 — Piso de Ingresos (Semanas 1-4): 3.5h Vender / 0.5h Mantener / 0h Construir

Sí, has leído bien. Cero horas de construcción durante las primeras 4 semanas.

Tu objeción inmediata: "Pero no tengo producto que vender. ¿Cómo voy a dedicar 3.5h a ventas si no tengo nada que mostrar?"

Objeción válida. Pero miope.

Vender no significa vender tu producto SaaS. Vender significa vender tu expertise. Consultoría. Servicios. Implementaciones. Incluso escribir documentación técnica por encargo. El piso de ingresos se construye con lo que ya sabes hacer, no con lo que estás construyendo.

Durante esta fase:

• 3.5h diarias a prospección, llamadas, consultoría, servicios

• 0.5h a mantener sistemas existentes

• Cero construcción de producto nuevo

El objetivo no es código. Es ingresos recurrentes que cubran gastos básicos. Una vez que eso existe, puedes respirar.

Tu segunda objeción: "Mi producto necesita X horas de construcción sí o sí para ser viable. No puedo posponerlo."

Esta objeción revela algo más profundo: si necesitas 200 horas de construcción antes de poder vender, no tienes un problema de tiempo. Tienes un problema de modelo de negocio.

El MVP grande es una falacia. Conozco productos que generaron ingresos con 10 horas de construcción. Si tu producto necesita 200, el problema no es el tiempo. Es que estás construyendo algo demasiado grande para un solo-operator.

Fase 2 — Construcción Protegida (Semanas 5-12): 2h Construir / 1.5h Vender / 0.5h Mantener

Has alcanzado el piso de ingresos. Los clientes de consultoría o servicios te pagan lo suficiente para cubrir lo básico. Ahora puedes redistribuir.

• 2h diarias a construir producto

• 1.5h a vender (manteniendo prospección activa)

• 0.5h a mantenimiento mínimo

La clave de esta fase: las ventas residuales del piso de ingresos te permiten construir sin la urgencia de vender.

No estás construyendo desde cero con el reloj en contra. Estás construyendo desde un colchón. Eso cambia completamente la calidad de tus decisiones técnicas. No tomas atajos. No acumulas deuda técnica por presión. Construyes bien.

"¿Y si las ventas de consultoría empiezan a caer?"

Buena pregunta. Por eso las 1.5h de ventas siguen ahí. No puedes permitirte que el piso se erosione mientras construyes. Si ves que las ventas bajan, paras la construcción y vuelves a fase 1.

Fase 3 — Mantenimiento Automatizado (Semana 13+): 2h Construir / 1.5h Vender / 0.5h Mantener

La gran pregunta: ¿cómo mantienes el mantenimiento en 0.5h diarias?

Automatización. No es opcional. Es la única salida.

• Despliegues automáticos con zero-downtime

• Tests automatizados que atrapan regresiones antes de producción

• Monitoreo con alertas inteligentes (no 50 notificaciones al día, solo las que importan)

• Self-healing donde sea posible: si un servicio cae, que se reinicie solo

El objetivo es que tu sistema aguante sin ti durante horas. Que puedas estar 4 horas en el taller de pintura sin que el móvil vibre cada 10 minutos.

Si no puedes dejar tu producto 8 horas sin supervisión, no tienes un producto. Tienes un trabajo a tiempo completo disfrazado de negocio.

La Regla de Parada Semanal

Esta es la regla que te salva del burnout cuando todo lo demás falla:

Si en una semana has dedicado más de 10 horas a construir sin haber facturado nada nuevo, detente.

No "reduce las horas de construcción". Detente por completo. Vuelve a vender hasta recuperar el piso de ingresos.

El código sin ingresos no es un activo. Es deuda. Y la deuda hay que pagarla antes de acumular más.

---

¿Y el Mantenimiento de Usuarios Existentes?

Tu tercera objeción: "El mantenimiento no es opcional. Mis usuarios actuales dependen de mí."

Cierto. Pero esto solo es un problema si ya tienes usuarios sin tener piso de ingresos. Es el círculo vicioso clásico: construiste antes de validar, ahora tienes mantenimiento que pagar sin ingresos que lo sostengan.

La solución es doble:

1. Automatiza hasta el mínimo viable. Deploy automático, zero-downtime, self-healing. Cada hora que tu sistema pueda funcionar sin ti es una hora que puedes dedicar a vender o construir.

2. Externaliza si puedes permitírtelo. Un desarrollador junior de mantenimiento cuesta menos que tu hora de construcción perdida. Si tu hora de construcción vale más que lo que le pagas a alguien para mantener, externaliza.

---

El Patrón del Constructor Consultor Híbrido

Hay un patrón que veo una y otra vez en solo-operators que realmente lo logran:

Empiezan con 3h de consultoría (vender + mantener) y 1h de producto (construir). El piso de ingresos son las horas de consultoría. Una vez estable, invierten el ratio gradualmente.

Esto contradice la narrativa de "producto desde el día 1" que venden la mayoría de gurús del SaaS. Pero es la realidad del operador que tiene que pagar facturas mientras construye.

La consultoría no es una distracción. Es el combustible que permite construir sin urgencia.

---

La Jerarquía Temporal Que Nadie Te Enseña

Vamos a resumir con claridad. Esta es la jerarquía que deberías tener grabada:

1. El piso de ingresos es el primer objetivo. No el código. No el producto. No la UI bonita.

2. El reparto de tiempo es función del estado financiero, no de preferencias. Si no tienes piso de ingresos, tu tiempo debe ser 90% ventas. Punto.

3. El mantenimiento es deuda que crece con el código no vendido. Cada línea de código que nadie paga es un coste futuro. Minimízala hasta que tengas ingresos que la justifiquen.

4. La regla de parada semanal no es negociable. 10 horas de construcción sin facturación nueva = parar y vender.

5. La automatización no es lujo. Es la única forma de escalar 4 horas diarias. Si tu sistema no sobrevive 8 horas sin ti, no escalas. Sobrevives.

---

La Única Pregunta Que Importa

Mañana tienes 4 horas. Tu hijo se despierta a las 7. A las 11 tienes que recogerlo. Entre medias, puedes elegir.

¿Vas a construir código que nadie ha pagado? ¿O vas a conseguir el cliente que te da libertad para construir sin presión?

La respuesta determina si dentro de 6 meses sigues siendo un solo-operator con deuda técnica acumulada... o si eres dueño de un negocio que funciona mientras tú duermes.

*La elección es tuya. Pero el tiempo no espera.*

Lee el artículo completo en brianmenagomez.com

Más sobre mis servicios en brianmenagomez.com

Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF

La pregunta no es si funciona.

*La pregunta es si estás listo para dejar de ser el que controla. *

El 90% de los desarrolladores que empiezan con Claude Code lo tratan como un ChatGPT con acceso a ficheros.

Le piden que genere una función. Copian el código. Lo pegan. Ejecutan los tests manualmente.

*Eso no es usar Claude Code. Eso es usar un chat con esteroides. *

Claude Code opera en tu terminal con permisos de lectura/escritura sobre tu sistema de ficheros, ejecución de bash, y control total de git. No genera texto que tú ejecutas después — ejecuta él mismo.

Y eso cambia todo.

❌ Uso incorrecto: "Genera un decorador en Python que mida tiempo de ejecución" → copias, pegas, ejecutas manualmente

✅ Uso correcto: "Añade un decorador de logging a todas las funciones del módulo `services/`, ejecuta los tests y haz commit si pasan"

La diferencia no es el modelo. Es quién controla el loop de ejecución.

Para entender por qué esta distinción es tan crítica, tenemos que examinar cómo piensa la mayoría de desarrolladores cuando se enfrentan a una herramienta nueva. Llevamos años usando asistentes de código que funcionan como intérpretes pasivos: escribimos un prompt, obtenemos una respuesta, y luego nosotros decidimos qué hacer con ella. Ese patrón está tan arraigado que la mayoría ni siquiera se plantea que podría funcionar de otra forma.

Pero Claude Code rompe ese esquema por completo. Ya no eres tú quien cierra el círculo entre la generación y la ejecución. Lo hace el agente. Y cuando el agente puede ejecutar, probar y corregir en un solo ciclo, el ritmo de desarrollo se transforma.

Sin embargo, aquí aparece el primer escollo psicológico: soltar el control asusta. A nadie le gusta que una máquina toque su código sin supervisión. Por eso es tan importante entender primero cómo funciona esta arquitectura, y después establecer límites claros.

---

La Arquitectura Que Lo Cambia Todo: Tool-Use Frente a Chat Estático

La mayoría de asistentes de código funcionan igual: reciben un prompt, generan texto, te lo devuelven. Tú decides si copiarlo, ejecutarlo, o ignorarlo.

Eres tú quien cierra el loop.

Claude Code usa una arquitectura de tool-use. El modelo decide dinámicamente qué herramientas invocar según el contexto:

• `Edit` — Lee y escribe ficheros

• `Bash` — Ejecuta comandos en tu terminal

• `Search` — Busca en tu código base

• `Git` — Crea ramas, hace commits, gestiona PRs

El modelo no solo genera una respuesta. Observa el resultado de cada acción y decide el siguiente paso.

```

Tú: "Arregla el test que falla en tests/api.test.js"

Claude Code piensa:

Paso 1: Leer tests/api.test.js → encuentra el test fallido

Paso 2: Ejecutar el test → obtiene el mensaje de error

Paso 3: Leer el código fuente implicado

Paso 4: Identificar el bug (un null no manejado)

Paso 5: Editar el fichero fuente para arreglarlo

Paso 6: Re-ejecutar el test → pasa

Paso 7: Hacer commit con mensaje descriptivo

```

Sin que tú copies, pegues, ni ejecutes nada.

Esto no es incremental. Es un salto categórico. El desarrollador pasa de ser "implementador" a "revisor y aprobador". El cuello de botella ya no es lo rápido que escribes código — es lo rápido que revisas y especificas tareas.

Para visualizar la diferencia, piensa en un editor de texto tradicional frente a un entorno de desarrollo integrado (IDE). El editor solo te deja escribir; el IDE compila, depura y ejecuta. Claude Code hace algo similar, pero llevado al extremo: no solo ejecuta, sino que observa los resultados y ajusta su comportamiento.

Ahora bien, esta capacidad de encadenar acciones tiene un límite importante: el contexto. Si el modelo no sabe nada sobre tu proyecto, sus decisiones serán genéricas. Y las decisiones genéricas rara vez producen buen código.

---

El Contexto Es el Verdadero Cuello de Botella

Aquí está la parte que casi nadie configura bien.

Claude Code no tiene memoria de tu proyecto a menos que se la des explícitamente.

Si abres tu terminal y escribes `claude`, el modelo arranca sin contexto de tu arquitectura, tus convenciones de código, ni tus decisiones de diseño.

El resultado es como pedirle a un freelance que empiece a programar sin leer la documentación del proyecto.

Muchos desarrolladores se frustran porque el código generado no sigue sus patrones habituales. Culpan al modelo. Pero el problema no es el modelo: es la falta de contexto. Le estás pidiendo que acierte a ciegas.

El Patrón CLAUDE.md

Crea un fichero `CLAUDE.md` en la raíz de tu proyecto. Ahí documentas:

```markdown

CLAUDE.md — Proyecto API de Gestoría

Arquitectura

• Next.js 16 con App Router

• API routes en /api/

• Base de datos: Supabase con RLS

• Edge Functions para webhooks

Convenciones de código

• TypeScript estricto, sin `any`

• Props tipadas con interfaces, no types

• Tests en Vitest, cobertura > 80%

• Nombres de carpetas en kebab-case

Estilo

• Funciones flecha exportadas por defecto

• Fetch con React Query, nunca raw fetch

• Errores con ErrorBoundary por ruta

```

Invertir 15 minutos en este fichero multiplica la calidad del output.

Claude Code lo lee al iniciar sesión en el proyecto. Sabe cómo escribes, qué patrones sigues, y qué esperas de él. Sin el `CLAUDE.md`, el modelo adivina. Y adivinar sale caro.

Pero el `CLAUDE.md` no es algo que escribas una vez y olvides. Es un documento vivo. Cada vez que el modelo genera código que no se ajusta a lo que esperabas, esa es una señal de que el contexto necesita mejorar. Tal vez falta una regla sobre cómo manejas los errores, o una convención sobre nombres de variables. Añádelo.

El proceso de iterar este fichero es, en sí mismo, un ejercicio de claridad técnica. Te obliga a articular explícitamente decisiones que antes dabas por supuestas. Y eso no solo mejora el output de Claude Code: también mejora tu propio entendimiento del proyecto.

---

El Framework de 3 Niveles para Usar Claude Code Como un Agente Real

La mayoría empieza pidiéndole que escriba código directamente. Error. El onboarding correcto tiene tres fases:

1. Modo Solo Lectura (Día 1-3)

Antes de darle permisos de escritura, úsalo para entender tu código:

```

"Explícame la arquitectura de este proyecto"

"Encuentra posibles bugs en services/auth.js"

"Resume el flujo de datos en esta ruta API"

"Dime qué dependencias no se están usando"

```

No dejes que toque nada. Solo observa cómo entiende tu base de código.

Si al leer el `CLAUDE.md` ves que interpreta mal decisiones de diseño, mejora el fichero de contexto. Ese proceso de iteración es más valioso que cualquier código que genere.

Durante estos primeros días, presta atención a cómo razona. ¿Entiende bien la separación entre capas? ¿Identifica correctamente los patrones de tu arquitectura? Si ves lagunas, es porque tu `CLAUDE.md` tiene lagunas.

2. Modo Escritura Supervisada (Día 4-7)

Cuando confíes en que entiende el proyecto, pasa a tareas con write pero con revisión manual:

```

"Refactoriza este controlador Express a funciones flecha"

"Añade validación Zod al endpoint POST /api/users"

"Convierte este bucle for a map/filter"

```

Claude Code editará los ficheros directamente. Antes de aceptar, revisa el diff.

Trata el código generado como código de un junior. Rápido, entusiasta, pero necesita supervisión. Si ves patrones incorrectos, corrígelos en el `CLAUDE.md`.

Un consejo práctico: usa herramientas de diff visual como las que ofrece tu editor o tu proveedor de git. Revisa cada cambio línea por línea. Pregúntate: "¿Entiendo por qué ha hecho este cambio? ¿Sigue las convenciones del proyecto? ¿Hay algún efecto secundario que no haya considerado?"

Si respondes "no" a cualquiera de esas preguntas, ese es el momento de parar y ajustar.

3. Modo Autónomo (Día 8+)

El nivel donde Claude Code opera el ciclo completo:

```

"Busca las dependencias sin usar, elimínalas, ejecuta los tests y haz commit si todo pasa"

"Arregla todos los tests que fallen en la carpeta __tests__ y documenta cada fix"

"Añade cobertura de tests para todos los controladores que tengan menos del 60%"

```

Aquí Claude Code ejecuta comandos de bash (`npm ls`, `depcheck`), edita ficheros, ejecuta tests, y hace commit.

*Este es el nivel donde la productividad se multiplica. Y donde el riesgo también. *

Y aquí surge una pregunta incómoda: ¿qué pasa cuando el agente se equivoca? Pasa igual que cuando un compañero se equivoca: revisas, corriges, y aprendes. La diferencia es que Claude Code no se cansa, no se ofende, y puede repetir una tarea cien veces hasta que la haga bien. Eso sí, siempre bajo tu supervisión.

---

La Barrera de Seguridad Que Nadie Te Cuenta

Claude Code puede ejecutar `rm -rf node_modules`, instalar paquetes npm, y hacer force push a tu repo.

¿Te fías?

La mayoría de desarrolladores copian código de Stack Overflow y LLM chats sin pensarlo dos veces. Eso es más peligroso — no hay auditoría, no hay log, no hay revert.

Claude Code tiene un sistema de permisos graduados:

• Read-only: operaciones seguras, sin aprobación

• Write: ediciones de ficheros, requiere confirmación

• Destructive: `git push --force`, `rm -rf`, instalación de paquetes — requiere confirmación explícita

El truco está en definir tu permission boundary:

✅ Auto-aprueba: ediciones de ficheros, ejecución de tests, commits a ramas de feature

❌ Requiere aprobación: instalación de dependencias, operaciones destructivas, push a main

Pero el sistema de permisos no es solo técnico. También es cultural. Si trabajas en equipo, necesitáis acordar qué nivel de autonomía dais al agente. Un equipo donde cada miembro configura sus permisos de forma distinta es un equipo donde el agente se comporta de forma impredecible. Y la impredecibilidad en un entorno de producción es cara.

Una buena práctica: definir un `CLAUDE.md` compartido para el equipo, con las reglas de permisos explícitas. Así todos parten de la misma base y los comportamientos del agente son consistentes.

---

Los Errores Más Comunes de los Primeros 30 Días

Incluso con el mejor `CLAUDE.md` y los permisos bien configurados, los primeros días con Claude Code están llenos de trampas. Estas son las más frecuentes:

1. Prompts ambiguos. Decir "arregla esto" sin especificar qué significa "arreglado". Claude Code ejecutará, pero puede que no haga lo que esperabas. La solución: sé explícito sobre la definición de "hecho". "Arregla esto" → "Arregla el test X para que pase, sin modificar la lógica de negocio".

2. Dejar que toque infraestructura sin supervisión. Los cambios en configuración de despliegue, variables de entorno o dependencias del sistema deberían estar siempre en modo destructivo. Un cambio inocente en un `docker-compose.yml` puede tirar todo un entorno de staging.

3. Olvidar que el contexto se agota. Claude Code tiene un límite de tokens. Si llevas una sesión larga con muchas iteraciones, el modelo empieza a "olvidar" partes del contexto inicial. La solución: cuando notes que la calidad baja, abre una nueva sesión y recarga el `CLAUDE.md`.

4. Ignorar los logs de las acciones. Claude Code registra cada operación que ejecuta. Si algo sale mal, los logs son tu primera fuente de verdad. Acostúmbrate a revisarlos antes de culpar al agente.

---

El Cambio de Rol Que Nadie Está Procesando

Cuando Claude Code ejecuta, el desarrollador revisa. Eso suena simple pero invierte la dinámica del desarrollo.

Antes: escribías 100 líneas, las probabas, las depurabas.

Ahora: escribes 2 líneas de prompt, revisas 100 líneas de código generado, y decides si aceptas o rediriges.

La habilidad más valiosa ya no es escribir código rápido. Es especificar tareas con precisión y revisar código generado con criterio.

Los seniors que entienden la arquitectura del proyecto — que saben qué preguntar y cómo validar el output — obtienen resultados brutales. Los juniors que delegan sin entender producen código que no saben depurar.

*Claude Code no reemplaza el criterio técnico. Lo amplifica. *

El desarrollador que más se beneficia no es el que escribe más código. Es el que entiende mejor su código y puede decirle al agente exactamente qué hacer.

Aquí hay una reflexión importante para los equipos: el senior que antes pasaba el día codeando ahora pasa el día revisando. Eso significa que su rol cambia de "constructor" a "validador". Y si el equipo no ajusta las expectativas, el senior puede sentirse frustrado porque "ya no programa". La realidad es que programa a través del agente, y su valor ahora está en la calidad de la revisión, no en la cantidad de líneas escritas.

Para los juniors, el reto es diferente. Si usan Claude Code sin entender lo que genera, están construyendo una deuda técnica enorme. El agente les da velocidad, pero no les da comprensión. Y la comprensión es lo único que diferencia a un desarrollador que crece de uno que solo ejecuta prompts.

---

Empezar Hoy: Tu Checklist de 5 Pasos

1. Crea un proyecto sandbox. Un directorio vacío, un repo de prueba. Experimenta sin consecuencias.

2. Escribe tu CLAUDE.md. 15 minutos. Patrones, convenciones, stack tecnológico.

3. Empieza en modo read-only. Pídele que analice, no que escriba.

4. Define tu permission boundary. Qué auto-apruebas, qué requieres aprobar.

5. Itera el contexto. Cada vez que veas un output pobre, mejora el `CLAUDE.md`. El fichero de contexto es tu activo más valioso.

Y un sexto paso que no está en ninguna guía oficial: comparte lo que aprendes. El patrón `CLAUDE.md` es nuevo para casi todo el mundo. Si encuentras una forma especialmente buena de documentar convenciones o de estructurar permisos, compártelo con tu equipo. El conocimiento colectivo sobre cómo trabajar con agentes aún se está construyendo, y los que mejor lo entienden ahora serán los que marquen la pauta en los próximos años.

Claude Code no es un chat. No es una herramienta de autocompletado. Es un agente que ejecuta en tu máquina.

La pregunta no es si funciona. La pregunta es si estás listo para trabajar con él en lugar de contra él.

Y la respuesta, como casi siempre en desarrollo, no está en la herramienta. Está en cómo decides usarla.

Lee el artículo completo en brianmenagomez.com

Más sobre mis servicios en brianmenagomez.com

Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF

Crees que tu problema es que no tienes tiempo para construir producto. Tu problema real es que no tienes un piso de ingresos que te lo permita.

Te levantas. Abres el portátil. Tienes tres reuniones de ventas, dos llamadas de soporte a clientes legacy, y un entregable freelance que prometiste ayer.

Son las siete de la tarde. No has escrito ni una línea de código para tu producto.

*El problema no es tu productividad. El problema es que no tienes un solo-revenue floor.*

Llevo cuatro años operando así. He montado conversoriaecnae.es, gestoriascercademi.com, findemergencyplumber.com, Jurídica Integral, Grot, Módulos-IRPF. Todos mientras pintaba coches cuatro horas al día en un taller de Málaga y cuidaba a mi peque de seis meses.

Y el patrón se repite siempre: los que fracasan construyen antes de facturar. Los que sobreviven facturan antes de construir.

El problema de fondo es más profundo de lo que parece. No se trata de organización personal ni de dominar técnicas de productividad. Se trata de una decisión estructural sobre cómo distribuyes tu energía cuando tu tiempo es limitado. Si trabajas solo, cada hora que dedicas a una cosa la estás robando de otra. Y cuando esa otra es la que paga las facturas, el robo tiene consecuencias inmediatas.

La mayoría de operadores solos que conozco no fracasan porque su producto sea malo. Fracasan porque se quedan sin margen antes de terminarlo. Y ese margen no es solo económico: es margen mental, margen de atención, margen para poder decir "no" a una urgencia de servicio para decir "sí" a una feature que necesita tres horas seguidas de concentración.

Por eso he decidido escribir esto. No como teoría, sino como el marco que he aplicado una y otra vez en cada proyecto que he lanzado. Algunos han funcionado. Otros no. Pero todos compartían una misma variable: cuando tenía el piso de ingresos resuelto, el producto salía. Cuando no, el producto se quedaba a medio camino.

La Trampa del Constructor que No Factura

Cada semana veo a decenas de operadores solos repitiendo el mismo error. Abren un proyecto nuevo. Configuran Next.js. Despliegan una landing page. Integran Stripe. Escriben el backend durante tres semanas.

Y entonces se dan cuenta de que no tienen ni un solo cliente esperando.

Scott Perry lo explica bien en Creative on Purpose: el crecimiento por el crecimiento es una solución en busca de un problema. Pero aquí el problema es más básico. No es que tengas los suscriptores equivocados. Es que no tienes ingresos que te compren tiempo.

Cuando no tienes solo-revenue floor, cada hora que dedicas a producto es una hora que NO dedicas a conseguir el próximo cliente de servicio.

El resultado es predecible:

❌ Construyes en vacío. Sin feedback de clientes reales, tu producto resuelve problemas que nadie tiene.

❌ Te quedas sin caja. El dinero de tus ahorros se acaba antes de que el producto genere su primer euro.

❌ Abandonas. No es que el producto sea malo. Es que no tenías el margen financiero para terminarlo.

Pero hay una cuarta consecuencia que es más sutil y más peligrosa: el desgaste de la reputación. Cuando lanzas un producto a medias porque te quedaste sin tiempo, ese producto lleva tu nombre. Los primeros usuarios que confiaron en ti no volverán a hacerlo. Y en un mercado donde la confianza es el activo más escaso, quemarla por prisas es un error que pagas durante años.

El LinkedIn de 2026 lo confirma: los algoritmos premian la consistencia, no la perfección. Pero tú no puedes ser consistente si estás alternando entre "construir producto" y "conseguir el siguiente cliente de servicio" como si fueran dos trabajos distintos.

La consistencia de la que hablan los gurús no es solo publicar tres veces por semana. Es tener la capacidad de aparecer cada día con la misma energía, el mismo foco, la misma calidad. Y eso es imposible cuando tu atención está dividida entre dos frentes que compiten directamente por tu tiempo.

Fíjate en el patrón de los que realmente lo logran: no son los que construyen más rápido. Son los que tienen la libertad de construir sin urgencia. Los que pueden permitirse iterar, equivocarse, y volver a intentarlo porque saben que el dinero de este mes ya está cubierto.

Qué Es el Solo-Revenue Floor (Y Por Qué el 90% lo Calcula Mal)

El solo-revenue floor es el número mínimo de clientes recurrentes de servicio que necesitas tener antes de poder dedicar el 100% de tu tiempo operativo a construir producto.

La mayoría lo calcula así: "necesito X euros al mes para vivir". Miran sus gastos. Suman. Dividen entre el precio de su servicio. Y ese es su número.

*Ese cálculo no funciona.*

Porque no consideras tres factores que solo un operador con hijos, taller de pintura y clientes reales conoce:

1. El coste de adquisición no es cero cuando dejas de vender.

Si hoy dejas de prospectar para construir producto, dentro de dos meses no tendrás nuevos clientes de servicio. Tu pipeline se seca. Y cuando vuelvas a necesitar vender servicios, arrancar de cero cuesta el doble. No solo porque has perdido contacto con tu red, sino porque tu "músculo de ventas" se ha atrofiado. Las primeras semanas de reincorporación son siempre las más difíciles: los guiones suenan robóticos, las objeciones te pillan desprevenido, y cierras menos de lo que esperabas.

2. La moral no es lineal.

Los primeros quince días sin ingresos nuevos no duelen. El día treinta empiezas a mirar el saldo. El día cuarenta y cinco dejas de dormir bien. Y el código que escribes con ansiedad no es código que quieras desplegar en producción.

He visto a operadores talentosos cometer errores garrafales en producción simplemente porque estaban acelerados, porque no podían permitirse el lujo de probar dos veces, porque cada deploy fallido significaba un día más sin ingresos. La ansiedad no solo afecta a tu salud: afecta a la calidad de tu trabajo de una forma que tus usuarios notan inmediatamente.

3. El soporte a clientes existentes no desaparece.

Aunque dejes de tomar nuevos clientes de servicio, los que ya tienes siguen necesitándote. Y un cliente legacy insatisfecho puede costarte más tiempo que diez clientes nuevos contentos.

He visto a operadores perder semanas enteras apagando incendios de clientes antiguos mientras su producto nuevo se pudría en un repositorio. El cliente legacy no entiende que estás construyendo algo nuevo. Él pagó por un servicio y espera recibirlo. Y tiene razón. El problema no es suyo: es tuyo, por no haber dimensionado correctamente cuánta atención ibas a necesitar para mantenerlo satisfecho mientras construías.

El Framework del Solo-Revenue Floor: 3 Capas para Salir del Bucle

No te voy a dar teoría. Te voy a dar el marco que uso para decidir cuándo puedo permitirme construir producto sin arruinarme. Son tres capas que funcionan como filtros: si no cumples la primera, ni siquiera mires la segunda. Si no cumples la segunda, no llegues a la tercera. Y si no cumples la tercera, cierra el editor de código y vuelve a vender.

1. El Piso de Supervivencia (Capa 1)

Este es el número que la mayoría conoce, pero calcula mal.

Identifica el ingreso mínimo que cubre tus gastos fijos + 3 meses de colchón operativo. Eso incluye:

• Tu retirada personal (lo mínimo que necesitas para vivir)

• Los costes de tu stack técnico (dominios, servidores, APIs, herramientas)

• Un buffer del 30% para imprevistos (el cliente que no paga, la API que sube el precio, el ordenador que se rompe)

✅ Multiplica ese número por 1.5. Ese es tu piso real.

Porque cuando construyas producto, tendrás gastos imprevistos que hoy no ves. Y el margen del 50% es lo que te permite decir "no" a un cliente de servicio urgente para terminar una feature crítica.

No es un cálculo conservador. Es un cálculo realista. He visto a demasiados operadores calcular su piso justo al límite, y luego una subida de precios de una API que usaban o un cliente que retrasó el pago los dejó sin margen en el peor momento posible. El margen del 50% no es para gastar: es para respirar.

2. El Techo de Retención (Capa 2)

Tus clientes actuales no son eternos. Si dejas de vender durante tres meses, una parte se irá.

Calcula tu tasa de abandono mensual natural. Si pierdes un 5% de clientes al mes incluso cuando estás operando al 100%, cuando dejes de dedicar tiempo a retenerlos, esa tasa subirá.

Tu solo-revenue floor necesita tener al menos un 30% más de clientes de los que necesitas realmente.

*Ese 30% es tu colchón de abandono.*

Si necesitas 10 clientes para cubrir gastos, no empieces a construir producto hasta que tengas 13. Los 3 que se irán durante los dos meses de desarrollo son tu margen de error.

Este colchón no es opcional: es estructural. Durante el tiempo que construyes producto, tu atención está dividida. No estás haciendo el seguimiento que solías hacer. No estás enviando esos correos de valor añadido. No estás resolviendo incidencias con la misma velocidad. Y los clientes lo notan. Algunos se irán. No porque estén enfadados, sino porque simplemente dejas de estar presente.

El 30% adicional no es para cubrir gastos: es para cubrir esa pérdida natural de atención.

3. La Barrera de Atención (Capa 3)

Esta es la capa que nadie menciona y la que más duele.

Cada cliente de servicio consume atención. No solo tiempo de entrega, sino energía mental. Una llamada de soporte de quince minutos puede arruinar tu bloque de concentración de tres horas para codificar.

Cuando calcules tu solo-revenue floor, necesitas saber cuánta atención consume cada cliente.

El cálculo es sencillo:

• Cliente servicio bajo mantenimiento: consume 1 unidad de atención al mes

• Cliente servicio con entregas activas: consume 3 unidades de atención al mes

• Cliente legacy problemático: consume 5 unidades de atención al mes

Tu capacidad máxima de atención, si trabajas solo y con familia, es de 12 unidades al mes (4 horas/día de taller × 30 días, dividido entre lo que necesitas para codificar).

Cuando estés en modo construcción de producto, necesitas como mínimo 6 unidades libres al mes para poder enfocarte.

*Traducción: no puedes tener más de 6 unidades de atención ocupadas por clientes si quieres construir producto.*

Y aquí está la parte más difícil: las unidades de atención no son lineales. Un día malo puede consumir 3 unidades de atención en una sola hora. Una discusión con un cliente, un error en producción, una urgencia familiar. La atención no es un recurso que puedas estirar. Es un recurso que, cuando se agota, se agota para todo el día. No puedes engañar a tu cerebro para que rinda igual después de una interrupción emocionalmente costosa.

Por eso la capa 3 no es solo sobre cuántos clientes tienes, sino sobre qué tipo de clientes tienes. Un cliente de bajo mantenimiento al que ves una vez al mes no es lo mismo que un cliente que te llama cada semana con urgencias. Y en modo construcción, deberías aspirar a tener solo clientes del primer tipo.

Cómo Aplicarlo: El Caso de un Operador Cualquiera

Pongamos que eres un solo-operator. Tienes 5 clientes de servicio que te generan ingresos recurrentes. Cada uno consume 2 unidades de atención al mes (entregas mensuales con revisiones).

Estás usando 10 de tus 12 unidades de atención disponibles. No puedes construir producto. No tienes margen.

Tu objetivo: llegar a 7 clientes de servicio que consuman menos de 1 unidad de atención cada uno. Productizas la entrega. Automatizas el reporting. Pones un chatbot de IA para el soporte básico.

De repente, con 7 clientes consumes solo 5 unidades de atención. Tienes 7 libres para producto.

*Has encontrado tu solo-revenue floor.*

No es un número de clientes. Es una relación entre ingresos, atención y capacidad de construcción.

Y este es el punto que la mayoría no entiende: puedes tener más clientes y menos carga de atención. La clave no es reducir clientes. Es reducir la atención que cada cliente consume. Por eso la productización del servicio no es opcional: es el mecanismo que te permite escalar tu capacidad de atención sin escalar tu tiempo.

Imagina el caso contrario. Tienes 4 clientes, pero cada uno consume 3 unidades de atención porque son proyectos personalizados con entregas semanales y revisiones constantes. Estás usando 12 de 12 unidades. No tienes margen para nada. Estás atrapado. Ganas suficiente dinero para vivir, pero no tienes ni un minuto para construir otra cosa.

Ese es el infierno del que nadie habla: tener ingresos suficientes pero cero libertad. Y la libertad no la da el dinero: la da la atención no comprometida.

El Orden Correcto: Primero Factura, Luego Construye

El framework se resume en tres pasos. Hazlos en orden. No te saltes ninguno.

Paso 1: Consigue suficientes clientes de servicio que cubran tu piso de supervivencia × 1.5.

No empieces a construir hasta que este paso esté consolidado. Y "consolidado" significa que los ingresos llevan entrando al menos dos meses de forma consistente. No vale un mes bueno seguido de otro malo. Necesitas ver el patrón.

Paso 2: Añade un 30% más de clientes para cubrir el abandono durante la fase de construcción.

Este paso es el que más duele porque requiere vender más cuando ya tienes suficiente. Pero es precisamente ese excedente el que te da la tranquilidad para construir. Sin él, cada cliente que se va es una emergencia. Con él, es un dato más.

Paso 3: Automatiza la entrega de esos clientes hasta que consuman menos de la mitad de tu capacidad de atención.

Invierte el tiempo que sea necesario en productizar: plantillas, procesos documentados, chatbots, dashboards automatizados, informes generados automáticamente. Cada hora que inviertas aquí te devuelve horas de atención para construir producto.

Solo entonces abre el editor de código.

Y cuando lo hagas, establece un período de construcción con fecha de finalización. No puedes estar construyendo para siempre. Tres meses es un buen límite. Si en tres meses no has lanzado nada, algo está mal en tu enfoque. O tu producto es demasiado grande, o no estás priorizando bien, o en realidad no necesitas ese producto.

No Construyas Tu Castillo Sobre Arena

El LinkedIn de 2026 premia la consistencia. Los LLM y agentes de IA aceleran la construcción de producto. Las Edge Functions permiten desplegar en minutos. Nunca ha sido más fácil lanzar software.

*Pero la facilidad para construir es una trampa si no tienes el suelo bajo los pies.*

El solo-revenue floor no es un concepto teórico. Es la línea roja que separa al operador que construye con calma del que construye con el agua al cuello.

Yo lo aprendí con mi peque de seis meses y cuatro horas diarias en el taller de pintura. Cuando construyes con tiempo limitado, no puedes permitirte el lujo de adivinar. Necesitas certezas.

*La certeza de que, pase lo que pase con tu producto, los clientes de servicio siguen pagando las facturas.*

La certeza de que tienes margen para iterar, equivocarte, y volver a intentarlo.

Esa certeza se llama solo-revenue floor.

Y no es un número bonito en una hoja de cálculo. Es el permiso que te das a ti mismo para construir sin miedo.

Cada vez que veo a un operador solo lanzando un producto sin tener este piso resuelto, sé lo que va a pasar. No porque sea adivino, sino porque lo he vivido cuatro veces. Y las cuatro veces que lo hice sin piso, el proyecto murió. Las tres veces que esperé a tenerlo, el proyecto sobrevivió.

No es complicado. Es disciplina. Tener el número claro. No saltarse los pasos. Y recordar que, cuando trabajas solo, tu atención es tu activo más valioso. Protégela como si de ella dependiera tu proyecto. Porque así es.

Lee el artículo completo en brianmenagomez.com

Más sobre mis servicios en brianmenagomez.com

Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF

Imagina contratar a un empleado que olvida todo lo que hizo ayer cada mañana.

Que no recuerda que ya probasteis la solución X y falló. Que cada conversación empieza desde cero. Que repite los mismos errores una y otra vez.

Eso es exactamente lo que estamos haciendo con el 90% de los AI agents hoy.

Los entrenamos en benchmarks de inteligencia. Razonamiento, coding, matemáticas. Pero les negamos el derecho a recordar.

*El verdadero cuello de botella no es la inteligencia del modelo. Es la arquitectura de memoria que persiste contexto entre sesiones. *

GPT-4, Claude, Gemini — todos son igual de amnésicos. El problema no es el cerebro del agente. Es que nadie le está construyendo un sistema de memoria externo.

Y en 2026, si tu agente no recuerda lo que hizo hace cinco minutos, es funcionalmente inútil para cualquier tarea del mundo real que requiera persistencia.

La Amnesia Estructural de los LLMs: Por Qué el Contexto No Es Suficiente

Los LLMs no tienen memoria inherente.

Cada invocación comienza desde cero a menos que inyectes explícitamente el historial. Y aquí es donde la mayoría de desarrolladores meten la pata.

❌ El enfoque equivocado: meter toda la ventana de contexto del modelo como memoria. "El modelo soporta 200k tokens, pues le paso todo el historial."

✅ El enfoque real: memoria selectiva, estructurada en capas, con retrieval optimizado. No más contexto bruto — mejor contexto relevante.

Los modelos sufren de lost in the middle: la información en el centro de ventanas largas se pierde. Además, el coste cuadrático de atención hace que ventanas enormes sean prohibitivamente caras.

*La memoria selectiva y estructurada siempre gana a la memoria bruta. *

El Framework de 3 Capas: Short-Term, Long-Term y Episodic Memory

La solución no es un único sistema de memoria. Son tres capas independientes que trabajan juntas.

1. Short-Term Memory (Working Memory): El Buffer de Contexto Inmediato

Es la memoria de trabajo del agente. El contexto inmediato de la conversación actual.

Pero no se trata solo de recortar tokens viejos. Hay que decidir qué se evicciona primero.

Una estrategia naive elimina los mensajes más antiguos. Eso puede borrar información crítica: instrucciones del usuario, decisiones clave, contexto de una tarea en curso.

La solución es rankear por relevancia semántica, no por orden cronológico.

```python

import tiktoken

from collections import deque

from typing import List, Dict

class ShortTermMemory:

\"\"\"Buffer circular con evicción por relevancia semántica\"\"\"

def __init__(self, max_tokens: int = 4000):

self.max_tokens = max_tokens

self.buffer: deque = deque()

self.encoder = tiktoken.get_encoding("cl100k_base")

def add(self, message: Dict[str, str], priority: int = 0):

\"\"\"Añade un mensaje con prioridad. Prioridad alta = menos probable de ser eviccionado.\"\"\"

self.buffer.append({"message": message, "priority": priority})

self._evict_if_needed()

def _evict_if_needed(self):

\"\"\"Evicciona mensajes de menor prioridad si se supera el límite de tokens\"\"\"

while self._total_tokens() > self.max_tokens:

Encuentra el mensaje de menor prioridad (no crítico)

lowest = min(self.buffer, key=lambda x: x["priority"])

self.buffer.remove(lowest)

def _total_tokens(self) -> int:

total = 0

for item in self.buffer:

content = f"{item['message']['role']}: {item['message']['content']}"

total += len(self.encoder.encode(content))

return total

def get_context(self) -> List[Dict[str, str]]:

return [item["message"] for item in self.buffer]

```

El truco está en las prioridades. Las instrucciones del sistema tienen prioridad máxima. Los mensajes del usuario que contienen decisiones clave, prioridad alta. El chit-chat, prioridad baja.

2. Long-Term Memory (Persistent Knowledge): Vectorizar para Recordar

Esta capa responde a: ¿qué sé yo sobre este usuario?

Hechos, preferencias, datos históricos. Se almacena en una base de datos vectorial y se recupera automáticamente al inicio de cada sesión.

Usamos ChromaDB por simplicidad local. Qdrant si necesitas escalar.

```python

import chromadb

from chromadb.utils import embedding_functions

class LongTermMemory:

\"\"\"Memoria persistente con retrieval semántico\"\"\"

def __init__(self, collection_name: str = "user_memory"):

self.client = chromadb.Client()

self.collection = self.client.get_or_create_collection(

name=collection_name,

embedding_function=embedding_functions.DefaultEmbeddingFunction()

)

def store_interaction(self, user_id: str, interaction: str, metadata: dict = None):

\"\"\"Vectoriza y almacena una interacción clave\"\"\"

self.collection.add(

documents=[interaction],

metadatas=[metadata or {}],

ids=[f"{user_id}_{hash(interaction)}"]

)

def retrieve_relevant(self, user_id: str, query: str, n_results: int = 5) -> list:

\"\"\"Recupera las interacciones más relevantes para el contexto actual\"\"\"

results = self.collection.query(

query_texts=[query],

n_results=n_results,

where={"user_id": user_id}

)

return results["documents"][0] if results["documents"] else []

```

Cada interacción significativa se vectoriza. Al inicio de cada sesión, injectas las 3-5 más relevantes al contexto del LLM.

*El retrieval pipeline es el nuevo cuello de botella. * Tener 10 millones de experiencias no sirve de nada si no puedes recuperar las 3 más relevantes en tiempo real.

Usa índices HNSW en tu vector database. Un retrieval optimizado añade ~50-100ms. Aceptable para mantener la fluidez.

3. Episodic Memory: Aprender de Experiencias Pasadas

Esta es la capa que diferencia a los agents mediocres de los que realmente aprenden.

La memoria episódica responde a: ¿qué ha pasado antes en esta relación?

No solo almacena hechos. Almacena experiencias.

• La última vez que el usuario pidió X, eligió Y.

• La solución A funcionó, la solución B falló.

• El usuario prefiere respuestas concisas por la mañana y detalladas por la tarde.

Sin memoria episódica, el agente trata cada interacción como un primer encuentro. Imposibilita construir rapport o contexto progresivo.

```python

import sqlite3

import json

from datetime import datetime

class EpisodicMemory:

\"\"\"Memoria episódica con metadatos temporales y outcomes\"\"\"

def __init__(self, db_path: str = "episodic_memory.db"):

self.conn = sqlite3.connect(db_path)

self._create_table()

def _create_table(self):

self.conn.execute("""

CREATE TABLE IF NOT EXISTS episodes (

id INTEGER PRIMARY KEY AUTOINCREMENT,

user_id TEXT NOT NULL,

timestamp TEXT NOT NULL,

context TEXT NOT NULL,

action TEXT NOT NULL,

outcome TEXT NOT NULL,

user_feedback TEXT,

metadata TEXT

)

""")

self.conn.commit()

def store_episode(self, user_id: str, context: str, action: str,

outcome: str, user_feedback: str = None):

\"\"\"Almacena una experiencia completa\"\"\"

self.conn.execute(

"INSERT INTO episodes (user_id, timestamp, context, action, outcome, user_feedback) "

"VALUES (?, ?, ?, ?, ?, ?)",

(user_id, datetime.now().isoformat(), context, action, outcome, user_feedback)

)

self.conn.commit()

def get_similar_episodes(self, user_id: str, context_query: str, limit: int = 3) -> list:

\"\"\"Recupera episodios relevantes por patrón de contexto\"\"\"

En producción usarías embeddings. Aquí búsqueda por keyword como ejemplo.

cursor = self.conn.execute(

"SELECT * FROM episodes WHERE user_id = ? ORDER BY timestamp DESC LIMIT ?",

(user_id, limit)

)

return cursor.fetchall()

```

La clave está en el campo `outcome`. Cuando el agente almacena no solo lo que hizo, sino si funcionó o no, puede evitar repetir errores.

Un agente de soporte técnico con memoria episódica:

• Recuerda que el usuario ya probó el paso A y falló.

• No sugiere la misma solución fallida.

• Pasa directamente al paso alternativo.

Esto no es un problema de razonamiento. Es un problema de arquitectura de memoria.

Integrando las 3 Capas: El Gestor de Memoria Unificado

Cada capa por separado es útil. Juntas, son transformadoras.

```python

from typing import List, Dict

class MemoryManager:

\"\"\"Gestor unificado de las 3 capas de memoria\"\"\"

def __init__(self):

self.short_term = ShortTermMemory(max_tokens=4000)

self.long_term = LongTermMemory()

self.episodic = EpisodicMemory()

def prepare_context(self, user_id: str, current_query: str) -> List[Dict[str, str]]:

\"\"\"Prepara el contexto óptimo para la invocación del LLM\"\"\"

1. Contexto inmediato de la conversación actual

working_context = self.short_term.get_context()

2. Conocimiento persistente del usuario

relevant_knowledge = self.long_term.retrieve_relevant(user_id, current_query)

3. Lecciones de experiencias pasadas

past_episodes = self.episodic.get_similar_episodes(user_id, current_query)

Construir el contexto enriquecido

augmented_context = []

Inyectar conocimiento de largo plazo como system context

if relevant_knowledge:

augmented_context.append({

"role": "system",

"content": f"Información relevante del usuario: {' '.join(relevant_knowledge)}"

})

Inyectar lecciones episódicas

if past_episodes:

lessons = self._format_episodes(past_episodes)

augmented_context.append({

"role": "system",

"content": f"Experiencias previas relevantes: {lessons}"

})

Añadir el contexto de trabajo actual

augmented_context.extend(working_context)

return augmented_context

def record_interaction(self, user_id: str, query: str, response: str,

outcome: str, feedback: str = None):

\"\"\"Registra la interacción en todas las capas\"\"\"

Short-term se actualiza automáticamente

self.short_term.add({"role": "user", "content": query}, priority=5)

self.short_term.add({"role": "assistant", "content": response}, priority=3)

Long-term: vectorizar si es información relevante

if len(query) > 20: # Umbral de relevancia

self.long_term.store_interaction(user_id, f"Q: {query} A: {response}")

Episodic: almacenar la experiencia completa

self.episodic.store_episode(user_id, query, response, outcome, feedback)

```

El gestor decide qué inyectar en cada invocación según la tarea actual. No todo el historial — solo lo relevante.

Por Qué Esto No Es un Problema de Modelos, Sino de Arquitectura

La obsesión con benchmarks de inteligencia ha cegado a la industria.

Cada nuevo modelo promete mejor razonamiento, mejor coding, mejor seguimiento de instrucciones. Y sí, son mejores. Pero todos son igual de amnésicos.

*Un agente que no recuerda lo que hizo hace 5 minutos es funcionalmente inútil para cualquier tarea que requiera persistencia. *

El 90% de los casos de uso reales requieren continuidad:

• Soporte técnico multi-turno.

• Asistentes de ventas con seguimiento.

• Agentes personales que aprenden de tus preferencias.

• Sistemas de onboarding que recuerdan dónde se quedó el usuario.

Sin arquitectura de memoria, estos casos de uso colapsan.

Cómo Empezar Hoy

No necesitas un modelo más grande. Necesitas mejor arquitectura de memoria.

Primero: audita la amnesia actual. Identifica qué información crítica se pierde entre sesiones de tu agente.

Segundo: implementa la capa de Short-Term Memory con evicción por relevancia, no por orden cronológico. Es la más fácil y la que más impacto inmediato da.

Tercero: añade Long-Term Memory con ChromaDB o Qdrant. Vectoriza las interacciones clave y haz retrieval automático al inicio de cada sesión.

Cuarto: incorpora la capa episódica con SQLite. Cada experiencia debe incluir timestamp, outcome y user feedback. Ahí está el aprendizaje real.

Quinto: integra las tres capas en un solo gestor de memoria que decida qué inyectar en cada invocación según la tarea.

*El futuro de los AI agents no está en modelos más inteligentes. Está en agents que recuerdan. *

La pregunta no es si tu agente puede razonar mejor. La pregunta es: ¿va a recordar lo que hizo ayer?

Si la respuesta es no, tienes un problema de arquitectura. Y ya sabes cómo solucionarlo.

Lee el artículo completo en brianmenagomez.com

Más sobre mis servicios en brianmenagomez.com

Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF

Crees que construir un supervisor de agentes es cuestión de lógica programática. State machines. Grafos acíclicos dirigidos. If-else anidados. Workflows definidos paso a paso.

*Te has equivocado de diagnóstico.*

El 90% de los equipos que implementan el patrón supervisor construyen exactamente lo contrario de lo que deberían: microgestores de software.

Un gerente real no le dice a su equipo "escribe el primer párrafo, ahora busca la fuente, ahora dale formato". Le dice: "necesito un informe sobre X para el viernes". Define el qué. El equipo decide el cómo.

Tu supervisor de agentes debería funcionar igual. Pero has construido un jefe que respira en la nuca de sus sub-agentes.

---

El Error No Es Técnico. Es de Diseño.

Lo que la mayoría cree

El patrón supervisor se explica así: un agente "supervisor" que orquesta varios sub-agentes especializados. Cada sub-agente hace una tarea concreta. El supervisor decide quién hace qué y en qué orden.

Suena limpio. Suena profesional.

Pero la implementación típica es un desastre.

La mayoría construye supervisores con DAGs (grafos acíclicos dirigidos) o state machines. Definen nodos. Conectan aristas. Establecen condiciones de transición. El resultado es un monstruo de lógica secuencial que:

• Se rompe si un sub-agente devuelve algo inesperado.

• Requiere recompilar todo el grafo para añadir un nuevo sub-agente.

• Microgestiona cada paso como si los sub-agentes fueran becarios sin criterio.

❌ Supervisor típico (microgestor):

• Define paso 1, paso 2, paso 3 secuencialmente.

• Asume que cada paso se completa correctamente.

• Si algo falla, el grafo entero se para.

• Cambiar la lógica requiere modificar código y redeployar.

✅ Supervisor efectivo (delegador):

• Recibe un objetivo de alto nivel.

• Decide qué sub-agentes invocar según el contexto.

• Evalúa resultados antes de decidir el siguiente paso.

• Puede re-planificar si un sub-agente falla.

Lo contraintuitivo

El supervisor más robusto que he visto en producción para SMBs no tiene lógica programática rígida. Es un LLM con un prompt bien diseñado que delega intenciones de alto nivel a sub-agentes especializados.

Cada sub-agente decide cómo ejecutar. El supervisor solo decide qué se necesita y quién lo hace.

La complejidad se traslada del código al prompt. Y eso, para una SMB sin equipo de ML, es una ventaja, no una limitación.

---

La Evidencia: El Caso del Supervisor que Delegaba Intenciones

Construí un sistema de orquestación para un flujo de facturación recurrente. Un supervisor recibía consultas como: "necesito una factura para el cliente X con los datos de la última reunión".

El supervisor no tenía un grafo predefinido con pasos. Tenía acceso a tres sub-agentes:

1. Agente CRM — buscaba datos del cliente.

2. Agente de notas — recuperaba el resumen de la última reunión.

3. Agente de generación PDF — ensamblaba y emitía la factura.

El supervisor no decidía el orden. Decidía la intención: "esto requiere datos de cliente, contexto de reunión y generación de documento". Llamaba a los sub-agentes según lo que el contexto demandaba.

El resultado: el mismo supervisor manejaba consultas que no había visto antes sin tocar una línea de código. Si llegaba "quiero una factura pero solo con los datos fiscales, sin notas de reunión", el supervisor omitía el agente de notas automáticamente.

*Eso no pasa con un DAG predefinido.*

---

El Marco: El Patrón de Delegación por Intención

He llamado a esto el Marco de Delegación por Intención. Son 5 pasos. No necesitas LangChain, ni CrewAI, ni un grafo de nodos. Necesitas un prompt bien escrito y herramientas bien definidas.

Paso 1: Define los límites de cada sub-agente

Cada sub-agente debe tener una tool description clara que el supervisor pueda leer. No escribas "este agente busca clientes". Escribe:

```

Busca clientes en el CRM por nombre o NIF.

Devuelve: id_cliente, nombre, email, dirección fiscal.

Si no encuentra coincidencias exactas, devuelve las 3 más probables.

No modifica datos del CRM.

```

El supervisor necesita saber qué puede esperar de cada sub-agente. Si la descripción es vaga, el supervisor improvisará. Y improvisar con LLMs sale caro.

Paso 2: Diseña el prompt del supervisor como un cerebro ejecutivo

El prompt del supervisor NO es una lista de pasos. Es una declaración de:

• Objetivo: qué se espera del sistema en conjunto.

• Recursos: qué sub-agentes están disponibles y qué hace cada uno.

• Reglas de derivación: cuándo escalar a un humano.

Ejemplo mínimo de cómo se estructura el prompt:

```python

SUPERVISOR_PROMPT = """

Eres un supervisor de operaciones administrativas.

Tu objetivo es completar tareas del usuario delegando a los sub-agentes disponibles.

Sub-agentes disponibles:

• buscar_cliente: busca clientes en el CRM

• recuperar_notas: obtiene el resumen de la última reunión con un cliente

• generar_pdf: crea y envía una factura en PDF

Reglas:

• Si un sub-agente no encuentra datos, intenta con otra estrategia antes de escalar.

• Si después de 2 intentos no hay solución, escala al humano con un resumen del problema.

• No preguntes al usuario pasos intermedios. Resuelve y presenta el resultado final.

El usuario te dirá qué necesita. Tú decides qué sub-agentes usar y en qué orden.

"""

```

Sin if-else. Sin grafos. Sin state machines.

Paso 3: Implementa el bucle de verificación

El supervisor no debe asumir que un sub-agente devolvió lo correcto. Debe verificar antes de pasar al siguiente paso.

Ejemplo en pseudocódigo:

```python

def ejecutar_tarea(consulta_usuario):

plan = supervisor.decide_subagentes(consulta_usuario)

resultados = {}

for subagente in plan:

resultado = subagente.ejecutar()

El supervisor evalúa si el resultado es válido

if not supervisor.verificar_resultado(resultado):

Re-planifica: ¿otro subagente? ¿misma tarea con parámetros diferentes?

nuevo_plan = supervisor.replanificar(consulta_usuario, resultados)

if not nuevo_plan:

return escalar_a_humano(resultados)

resultados.update(ejecutar_tarea_parcial(nuevo_plan))

else:

resultados[subagente.id] = resultado

return resultados

```

El bucle de verificación es lo que separa un supervisor robusto de uno frágil. Sin él, cualquier error de un sub-agente propaga al resultado final.

Paso 4: Establece el mecanismo de fallback humano

El supervisor debe saber cuándo rendirse. No hay nada peor que un agente dando vueltas en círculos gastando tokens.

Reglas claras:

• Si un sub-agente falla dos veces seguidas, escala.

• Si el resultado no pasa validaciones básicas (formato, campos obligatorios), escala.

• Si el usuario pide algo que ningún sub-agente puede hacer, escala.

El fallback humano debe ser explícito: un canal de Slack, un email, un webhook. No un "lo intentaré más tarde" que se queda en el aire.

Paso 5: Mide la tasa de delegación exitosa

Cada vez que el supervisor escala a un humano, es un fracaso del sistema. Pero también es datos.

Mide:

• Tasa de delegación exitosa: % de tareas completadas sin intervención humana.

• Motivos de escalado: ¿qué tipo de consultas fuerzan el fallback? Ahí tienes tu roadmap de mejora.

• Coste por tarea: cuántos tokens consume cada ejecución completa.

Si tu tasa de delegación exitosa está por debajo del 70%, el problema no es el supervisor. Es la definición de los sub-agentes o la calidad de sus tool descriptions.

---

Por Qué las SMBs Se Benefician Más de Este Enfoque

Las grandes empresas tienen equipos de ML para debuggear cadenas de agentes complejas. Pueden permitirse 15 micro-agentes conectados con pipelines diferentes.

Las SMBs no.

Para una gestoría, un despacho de abogados o una asesoría freelance, el patrón supervisor debe ser:

• Observable: saber en todo momento qué está haciendo el supervisor y por qué.

• Predecible: que no haga cosas raras porque el prompt tiene un fallo oculto.

• Mantenible: que lo pueda tocar el dueño del negocio, no solo un ingeniero.

Un supervisor con un solo prompt monolítico es más fácil de auditar que 15 agentes encadenados. La simplicidad no es una limitación. *Es un feature.*

---

Los Riesgos Reales (y Cómo Mitigarlos)

Latencia y coste

Cada llamada del supervisor a un sub-agente implica una ida y vuelta al LLM. Si el supervisor microgestiona ("¿terminaste?", "¿qué sigue?", "¿estás seguro?"), los costes se disparan.

La solución no es técnica. Es de diseño.

El supervisor debe delegar tandas de trabajo completas, no pasos individuales. En vez de preguntar "busca el cliente" y esperar, debe decir "busca el cliente, recupera sus datos fiscales y prepara el borrador de factura". Un solo viaje de ida y vuelta.

Supervisores que improvisan demasiado

Un LLM sin restricciones puede inventar sub-agentes que no existen o tomar decisiones incorrectas.

Solución híbrida: reglas programáticas para decisiones críticas (seguridad, privacidad, validación de datos sensibles). Delegación al LLM para decisiones creativas o contextuales.

No es "todo LLM". Es un modelo híbrido donde la lógica dura protege lo que no puede fallar.

---

Lo Que Nadie Te Dice del Patrón Supervisor

El patrón supervisor no es una capa jerárquica más. Es el punto donde la mayoría de implementaciones fracasan porque confunden orquestación con control secuencial.

Un supervisor no necesita saberlo todo. Necesita saber a quién preguntar.

Construyes un sistema de agentes para delegar trabajo, no para centralizar decisiones. Si tu supervisor decide cada micro-paso, has creado un cuello de botella más caro y lento que el proceso manual que querías reemplazar.

El mejor supervisor es el que menos decide. El que confía en sus sub-agentes. El que delega intenciones, no instrucciones.

*Eso no es solo buena arquitectura. Es buen management.*

Lee el artículo completo en brianmenagomez.com

Más sobre mis servicios en brianmenagomez.com

Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF

El secreto no está en el framework. Está en que Claude ya sabe cómo ser un agente.

*Solo necesitas dejarle hacer su trabajo. *

La mayoría de la comunidad asume que construir agentes con LLMs requiere frameworks complejos. LangChain, AutoGPT, cadenas de pensamiento elaboradas, planners externos, memorias sofisticadas.

Todo eso era cierto... antes de que Claude 3.5+ llegara.

El Claude Agent SDK de Anthropic introduce una realidad incómoda para los que han invertido meses aprendiendo LangChain: *cuando el modelo tiene tool use nativo, la orquestación se reduce a 40 líneas. * No necesitas un planner separado. No necesitas chains. No necesitas memorias complejas.

El modelo mismo decide cuándo y cómo usar herramientas.

Este tutorial te va a mostrar exactamente cómo funciona. Sin hype. Sin teoría. Código que puedes copiar, pegar y llevar a producción hoy.

---

❌ El Problema: Estás Construyendo Aviones con Instrucciones de Lego

Antes del Claude Agent SDK, construir agentes era un ejercicio de ingeniería inversa.

Los modelos base no estaban entrenados para tool use. Había que enseñarles. Y para eso nacieron frameworks como LangChain, que añadían capas de abstracción para compensar lo que el modelo no sabía hacer por sí mismo.

✅ El resultado típico de un agente con API cruda de OpenAI:

```python

~150-200 líneas de boilerplate

while not done:

response = openai.chat.completions.create(...)

parsear JSON manualmente

manejar tool calls con try/except

implementar backoff exponencial

gestionar el historial manualmente

loop infinito si el modelo alucina

```

Cada uno de esos pasos es una fuente de bugs. Cada capa de abstracción es deuda técnica que pagarás cuando el modelo actualice su API.

*El verdadero problema no es la complejidad del agente. Es que estás construyendo infraestructura para compensar limitaciones que ya no existen. *

Claude 3.5+ fue entrenado con tool use como capacidad fundamental. No es un añadido. No es un parche. *El modelo entiende intrínsecamente cómo formatear tool calls, interpretar resultados y decidir el siguiente paso. *

Algo que otros modelos necesitan prompt engineering elaborado para lograr.

---

✅ La Solución: 40 Líneas con Claude Agent SDK

Mira este contraste. Un agente funcional con la API cruda de Anthropic:

```python

API cruda ~150 líneas

import anthropic

client = anthropic.Anthropic()

messages = []

tools = [...]

while True:

response = client.messages.create(

model="claude-sonnet-4-20250514",

max_tokens=4096,

tools=tools,

messages=messages

)

if response.stop_reason == "tool_use":

for block in response.content:

if block.type == "tool_use":

result = execute_tool(block.name, block.input)

messages.append({"role": "user", "content": result})

else:

break

```

Ahora, el mismo agente con Claude Agent SDK:

```python

~40 líneas — y funciona igual o mejor

from claude_agent_sdk import Agent, tool

@tool

def buscar_pedido(pedido_id: str) -> dict:

"""Busca un pedido por ID en el sistema"""

return db.query(f"SELECT * FROM pedidos WHERE id = '{pedido_id}'")

@tool

def cancelar_pedido(pedido_id: str) -> bool:

"""Cancela un pedido activo"""

return db.execute(f"UPDATE pedidos SET estado = 'cancelado' WHERE id = '{pedido_id}'")

agent = Agent(

tools=[buscar_pedido, cancelar_pedido],

model="claude-sonnet-4-20250514"

)

respuesta = agent.run("Necesito cancelar mi pedido #1234")

print(respuesta)

```

*El bucle de agente (think → act → observe) está implementado por defecto en el AgentExecutor. *

No tienes que escribir el while loop. No tienes que parsear tool calls. No tienes que gestionar el historial manualmente. El SDK maneja el ciclo completo de llamada-herramienta-resultado, incluyendo el enrutamiento de respuestas parciales.

La reducción: de ~200 líneas de implementación manual a ~40 líneas con el SDK. Un 80% menos de código.

---

El Cambio Mental: Confiar en el Modelo, No en Tu Infraestructura

Aquí está el punto que la mayoría no entiende.

Con agentes tradicionales, el desarrollador definía el flujo de decisión. Un grafo DAG. Un planner-react. Una cadena de pasos explícita.

*Con Claude Agent SDK, el desarrollador define las herramientas y las reglas de negocio, pero el modelo decide el flujo. *

Esto no es una sutileza técnica. Es un cambio fundamental en cómo diseñamos sistemas.

Ejemplo real: Un asistente de atención al cliente.

❌ Enfoque tradicional:

1. Clasificador de intención del usuario

2. Router a handler específico

3. Lógica condicional para casos compuestos

4. Generación de respuesta

5. Validación post-hoc

✅ Con Claude Agent SDK:

1. Define herramientas: `buscar_pedido`, `cancelar`, `reembolsar`, `escalar`

2. Deja que Claude decida cuál usar basado en la conversación natural

3. El modelo maneja peticiones compuestas sin lógica condicional explícita

El resultado es un sistema más flexible que maneja casos borde — como "quiero cancelar el pedido de ayer y reembolsarlo a mi otra tarjeta" — sin que hayas escrito ni una línea de lógica condicional para ese caso concreto.

---

Múltiples Herramientas en Paralelo: Donde el SDK Brilla

Uno de los superpoderes menos conocidos del Claude Agent SDK es su capacidad para manejar múltiples herramientas de forma paralela y secuencial, con manejo de errores integrado.

```python

from claude_agent_sdk import Agent, tool

import httpx

@tool

def buscar_precios(producto: str) -> list:

"""Busca precios de un producto en varias APIs"""

return httpx.get(f"https://api.precios.com/search?q={producto}").json()

@tool

def calcular_iva(precio_base: float) -> float:

"""Calcula el IVA aplicable al precio base"""

return precio_base * 0.21

@tool

def guardar_cotizacion(producto: str, precio_final: float) -> str:

"""Guarda una cotización en la base de datos"""

return db.insert("cotizaciones", {"producto": producto, "precio": precio_final})

agent = Agent(

tools=[buscar_precios, calcular_iva, guardar_cotizacion],

model="claude-sonnet-4-20250514",

max_iterations=10

)

respuesta = agent.run(

"Busca el precio del MacBook Pro M4, calcula el IVA, "

"y guarda la cotización en el sistema"

)

```

Fíjate en lo que no tienes que hacer:

• ❌ Manejar dependencias entre tool calls manualmente

• ❌ Implementar reintentos con backoff exponencial

• ❌ Gestionar rate limits

• ❌ Parsear el JSON de respuesta del modelo

• ❌ Escribir un loop while con estado

*Todo eso viene incluido en el SDK. * El modelo decide el orden: primero busca precios, luego calcula IVA, luego guarda. Y si una llamada falla, el SDK reintenta automáticamente.

---

Manejo de Errores y Rate Limits: El Infierno que el SDK Te Ahorra

Construir un agente manualmente significa implementar todo esto:

```python

Implementación manual de backoff (solo esto son 30 líneas)

import time

import random

def call_with_backoff(func, max_retries=5):

for attempt in range(max_retries):

try:

return func()

except RateLimitError:

wait = (2 ** attempt) + random.uniform(0, 1)

time.sleep(wait)

except ToolExecutionError as e:

if attempt == max_retries - 1:

raise

time.sleep(1)

raise MaxRetriesExceeded()

```

Con el SDK, esto ocurre debajo del capó:

```python

El SDK maneja rate limits, timeouts, y reintentos automáticamente

@tool(max_retries=3, timeout=30)

def llamar_api_externa(endpoint: str) -> dict:

"""Llama a una API externa con manejo de errores integrado"""

return httpx.get(endpoint).json()

```

*El SDK incluye manejo automático de rate limits, timeouts, y reintentos para cada tool call. * Algo que en frameworks alternativos requiere configuración manual explícita.

Y no solo eso. El SDK también ofrece hooks para monitorización:

```python

agent = Agent(

tools=[...],

on_tool_call=lambda name, args: log.info(f"Tool call: {name} con {args}"),

on_tool_result=lambda name, result: log.info(f"Resultado de {name}: {result}"),

on_error=lambda error: sentry.capture_exception(error)

)

```

Esto te permite ver exactamente qué decisiones está tomando el modelo, en tiempo real.

---

Comparación: Claude Agent SDK vs. LangChain vs. API Cruda

Para el mismo caso de uso — un agente que busca información, la procesa y devuelve un resultado estructurado:

| Aspecto | API Cruda | LangChain | Claude Agent SDK |

|---------|-----------|-----------|----------------------|

| Líneas de código | ~200-300 | ~100-150 | ~40 |

| Bucle agente | Manual | Abstraído (pero complejo) | Nativo |

| Manejo de errores | Manual | Parcial | Automático |

| Tool parsing | JSON manual | Chains + parsers | Decorador @tool |

| Dependencias entre tools | Manual | DAG complejo | Modelo decide |

| Curva de aprendizaje | Alta | Muy alta | Baja |

*Cuando el modelo tiene tool use nativo, cada capa de abstracción extra es deuda técnica que pagas en bugs y complejidad. *

---

Objeción: ¿Y si quiero cambiar de proveedor de LLM?

Es la objeción más común.

"Prefiero LangChain porque no me ata a un solo proveedor."

Es una preocupación válida, pero la realidad es que la mayoría de los equipos que usan LangChain terminan optimizando para un solo proveedor de todas formas. Y pagan el precio de mantener abstracciones que no necesitan.

*Si ya usas Claude, el SDK oficial reduce la complejidad, mejora el rendimiento y elimina la deuda técnica de mantener capas que no usas. *

Además, nada impide usar Claude Agent SDK para el agente principal y tener sistemas específicos con otros proveedores para tareas concretas (embedding con OpenAI, validación con modelos locales, etc.).

No es una decisión binaria. Es una decisión de arquitectura.

---

Objeción: ¿Está el SDK lo suficientemente maduro?

El SDK es más reciente que LangChain, sí.

Pero Anthropic ha priorizado la calidad sobre la cantidad de features. Al ser más pequeño, tiene menos bugs, menos breaking changes, y una curva de aprendizaje más suave.

La desventaja: hay menos ejemplos comunitarios y menos integraciones pre-construidas.

*Sin embargo, para casos de uso estándar — asistentes, automatización, RAG con tools — es más que suficiente. * Y al ser código abierto, puedes extenderlo si necesitas algo que no viene incluido.

---

El Marco de 3 Pasos para Empezar Hoy

Paso 1: Instalación y configuración básica

```bash

pip install claude-agent-sdk

export ANTHROPIC_API_KEY="sk-ant-..."

```

Estructura básica:

```python

from claude_agent_sdk import Agent

agent = Agent(model="claude-sonnet-4-20250514")

resultado = agent.run("Hola, ¿cómo estás?")

print(resultado)

```

Paso 2: Define tus herramientas con @tool

El decorador `@tool` es la pieza central. La descripción de cada herramienta es *crítica para el rendimiento del modelo* — sé específico:

```python

@tool

def buscar_cliente(email: str) -> dict:

"""

Busca un cliente por su email en el CRM.

Devuelve nombre, ID, pedidos recientes y estado de cuenta.

El email debe ser exacto.

"""

return crm.query(f"SELECT * FROM clientes WHERE email = '{email}'")

```

Paso 3: Configura el AgentExecutor

```python

agent = Agent(

tools=[buscar_cliente, buscar_pedido, calcular_iva],

model="claude-sonnet-4-20250514",

max_iterations=15, # límite de ciclos agente-herramienta

parallel_tool_calls=True, # ejecuta herramientas en paralelo cuando sea posible

system_prompt="Eres un asistente de atención al cliente español. Responde siempre con amabilidad y precisión."

)

```

---

Lo que Nadie Te Cuenta del Claude Agent SDK

Dos detalles que marcan la diferencia en producción:

Primero: las descripciones de las herramientas son más importantes que el código de las mismas. El modelo decide qué herramienta usar basándose en la descripción que le das. Gasta tiempo en escribir descripciones precisas. Es la diferencia entre un agente que acierta el 90% de las veces y uno que acierta el 50%.

Segundo: el SDK expone el árbol de decisiones del agente. Puedes inspeccionar cada paso, cada tool call, cada decisión:

```python

respuesta = agent.run("Cancela mi pedido y reembolsa")

print(respuesta.trace)

Muestra el árbol completo de decisiones del agente

```

Esto no es magia. Es arquitectura bien diseñada.

---

El Futuro de los Agentes no Tiene Frameworks

El Claude Agent SDK representa algo más grande que una herramienta.

*Representa un cambio en cómo pensamos sobre los agentes. *

Durante años, asumimos que construir agentes requería capas de abstracción porque los modelos no podían manejar la complejidad por sí mismos. LangChain, AutoGPT, y todos los frameworks que vinieron antes existían para compensar las limitaciones de los modelos.

Pero Claude 3.5+ cambió las reglas.

Cuando el modelo ya sabe usar herramientas, planificar, y ejecutar ciclos agente-herramienta, la mayoría del código que escribíamos se vuelve redundante.

*No necesitas más framework. Necesitas menos framework. *

El trabajo del desarrollador no es orquestar cada decisión del modelo. Es definir bien las herramientas, escribir descripciones precisas, y luego apartarse.

El resto, Claude lo sabe hacer mejor que tú.

---

Resumen: Lo que Te Llevas

1. El Claude Agent SDK reduce el código de agente en un 60-80% comparado con alternativas

2. El tool use nativo de Claude elimina la necesidad de planners, chains y memorias externas

3. El manejo de errores, rate limits y reintentos viene integrado — no necesitas implementarlo

4. Las descripciones de tus herramientas son más importantes que el código de las mismas

5. El SDK es más pequeño, más rápido y más predecible que frameworks generalistas

Empieza hoy. 40 líneas. Un agente funcional. Cero boilerplate.

Ese es el poder de trabajar con un modelo que ya sabe cómo ser un agente. Solo tienes que dejarle hacer su trabajo.

Lee el artículo completo en brianmenagomez.com

Más sobre mis servicios en brianmenagomez.com

Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF

El 90% de los desarrolladores trata Sanity como un CMS headless con esteroides. Definís schemas, exponéis un API REST, montáis un frontend que fetchea contenido.

Y funciona. Pero estáis perdiendo el 80% de lo que Sanity puede hacer por vosotros.

*La sabiduría convencional dice: define tus modelos de contenido primero, expónlos por API, y renderiza en el frontend. *

La realidad es que Sanity invierte esa lógica. No es un CMS con un API colgado. Es una base de datos de documentos en tiempo real con un React UI desacoplado, un query language propio (GROQ) capaz de hacer joins en tiempo de consulta, y un modelo de schemas sin migraciones que permite iterar a velocidad de código.

La mayoría de los tutoriales os enseñan a montar Sanity como si fuera WordPress con GraphQL. Cread contenidos, llamad a la API, mostrad en pantalla. Eso funciona, pero no aprovecha la arquitectura real de Sanity: el Content Lake.

El Content Lake no es una base de datos relacional. Es un almacén de documentos JSON donde cada contenido es un nodo atómico. Y GROQ —no REST, no GraphQL— es el lenguaje diseñado para navegar ese grafo. Las proyecciones en tiempo de consulta son el superpoder que el 90% ignora.

El Error de Tratar Sanity Como un REST API

Cuando montáis Sanity como un REST API estándar, hacéis esto:

1. Definís un schema de `post` con campos anidados.

2. Creáis un endpoint que devuelve el `post` entero.

3. En el frontend, filtráis y transformáis los datos en JSX.

Funciona. Pero cada petición devuelve datos que no necesitáis. Cada componente que renderiza el mismo `post` desde distinto ángulo tiene que hacer su propia transformación. Y si queréis datos relacionados (autor, categorías, posts similares), necesitáis múltiples llamadas o un schema hinchado.

❌ Enfoque REST tradicional: Schema monolítico → endpoint fijo → transformación en frontend.

✅ Enfoque Sanity real: Documentos atómicos → proyección GROQ → datos exactos por componente.

GROQ te permite hacer en una sola consulta lo que en REST necesitarías tres endpoints. Mira este ejemplo:

```groq

*[_type == "post" && defined(slug.current)]{

title,

excerpt,

"author": author->name,

"categories": categories[]->title,

"relatedPosts": *[_type == "post" && _id != ^._id && count(categories[@ in ^.categories]) > 0]{title, slug}

}

```

Una sola petición. Tres colecciones relacionadas. Proyección parcial. Joins en tiempo de consulta. Sin resolvers, sin endpoints adicionales, sin schemas complejos de GraphQL.

*Eso no es un CMS. Eso es una base de datos de documentos con un lenguaje de consulta que compite con SQL para datos semi-estructurados. *

GROQ: El Query Language que Nadie Aprende (y Debería)

GROQ es el activo infravalorado de Sanity. La mayoría lo ignora porque "ya saben GraphQL". Error.

GraphQL sobre Sanity añade una capa de abstracción que:

• Duplica la definición de tipos.

• Introduce resolvers que son ida y vuelta al mismo Content Lake.

• Necesita schema stitching si tenéis múltiples fuentes.

• Oculta la capacidad de proyección parcial nativa de Sanity.

GROQ, en cambio, es un lenguaje de query diseñado específicamente para documentos JSON anidados con referencias. No necesitáis definir resolvers. No necesitáis schemas GraphQL. Escribís la query que produce exactamente el JSON que vuestro componente necesita.

Esto es especialmente potente cuando tenéis múltiples consumidores del mismo contenido:

```groq

// Proyección para web

*[_type == "article" && slug.current == $slug]{

title,

body[]{

...,

_type == "image" => {asset->{url, metadata}},

_type == "code" => {language, code}

}

}

// Proyección para excerpt (email/resumen)

*[_type == "article" && slug.current == $slug]{

title,

"excerpt": pt::text(body)[0..200]

}

```

Mismo contenido. Dos proyecciones distintas. El schema no cambia. Cada consumidor recibe exactamente lo que necesita y nada más.

Portable Text: El Formato que Te Libera del Vendor Lock-In

Sanity no guarda el contenido como HTML. Lo guarda como un array de objetos JSON tipados. Cada bloque (párrafo, imagen, código, embed) es un objeto con `_type`, valor, y metadatos.

Esto se llama Portable Text y es, probablemente, la decisión arquitectónica más inteligente de Sanity.

❌ CMS tradicional: El editor escribe HTML → guardas HTML → renderizas HTML en web. Te has casado con ese formato.

✅ Portable Text: El editor escribe bloques estructurados → guardas JSON → renderizas como HTML, texto plano, RSS, o lo que necesites.

Un renderer de Portable Text es un pipeline de componentes React (o Vue, o Svelte, o Swift) que mapea cada `_type` a un componente:

```tsx

// Renderer de Portable Text

const ptComponents = {

types: {

image: ({value}) => <Image asset={value.asset} alt={value.alt} />,

code: ({value}) => <SyntaxHighlighter language={value.language} code={value.code} />,

callout: ({value}) => <Callout type={value.type}>{value.text}</Callout>,

embed: ({value}) => <YouTubeEmbed url={value.url} />,

},

marks: {

link: ({children, value}) => <a href={value.href}>{children}</a>,

highlight: ({children}) => <mark>{children}</mark>,

}

}

```

Ese mismo JSON que renderizáis en web puede renderizarse en iOS con un renderer Swift, o en un email como texto plano. El contenido no depende del formato de salida. Lo escribís una vez, lo consumís en cualquier lado.

El Patrón que el 90% Ignora: Schemas Atómicos + Proyecciones GROQ

El anti-patrón más común en proyectos Sanity es la normalización prematura. Desarrolladores acostumbrados a SQL empiezan a dividir el contenido en decenas de tipos interconectados con referencias profundas. El resultado: queries lentas, editores frustrados que tienen que navegar cinco referencias para editar una página, y un schema que replica una base de datos relacional en un almacén de documentos.

*El enfoque Sanity-idiomático es opuesto: documentos planos, referencias ligeras, y proyecciones GROQ para componer. *

1. Schemas Atómicos

No creéis un schema de "página web". Cread tipos pequeños y reutilizables: `block`, `image`, `link`, `person`, `testimonial`, `pricingTier`. Luego componedlos con arrays y referencias.

```ts

// schemaTypes/block.ts

export default {

name: 'block',

type: 'object',

title: 'Bloque de Contenido',

fields: [

{name: 'heading', type: 'string'},

{name: 'content', type: 'blockContent'},

{name: 'image', type: 'image'},

{name: 'cta', type: 'link'}

]

}

// schemaTypes/page.ts

export default {

name: 'page',

type: 'document',

title: 'Página',

fields: [

{name: 'title', type: 'string'},

{name: 'slug', type: 'slug'},

{name: 'blocks', type: 'array', of: [{type: 'block'}]}

]

}

```

2. Proyecciones GROQ Antes de la UI

Antes de escribir un solo componente de React, escribid las queries GROQ que vais a necesitar. Esto revela gaps en el modelado antes de que lleguéis al frontend, y os obliga a pensar en términos de qué necesita cada componente, no de qué tiene el schema.

3. Studio Personalizado

El Sanity Studio es una aplicación React open-source. Podéis:

• Añadir componentes de input personalizados que validen en cliente antes de llegar al backend.

• Crear vistas previas en tiempo real que rendericen el contenido mientras el editor escribe.

• Definir acciones de documento personalizadas (publicar con webhook, generar metadatos SEO, etc.).

Un Studio customizado es un diferenciador real para vuestro equipo editorial.

4. Webhooks para Cachear en Producción

GROQ es rápido, pero no deberíais llamar a la API de Sanity en cada visita de producción. El patrón correcto: GROQ-powered webhooks que disparan un revalidado del cache.

```ts

// Webhook handler en Vercel Edge Function

export async function POST(request: Request) {

const {body, signature} = await request.json();

const isValid = verifySanitySignature(signature, process.env.SANITY_WEBHOOK_SECRET);

if (!isValid) return new Response('Unauthorized', {status: 401});

const {_type, slug} = body;

if (_type === 'post') {

await revalidateTag(`post-${slug.current}`);

// O: purgar CDN, revalidar ISR, etc.

}

return new Response('OK', {status: 200});

}

```

Migraciones Sin Migraciones: El Modelo que Cambia las Reglas

Sanity no requiere migraciones de base de datos. Añadís un campo al schema, y los documentos existentes simplemente tienen ese campo como `null` hasta que lo rellenáis. No hay `ALTER TABLE`, no hay downtime, no hay scripts de migración que se ejecuten en producción.

*El trade-off: sacrificáis consistencia de datos por velocidad de iteración. Para sitios impulsados por contenido, es casi siempre la decisión correcta. *

Para sistemas transaccionales, no. Pero Sanity no está diseñado para transacciones. Está diseñado para contenido editorial, y en ese dominio, la capacidad de iterar el schema sin fricción es un superpoder que WordPress, Contentful y Strapi no igualan.

El Framework: El Modelo de 3 Capas para Sanity

Llamadlo El Modelo de Composición Atómica. Tres capas, una dependencia.

1. Capa de Schemas Atómicos: Tipos pequeños, reutilizables, sin saber quién los va a consumir.

2. Capa de Proyecciones GROQ: Queries por componente que devuelven exactamente los datos que cada vista necesita.

3. Capa de Renderizado Contextual: Renderers de Portable Text que transforman el mismo JSON en HTML, texto plano, o nativo según el dispositivo.

Cada capa puede iterarse independientemente. Cambiáis la proyección sin tocar el schema. Cambiáis el renderer sin tocar la query. Cambiáis el schema y los documentos antiguos no se rompen, solo tienen campos vacíos.

La Trampa: No Uses Sanity Como WordPress

Si tratáis Sanity como un CMS que devuelve HTML, estáis usando la herramienta equivocada. Sanity no es un generador de páginas. Es una plataforma de contenido donde vosotros construís las reglas de validación, las relaciones, y los formatos de salida.

*El verdadero poder de Sanity no está en lo que viene configurado. Está en lo que podéis construir vosotros encima. *

GROQ, Portable Text, el Studio personalizable, las suscripciones en tiempo real, los webhooks con firma — cada pieza está diseñada para que montéis vuestro propio CMS, no para que uséis el que otros definieron.

El 90% de los proyectos Sanity ignora esto. El 10% que lo entiende construye sistemas de contenido que son más rápidos, más flexibles, y más fáciles de mantener que cualquier alternativa en el mercado.

*La pregunta no es si Sanity es bueno. La pregunta es si estáis dispuestos a construirlo vosotros. *

Porque Sanity no es un CMS. Es un kit de construcción de CMS. Y el mejor tutorial no os enseña a usarlo — os enseña a decidir qué queréis construir con él.

Lee el artículo completo en brianmenagomez.com

Más sobre mis servicios en brianmenagomez.com

Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF

Crees que el follow-up post-reunión es un problema de timing. Que si envías el email demasiado pronto pareces desesperado. Que si esperas tres días, el prospecto se enfría. Que el tono perfecto está en algún punto entre "recordatorio amable" y "urgencia comercial".

*Te has equivocado de diagnóstico.*

El 80% de los pipelines de follow-up fallan no por el tono del mensaje ni por la frecuencia. Fallan porque ningún agente actual se atreve a preguntar: "¿Cómo te sientes realmente después de esa reunión?"

La verdad incómoda que nadie en el SaaS de ventas quiere reconocer: el factor decisivo no es cuándo envías el mensaje ni cómo lo redactas. Es la capacidad de tu agente para leer el estado emocional del prospecto después de la reunión — niveles de urgencia, dudas no expresadas, desorganización interna — y adaptar la estrategia de cierre en tiempo real.

Los pipelines actuales optimizan métricas vanity (tasa de apertura, clicks en enlaces). El 100% ignora las métricas de intención real: ¿el prospecto descargó la plantilla? ¿Subió el documento que le falta? ¿Respondió a la pregunta concreta que desbloquea la decisión?

Vale. Vamos a construir algo que funcione.

---

Por Qué el "Recordatorio Amable" Es Peor Que No Enviar Nada

El enfoque estándar del follow-up es un cliché andante:

❌ Día 1 post-reunión: "Gracias por tu tiempo. ¿Te quedó alguna duda?"

❌ Día 3: "Solo quería saber si has podido revisar la propuesta."

❌ Día 7: "Te escribo por última vez por si aún te interesa."

Este patrón asume que la reunión fue bien y que el prospecto solo necesita un empujoncito. Pero la evidencia del mundo real — la que hemos visto en decenas de pipelines de gestorías, despachos y SMBs — cuenta otra historia.

✅ El enfoque que sí funciona: detectar que el prospecto salió de la reunión con urgencia regulatoria pero los papeles desordenados, y en lugar de un recordatorio, enviarle una checklist de documentos con instrucciones paso a paso.

La analogía directa viene del intake legal. En el proceso de captación de clientes para una gestoría o despacho de abogados, el cuello de botella no es la precisión técnica del agente de intake — es la captura del estado emocional del cliente: urgencia regulatoria, desorganización documental, dudas no expresadas sobre el proceso. Si un agente no puede detectar que un cliente está en medio de una inspección (urgencia alta) y tiene los papeles en una bolsa de plástico (desorganización extrema), cualquier recordatorio de seguimiento será contraproducente.

El follow-up post-reunión B2B es exactamente igual. Tu prospecto no está siendo "poco interesado". Está abrumado, desorganizado y confundido sobre cuál es el siguiente paso concreto.

---

La Evidencia Que Nadie Quiere Ver

Tres datos que cambian cómo deberías diseñar tu agente de follow-up:

1. El estado emocional del cliente determina el 80% de la tasa de cierre.

Lo hemos visto en pipelines reales de intake documental: la urgencia regulatoria combinada con desorganización documental es el factor crítico que todos los agentes actuales ignoran. Ningún CRM con templates de email captura esto. Ninguna secuencia de HubSpot lo detecta.

2. Los agentes de IA actuales fallan sistemáticamente en capturar contexto emocional o conductual.

No es un fallo técnico. Es un fallo de diseño. La mayoría de los agentes de follow-up se implementan como secuencias lineales de emails pre-escritos. Un árbol de decisión necesitaría detectar señales que ningún formulario ni template captura: el tono de voz en la reunión, las pausas cuando el prospecto habla de plazos, las preguntas que evita responder.

3. Apify demuestra que los agentes pueden operar como runtimes serverless completos con scheduling, webhooks y proxy.

Esto no es teoría. La infraestructura existe. Apify permite desplegar, encadenar y escalar aplicaciones con scheduling, webhooks y proxy integrados. n8n también. Lo que falta no es la tecnología — es el modelo mental de qué debería estar haciendo el agente.

---

El Modelo Mental Correcto: El Árbol de Decisión Emocional

El follow-up no es una secuencia lineal. Es un árbol de decisión que se ramifica según el estado del prospecto.

Cada reunión de ventas genera un perfil emocional con tres dimensiones:

| Dimensión | Bajo | Medio | Alto |

|---|---|---|---|

| Urgencia percibida | "Lo miro cuando pueda" | "Necesito resolverlo este mes" | "Tengo una inspección la semana que viene" |

| Nivel de duda | "Me parece bien" | "Tengo algunas preguntas" | "No estoy seguro de que esto sea para mí" |

| Desorganización documental | "Tengo todo digitalizado" | "Tengo los papeles pero no sé cuáles faltan" | "Los documentos están en una caja sin clasificar" |

La mayoría de las reuniones caen en una combinación predecible. Pero ningún agente actual mide esto. Envían el mismo email a los tres tipos de prospecto.

Ahora, el salto cualitativo: cada combinación de estado emocional debería disparar una secuencia de acciones *distinta*.

Ejemplo real:

• Urgencia alta + desorganización alta: No envíes un "recordatorio amable". Envía una checklist de documentos con casillas de verificación y un enlace directo para subir PDFs. El prospecto no necesita que le recuerden la reunión — necesita una estructura para organizarse.

• Duda alta + urgencia baja: No insistas con la propuesta. Envía un case study de 3 párrafos que resuelva la objeción no dicha. El prospecto no necesita más información — necesita que validen su miedo específico.

• Urgencia alta + duda baja: Pide directamente la llamada de cierre de 15 minutos. El prospecto está listo. Cualquier paso intermedio es fricción.

---

El Marco de 5 Pasos: Cómo Construir un Agente de Follow-Up Que Cierra

Llamémoslo El Ciclo de Cierre Emocional (Emotional Close Loop). Son cinco pasos. Ninguno requiere un equipo de data science. Todos se implementan con herramientas que ya existen.

Paso 1 — Post-Call Sentiment Mapping

Implementa un pipeline que analice la grabación o transcripción de la reunión extrayendo las 3 dimensiones emocionales usando un LLM con prompt estructurado.

Aquí tienes el prompt que uso para esto:

```python

prompt = f"""

Analiza la siguiente transcripción de reunión comercial.

Extrae solo 3 dimensiones con valor numérico de 1 a 10:

1. urgencia_percibida: ¿El prospecto menciona plazos, inspecciones,

fechas límite o consecuencias de no actuar?

2. nivel_duda: ¿Hace preguntas evasivas, cambia de tema cuando se

habla de precio, o dice "lo reviso" sin compromiso?

3. desorganizacion_documental: ¿Menciona que tiene que buscar papeles,

que los tiene en varias carpetas, o que "no sabe exactamente qué falta"?

Devuelve SOLO un JSON con estas tres claves y valores numéricos.

No expliques nada. No añadas texto adicional.

Transcripción: {transcript}

"""

response = openai.chat.completions.create(

model="gpt-4o-mini", # Cuesta céntimos por análisis

messages=[{"role": "user", "content": prompt}],

response_format={"type": "json_object"}

)

```

¿El coste? Céntimos por reunión. El análisis se hace una sola vez, post-reunión. No es tiempo real. No necesitas GPUs. Necesitas un prompt bien escrito y una API key.

Paso 2 — Estado → Estrategia de Acción

Mapea cada combinación de puntuaciones a una secuencia de acciones. Esto no es magia — es una lookup table:

```python

estrategias = {

(9, 3, 8): "checklist_documentos", # Urgencia alta, duda baja, desorganización alta

(4, 7, 3): "casestudy_objecion", # Urgencia baja, duda alta, organizado

(8, 2, 4): "cierre_directo_15min", # Urgencia alta, duda baja, organizado

(6, 5, 6): "resumen_ejecutivo_3lineas", # Perfil medio

}

```

La clave está en que cada estrategia dispara un flujo serverless distinto. No es un template de email con distinto asunto. Son flujos completos con diferentes acciones, tiempos y canales.

Paso 3 — Pipeline Serverless con Scheduling

Implementa el agente como runtime serverless (Apify, n8n o Cloud Functions) con webhooks que se disparen automáticamente N horas post-reunión según el segmento emocional detectado.

```javascript

// Ejemplo con webhook en n8n o Edge Function

// Se dispara automáticamente según el segmento

const segmento = detectarSegmento(analisisEmocional);

const acciones = {

checklist_documentos: {

delay: 2, // horas post-reunión

template: "emails/checklist_urgencia.mjml",

webhook_espera: "/webhook/documento-subido",

max_intentos: 3

},

cierre_directo_15min: {

delay: 1, // horas

template: "emails/cierre_directo.mjml",

webhook_espera: "/webhook/calendario-agendado",

max_intentos: 2

}

};

```

El scheduling + webhooks permiten que el agente espere a que el prospecto realice una acción (subir un documento, responder una pregunta) y adapte el siguiente paso automáticamente, sin intervención humana. Esto es lo que diferencia un agente real de una secuencia de Mailchimp.

Paso 4 — Métricas de Intención Real sobre Vanity Metrics

Reemplaza la tasa de apertura por la tasa de acción concreta.

• ❌ Vanity metric: "El 45% abrió el email de seguimiento."

• ✅ Intención real: "El 22% descargó la plantilla de documentos. El 12% subió al menos un archivo. El 8% agendó la llamada de cierre."

Esto cambia el diseño completo del agente. En lugar de optimizar para subject lines que generen clicks, optimizas para micro-conversiones hacia el cierre.

La pregunta que tienes que hacerte no es "¿abrió el email?" sino "¿realizó una acción que acerca el cierre?" — descargar una plantilla, agendar una llamada de 15 minutos, subir un documento faltante.

Paso 5 — Bucle de Retroalimentación Emocional

Cada interacción del follow-up debe re-evaluar el estado emocional del prospecto y actualizar la estrategia de cierre en tiempo real.

Un prospecto que responde con "lo reviso y te confirmo" pero con tono evasivo en la reunión no necesita un recordatorio a los 3 días. Necesita un email que resuelva la objeción no dicha:

> "Sé que revisar el contrato puede ser abrumador. Aquí está el punto clave en 3 líneas. Si prefieres, lo vemos en 10 minutos mañana."

Esto no es manipulación psicológica. Es pragmatismo comercial. Estás eliminando la fricción que impide que el prospecto avance.

---

La Objeción Que Te Estás Haciendo Ahora Mismo

"Un agente que analiza el estado emocional suena a manipulación o invasivo."

Dos aclaraciones:

Primero: el análisis es sobre necesidades y obstáculos (urgencia regulatoria, desorganización documental, dudas específicas), no sobre psicología profunda del prospecto. No estamos leyendo la mente de nadie. Estamos detectando si alguien dijo "tengo una inspección la semana que viene" o "los papeles están en una caja".

Segundo: el 80% de los SMBs no "no tienen interés". Están abrumados, desorganizados, o no entienden el siguiente paso. Un agente que resuelve eso no está manipulando — está facilitando una decisión que el prospecto ya quiere tomar pero no sabe cómo ejecutar.

---

El Futuro No Son Más Emails. Es Intención Real.

Los pipelines de follow-up actuales están diseñados para la era del batch-and-blast. Envío masivo, espero, re-envío. Es un modelo de broadcasting, no de relación comercial.

El agente de follow-up que realmente funciona no es el que envía más emails. Es el que escucha lo que no se dijo en la reunión y actúa en consecuencia. El que sabe que un "lo reviso" con pausa de 3 segundos no es lo mismo que un "lo reviso" con tono seguro.

La infraestructura existe. Apify, n8n, Cloud Functions, Edge Functions — todo está listo para desplegar agentes con scheduling, webhooks y árboles de decisión complejos.

Lo que falta no es tecnología.

Lo que falta es preguntar la pregunta correcta después de cada reunión.

No "¿cuándo le vuelvo a escribir?"

Sino "¿cómo se quedó realmente?"

---

Resumen y Próximo Paso

• El 80% de los follow-ups fallan por ignorar el estado emocional del prospecto, no por el tono o la frecuencia del mensaje.

• Tres dimensiones capturan el perfil post-reunión: urgencia, duda, desorganización documental.

• Cada combinación dispara una estrategia de acción distinta — no el mismo template de email.

• Métricas de intención real (tasa de acción concreta) sobre vanity metrics (tasa de apertura).

• Bucle de retroalimentación: cada interacción re-evalúa el estado y actualiza la estrategia.

La próxima vez que termines una reunión y tu CRM te pregunte cuándo programar el siguiente email, hazte una pregunta diferente: ¿qué no me dijo el prospecto que determinará si esto se cierra o no?

Esa pregunta vale más que todos los templates de follow-up del mundo.

Lee el artículo completo en brianmenagomez.com

Más sobre mis servicios en brianmenagomez.com

Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF

La sabiduría convencional dice: Vercel es la forma más fácil de desplegar Next.js con zero-config. Pinchas un repo, tecleas un `git push`, y en segundos tienes preview deployments, SSL, CDN global, y un dashboard que te hace sentir que dominas la infraestructura.

*La realidad es que Vercel optimiza para la experiencia de registro, no para la de salida. *

Cada feature que te enamora en el dashboard —ISR en el edge, Edge Config, KV storage, Analytics, Cron Jobs, Speed Insights— es un ancla que ata tu código a su runtime propietario. No es que Vercel sea mal hosting. Es que su modelo de negocio no es venderte servidores; es hacer que sea tan cómodo quedarse que el coste de irte sea psicológica y técnicamente prohibitivo.

Elegir Vercel por simplicidad no es elegir un host. Es firmar un contrato arquitectónico que será más caro de romper que migrar de AWS a Azure. Y lo peor es que la mayoría de los equipos no leen la letra pequeña hasta que están pagando la fianza de salida.

El Lock-In No es un Bug. Es la Feature

Vercel no es "hosting con esteroides". Es un runtime propietario disfrazado de plataforma de deploy. La compañía ha construido un ecosistema donde cada integración vertical —desde el almacenamiento KV hasta el sistema de análisis— está diseñada para funcionar impecablemente dentro de sus fronteras y fallar silenciosamente fuera de ellas.

*El mayor error que cometen los equipos es tratar Vercel como si fuera un Apache compartido pero con mejor UI. *

No lo es. Apache compartido ejecuta PHP estándar. Lo subes a cualquier servador y funciona. Vercel ejecuta un runtime que modifica el comportamiento de tu framework en tiempo de build, inyecta dependencias, sobreescribe configuraciones de rutas, y te ofrece APIs que simplemente no existen en ningún otro lugar.

| Feature | ¿Funciona fuera de Vercel? |

|---------|---------------------------|

| ISR (Incremental Static Regeneration) en el edge | ❌ No. Self-hosted requiere un cache handler personalizado como `@neshca/cache-handler`. Ni siquiera funciona out of the box con `next start`. |

| Edge Functions (`@vercel/edge`) | ❌ No. Cloudflare Workers y Netlify Edge Functions usan APIs distintas. `NextRequest` y `NextResponse` no existen fuera de Vercel. |

| Edge Config | ❌ No. No hay equivalente self-hosted. Es un feature flag store que solo vive en el edge de Vercel. |

| KV Storage | ❌ No. Es una integración con Redis gestionada por Vercel. Migrar a Upstash o Redis propia requiere reescribir todas las queries. |

| Analytics / Speed Insights | ❌ No. `@vercel/analytics` y `@vercel/speed-insights` inyectan tracking que solo funciona en el dominio de Vercel. |

| Cron Jobs | ⚠️ Parcialmente. Vercel los ejecuta como Edge Functions con un scheduler interno. Fuera, necesitas cron jobs externos o un worker. |

| Cache API (`revalidatePath`, `revalidateTag`) | ❌ No. Funciona solo en infraestructura de Vercel. Self-hosted necesitas un adapter de caché. |

Cada checkmark en esa tabla no es una feature. Es una dependencia que tendrás que romper si decides irte. Y el problema no es que existan estas dependencias; el problema es que se presentan como "features gratuitas" cuando en realidad son mecanismos de retención.

Para entender la magnitud del problema, basta con observar cómo funciona la industria del software en 2026. Así como el marketing de redes sociales ha visto tácticas que funcionaban hace dos años volverse contraproducentes —como los chatbots de IA intrusivos en mensajes privados que la gente rechaza activamente—, el hosting de aplicaciones ha seguido una trayectoria similar. Lo que antes era una ventaja competitiva (automatización, integración profunda, "todo en una caja") se ha convertido en una fuente de dependencia que los equipos no anticiparon.

Cuando Snapchat forzó su chatbot de IA en las bandejas de entrada de todos los usuarios en 2023, la calificación de la app en la App Store estadounidense cayó a 1,67 estrellas, con el 75% de las reseñas otorgando una estrella. Los usuarios no habían pedido esa integración. Del mismo modo, los equipos de desarrollo no pidieron explícitamente un runtime propietario que secuestrara su lógica de negocio. Simplemente aceptaron la comodidad sin preguntar por el coste de salida.

El Precio Oculto del "Zero-Config"

Vercel se vende como "funciona sin configurar nada". Y es verdad —para el primer deploy. Pero ese zero-config inicial es el cebo. El anzuelo está en las decisiones arquitectónicas que tomas sin saber que las estás tomando.

El problema es que el build system de Vercel aplica heurísticas que cambian el comportamiento de tu app. Detecta automáticamente tu framework, inyecta build plugins, variables de entorno, y sobreescribe rutas. No te pide permiso. Te lo oculta tras un dashboard bonito.

*Tu app se comporta distinto en `vercel dev` que en `next dev`. *

Y se comporta distinto en producción Vercel que en un Docker container. Esto no es una exageración. Es un hecho comprobable: el middleware de Next.js, que debería ser estándar, se ejecuta en el edge de Vercel con APIs que no forman parte del estándar web. Las Server Actions que usan `revalidateTag` funcionan porque Vercel inyecta su propio sistema de caché. Fuera de ahí, todo se rompe.

Los equipos descubren esto cuando su staging environment se rompe silenciosamente después de que una actualización de Vercel cambia una heurística de build. O cuando intentan mover su app a un VPS para ahorrar costes y descubren que el ISR no funciona, el middleware lanza errores, y las analytics dejan de recoger datos. No es que hayan hecho algo mal. Es que nunca les dijeron que estaban atados.

Es un fenómeno similar al que ocurre en el marketing con los avatares de IA generados por inteligencia artificial. Según la encuesta Sprout Social Pulse, el 46% de los usuarios de redes sociales dicen no sentirse cómodos con que las marcas utilicen influencers de IA. La investigación citada por expertos del sector muestra que el contenido generado por IA, incluidos los avatares, es percibido por las audiencias como publicidad deshumanizada, carente de la empatía y el toque humano que genera confianza. Los equipos de marketing adoptaron estas herramientas por su comodidad y bajo coste inicial, pero el coste a largo plazo —pérdida de confianza, backlash, regulación— superó con creces el beneficio inmediato.

Con Vercel ocurre exactamente lo mismo. La comodidad inicial de "pinchar y desplegar" oculta un coste arquitectónico que solo se manifiesta cuando intentas ejercer tu libertad de elección.

❌ El enfoque débil: "Mi app es pequeña, nunca necesitaré migrar. Esto no me aplica."

✅ El enfoque real: "El lock-in más peligroso es el que no planificas. Hoy es un side project. Mañana es una startup con 50.000 usuarios y una deuda arquitectónica que duele."

El Caso Real: Lo Que Duele No es la Migración Técnica. Es la Arquitectónica

Imagina que tu app usa ISR para páginas de producto. Tienes 10.000 URLs que se regeneran bajo demanda con `revalidateTag`. Funciona perfecto en Vercel. Las páginas se sirven rápido, la invalidación ocurre en milisegundos, y tu equipo ni siquiera piensa en ello.

Ahora decides migrar a un servidor propio o a Cloudflare Pages.

El problema no es mover los ficheros. El problema es que `revalidateTag` no existe fuera de Vercel. No es que tengas que reconfigurar algo. Es que tienes que implementar tu propio sistema de invalidación de caché con Redis, un worker de purga, y un adapter personalizado. Necesitas decidir cómo almacenas el mapa de tags a URLs, cómo purgas de forma atómica, y cómo aseguras que la regeneración no deje tu sitio serviendo contenido obsoleto.

Eso no es "ajustar la configuración". Es una reescritura que puede llevar semanas.

Y si además usas Edge Config para feature flags y Middleware para redirecciones basadas en geolocalización —todo integrado con `@vercel/edge`— la migración se convierte en un proyecto de varias semanas. Cada integración es un módulo que dejará de funcionar. Cada API propietaria es una deuda que vence.

*El verdadero coste de Vercel no son los euros del plan Pro. Es el trabajo de ingeniería necesario para salir. *

Piensa en ello en términos de ingeniería: una migración de AWS a Azure, aunque tediosa, implica mover servicios equivalentes. RDS a Azure SQL. S3 a Blob Storage. Lambda a Azure Functions. Son caros y requieren trabajo, pero el mapa de equivalencias está trazado. Hay guías, herramientas, y consultores que lo han hecho cientos de veces.

Migrar desde Vercel no tiene ese mapa. Porque Vercel no es un servicio de infraestructura: es una plataforma que te vende productividad a cambio de lealtad. Y como cualquier plataforma que opera con ese modelo, la salida es el producto que nunca quisieron que compraras.

El Marco de 5 Pasos para Auditar tu Dependencia de Vercel

Llamémoslo El Marco de Portabilidad Forzada. Funciona así: asumes que mañana mismo Vercel desaparece o cambia sus precios drásticamente, y tu app tiene que funcionar en otro sitio en un plazo máximo de una semana. ¿Cuánto tardas en tenerla operativa? ¿Puedes responder a esa pregunta con precisión?

Si no puedes, este marco es para ti.

Paso 1: Audit de Superficie de Ataque Propietaria

Abre tu `package.json`. Busca todo lo que empiece por `@vercel/`.

```json

// package.json — busca estas dependencias

"@vercel/analytics": "^1.0.0",

"@vercel/speed-insights": "^1.0.0",

"@vercel/edge": "^1.0.0",

"@vercel/kv": "^1.0.0",

"@vercel/blob": "^1.0.0"

```

Cada una de esas líneas es un punto de anclaje. Pero no te detengas en `package.json`. El lock-in más peligroso no está en las dependencias declaradas, sino en las tácitas: middleware que usa `NextRequest`, Server Actions que llaman a `revalidateTag`, page layouts que asumen ISR en el edge, cron jobs definidos en `vercel.json`, y variables de entorno que solo existen en el dashboard de Vercel.

El objetivo es tener visibilidad total de lo que te ata. Haz una hoja de cálculo con cada dependencia, su propósito, y una estimación del esfuerzo necesario para reemplazarla. Este documento, por sí solo, ya te está dando información que probablemente no tenías.

Paso 2: Abstrae las Dependencias Detrás de Interfaces

No importes `@vercel/kv` directamente en tu lógica de negocio. Esa es la receta para el desastre. Crea un adapter que desacople tu código de la implementación concreta:

```typescript

// cache-adapter.ts — abstracción portable

export interface CacheAdapter {

get(key: string): Promise<string | null>;

set(key: string, value: string, ttl?: number): Promise<void>;

invalidate(tag: string): Promise<void>;

}

// vercel-implementation.ts

import { kv } from '@vercel/kv';

export const vercelCache: CacheAdapter = {

get: (key) => kv.get(key),

set: (key, value, ttl) => kv.set(key, value, { ex: ttl }),

invalidate: (tag) => kv.del(tag),

};

// redis-implementation.ts — para cuando migres

import { Redis } from '@upstash/redis';

export const redisCache: CacheAdapter = {

get: (key) => redis.get(key),

set: (key, value, ttl) => redis.setex(key, ttl!, value),

invalidate: async (tag) => { / lógica de purga por tag / },

};

```

El resto de tu código no sabe si estás en Vercel, Redis, o SQLite. Eso es portabilidad real. Y lo mejor es que este patrón no es específico de caché: aplícalo a Edge Config, Blob Storage, Analytics, y cualquier otra integración propietaria. Cada adapter que escribes es una póliza de seguro contra el lock-in.

Paso 3: Despliega en un Segundo Proveedor y Tira la Suite de Tests

No esperes a necesitar migrar. Configura un staging en Netlify, Cloudflare Pages o un servidor propio. Corre tu test suite completo.

Vas a encontrar sorpresas. Siempre las hay. Middleware que falla porque `NextRequest` no existe fuera del contexto de Vercel, ISR que no regenera porque el cache handler no está configurado, analytics que no recolectan datos porque el script de tracking apunta a un endpoint inexistente, cron jobs que no se ejecutan porque no hay scheduler.

Resuélvelas ahora, no cuando estés contra reloj. Cada error que encuentres en staging es una oportunidad para hacer tu código más robusto. Cada dependencia que descubras es una lección sobre cómo no diseñar sistemas.

Este paso tiene un beneficio colateral importante: te obliga a escribir tests que cubren el comportamiento real de tu app en diferentes entornos, lo que mejora la calidad general del software.

Paso 4: Sustituye Middleware Propietario por Web Standards

`NextRequest` y `NextResponse` son comodidades de Vercel. Pero el estándar web es `Request` y `Response`. Y los estándares web son la única garantía de portabilidad real a largo plazo.

```typescript

// ❌ Atado a Vercel

import { NextRequest, NextResponse } from 'next/server';

export function middleware(request: NextRequest) {

const country = request.geo?.country;

return NextResponse.redirect(new URL(`/${country}`, request.url));

}

// ✅ Portable

export function middleware(request: Request) {

const country = request.headers.get('x-vercel-ip-country') || 'ES';

return Response.redirect(new URL(`/${country}`, request.url));

}

```

El segundo bloque funciona en cualquier runtime que soporte el estándar web. Cloudflare Workers, Deno, Bun, Node 20+. No importa dónde despliegues: el código es el mismo.

Este principio aplica a más que middleware. Tus Server Actions deberían devolver `Response` estándar. Tus API routes deberían usar `Request` y `Response` nativos. Cada vez que usas una abstracción propietaria, pregúntate: "¿Puedo escribir esto con APIs estándar del navegador?" Si la respuesta es sí, hazlo. Si es no, pregúntate por qué estás usando esa feature.

Paso 5: Documenta un Pipeline de Build Agnóstico

Tu `next.config.js` no debería tener flags específicas de Vercel que rompan en otros entornos. Un buen pipeline de build es aquel que produces el mismo artefacto independientemente de dónde se ejecute.

```typescript

// next.config.ts — portable

const nextConfig = {

output: process.env.DOCKER ? 'standalone' : undefined,

images: {

// No uses imágenes solo de Vercel Blob

remotePatterns: [

{ protocol: 'https', hostname: '**.vercel-storage.com' },

{ protocol: 'https', hostname: '**.s3.amazonaws.com' },

{ protocol: 'https', hostname: '**.cloudinary.com' },

],

},

};

export default nextConfig;

```

Un único comando para build local, Vercel, y Docker. Sin sorpresas, sin configuraciones mágicas que solo existen en el dashboard de Vercel, sin heurísticas de build que cambian silenciosamente el comportamiento de tu aplicación.

Documenta también el proceso de deploy: qué variables de entorno son necesarias, qué secretos hay que configurar, qué pasos de post-build se requieren. Este documento es tu salvavidas cuando llegue el momento de migrar.

La Alternativa Real No es Netlify. Es AWS

La comparación justa no es Vercel vs. Netlify. Es Vercel vs. AWS con Docker. Cambiar de un proveedor propietario a otro similar no resuelve el problema fundamental; solo cambia el nombre del casero.

El camino más pragmático para apps Next.js en producción que necesitan portabilidad es un despliegue Dockerizado en AWS Fargate o ECS con un CDN por delante (CloudFront). No es la opción más sexy, pero es la que te da libertad real.

❌ Pierdes: instant rollbacks, preview deployments, zero-config, la sensación de que todo es mágico.

✅ Ganas: control total sobre caching, escalado, costes, la libertad de irte cuando quieras, y la capacidad de auditar cada aspecto de tu infraestructura.

El trade-off es simple: complejidad operativa hoy vs. deuda arquitectónica mañana. Y la mayoría de los equipos elige la primera opción no porque sea mejor, sino porque es más fácil de vender al negocio. "Lo desplegamos en dos clics" suena mejor que "invertimos dos semanas en configurar un pipeline de CI/CD reproducible".

*La mayoría de equipos subestima la deuda arquitectónica hasta que es demasiado tarde. *

Así como los equipos de marketing que adoptaron avatares de IA sin preguntarse cómo reaccionaría su audiencia, los equipos de desarrollo adoptan Vercel sin preguntarse cómo será la migración. El patrón es el mismo: una solución que parece barata y rápida hoy, pero que acumula un coste oculto que se dispara cuando intentas cambiar de dirección.

Y al igual que la regulación está alcanzando a la IA generativa —con la Ley de IA de la UE y la FTC estadounidense impulsando requisitos de divulgación obligatoria para contenido generado por IA—, el mercado del hosting está madurando hacia una exigencia de portabilidad. Los equipos que ya han pasado por una migración dolorosa están empezando a exigir transparencia sobre las dependencias propietarias antes de firmar contratos.

La Única Pregunta Que Importa

No es "¿Vercel es bueno o malo?". Vercel es excelente para ciertos casos: proyectos pequeños, MVPs rápidos, prototipos que validan una idea, apps internas con pocos usuarios. Para esos escenarios, la velocidad de desarrollo que ofrece es inigualable.

La pregunta real es:

*¿Sabes exactamente lo que te costaría irte? Sí o no. *

Si no puedes responder con un número de días de ingeniería y una lista de dependencias, tu arquitectura ya está comprometida. No importa lo bien que funcione hoy. No importa lo bonito que sea el dashboard. Estás construyendo sobre terreno que no controlas.

El Marco de Portabilidad Forzada te lleva menos de un día de implementar. Y te ahorrará semanas —o meses— cuando llegue el momento de salir. No porque Vercel sea malo, sino porque cualquier plataforma que controla tu runtime es un riesgo que merece ser medido.

Porque en 2026, el verdadero lujo no es el zero-config. Es poder elegir dónde corre tu código. Es tener la certeza de que, si mañana las condiciones cambian, tu aplicación no se queda atrapada en un ecosistema del que no puedes escapar.

La portabilidad no es un lujo. Es el requisito mínimo para llamarte profesional.

Lee el artículo completo en brianmenagomez.com

Más sobre mis servicios en brianmenagomez.com

Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF