Cómo Construyo Realmente Agentes de IA Que Hacen el Trabajo

Hace seis meses, vi a un ingeniero hacer una demo de un agente de IA que agendaba reuniones, redactaba propuestas y actualizaba un CRM — todo desde un solo prompt. La secuencia completa tomó unos noventa segundos. El público aplaudió. Alguien preguntó "¿esto es real?" El presentador sonrió y dijo que sí.

Fui a casa e intenté construir lo mismo. Me tomó tres semanas lograr algo que funcionara a medias. El agente alucinaba llamadas a herramientas. Perdía el contexto entre pasos. Llamaba a los endpoints de API equivocados con los parámetros incorrectos. En un momento, envió un correo de prueba a un cliente real con el asunto "TODO: fix this later."

Esa experiencia me enseñó algo a lo que sigo volviendo: la brecha entre una demo de un agente de IA y un agente de IA que funciona en producción es enorme. Y casi nadie habla de lo que llena esa brecha.

Recientemente vi el análisis de Remy Gasill sobre cómo dominar los agentes de IA — un recorrido genuinamente exhaustivo que cubre toda la pila, desde modelos mentales hasta arquitectura práctica. Cristalizó muchos patrones que yo venía usando intuitivamente en marcos que ahora puedo explicar con claridad. Lo que sigue es mi visión de esos conceptos, filtrada a través de meses construyendo agentes con Claude Code para proyectos reales, clientes reales y errores reales.

¿Lo que más me sorprendió? La parte más difícil de construir agentes de IA útiles no es la IA. Es todo lo que rodea a la IA.

Los Modelos de Chat No Son Agentes (y la Confusión Te Cuesta Semanas)

Necesito aclarar esto primero porque el malentendido está tan extendido que se ha convertido en el modelo mental por defecto — y es incorrecto.

Cuando la mayoría de la gente dice "uso agentes de IA," se refiere a que abre ChatGPT o Claude y escribe preguntas. Eso es un modelo de chat. Uno muy bueno. Pero es fundamentalmente una interacción de un solo paso: preguntas, responde, preguntas de nuevo, responde de nuevo. Cada intercambio es relativamente aislado. El modelo no sale a hacer cosas en tu nombre. Responde.

Un agente es arquitectónicamente diferente. Un agente recibe un objetivo, lo divide en pasos, ejecuta esos pasos usando herramientas, evalúa los resultados y decide qué hacer a continuación — todo sin que escribas otro prompt. El humano establece el destino. El agente conduce.

Piénsalo de esta manera. Si le pides a un modelo de chat que "configure un nuevo proyecto de Express.js con TypeScript, ESLint y Prettier configurados," te dará una respuesta hermosa explicando cada paso. Quizás incluso bloques de código que puedes copiar y pegar. Pero tú todavía tienes que crear los archivos. Tú todavía tienes que ejecutar los comandos. Tú todavía tienes que depurar los conflictos de configuración entre ESLint y Prettier que el modelo olvidó mencionar.

¿Un agente ejecutándose dentro de Claude Code? Crea el directorio. Inicializa el proyecto. Instala las dependencias. Escribe los archivos de configuración. Ejecuta el linter para verificar que todo funcione. Corrige los dos conflictos de configuración que encuentra. Hace commit del resultado. Listo.

Esa diferencia — entre decirte qué hacer y realmente hacerlo — es todo el cambio de paradigma. Y cambia cómo piensas sobre cada tarea que delegas a la IA.

Pasé mi primer mes con Claude Code todavía tratándolo como un modelo de chat. Haciendo preguntas. Leyendo respuestas. Ejecutando manualmente las sugerencias. El momento en que empecé a darle objetivos en lugar de preguntas, mi productividad cambió de una manera que puedo medir: tareas que me tomaban 45 minutos empezaron a terminarse en menos de 10. No porque la IA se volviera más inteligente. Porque dejé de ser el cuello de botella entre su pensamiento y su ejecución.

Pero hay algo más — un agente solo funciona si su arquitectura subyacente es sólida. Y esa arquitectura tiene nombre.

El Bucle del Agente: Observar, Pensar, Actuar

