Por qué las Clis superan a MCP en la creación de agentes de IA, y cómo crear tu propio ejército de Clis. El tipo con 190.000 estrellas en GitHub me acaba de dar la razón.

Seis palabras. Eso fue lo que publicó Peter Steinberger —el tipo detrás de OpenClaw, 190.000 estrellas en GitHub, recién reclutado por Sam Altman— en X el mes pasado. Y mi reacción inmediata fue hacerle una captura de pantalla y enviársela a tres amigos developers con un “TE LO DIJE” en mayúsculas.

Llevo años desarrollando en Ubuntu.

Cada herramienta que uso a diario es una CLI.

Supabase CLI, Vercel CLI, Docker, git, n8n — todo mi stack funciona y cobra vida desde una terminal. Cuando los servidores MCP empezaron a ser tendencia el año pasado, confieso que probé algunos. Funcionaban, es verdad. También consumían el 40% de mi ventana de contexto, fallaban aleatoriamente de la nada y añadían una dependencia absurda para algo que yo ya podía hacer perfectamente con un one-liner y un pipe.

Así que cuando el desarrollador open-source más prolífico de 2026 dice que las CLIs son la verdadera interfaz entre los agentes de IA y el mundo —y OpenAI está lo suficientemente de acuerdo como para ir a buscarlo y contratarlo— quizá sea momento de detenerse y prestar atención.

TL;DR: Los servidores MCP inflan tu ventana de contexto, añaden dependencias frágiles y resuelven un problema que no existe si tus herramientas ya son CLIs 😂 Peter Steinberger construyó ~10 CLIs personalizadas para OpenClaw y OpenAI lo contrató por ello.

Puedes usar exactamente este patrón hoy mismo con Claude Code (documentando CLIs en CLAUDE.md), conectarlas a OpenClaw como skills o construir tu propio agente autónomo con la API tool_use de Anthropic. Las CLIs son la interfaz nativa entre agentes IA y el mundo real. Las GUIs son para humanos. Las APIs son para servicios. Las CLIs son para agentes.

MCP vs CLI de un vistazo

Para poner las cartas sobre la mesa, vale la pena mirar frente a frente cómo se comportan ambas arquitecturas cuando un modelo de lenguaje intenta interactuar con ellas:

El caso contra MCP (y por qué el tipo de OpenClaw está de acuerdo con mi terminal)

Vamos a ordenar las formas en que un agente IA puede interactuar con herramientas externas. De peor a mejor, para que se entienda el panorama.

Las GUIs están obviamente descartadas en el primer segundo. No le pedirías jamás a tu pipeline de CI/CD que haga clics en un navegador para desplegar. La misma lógica aplica a los agentes. Sigamos.

Las APIs REST y SDKs funcionan, no lo voy a negar. Pero cada servicio tiene su propio flujo de autenticación, su propio formato de respuesta y su propio manejo de errores. Acabas escribiendo toneladas de código wrapper para cada bendita integración. Está bien para un backend SaaS convencional, pero es un exceso absoluto para un agente que solo necesita comprobar si tienes emails nuevos en la bandeja de entrada.

MCP —el Model Context Protocol— se suponía que iba a ser la solución definitiva a esto. Un protocolo estándar para conectar agentes con herramientas. Suena idílico y genial en teoría. ¿En la práctica? Cada servidor MCP que añades vuelca todo su esquema de golpe en la ventana de contexto de tu agente. Descripciones de herramientas, listas interminables de parámetros, declaraciones de capacidades —todo. Antes siquiera de que el agente empiece a pensar un solo segundo sobre tu petición real, ya se ha consumido un 30–40% del contexto en puro boilerplate de MCP.

Peter Steinberger lo probó. Construyó soporte para ello. Después creó MCPorter —una herramienta que literalmente convierte servidores MCP de nuevo en CLIs. Porque así de equivocado cree que está el formato.

Sus palabras exactas sobre lo único bueno que aportó MCP al ecosistema son para enmarcar:

“Lo único bueno de MCP fue que las empresas empezaron a abrir algunas APIs.”

Brutal. Y dolorosamente preciso. El protocolo en sí fue simplemente un desvío —las APIs que forzó a existir son el verdadero regalo de toda esta fiebre.

Las CLIs ganan por goleada porque son lo opuesto a todo ese bloat. Una CLI te ofrece:

