---
title: "La curiosidad es lo que te hace bueno usando la IA"
description: "Los agentes ocultan todo lo que era visible cuando construías cada paso tú mismo. Aún puedes investigar: lee la lista de herramientas, entra en las llamadas, pregunta cómo planea hacer las cosas. Esto es lo que yo analizo y lo que me ha aportado."
date: 2026-09-20
language: es
canonical: https://gduv.club/es/articles/curiosity-with-ai-agents
source: gduv.club
---
Antes de los agentes, creaba automatizaciones de IA en n8n. No tenías más remedio que entender qué estaba pasando, porque construías cada paso tú mismo.

Arrastras un nodo. Lo ejecutas. Recibes un payload JSON. Analizas ese payload y mapeas sus claves en el siguiente paso: este campo va al system prompt, aquel al mensaje del usuario y otro más define la estructura de la salida para que puedas usar sus claves tres pasos más adelante.

Es lento de configurar, pero te lo enseña todo. Acabas con una imagen muy visual de lo que es realmente una llamada a la IA: un paso, con una entrada que tú eliges, un prompt que tú escribes y una salida con la que tienes que hacer algo.

## Lo que eso te obligaba a hacer bien

Un ejemplo real. Llega un ticket de feedback de producto a través de un webhook. Pasas el texto a un modelo cuya única función es categorizarlo: ¿es un error?, ¿es urgente?. Lees la respuesta y, si es urgente, lo rediriges a una notificación de Slack con un resumen de dos líneas para que el equipo esté al tanto.

Tres pasos sencillos. Cada uno con su propio prompt. Cada prompt conteniendo solo lo que ese paso necesita.

Nadie le entrega al modelo toda la empresa y reza para que funcione. No podías, la herramienta no te dejaba.

## Los agentes eliminaron todo aquello

Ahora abro Claude Code y le planteo el problema. Lee mis archivos, llama a mis herramientas conectadas y decide por sí mismo qué hacer a continuación. Funciona, para casi cualquier cosa, y precisamente por eso merece la pena usarlo.

Pero también oculta todos los conceptos anteriores. Y en algunas configuraciones carga la descripción de cada herramienta de cada conector antes incluso de que hayas preguntado nada, lo que supone un gasto enorme de tokens en capacidades que hoy no vas a tocar.

**Construir los pasos tú mismo** (Lento e instructivo)

- Ves el payload de cada llamada
- Escribes cada prompt para una tarea concreta
- Decides qué entra en el contexto
- Ser curioso no es opcional, es el trabajo

**Delegar en un agente** (Rápido y opaco)

- Ves un resultado y un icono de carga
- Un solo prompt y el agente resuelve el resto
- Decide qué leer, a veces todo
- Ser curioso es ahora una elección

_Nada de esto dice que el método antiguo fuera mejor. Era más lento y enseñaba más, y recuperar esa segunda parte merece la pena._

## Por qué debería importarte, aunque nunca lances un producto

Dos cosas se rompen cuando no vigilas.

**Tu presupuesto.** Si agotas los tokens de la semana el miércoles, el jueves y el viernes serán un problema que tú mismo creaste el lunes.

**Tu ciclo.** Si cada mensaje tarda quince minutos en volver, dejas de iterar. Escribes una instrucción, te pones con otra cosa, vuelves, ves que ha ido mal y empiezas de nuevo. El coste no son los quince minutos, sino que solo puedes hacer cuatro intentos al día.

También está el modelo que utilizas. La mayoría usamos uno grande para todo, cuando para más de la mitad de las tareas uno más pequeño respondería más rápido, igual de bien y por menos dinero. La regla general se mantiene: más pequeño es más barato y rápido; más inteligente es más lento y caro. Saber qué parte de tu trabajo cae en cada categoría supone un ahorro real.

## Y si lanzas un producto, no es un detalle menor

Cuando eres tú quien está al teclado, que una tarea tarde diez o doce minutos es (más o menos) lo mismo. Ya comprobarás los resultados luego.

Pon lo mismo frente a un cliente y los números cambian de significado. Alguien sube un archivo, tu mapeo automático tarda veinticinco segundos y el usuario se va. No cuatro minutos. Veinticinco segundos.

Me topé con la versión más cruda de esto al construir Lookio. Entre que una respuesta llegue en cinco segundos o en nueve, una encaja en un widget de chat y la otra no. Entre un centavo por respuesta y nueve centavos, mi margen es del 85% o del 40%, y eso decide cuánto puedo cobrar.