Todo agente de IA funcional opera sobre el mismo bucle central. Remy Gasill lo llama "observar, pensar, actuar," y ese enfoque es el más limpio que he visto. Una vez que entiendes este bucle, entiendes por qué los agentes tienen éxito o fracasan — y más importante aún, cómo depurarlos cuando fallan.

Observar. El agente absorbe contexto. Esto incluye la tarea original, cualquier archivo que haya leído, las salidas de herramientas de pasos anteriores, mensajes de error, estado del entorno. Todo lo que el agente sabe en este momento vive en su ventana de contexto. La calidad de esta fase de observación determina todo lo que viene después.

Pensar. El LLM razona sobre lo que ha observado. ¿Qué se ha logrado hasta ahora? ¿Qué falta? ¿Cuál es el siguiente paso lógico? ¿Debería llamar a una herramienta, pedir aclaraciones o entregar un resultado final? Aquí es donde la inteligencia del modelo realmente importa — y es donde los modelos más económicos empiezan a flaquear en tareas complejas.

Actuar. El agente ejecuta una llamada a herramienta. Leer un archivo. Ejecutar un comando en terminal. Hacer una solicitud a una API. Editar código. Cualquier acción que el paso de razonamiento haya seleccionado, el agente la ejecuta. El resultado de esa acción retroalimenta la fase de observación, y el bucle continúa.

Este ciclo se repite — a veces tres veces, a veces treinta — hasta que el agente determina que la tarea está completa.

Esto es lo que me tomó un tiempo interiorizar: la calidad del agente vive en el bucle. No en el modelo. No en las herramientas. En el bucle. Un modelo mediocre con excelente ingeniería de contexto y herramientas bien diseñadas superará a un modelo brillante con contexto descuidado y herramientas mal definidas. Lo he probado. He ejecutado la misma tarea a través de Claude Opus 4.6 con archivos de contexto basura versus Claude Sonnet con contexto cuidadosamente diseñado. Sonnet ganó. Consistentemente.

Por eso los tres conceptos siguientes — harnesses, ingeniería de contexto y skills — importan tanto. Todos son mecanismos para hacer que el bucle funcione mejor.

Harnesses de Agentes: La Cabina Donde Se Sienta Tu IA

El bucle del agente no se ejecuta en el vacío. Necesita un entorno — un harness — que gestione la ejecución del bucle, proporcione herramientas, maneje permisos y presente la interfaz con la que interactúas. Piénsalo como la cabina de un avión. El LLM es el piloto. El harness es cada instrumento, superficie de control y sistema de seguridad que rodea a ese piloto.

He trabajado extensamente con cuatro harnesses, y cada uno tiene su personalidad.

Claude Code es mi herramienta diaria. Nativo de terminal, integración profunda con el sistema de archivos y git, permisos granulares. Cuando necesito un agente que pueda razonar sobre un codebase completo y ejecutar cambios con confianza, nada más se le acerca ahora mismo.

Codex de OpenAI crea un entorno sandbox en la nube para cada tarea — tus archivos locales permanecen intactos a menos que sincronices explícitamente los resultados. Excelente para equipos preocupados por el radio de impacto. La contrapartida es la latencia por la creación del entorno.

OpenClaw es la opción open-source que vale la pena seguir. Basado en terminal, extensible, impulsado por la comunidad. Bordes más ásperos que Claude Code, pero máximo control sobre el comportamiento del agente.

Los agentes Co-work (como el agente web de Claude de Anthropic) manejan tareas de larga duración. Lanza una solicitud, cierra el navegador, vuelve por los resultados. Síntesis de investigación, análisis de documentos extensos, flujos de trabajo de múltiples pasos que no necesitan interacción en tiempo real.

Elige el harness que coincida con tu forma de trabajar. Perdí dos semanas intentando usar un agente web para iteración rápida de código antes de cambiar a Claude Code — y mi frustración desapareció de la noche a la mañana. No hay una mejor opción universal, solo la adecuada para tu flujo de trabajo.

Pero independientemente del harness que elijas, hay un protocolo que rápidamente se está convirtiendo en el estándar para conectar agentes a herramientas externas. Y si aún no lo estás usando, estás construyendo con una mano atada a la espalda.

MCP: El Puerto USB-C para Agentes de IA