• Cero overhead de contexto. Tu agente no necesita cargar un esquema pesado en memoria. Lee una página de documentación rápida (o ejecuta un comando --help) y ya conoce todos los comandos disponibles al instante.
• Composable. Puedes encadenar la salida de una CLI a otra con total naturalidad. goplaces search "coffee" --json | jq '.[0].address' —intenta hacer eso con un servidor MCP y me cuentas la frustración.
• Testeable en 2 segundos. Abres una terminal, ejecutas el comando tú misma y ves qué pasa en tiempo real. No hay servidor que levantar, ni handshake de protocolo que validar, ni conexiones WebSocket de las que depender.
• Salida estructurada gratis. Añades un flag --json y tu agente obtiene datos parseables de inmediato, sin ninguna capa extra de serialización caprichosa.
• Una sola llamada exec. Eso es todo lo que necesita un agente para usar una CLI. Sin middleware, sin protocolo, sin procesos en background consumiendo RAM valiosa solo por el hecho de existir.

El ejército de CLIs que llamó la atención de OpenAI

Y esto, de verdad, no es una simple preferencia teórica o un romance con la pantalla negra de la terminal.

Steinberger construyó todo el ecosistema de OpenClaw alrededor de CLIs. Aproximadamente una docena de ellas, cada una enfocada en una tarea ultraespecífica:

• goplaces para exprimir Google Maps.
• imsg para interactuar con iMessage.
• bird para conectar con X/Twitter.
• wacli para gestionar WhatsApp.
• gog para domar Gmail y Google Calendar.
• camsnap para interactuar con cámaras de seguridad.
• peekaboo para screenshots de macOS combinadas con visión IA.
• summarize para resumir de forma impecable vídeos y podcasts.

Cada una sigue rigurosamente el mismo patrón: hace una sola cosa bien, soporta --json y tiene un --help ridículamente claro.

Pasó la mayor parte de un año construyendo este ejército de CLIs. Y después, OpenAI fue y lo contrató. Sam Altman no reclutó a un ingeniero que hacía dashboards bonitos ni interfaces complejas —reclutó al tipo que demostró que bash es la mejor interfaz posible para que los agentes operen. Saca tus propias conclusiones.

Usar CLIs ahora mismo para construir más rápido (sin necesidad de OpenClaw)

No necesitas desplegar OpenClaw para empezar a beneficiarte de esto hoy mismo. Si usas Claude Code, Codex o cualquier agente con acceso a la shell, ya tienes toda la infraestructura que necesitas en tus manos.

El truco que la mayoría no termina de entender: tu agente ya puede llamar CLIs de forma nativa. Pero no conoce TUS CLIs específicas hasta que se lo dices explícitamente. Basta con dejar un archivo de texto bien estructurado en la raíz:

El archivo CLAUDE.md (raíz de tu proyecto)

Markdown

## CLIs disponibles

### Supabase
- `supabase db push` - aplicar migraciones al remoto
- `supabase functions deploy <name>` - desplegar edge function
- `supabase db dump --data-only` - exportar datos de producción
- `supabase migration new <name>` - crear nuevo archivo de migración

### Vercel
- `vercel deploy --prod` - desplegar a producción
- `vercel env pull .env.local` - sincronizar variables de entorno
- `vercel logs <url> --follow` - seguir logs de producción

### Específicas del proyecto
- `./scripts/check-mrr.sh` - devuelve JSON con MRR actual, registros y churn
- `./scripts/seed-demo.sh` - reinicia entorno demo con datos de ejemplo

Eso es todo lo que hace falta. Claude Code lee CLAUDE.md al inicio de cada sesión. La próxima vez que le digas “despliega a producción y comprueba si cambió el MRR”, ya sabe exactamente qué comandos ejecutar tras bambalinas. Sin plugins, sin servidor MCP intermedio, sin un archivo de configuración con 47 claves anidadas que te rompa la cabeza.

Para Codex, es el mismo concepto pero el archivo se llama AGENTS.md. Para Cursor, se llama .cursorrules. Nombre distinto, mismo patrón exacto.

Pero el verdadero movimiento inteligente es empezar a construir tus propias CLIs. Y antes de que cierres esta pestaña pensando “no tengo tiempo para construir herramientas CLI desde cero” —estamos hablando de escribir apenas 20–30 líneas de código. En serio.

Y hay un nivel aún más profundo que simplemente envolver servicios externos. La CLI que más importa es la que está dentro de tu propia app, compartiendo la misma capa de negocio que tu dashboard principal. Expliqué por qué deberías tratar esa CLI como el verdadero kernel de tu stack después de auditar dos de mis propias apps y encontrar una diferencia de velocidad de desarrollo de 1.8x a favor de este enfoque.