Mismo modelo, mismo producto. La diferencia estaba en cómo se había montado.

## Cómo ser curioso en la práctica

Puede que nunca hayas construido la versión de n8n. Aun así, puedes obtener la mayor parte de ese conocimiento del agente que ya utilizas.

### Lee la lista de herramientas que te ofrece un conector

Cuando conectas algo, la plataforma suele mostrarte cada herramienta que expone, con un nombre y una descripción. Léela una vez. Aprenderás más sobre lo que puede hacer esa integración en dos minutos que en una semana de preguntas.

Si tu conector de CRM no tiene ninguna herramienta para eliminar un contacto y pasas diez minutos presionando al agente para que lo borre, no es que sea perezoso. La capacidad no existe y no puede inventarla.

También puedes preguntar directamente:

```text
Enumera todas las herramientas que expone este conector. Para cada una: su nombre,
qué hace y si la usarías para lo que voy a pedirte.
Señala cualquier cosa que yo asuma que existe y que no esté.
```

**Por qué esto es más importante de lo que parece**

  Contratar a alguien sin saber si tiene ordenador dificulta darle trabajo. Es el mismo problema. Y estos modelos quieren complacerte, por lo que una petición que no se puede satisfacer a veces vuelve como "hecho" en lugar de "no puedo". Saber qué es realmente posible es lo que te permite detectar ese error.

### Haz clic en las llamadas a las herramientas

A partir de tu mensaje, el agente elige entre varias opciones: llamar a una herramienta, escribirte una nota intermedia sobre lo que va a hacer, o responderte y detenerse. Luego lee lo que ha recibido y elige de nuevo. Ese es el ciclo.

En Claude Code puedes hacer clic en cualquiera de esas llamadas y ver qué hay dentro.

**Un turno de un agente: tu mensaje, la herramienta elegida, los parámetros escritos, la carga recibida y el identificador en esa carga que reutiliza en el siguiente turno.**

  <div class="dg-col" style="--dg-gap:0.8rem">
    <div class="dg-box dg-box--info">
      <span class="dg-box__title">Tú</span>
      <span class="dg-box__note">"Añade a Marie Lefevre de Borealis al CRM."</span>
    </div>

    <span class="dg-arrow dg-arrow--down" aria-hidden="true"></span>

    <div class="dg-box">
      <span class="dg-box__title">Elige una herramienta y escribe los parámetros</span>
      <span class="dg-json">{`crm_create_contact({
  "name": "Marie Lefevre",
  "company": "Borealis",
  "email": null     ← no se proporcionó
})`}</span>
    </div>

    <span class="dg-arrow dg-arrow--down" aria-hidden="true"></span>

    <div class="dg-box">
      <span class="dg-box__title">La herramienta responde. Esta es la parte que la gente nunca abre</span>
      <span class="dg-json">{`{
  "ok": true,
  "id": "cnt_8fJ2k",  ← conservar esto
  "created_at": "2026-09-20T14:02Z"
}`}</span>
    </div>

    <span class="dg-arrow dg-arrow--down" aria-hidden="true"></span>

    <div class="dg-box dg-box--good">
      <span class="dg-box__title">Siguiente turno, dices "añade su número de teléfono"</span>
      <span class="dg-json">{`crm_update_contact({
  "id": "cnt_8fJ2k",  ← del paso anterior
  "phone": "+33 6 12 34 56 78"
})`}</span>
    </div>
  </div>

Abre algunas de estas llamadas y la magia desaparece, en el buen sentido. El agente no inventa nada. Lee lo que la herramienta le devolvió, igual que lee un archivo, y decide qué hacer con ello.

### Pregunta cómo planea hacerlo antes de que lo haga

Imagina que pides un MP4 creado a partir de código en lugar de imágenes reales. Pregunta cómo piensa hacerlo.

Te dirá que escribe HTML y CSS para la animación, lo renderiza en un navegador headless, graba los fotogramas y los codifica en un vídeo.

Ahora sabes algo útil. Ya tienes HTML, el de tu sitio web, con tus fuentes y tus colores. Así que puedes hacer la siguiente pregunta: *¿puedes reutilizar los estilos de mi web para que el vídeo se vea igual?*

No se te habría ocurrido preguntar eso una hora antes. Entender la ruta es lo que generó la idea.

```text
Antes de empezar: ¿cómo planeas hacer esto? ¿Qué herramientas, en qué
orden y qué produce cada paso? No escribas ningún código todavía.
```