Model Context Protocol — MCP — es una de esas cosas que suena aburrida hasta que entiendes lo que realmente desbloquea. Entonces se convierte en la pieza más emocionante de la pila de agentes.

Este es el problema que MCP resuelve. Digamos que quieres que tu agente interactúe con tu base de datos. Sin MCP, escribirías código personalizado: una función que se conecta a PostgreSQL, ejecuta una consulta, formatea los resultados y los envía de vuelta al agente. Luego quieres integración con Slack. Más código personalizado. Luego Google Calendar. Más código personalizado. Luego tu API interna. Más código personalizado. Cada integración es a medida, frágil y mantenida solo por ti.

MCP estandariza esto. Crea un protocolo universal — piénsalo como un puerto USB-C — al que cualquier herramienta puede conectarse. Alguien construye un servidor MCP para PostgreSQL una vez, y cada harness de agente que soporte MCP puede usarlo. Otra persona construye uno para Slack. Otro para Notion. Otro para tu CRM. Al agente no le importa cómo funciona la herramienta internamente. Simplemente la llama a través de MCP y recibe resultados estructurados.

Actualmente ejecuto servidores MCP para GitHub, acceso al sistema de archivos y una API interna personalizada que construí para un proyecto de cliente. Añadir una nueva capacidad a mi agente solía significar escribir código de integración. Ahora significa agregar tres líneas a un archivo de configuración que apunta a un servidor MCP.

La configuración práctica se ve así en Claude Code:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "your-token-here"
      }
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": {
        "DATABASE_URL": "postgresql://user:pass@localhost:5432/mydb"
      }
    }
  }
}

Coloca eso en tu configuración .claude/, y de repente tu agente puede consultar repos de GitHub y bases de datos PostgreSQL tan naturalmente como lee archivos. Sin wrappers personalizados. Sin código de API frágil. Solo herramientas, disponibles y listas.

El ecosistema MCP está creciendo rápido. A principios de 2026, hay servidores mantenidos por la comunidad para docenas de servicios — bases de datos, herramientas de comunicación, proveedores de nube, plataformas de gestión de proyectos. La calidad varía (algunos son excelentes, otros son proyectos de fin de semana), pero la trayectoria es clara. MCP se está convirtiendo en la capa de integración estándar para agentes de IA.

Una nota de seguridad que quiero señalar aquí porque es importante: cada servidor MCP que agregas amplía la superficie de ataque de tu agente. Un servidor MCP con acceso a la base de datos significa que tu agente puede leer — y potencialmente escribir — tu base de datos. Define los permisos de forma estricta. Usa conexiones de solo lectura cuando sea posible. No le des a tu agente las llaves de producción a menos que hayas pensado bien en lo que pasa cuando comete un error. Porque cometerá errores. Los míos ciertamente lo han hecho.

Esto nos lleva a algo tan importante como las herramientas que tu agente puede usar — y posiblemente más importante: el contexto que tu agente recibe antes de empezar a trabajar.

Ingeniería de Contexto: La Habilidad Que Nadie Enseña

Solía pensar que la ingeniería de prompts era la habilidad limitante para trabajar con IA. Escribe mejores prompts, obtén mejores resultados. Y es cierto — para modelos de chat. Para agentes, el cuello de botella es algo diferente: la ingeniería de contexto.

La ingeniería de contexto es la práctica de estructurar lo que un agente sabe antes y durante la ejecución. No es solo el prompt que escribes. Son los archivos que el agente lee automáticamente. Las instrucciones a nivel de proyecto que ingiere antes de procesar tu solicitud. La memoria que lleva de sesiones anteriores. Las convenciones que sigue sin que se las repitas cada vez.

En Claude Code, la ingeniería de contexto vive principalmente en dos lugares: archivos CLAUDE.md y agents.md.

Tu archivo CLAUDE.md es lo primero que Claude Code lee cuando inicia una sesión en cualquier directorio. El mío contiene convenciones específicas del proyecto, decisiones arquitectónicas, estándares de código e instrucciones explícitas sobre qué NO hacer. Esa última parte — las restricciones negativas — resultó ser sorprendentemente importante. Sin ellas, los agentes hacen suposiciones razonables-pero-incorrectas constantemente.