Para lograr que tus herramientas CLI sean un deleite para cualquier agente, solo tienes que seguir tres reglas esenciales:

1. Salida estructurada con --json

Tu agente no puede parsear cómodamente una tabla bonita llena de caracteres decorativos y líneas. Necesita JSON limpio.

JavaScript

#!/usr/bin/env node
// scripts/check-mrr.js
import { createClient } from '@supabase/supabase-js'

const supabase = createClient(process.env.SUPABASE_URL, process.env.SUPABASE_KEY)
const args = process.argv.slice(2)
const jsonMode = args.includes('--json')

const { data } = await supabase
  .from('subscriptions')
  .select('plan, status, created_at')

const active = data.filter(s => s.status === 'active')
const mrr = active.reduce((sum, s) => sum + (s.plan === 'pro' ? 29 : 9), 0)

const today = data.filter(s => 
  new Date(s.created_at).toDateString() === new Date().toDateString()
)

const stats = {
  mrr,
  active_subscriptions: active.length,
  signups_today: today.length,
  timestamp: new Date().toISOString()
}

if (jsonMode) {
  console.log(JSON.stringify(stats))
} else {
  console.log(`MRR: $${mrr}`)
  console.log(`Active: ${active.length}`)
  console.log(`Signups today: ${today.length}`)
}

2. Un --help que realmente explique las cosas

Los agentes leen el --help con la misma atención con la que los humanos leemos un buen README. Si tu menú de ayuda es vago o confuso, tu agente empezará a alucinar flags que no existen.

Bash

$ ./check-mrr.js --help

Usage: check-mrr [options]

Check current SaaS metrics from Supabase.

Options:
  --json     Output as JSON (default: human-readable)
  --period   Filter: today | week | month (default: today)
  --help     Show this message

3. Exit codes impecables y limpios

0 significa éxito absoluto. 1 (o cualquier otro número) significa error. Tu agente usa este estándar de la industria para decidir qué paso dar a continuación.

Aprendí esto por las malas a las 2 AM, viendo cómo mi script de deploy fallaba silenciosamente en la terminal mientras Claude seguía diciéndome con toda la calma del mundo: “Deployment successful”. Tardé 20 minutos de frustración en darme cuenta de que el script se estaba tragando los errores y seguía devolviendo un código 0 alegremente, pero me estoy desviando del tema.

Una vez que tienes unas cuantas CLIs diseñadas bajo este estándar, algo cambia en tu flujo de trabajo. Dejas de pedirle a Claude Code que escriba queries complejas de Supabase a mano; empiezas a decirle simplemente: “comprueba mis métricas y, si los registros han caído más de un 20% respecto a ayer, redacta un mensaje para Slack al equipo”. Claude encadena las CLIs, procesa la lógica interna y actúa firmemente sobre el resultado. Eso ya no es simple autocompletado de código. Eso es un agente autónomo de verdad.

El patrón que hace que esto escale: CLI + Skill Doc

Aquí está lo que Steinberger entendió muy pronto y que la mayoría de los desarrolladores todavía no ha interiorizado: una CLI sin documentación clara es completamente inútil para un agente.

Tu agente no puede explorar una CLI interactiva mediante prueba y error para ver qué pasa, como haría un humano curioso. Necesita saber de antemano qué comandos existen, qué flags están disponibles y cuál es la estructura exacta de la salida. Por eso cada una de las CLIs del ecosistema OpenClaw incluye un archivo SKILL.md —un documento estructurado que actúa como manual de instrucciones directo para el modelo.

El patrón es redondo: binario CLI + skill doc = capacidad autónoma.

La CLI se encarga del trabajo sucio. El skill doc le enseña al agente cómo invocarla adecuadamente. Juntos forman una unidad autocontenida que cualquier agente puede heredar. Steinberger las llama “skills”. El concepto es exactamente el mismo da igual si decides llamarlo skill, tool o “ese script bash que escribió Dave el martes pasado para salir del paso”.

Y lo mejor es que no necesitas OpenClaw para usar este patrón en tu día a día. De hecho, conceptualmente ya lo estás haciendo cuando escribes un CLAUDE.md para documentar tus herramientas. La diferencia es que Steinberger estandarizó este formato y construyó una capa de distribución masiva encima: ClawHub, que ya cuenta con más de 3.000 skills listas para explorar e instalar.

