Agent Communication Protocol (ACP): El HTTP de los agentes de IA

1530 palabras
8 min de lectura

Otro protocolo más que promete cambiarlo todo

Cuando IBM Research anunció el Agent Communication Protocol (ACP) como parte del proyecto BeeAI, mi primera reacción fue la habitual: “Ah, otro protocolo universal más”. Con casi 30 años en esto, he visto demasiados “estándares definitivos” que acabaron en el olvido.

Pero hay algo diferente en ACP que me hizo prestar atención: no promete resolver todos los problemas del mundo. Simplemente se enfoca en uno muy específico: hacer que agentes de IA de diferentes frameworks puedan hablar entre sí. Y lo hace de una manera que realmente tiene sentido.

El problema real que ACP intenta resolver

Imaginad que tenéis un agente construido con LangChain que necesita cooperar con otro hecho en CrewAI, y ambos tienen que coordinarse con un tercero desarrollado internamente. Ahora multiplicad eso por N frameworks y M equipos.

El resultado es lo que vemos hoy: islas de agentes que no pueden comunicarse. Cada framework inventa su propia forma de hacer las cosas, su propio formato de mensajes, su propia manera de manejar el estado.

// La realidad actual: cada framework su rollo
const langchainAgent = new LangChainAgent(config);
const crewAIAgent = new CrewAIAgent(setup);
const customAgent = new CustomFrameworkAgent(params);

// ¿Cómo los conectas? Con código pegamento único para cada par
// langchain -> crewai: custom integration #1
// langchain -> custom: custom integration #2  
// crewai -> custom: custom integration #3
// Y así sucesivamente...

ACP propone algo diferente: un protocolo estándar RESTful que cualquier agente puede implementar. No importa si está hecho en Python, TypeScript, Go o lo que sea.

¿Por qué ACP puede funcionar donde otros fallaron?

1. Se basa en estándares conocidos

No han reinventado la rueda. ACP es REST sobre HTTP, usando tipos MIME estándar para identificar contenido. Nada revolucionario, pero funciona:

# Ejemplo de mensaje ACP
POST /agents/translator/run
Content-Type: application/json

{
  "messages": [
    {
      "role": "user", 
      "content": "Translate this to Spanish",
      "mimeType": "text/plain"
    }
  ]
}

2. Diseño async-first, pero con soporte sync

Los agentes pueden tardar minutos o horas en completar tareas. ACP está diseñado para esto:

# Ejemplo con el SDK de Python
from acp_sdk.server import Server

server = Server()

@server.agent()
async def research_agent(input: list[Message], context: Context):
    # Puede tardar horas en completar
    yield {"status": "started", "message": "Iniciando investigación..."}
    result = await deep_research(input)
    yield {"status": "completed", "result": result}

3. Multimodal desde el diseño

No está limitado a texto. Imágenes, audio, video, documentos… cualquier tipo MIME funciona:

{
  "content": "data:image/png;base64,iVBORw0KGgo...",
  "mimeType": "image/png"
}

4. Arquitectura descentralizada

No hay un servidor central. Cada agente expone su propia API ACP. Los agentes se descubren entre sí usando metadatos embebidos:

# Manifiesto del agente
name: "translator-agent"
description: "Traduce texto entre idiomas"
capabilities:
  - translation
  - text-processing
endpoints:
  - url: "http://localhost:8080/acp"

Lo que realmente me gusta de ACP

Simplicidad operacional

Cada agente es un proceso independiente. Nada de sistemas complejos de orquestación. Si un agente se cae, no afecta a los demás.

Compatibilidad con Docker y Kubernetes

# Dockerfile para agente ACP
FROM python:3.11-slim
COPY . /app
WORKDIR /app
RUN pip install acp-sdk
EXPOSE 8080
CMD ["python", "agent.py"]

Deploy como cualquier otro servicio. Nada especial que aprender.

Observabilidad integrada