Aquí tienes un ejemplo simplificado de uno de mis proyectos Laravel:

# CLAUDE.md

## Project Architecture
- Laravel 11 with Inertia.js + React 19 + TypeScript
- PostgreSQL 16, Redis 7 for caching and queues
- All API responses use the ApiResponse helper class — never return raw arrays

## Conventions
- Controllers: single-action when possible, __invoke method
- Form Requests for ALL validation — never validate in controllers
- Feature tests use RefreshDatabase, unit tests don't touch the database

## Do NOT
- Never modify the User model without explicit approval
- Never change database migrations that have already been committed
- Never use DB::raw() — use the query builder or Eloquent scopes
- Never create routes outside of routes/web.php and routes/api.php

Ese archivo me ahorra corregir al agente docenas de veces por sesión. Sin él, Claude Code ocasionalmente ponía lógica de validación en controladores, usaba consultas SQL crudas o creaba archivos de rutas en ubicaciones no estándar. Todas opciones razonables en aislamiento — simplemente incorrectas para este proyecto específico.

El patrón agents.md extiende esto aún más para configuraciones multi-agente. Cuando tengo agentes especializados — un agente de revisión de código, un agente de documentación, un agente de testing — cada uno obtiene su propio archivo de contexto definiendo su rol, restricciones y comportamiento esperado. Así es como pasas de un agente de propósito general a un equipo de agentes especializados que cada uno hace bien su trabajo.

Remy Gasill hizo una observación que se me quedó grabada: la ingeniería de contexto en última instancia trata de reducir el número de decisiones que un agente tiene que tomar por su cuenta. Cada decisión que toma autónomamente es un error potencial. Cada decisión que codificas en el contexto es una oportunidad menos para que el agente se desvíe. Las mejores configuraciones de agentes que he construido son casi aburridas de observar. El agente no toma decisiones creativas. Sigue un camino bien definido, usando herramientas bien definidas, dentro de restricciones bien definidas. Y produce trabajo excelente gracias a esa previsibilidad, no a pesar de ella.

Pero los archivos de contexto solo cubren lo que el agente debe saber al inicio. ¿Qué hay de lo que aprende durante el trabajo?

Memory.md: Enseñando a Tu Agente a Recordar

Esta es la función que transformó mis flujos de trabajo con agentes de basados-en-sesión a continuos.

Por defecto, cuando cierras una sesión de Claude Code, todo lo que el agente aprendió durante esa sesión desaparece. Abre una nueva sesión, y empieza de cero. No sabe sobre el bug que arreglaste ayer. No sabe sobre el patrón de API que acordaste la semana pasada. No sabe que la clase UserService fue refactorizada en tres servicios más pequeños durante la sesión anterior.

Memory.md cambia esto. Es un archivo persistente — almacenado en el directorio de tu proyecto — que el agente lee al inicio de cada sesión y puede actualizar durante la sesión. Piénsalo como un cuaderno compartido entre tus sesiones pasadas y futuras con el agente.

Mi memory.md para un proyecto actual se ve algo así:

# Memory

## Decisions Made
- 2026-03-10: Switched from JWT to session-based auth. JWT was causing issues
  with token refresh on mobile. Session approach uses Redis for storage.
- 2026-03-14: Moved all email templates from Blade to React Email. Better
  component reuse and type safety.
- 2026-03-17: Added rate limiting middleware to all public API endpoints.
  Config: 60 requests/minute for authenticated, 20 for unauthenticated.

## Known Issues
- The PaymentService has a race condition on concurrent subscription updates.
  Temporary fix: database-level advisory lock. Proper fix planned for next sprint.
- Test suite takes 4+ minutes to run. Focus: writing targeted tests, not
  running the full suite on every change.

## Patterns Established
- All new services use constructor injection with interfaces, not facades.
- Background jobs extend BaseJob which handles retry logic and dead-letter queue.
- API versioning: URI-based (/v1/), not header-based.

Cuando el agente lee este archivo al inicio de la sesión, inmediatamente tiene continuidad. No sugerirá JWT para el sistema de autenticación. No usará Blade para plantillas de correo. Sabe sobre la condición de carrera y no la activará accidentalmente. Sigue los patrones establecidos sin que se lo recuerden.