¿La parte realmente interesante? Puedes robar tranquilamente cualquiera de esas skills para tu propia configuración. Cada skill de ClawHub es simplemente una CLI que puedes instalar de forma independiente (brew install steipete/tap/goplaces, npm install -g @steipete/oracle, etc.) y un archivo SKILL.md que puedes leer. No necesitas para nada el runtime de OpenClaw. Instalas el binario en tu máquina, pegas los comandos relevantes en tu CLAUDE.md y Claude Code podrá usarlos inmediatamente.

Markdown

# En tu CLAUDE.md — robado directamente de ClawHub

## goplaces (Google Maps CLI)
- `goplaces search "coffee near me" --open-now --json` - buscar lugares
- `goplaces search "pizza" --lat 40.8 --lng -73.9 --radius-m 3000 --json` - búsqueda geolocalizada
- `goplaces details <place_id> --json` - detalles completos con reseñas
- `goplaces resolve "Soho, London" --json` - geocodificar un lugar

Requires: GOOGLE_PLACES_API_KEY env var

## summarize (CLI para resumir vídeos/podcasts/web)
- `summarize --url "https://youtube.com/watch?v=xxx" --json` - resumir un vídeo
- `summarize --url "https://some-blog.com/post" --json` - resumir una página web
- `summarize --url "https://podcast.fm/ep42" --cli claude --json` - elegir qué modelo usar

Ahí tienes a goplaces y summarize —dos herramientas del propio Steinberger— ejecutándose dentro de Claude Code sin rastro ni dependencia de OpenClaw. Solo un binario instalado y un documento de texto que le da contexto al modelo.

Por eso el enfoque CLI escala de una forma que MCP nunca logrará. Un servidor MCP es un proceso vivo en ejecución que necesita mantenimiento, configuración, handshake de protocolo y espacio valioso en la ventana de contexto. Una skill CLI es un binario estático y un archivo de texto explicativo. Uno necesita infraestructura dedicada; el otro solo necesita un brew install y 10 líneas bien escritas de markdown.

Conectando CLIs a OpenClaw

Si ya estás ejecutando OpenClaw en tu entorno, convertir una CLI propia en una skill lista para tus agentes te llevará apenas unos 5 minutos.

El sistema funciona con una simplicidad tremenda: cada skill tiene un archivo SKILL.md que describe minuciosamente qué hace la CLI, cómo se instala en el sistema y qué comandos están disponibles. El agente procesa ese archivo y asimila la herramienta al instante.

YAML

---
name: check-mrr
description: Check SaaS metrics (MRR, signups, churn) from Supabase.

metadata:
  openclaw:
    requires:
      env:
        - SUPABASE_URL
        - SUPABASE_KEY
      bins:
        - node
    primaryEnv: SUPABASE_URL
---

# check-mrr

Get current SaaS metrics from production Supabase.

## Install

npm install -g @yourhandle/check-mrr

## Commands

- `check-mrr --json` - full metrics as JSON
- `check-mrr --period week` - metrics for the current week
- `check-mrr --period month` - monthly overview

## Output format (--json)

{
  "mrr": 1247,
  "active_subscriptions": 89,
  "signups_today": 3,
  "timestamp": "2026-02-17T10:30:00Z"
}

Publícalo en ClawHub (clawhub publish) y cualquiera que use OpenClaw podrá instalar tu skill en segundos. Pero el verdadero valor está en lo que puedes hacer en local: combínalo con un cron job y tu agente comprobará tus métricas de negocio cada mañana de forma autónoma, enviándote un WhatsApp detallado si nota algo extraño o algún comportamiento anómalo.

JSON

// In openclaw.json

{
  "cron": [
    {
      "schedule": "0 8 * * *",
      "message": "Run check-mrr --json. If signups_today is 0 or mrr dropped more than 5% from yesterday, alert me on WhatsApp with a summary. Otherwise just log it.",
      "channel": "whatsapp"
    }
  ]
}

Ese es el loop completo y perfecto. El cron activa el agente en el servidor, el agente lee la skill configurada, ejecuta la CLI en la terminal, interpreta el JSON devuelto y decide con criterio qué acción tomar. Ningún dashboard aburrido que tener que revisar manualmente cada mañana. Ninguna fatiga por notificaciones innecesarias en tu teléfono. El agente usa su propio criterio —el mismo patrón que Steinberger utiliza meticulosamente en todo su ecosistema.