ACP incluye hooks para OpenTelemetry. Trazas, métricas, logs… todo integrado desde el minuto uno.

Interactividad

Los agentes pueden pausar para pedir información adicional al cliente:

# El agente puede preguntar cosas durante la ejecución
yield RequestInput({
    "prompt": "¿Qué formato prefieres para el informe?",
    "options": ["PDF", "HTML", "Markdown"]
})

# Espera la respuesta del usuario
user_choice = yield WaitForInput()

BeeAI: La implementación de referencia

IBM no se limitó a publicar un spec. BeeAI es una plataforma completa que implementa ACP:

# Instalación en macOS
brew install i-am-bee/beeai/beeai

# Configuración rápida
beeai env setup  # configura providers (Ollama, OpenAI, etc.)

# Lista agentes disponibles
beeai list

# Ejecuta un agente
beeai run chat "¿Cómo está el tiempo?"

Y lo importante: interfaz web incluida en localhost:8333 para debugging, logs, trazas.

Casos de uso reales que he visto

1. Pipeline de análisis financiero

  • Agente scraper: Extrae datos financieros de múltiples fuentes
  • Agente análisis: Procesa los datos y genera insights
  • Agente reportes: Crea presentaciones automáticas

Cada uno en su propio framework, pero comunicándose vía ACP.

2. Sistema de seguridad

  • Agente logs: Procesa logs de CrowdStrike
  • Agente threat intel: Enriquece indicadores sospechosos
  • Agente mitigación: Crea tickets de Jira o dispara Terraform

Todo orquestado sin un orquestador central.

3. Investigación académica

  • Agente crawler: Extrae papers de arXiv
  • Agente indexer: Construye índices vectoriales
  • Agente research: Genera resúmenes y análisis

Cada investigador puede desarrollar su agente usando su stack preferido.

Lo que me preocupa (porque siempre hay peros)

1. ¿Es realmente necesario?

Con APIs REST funcionando bien, ¿necesitamos otro protocolo? El argument de IBM es que ACP añade:

  • Metadatos estándar para descubrimiento
  • Sesiones con estado
  • Interactividad integrada
  • Comunicación multimodal

Válido, pero ¿suficiente para justificar la complejidad adicional?

2. Fragmentación del ecosistema

Ya tenemos MCP de Anthropic, A2A de Google, y ahora ACP de IBM. ¿No estamos creando más fragmentación?

La respuesta de IBM es interesante: ACP puede encapsular MCP. Un agente ACP puede usar herramientas MCP internamente.

3. Seguridad

Agentes hablando entre sí, accediendo a datos empresariales, ejecutando código… ¿qué podría salir mal?

ACP incluye “capability tokens” - tokens criptográficos que limitan qué puede hacer cada agente. Pero la seguridad en sistemas multi-agente es compleja.

4. Performance

HTTP + JSON para todo. ¿Qué pasa cuando necesitas transferir GBs de datos entre agentes?

ACP permite streaming, pero aún así… REST no es el protocolo más eficiente para todo.

¿Por qué ACP puede triunfar?

Linux Foundation + Governance abierta

No es un proyecto corporativo. Está bajo la Linux Foundation con governance transparente. Eso reduce el riesgo de vendor lock-in.

Ecosistema en crecimiento

Ya hay agentes de referencia para casos comunes:

  • RAG con LlamaIndex
  • Análisis de código
  • Procesamiento de documentos
  • Integración con bases de datos

Foco en desarrolladores

No es una plataforma para end-users. Es una herramienta para desarrolladores que construyen sistemas multi-agente.

Timing

2025 es el año donde multi-agent systems empiezan a ser mainstream. ACP llega en el momento adecuado.

Mi experiencia práctica

He montado un setup de prueba con tres agentes:

  1. Agente monitor (Python + FastAPI)
  2. Agente analyzer (Node.js + Express)
  3. Agente reporter (Go + Gin)