Actualizo este archivo manualmente aproximadamente una vez por semana, y he empezado a hacer que el propio agente agregue entradas cuando se toman decisiones significativas durante una sesión. El comando es simple — "agrega esta decisión a memory.md" — y el agente formatea y agrega la entrada.

El efecto compuesto es real. Después de un mes manteniendo memory.md, mis sesiones con el agente empiezan notablemente más rápido. Menos correcciones. Menos repetición. Menos "no, decidimos no hacerlo de esa manera." El agente tiene conocimiento institucional. Y ese conocimiento persiste.

Si prefieres que alguien configure toda esta arquitectura de agentes — archivos de contexto, sistemas de memoria, integraciones MCP, todo el workspace — acepto exactamente este tipo de encargos. Puedes ver lo que he construido en fiverr.com/s/EgxYmWD.

Ahora, la memoria le dice al agente qué pasó en el pasado. Pero ¿cómo le dices cómo hacer tareas recurrentes de la manera correcta, cada vez?

Skills: Procedimientos Operativos Estándar Que Tu Agente Puede Seguir

Los skills son el concepto que finalmente hizo que mis agentes fueran consistentes. Antes de adoptarlos, cada vez que le pedía a un agente que "escribiera un artículo de blog" o "creara un endpoint de API" o "configurara un nuevo microservicio," la calidad del resultado variaba. A veces excelente. A veces mediocre. Siempre ligeramente diferente de la vez anterior.

El problema no era el modelo. Era yo. Estaba dando instrucciones vagas y esperando resultados consistentes. Es como darle a alguien un puesto de trabajo sin manual de incorporación y sorprenderte cuando hace las cosas diferente a lo que esperabas.

Los skills son el manual de incorporación.

Un skill es un archivo markdown — almacenado en .claude/skills/ — que contiene instrucciones paso a paso para una tarea específica y repetible. El agente lee el skill relevante antes de ejecutar y lo sigue como un procedimiento operativo estándar.

Aquí tienes un skill real que uso para crear endpoints de API en mis proyectos Laravel:

# Skill: Create API Endpoint

## Steps
1. Create a Form Request class in `app/Http/Requests/` with validation rules
2. Create a single-action controller using `__invoke` method
3. Add the route to `routes/api.php` inside the appropriate version group
4. Create a feature test in `tests/Feature/Api/` that covers:
   - Successful request with valid data
   - Validation failure with each invalid field
   - Authentication/authorization check
   - Edge cases specific to the endpoint
5. Run the test suite: `php artisan test --filter={TestClassName}`
6. If tests pass, add the endpoint to the API documentation in `docs/api.md`

## Conventions
- Response format: always use ApiResponse::success() or ApiResponse::error()
- Status codes: 201 for creation, 200 for retrieval/update, 204 for deletion
- Never return Eloquent models directly — use API Resources

## Common Mistakes to Avoid
- Don't forget to add the route inside the auth middleware group
- Don't use Route::resource() — we use explicit single-action routes
- Don't skip the authorization check in the Form Request

Cuando le digo al agente "crea un endpoint de API para actualización de perfil de usuario," lee este skill y lo sigue paso a paso. Cada vez. La estructura del controlador es consistente. La cobertura de pruebas es consistente. El formato de respuesta es consistente. No más variaciones. No más "oh, esta vez se olvidó del Form Request."

La belleza de los skills como archivos markdown simples es la portabilidad. Funcionan en diferentes harnesses de agentes. El mismo archivo de skill que uso en Claude Code funciona en Cursor, en OpenClaw, en cualquier herramienta que lea instrucciones en markdown. Una sola fuente de verdad, múltiples consumidores.

Actualmente tengo once skills en mi proyecto principal: creación de endpoint de API, migración de base de datos, scaffolding de componentes, escritura de tests, revisión de código, actualización de documentación, verificaciones de despliegue, auditoría de seguridad, revisión de rendimiento, triaje de bugs y generación de descripciones de PR. Cada uno me tomó 15-20 minutos escribirlo. Combinados, me ahorran horas por semana y — más importante aún — eliminaron toda una categoría de momentos "el agente lo hizo mal."