El directorio de ClawHub ya tiene más de 3.000 skills de terceros desarrolladas bajo esta estructura. goplaces para búsquedas geográficas, himalaya para gestionar emails vía IMAP, bird (a pesar de todo 😭) para X/Twitter, sonoscli para domar tus altavoces desde la consola… todo un ejército a tu disposición. Las instalas, el agente las aprende y están listas para rodar.

Construyendo tu propio agente (el patrón OpenClaw, sin OpenClaw)

Vale, ¿y si no quieres meterte en el ecosistema de OpenClaw? Quizá prefieres algo mucho más ligero, más personalizado a tus flujos diarios o simplemente disfrutas la gloria de construir tus propias herramientas desde cero. (Te entiendo perfectamente. Yo lo self-hosteo absolutamente todo en mis servidores. Es una enfermedad hermosa).

El patrón principal para lograr esto es absurdamente simple: un script Node básico que llama a la API de Anthropic configurando tool_use, mapea los nombres de las herramientas devueltas a ejecuciones reales en la CLI y mantiene el bucle activo hasta que el agente considera que ha terminado la tarea.

JavaScript

import Anthropic from '@anthropic-ai/sdk'
import { execSync } from 'child_process'

const client = new Anthropic()

// Tus CLIs declaradas como tools legibles para el modelo
const tools = [
  {
    name: "check_mrr",
    description: "Get current SaaS metrics (MRR, active subs, signups today)",
    input_schema: {
      type: "object",
      properties: {
        period: { type: "string", enum: ["today", "week", "month"], default: "today" }
      }
    }
  },
  {
    name: "deploy_production",
    description: "Deploy latest commit to Vercel production. Returns deploy URL.",
    input_schema: {
      type: "object",
      properties: {}
    }
  },
  {
    name: "send_slack",
    description: "Send a message to a Slack channel",
    input_schema: {
      type: "object",
      properties: {
        channel: { type: "string" },
        message: { type: "string" }
      },
      required: ["channel", "message"]
    }
  }
]

// Mapear de forma limpia nombres de tools a comandos reales de la CLI
function executeTool(name, input) {
  const commands = {
    check_mrr: `node ./scripts/check-mrr.js --json --period ${input.period || 'today'}`,
    deploy_production: `vercel deploy --prod --yes 2>&1`,
    send_slack: `curl -X POST -H 'Authorization: Bearer ${process.env.SLACK_TOKEN}' \
      -H 'Content-Type: application/json' \
      -d '{"channel":"${input.channel}","text":"${input.message}"}' \
      https://slack.com/api/chat.postMessage`
  }
  
  try {
    const result = execSync(commands[name], { encoding: 'utf-8', timeout: 30000 })
    return result
  } catch (err) {
    return JSON.stringify({ error: err.message, exitCode: err.status })
  }
}

// El loop core de nuestro agente
async function runAgent(task) {
  let messages = [{ role: "user", content: task }]
  
  while (true) {
    const response = await client.messages.create({
      model: "claude-sonnet-4-5-20260514", // usando la última versión estable del modelo
      max_tokens: 4096,
      system: "You are an autonomous agent. Use the available tools to complete tasks. Be concise in your reasoning.",
      tools,
      messages
    })

    // Si Claude terminó su trabajo y quiere responder, salimos del bucle
    if (response.stop_reason === "end_turn") {
      const text = response.content.find(b => b.type === 'text')
      return text?.text || 'Done.'
    }

    // Si Claude determina que necesita usar herramientas, las ejecutamos secuencialmente
    const toolBlocks = response.content.filter(b => b.type === 'tool_use')

    if (toolBlocks.length === 0) break

    messages.push({ role: "assistant", content: response.content })

    const toolResults = toolBlocks.map(block => ({
      type: "tool_result",
      tool_use_id: block.id,
      content: executeTool(block.name, block.input)
    }))

    messages.push({ role: "user", content: toolResults })
  }
}

// Ejecución inicial de prueba
const result = await runAgent(
  "Check our MRR. If it's above $1000, deploy to production and notify #team on Slack with the metrics. If it's below, just send a warning to Slack."
)

console.log(result)

~80 líneas de código estructurado. Ese es, literalmente, tu propio mini-OpenClaw personal. El agente tiene la capacidad de decidir de forma autónoma qué herramientas llamar y en qué orden lógico según la tarea exacta que le encomiendes. Añadir una nueva CLI a su arsenal te llevará apenas 30 segundos —añades una definición limpia de la tool, una línea en tu mapa de comandos exec y listo para rodar.