La configuración fue sorprendentemente simple:

# Agent 1: Monitor
@server.agent()
async def monitor_system():
    metrics = collect_metrics()
    # Envía datos al analyzer
    response = await acp_client.run_agent(
        "analyzer", 
        messages=[{"content": json.dumps(metrics)}]
    )
    return response
// Agent 2: Analyzer  
app.post('/agents/analyzer/run', async (req, res) => {
  const { messages } = req.body;
  const analysis = await analyzeMetrics(messages[0].content);
  
  // Envía al reporter
  await acpClient.runAgent('reporter', [{
    content: JSON.stringify(analysis)
  }]);
  
  res.json({ status: 'completed' });
});

Funcionó a la primera. Cada agente en su tecnología preferida, comunicándose sin problemas.

Diferencias clave con MCP

AspectoMCPACP
EnfoqueModel-to-toolsAgent-to-agent
TransporteJSON-RPCREST/HTTP
EstadoStatelessCon sesiones
DescubrimientoManualAutomático
InteractividadLimitadaIntegrada

No compiten directamente. MCP conecta modelos con herramientas. ACP conecta agentes entre sí. Pueden usarse juntos.

Mi recomendación (spoiler: experimenta)

Si estás construyendo sistemas multi-agente:

Para proyectos pequeños:

Quizás ACP sea overkill. HTTP directo puede ser suficiente.

Para sistemas empresariales:

ACP aporta valor real. Descubrimiento automático, observabilidad, interactividad… merece la pena el overhead adicional.

Para equipos distribuidos:

ACP brillará cuando diferentes equipos desarrollen agentes usando sus stacks preferidos.

Cómo empezar

1. Instala BeeAI

# macOS
brew install i-am-bee/beeai/beeai

# Linux
curl -sSL https://install.beeai.dev | bash

# Windows (WSL)
curl -sSL https://install.beeai.dev | bash

2. Configura un proveedor

beeai env setup
# Elige Ollama para local, OpenAI para cloud

3. Prueba un agente existente

beeai run chat "Explícame ACP en una frase"

4. Crea tu primer agente

# agent.py
from acp_sdk.server import Server
from acp_sdk.models import Message

server = Server()

@server.agent()
async def hello_agent(input: list[Message], context):
    name = input[0].content if input else "mundo"
    return f"¡Hola {name}!"

if __name__ == "__main__":
    server.run()
python agent.py &
beeai run hello "Antonio"

El panorama más amplio

ACP no es solo un protocolo técnico. Es una apuesta por la interoperabilidad en un momento donde la IA se está fragmentando.

Si miramos hacia atrás, los protocolos que triunfaron fueron los que:

  1. Resolvían problemas reales (HTTP, TCP/IP)
  2. Eran adoptados por múltiples vendors (no propietarios)
  3. Llegaron en el momento adecuado (ni muy temprano ni muy tarde)

ACP cumple los tres requisitos. Pero el tiempo dirá si es suficiente.

Conclusión: Cautelo optimismo

Como alguien que ha visto fallar muchos “estándares universales”, mantengo mi escepticismo saludable. Pero ACP tiene elementos que me dan confianza:

  • Governance abierta bajo Linux Foundation
  • Implementación de referencia funcional (BeeAI)
  • Casos de uso claros y específicos
  • Diseño técnico sólido basado en estándares probados

No va a resolver todos los problemas de la IA. Pero puede resolver el problema específico de la comunicación entre agentes. Y a veces, eso es suficiente.

Mi consejo: experimentad con ACP en proyectos pequeños. Ved si encaja en vuestro stack. Si construís sistemas multi-agente, puede ser exactamente lo que necesitáis.


¿Qué opináis? ¿Creéis que ACP tiene futuro, o es otro protocolo más destinado al olvido? ¿Habéis experimentado ya con sistemas multi-agente?

Mi intuición dice que 2025 será el año donde veremos si ACP despega o se queda en el limbo. Mientras tanto, vale la pena estar preparados.