Los skills se potencian con la memoria. El agente lee el skill para saber cómo hacer algo. Lee memory.md para saber qué decisiones ya se tomaron. Juntos, le dan al agente el conocimiento procedimental y el contexto institucional que necesita para operar como un miembro del equipo que lleva meses en el proyecto, no como un contratista que ve el codebase por primera vez.

Seguridad y Alcance de Permisos: La Conversación Que Nadie Quiere Tener

Voy a ser directo: darle a un agente de IA acceso a tu sistema de archivos, terminal y APIs externas es una decisión de seguridad. Trátala como tal.

Un ingeniero que conozco le dio a su agente acceso de escritura total y este sobrescribió un archivo .env de producción durante un refactoring rutinario. Nada malicioso — solo una decisión razonable-pero-catastrófica en un contexto donde el agente no debería haber tenido ese poder.

Mis principios de permisos:

Principio de mínimo privilegio. Dale al agente exactamente el acceso que necesita y nada más. Si solo necesita leer archivos, no le des acceso de escritura. Si solo necesita trabajar dentro de /src, no le permitas acceder a /. Los servidores MCP deben usar conexiones de solo lectura a la base de datos a menos que las escrituras sean explícitamente necesarias para la tarea.

Aisla las operaciones no confiables. Cuando pruebes un nuevo skill o un nuevo servidor MCP, ejecútalo en un entorno aislado primero. Una rama de git nueva, un contenedor Docker, una VM desechable. Observa lo que hace el agente antes de confiarle algo valioso.

Los registros de auditoría importan. Los diffs de git son tus aliados. Cada cambio del agente debe hacerse commit de forma incremental para que puedas revisar y revertir. Reviso los diffs generados por el agente de la misma manera que reviso pull requests de desarrolladores junior — con atención y escepticismo saludable.

Separa los entornos estrictamente. Los proyectos de producción reciben permisos más estrictos, menos servidores MCP y secciones explícitas de Do NOT. Los proyectos experimentales reciben más libertad porque el radio de impacto es menor.

Claves de API y credenciales. Nunca pongas credenciales en archivos de configuración accesibles por el agente. Usa variables de entorno. Asume que cualquier cosa que el agente pueda leer podría aparecer accidentalmente en un log o comentario de código generado. Lo he visto pasar.

Los agentes en los que más confío son los que he restringido con más cuidado.

Hablando de arquitectura cuidadosa — cómo organizas todas estas piezas importa más de lo que esperarías.

Arquitectura del Workspace: La Estructura de Carpetas Que Escala

Después de meses de iteración, he llegado a una estructura de workspace para proyectos potenciados por agentes que maneja todo — contexto, memoria, skills, configuración MCP — sin convertirse en un desorden a medida que el proyecto crece.

project-root/
├── .claude/
│   ├── settings.json          # MCP servers, permission config
│   ├── agents/
│   │   ├── code-review.md     # Specialized agent: code review
│   │   ├── documentation.md   # Specialized agent: docs
│   │   └── testing.md         # Specialized agent: test writing
│   └── skills/
│       ├── create-endpoint/
│       │   └── skill.md
│       ├── write-migration/
│       │   └── skill.md
│       ├── security-audit/
│       │   └── skill.md
│       └── deploy-check/
│           └── skill.md
├── CLAUDE.md                  # Project-level context (read on every session)
├── memory.md                  # Persistent agent memory
├── src/                       # Your actual code
├── tests/
└── docs/

Tres decisiones de diseño que vale la pena destacar. Primero, CLAUDE.md vive en la raíz del proyecto, no enterrado dentro de .claude/ — la visibilidad asegura el mantenimiento. Segundo, los skills son carpetas (no archivos individuales) porque eventualmente acumulan plantillas y ejemplos de apoyo. Tercero, memory.md es singular y global. Intenté archivos de memoria por agente. La sincronización fue una pesadilla. Un archivo compartido mantiene el conocimiento institucional unificado entre todos los agentes.

Esta estructura ha sobrevivido cuatro proyectos de clientes sin necesitar reorganización. La clave es empezar con ella desde el día uno — adaptarla a un proyecto existente es posible pero tedioso.

Primeros Pasos: Tu Primera Configuración de Agente Lista para Producción en 30 Minutos