### Pide tres formas, no una

Una respuesta será rápida de construir pero rígida. Otra será lenta de construir pero aceptará cualquier entrada que le des. Otra estará en medio.

Si lo dejas solo, un agente elige lo más sencillo que funcione, lo cual es un buen valor por defecto pero a menudo no es lo que quieres. Desafiarlo solo cuesta un mensaje.

```text
Dame tres formas de hacer esto, con las ventajas y desventajas de cada una: cuánto
tarda en construirse, cómo puede fallar y cuánto cuesta ejecutarlo. Dime
cuál elegirías tú y por qué.
```

### Pregunta qué fue lo que más tardó y qué le faltó

Después de una tarea costosa, pregunta qué pasos consumieron más tiempo y si tenía las herramientas adecuadas para el trabajo.

Aquí es donde descubres que estaba compensando carencias. Pídele que extraiga datos de empresas de LinkedIn y, al no tener una herramienta para ello, improvisará algo lento y poco fiable. Dale un servicio de scraping real como Apify y todo se reduce a una sola llamada.

Hice esto con mi propio renderizado de vídeo. Pregunté si la codificación podía ser más rápida. **Pasó de quince minutos a tres.** El mismo resultado. Eso cambió mi día, porque iterar cinco veces dejó de ocupar toda una tarde.

```text
Ya está hecho. Ahora analiza cómo lo has hecho: ¿qué pasos han tardado
más, dónde has tenido que improvisar por falta de una herramienta y qué
harías diferente? Prueba la versión mejorada y dime qué ha cambiado
y en qué medida.
```

**Merece la pena cuando es repetitivo**

  Nada de esto compensa en una tarea puntual. Hazlo y pasa a otra cosa. Compensa en el momento en que vuelvas a ejecutarlo la semana que viene, y a partir de ahí sigue compensando. Hay muy pocas tareas donde una pregunta extra no reduzca a la mitad el tiempo, los tokens o ambos.

### Prueba con tres antes de probar con doscientos

Antes de dirigir un agente hacia 200 competidores, haz que lo haga con 3. Luego pregunta qué fue lo más difícil de obtener, qué fue lento y dónde tuvo que adivinar.

Corregirás el proceso mientras corregirlo sea barato. A veces eso significa darle una herramienta que no tenía. Otras veces solo significa decir las cosas de otra manera.

```text
Antes de hacer esto para los 200, hazlo para 3. Luego dime qué funcionó,
qué no y qué cambiarías. Itera sobre esos 3 hasta tres veces si ayuda.
Cuando estés satisfecho con el método, explica cómo funciona y espera a que
lo apruebe antes de ejecutar los otros 197.
```

## La conclusión

Cada una de estas acciones toma un minuto y te devuelve una pieza de la imagen que las herramientas dejaron de mostrarte.

Después de un tiempo, dejas de delegar el problema completo y esperar lo mejor. Sabes aproximadamente qué hay debajo, así que preguntas mejor, detectas la respuesta errónea pero segura más rápido y reconoces un patrón que ya habías visto en una tarea completamente distinta.

Esto último es lo que no esperaba. La mayoría de mis mejores ideas del último año surgieron de entender cómo funcionaba algo y darme cuenta de que podía aplicarse a un lugar totalmente diferente.

## Mantén un lugar para experimentar

Tengo una carpeta llamada `duv-lab`. Su archivo `AGENTS.md` explica lo que es en una línea: un laboratorio, nada de lo que hay dentro es para producción, se espera desorden en los bordes.

Hay algunas cosas listas en la raíz para no tener que configurarlas nunca más: una clave de OpenRouter para probar modelos y credenciales de Cloudflare para que cualquier cosa pueda estar online en un minuto.

Luego, una subcarpeta por idea, cada una autónoma, cada una eliminable con `rm -rf` sin romper nada más. Pintar imágenes solo con JavaScript. Desmontar un modelo que devuelve probabilidades en lugar de texto. Animar un vídeo mediante código.

El objetivo es que no haya riesgos. Nada que romper, nada que justificar. La semana pasada grabé la pantalla de algo que alguien publicó, puse el clip en una carpeta nueva y pregunté: *si te pidiera que construyeras esto, ¿cómo lo harías y puedes probarlo de tres maneras?*

Necesitas un lugar así. Un lugar donde puedas equivocarte rápido sin que afecte al trabajo que realmente tienes que entregar.