PD: Si decidís probarlo, empezad con BeeAI. La instalación es sorprendentemente simple, y los ejemplos funcionan de verdad.

Comentarios

Artículos relacionados

6 min

1147 palabras

Dos protocolos, dos filosofías

En los últimos meses han aparecido dos protocolos que van a cambiar cómo construimos sistemas de IA: Agent2Agent Protocol (A2A) de Google y Model Context Protocol (MCP) de Anthropic. Pero aquí está el tema: no compiten entre sí.

Es más, tras analizar ambos durante semanas, me he dado cuenta de que entender la diferencia entre A2A y MCP es crucial para cualquiera que esté construyendo sistemas de IA más allá de simples chatbots.

5 min

857 palabras

Hace unos días me topé con un stream muy interesante donde alguien mostraba su setup para programación agéntica usando Claude Code. Después de años desarrollando “a la vieja usanza”, tengo que admitir que esto me ha resultado revelador.

¿Qué es la programación agéntica?

Para los que no estéis familiarizados con el término, la programación agéntica es básicamente dejar que un agente de IA (en este caso Claude) escriba código por ti. Pero no hablo de pedirle que te genere un snippet, sino de darle acceso completo a tu sistema para que pueda leer, escribir, ejecutar y debuggear código de forma autónoma.

5 min

1004 palabras

Últimamente no para de hablarse de agentes de IA por todas partes. Cada empresa tiene su roadmap lleno de “agentes que van a revolucionar esto y aquello”, pero cuando rascas un poco, te das cuenta de que pocos han conseguido realmente construir algo útil y que funcione en producción.

Hace poco leí un artículo muy interesante de LangChain sobre cómo construir agentes de forma práctica, y me ha parecido un enfoque muy sensato que quería compartir contigo. Lo he adaptado con mis propias reflexiones después de haberme dado más de un cabezazo intentando implementar sistemas “inteligentes” que al final no lo eran tanto.

8 min

1681 palabras

Hace unos años, muchos investigadores de IA (incluso los más reputados) predecían que el prompt engineering sería una habilidad temporal que desaparecería rápidamente. Se equivocaron completamente. No solo no ha desaparecido, sino que ha evolucionado hacia algo mucho más sofisticado: Context Engineering.

Y no, no es solo otro término de moda. Es una evolución natural que refleja la complejidad real de trabajar con LLMs en aplicaciones productivas.

De prompt engineering a context engineering

El problema con el término “prompt engineering” es que mucha gente lo confunde con blind prompting - simplemente escribir una pregunta en ChatGPT y esperar un resultado. Eso no es ingeniería, es usar una herramienta.

02
Jul 2025
6 min

1145 palabras

Confesión de un escéptico convertido

Cuando Anthropic anunció el Model Context Protocol (MCP) en noviembre de 2024, mi primera reacción fue: “Ah, otro protocolo más que promete resolver todos los problemas de integración”. Como DevOps Manager que ha visto nacer y morir docenas de “estándares universales”, tengo razones para ser escéptico.

Pero después de varios meses viendo cómo MCP se ha adoptado masivamente - OpenAI lo integró en marzo 2025, Google DeepMind en abril - decidí investigar más allá del hype. Y tengo que admitir algo: estaba equivocado.

5 min

987 palabras

Hace unos meses, cuando Anthropic lanzó su protocolo MCP (Model Context Protocol), sabía que íbamos a ver integraciones interesantes entre LLMs y bases de datos. Lo que no esperaba era ver algo tan pulido y funcional como AgentHouse de ClickHouse tan pronto.

Tengo planificado probar esta demo en breve, pero ya solo leyendo sobre ella me parece fascinante la idea de poder preguntarle a una base de datos cosas como “¿cuáles son los repositorios más populares de GitHub este mes?” y obtener no solo una respuesta, sino visualizaciones automáticas.