Si has leído hasta aquí, tienes el modelo mental. Ahora aquí está cómo pasar de cero a una configuración de agente funcional que incluye todo lo que hemos cubierto — contexto, memoria, skills e integración básica de MCP. Treinta minutos. Sin atajos, sin ejemplos de juguete.

Paso 1: Instala Claude Code (5 minutos)

npm install -g @anthropic-ai/claude-code

Ejecuta claude en el directorio de tu proyecto. Se autenticará con tu cuenta de Anthropic en el primer inicio. Si necesitas una configuración más económica, cubrí Claude Code con OpenRouter en una guía separada.

Paso 2: Crea tu CLAUDE.md (10 minutos)

Estos son los diez minutos de mayor impacto que invertirás. Crea un CLAUDE.md en la raíz de tu proyecto con cuatro secciones: Visión General del Proyecto (qué es, qué stack usa), Arquitectura (decisiones clave, estructura de directorios), Convenciones (estándares de código, patrones de nombres) y Do NOT (cosas que el agente nunca debe hacer).

Sé específico. "Seguir mejores prácticas" es inútil. "Todas las respuestas de API deben usar la clase ResponseHelper en app/Helpers/" es útil. El agente no puede leer tu mente, pero puede leer tu markdown.

Paso 3: Inicializa memory.md (2 minutos)

Crea un memory.md en la raíz del proyecto con tres secciones vacías: Decisiones Tomadas, Problemas Conocidos y Patrones Establecidos. Empieza ligero. Este archivo crece orgánicamente a medida que tú y el agente toman decisiones reales juntos. Forzar contenido prematuramente genera ruido.

Paso 4: Crea tu primer skill (8 minutos)

Elige la tarea que haces con más frecuencia. Para mí, fue crear endpoints de API. Para ti, podría ser escribir tests, hacer scaffolding de componentes o configurar nuevas páginas. Sea lo que sea — escribe los pasos que sigues cada vez en un archivo skill.md:

mkdir -p .claude/skills/your-task-name

Escribe el archivo de skill con pasos numerados, convenciones y errores comunes. Mantenlo por debajo de 50 líneas. Si es más largo, probablemente estás combinando múltiples skills o sobre-especificando.

Paso 5: Agrega un servidor MCP (5 minutos)

Empieza con algo de bajo riesgo. El servidor MCP de sistema de archivos o el de GitHub son buenas primeras opciones. Crea .claude/settings.json:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
      }
    }
  }
}

Almacena el token real en tus variables de entorno, no en el archivo de configuración. Pruébalo pidiendo al agente que "liste mis pull requests recientes de GitHub" y verifica que devuelva datos reales.

Paso 6: Ejecuta tu primera tarea agéntica (5 minutos)

Empieza con algo de lo que conozcas la respuesta correcta — no algo complejo. Pídele al agente que realice una tarea cubierta por tu archivo de skill. Observa cómo usa el contexto de CLAUDE.md y sigue los pasos del skill.

Si el resultado no da en el blanco, la solución casi siempre está en los archivos de contexto, no en el prompt. Afina el CLAUDE.md. Actualiza el skill con el paso que se saltó. Este ajuste iterativo es el verdadero trabajo de construir agentes de producción.

El Futuro Es un Sistema Operativo de IA Personal

Esto es en lo que pienso cuando miro hacia dónde se dirige todo esto — y quiero ser honesto, esto es especulación informada por patrones, no una predicción por la que apostaría mi hipoteca.

Estamos construyendo hacia sistemas operativos de IA personales. No del tipo vaporware que se presenta en conferencias. Del tipo práctico donde tu workspace de agentes se convierte en la interfaz principal para tus herramientas digitales. Piensa en lo que ya tenemos: un agente que lee archivos, ejecuta comandos, interactúa con APIs a través de MCP, recuerda decisiones pasadas, sigue procedimientos documentados y mejora a medida que el contexto y los skills se acumulan. Eso no es un chatbot. Es una capa de sistema operativo entre tú y tus herramientas.