Para la parte de automatización autónoma desatendida, simplemente envuelve el script en un cron clásico de tu sistema:

Bash

# crontab -e

0 8 * * * cd /home/deploy/my-agent && node agent.js "Morning check: metrics, deploy if stable, notify team"

0 20 * * * cd /home/deploy/my-agent && node agent.js "End of day: summarize signups, flag any anomalies to Slack"

También tienes la opción de ejecutarlo como un servicio nativo de systemd acompañado de un timer, o meterlo directamente dentro de un contenedor Docker aislado en tu propio servidor doméstico. Mismo resultado final, diferentes sabores de devops según tus manías.

GitHub Actions es otra alternativa fantástica si lo que buscas es una infraestructura líquida con coste y mantenimiento cero. Un workflow programado que se encarga de levantar el entorno, instalar tus CLIs locales en el runner temporal e invocar la API de Anthropic:

YAML

name: Daily Agent Run

on:
  schedule:
    - cron: '0 8 * * *'

jobs:
  agent:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '22'

      - run: npm install @anthropic-ai/sdk

      - run: node agent.js "Morning routine"
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
          SUPABASE_URL: ${{ secrets.SUPABASE_URL }}
          SUPABASE_KEY: ${{ secrets.SUPABASE_KEY }}

Completamente gratis para repositorios públicos, y dispones de 2.000 minutos al mes en repositorios privados. Nada mal para mantener un agente operativo diario que apenas tarda 30 segundos en completar su ejecución.

¿Y n8n dónde queda en todo esto?

Sé bien que es tentador intentar orquestar tus CLIs directamente desde paneles visuales como n8n, utilizando su nodo nativo Execute Command o envolviendo tus scripts en pequeñas instancias locales de FastAPI.

Pero, siendo completamente sincera, para este caso de uso específico esa arquitectura suele generar bastante más fricción que el enfoque limpio con scripts de código. n8n es una absoluta maravilla cuando necesitas orquestar flujos de trabajo visuales complejos, con 15 pasos distintos e integraciones complejas de branching —pero no aporta valor real para un flujo directo de “ejecuta una CLI concreta en la terminal y deja que el LLM decida el camino según el resultado”.

Si de todas formas quieres profundizar en cómo ejecutar código personalizado dentro de ese entorno, hace poco escribí una guía completa sobre cómo llamar scripts Python desde n8n que cubre detalladamente toda la configuración con Docker + FastAPI.

Qué significa todo esto para ti

La tendencia de la industria está clara y se mueve rápido.

Los builders más rápidos y productivos en el espacio actual de los agentes de IA no están perdiendo el tiempo apilando servidores MCP complejos ni peleándose con adaptadores de protocolo rebuscados. Están escribiendo CLIs pequeñas, afiladas como bisturís, y dejando que sus agentes las invoquen con total libertad.

Peter Steinberger lo demostró con creces a escala real con OpenClaw. OpenAI lo validó de la forma más rotunda posible extendiéndole un contrato de trabajo. Y tú puedes empezar hoy mismo a aplicar esta filosofía con un simple archivo CLAUDE.md bien estructurado y un script en Node de apenas 20 líneas.

El stack tecnológico de fondo no importa en absoluto. Ya sea OpenClaw, Claude Code, Codex o tu propio loop de agente personalizado —el patrón maestro permanece idéntico. Envuelve tus herramientas cotidianas en CLIs limpias. Documéntalas con mimo para tu agente. Y deja que el LLM se encargue de toda la orquestación pesada.

Un último apunte para cerrar: este artículo aborda las CLIs como la interfaz perfecta para que los agentes llamen herramientas externas. La otra mitad vital de la ecuación es la CLI que decides construir dentro de tu propia aplicación, donde se convierte en el kernel definitivo que permite a Claude Code desplegar features completas mientras tú descansas. Diferente superficie de ataque, pero compartiendo exactamente la misma capa de ingeniería.

Añade una CLI robusta a tu app o prepárate para que Claude Code te esté haciendo ping en Slack por cada pequeña funcionalidad que necesite.

Tu terminal llevaba siendo la interfaz de IA perfecta todo este tiempo. La mayoría simplemente todavía no se había dado cuenta del potencial que tenía guardado en su pantalla negra.

Gracias por leer Código en Casa.
Si esto te a ayudado y te sumo algo Dale un 👏 , compártelo con tu red o dejame un comentario para saber tu opinión.