Remy Gasill apuntó hacia esta misma conclusión. MCP proporciona el estándar de integración. Los skills proporcionan conocimiento procedimental. La memoria proporciona continuidad. La ingeniería de contexto proporciona alineación. Las piezas existen. Se están construyendo sobre protocolos abiertos que cualquier harness puede adoptar.

Lo que más me emociona no es la expansión de capacidades — es la multiplicación del apalancamiento. Un ingeniero con un workspace de agentes bien configurado trabaja a una escala diferente. Tareas que antes requerían contratar a alguien se convierten en tareas que delegas entre el café y tu primera reunión.

Lo Que Esto Realmente Cambia en Tu Forma de Trabajar

Esto es lo que quiero que te lleves — un modelo mental claro y una acción concreta.

El modelo mental: un agente de IA es un bucle (observar, pensar, actuar) ejecutándose dentro de un harness (Claude Code, Codex, etc.), conectado a herramientas (vía MCP), guiado por contexto (CLAUDE.md, agents.md), siguiendo procedimientos (skills) y recordando trabajo previo (memory.md). Cada uno de esos componentes es una palanca que puedes ajustar para mejorar tu agente. Cuando algo sale mal, identifica qué componente falló y corrígelo — no simplemente reescribas tu prompt.

La acción concreta: toma treinta minutos hoy y construye la estructura de workspace que describí en la sección de implementación. Crea el CLAUDE.md. Inicia el memory.md. Escribe un skill. Agrega un servidor MCP. Ejecuta una tarea. Esa es tu línea de partida.

Dentro de seis meses, mirarás atrás al flujo de trabajo con agentes que has construido — el contexto acumulado, los skills refinados, el archivo de memoria probado en batalla — y te darás cuenta de algo. El agente no se volvió más inteligente durante esos seis meses. Tú te volviste mejor dirigiéndolo. Y esa es la verdadera habilidad que nadie enseña: no cómo usar IA, sino cómo diseñar el sistema que hace que la IA sea útil.

¿Cuál es la primera tarea que vas a delegar?

Preguntas Frecuentes

¿Cuál es la diferencia entre un agente de IA y un chatbot normal?

Un agente de IA ejecuta autónomamente tareas de múltiples pasos usando herramientas — leyendo archivos, ejecutando comandos, llamando a APIs — en un bucle continuo hasta que se cumple el objetivo. Un chatbot responde a prompts individuales sin tomar acción. Para detalles sobre el bucle observar-pensar-actuar, consulta la sección del Bucle del Agente más arriba.

¿Cómo funciona MCP (Model Context Protocol) con agentes de IA?

MCP proporciona una interfaz estandarizada para conectar agentes de IA a herramientas y servicios externos como bases de datos, APIs y plataformas de comunicación. Configuras servidores MCP en el archivo de configuración de tu agente, y el agente los llama como herramientas nativas. Consulta la sección de MCP más arriba para ejemplos de configuración.

¿Necesito experiencia en programación para configurar agentes de IA para productividad?

Familiaridad básica con el terminal y edición de archivos es suficiente para empezar. La configuración del workspace usa archivos markdown y configuración JSON — no se requiere código de framework. El tutorial paso a paso en la sección de implementación cubre la configuración completa para principiantes.

¿Qué harness de agente de IA debería usar — Claude Code, Codex u OpenClaw?

Elige según tu flujo de trabajo: Claude Code para desarrollo nativo de terminal con integración profunda del sistema de archivos, Codex para ejecución en la nube con aislamiento y garantías de seguridad, OpenClaw para máxima extensibilidad open-source. La sección de Harnesses de Agentes más arriba compara cada uno en detalle.

¿Cómo mantengo seguro mi agente de IA al darle acceso a herramientas?

Aplica principios de mínimo privilegio: conexiones de solo lectura a la base de datos, tokens de API con alcance limitado, pruebas aisladas para nuevas herramientas y restricciones de permisos explícitas en tus archivos de contexto. Nunca almacenes credenciales en archivos de configuración accesibles por el agente — usa variables de entorno. Las prácticas de seguridad completas se cubren en la sección de Seguridad más arriba.

Let's Work Together

Looking to build AI systems, automate workflows, or scale your tech infrastructure? I'd love to help.

• Fiverr (custom builds & integrations): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (enterprise solutions): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (security services): xcybersecurity.io