La arquitectura Agent First: Agents, Skills, MCP y APIs
Por qué UnifAPI pone primero a los Agents de marketing, carga Skills como flujos y deja las APIs de SEO, GEO, navegador y social como evidencia.
En resumen: UnifAPI ahora parte del trabajo que un marketer quiere delegar en Claude, Codex u otro asistente compatible con MCP. Los Agents son la superficie de producto, las Skills son los runbooks ejecutables, MCP es la vía de conexión y las APIs son la capa de evidencia de datos públicos en vivo.
La primera versión de UnifAPI era fácil de explicar a los desarrolladores: una clave de API, un contrato OpenAPI, muchos endpoints de datos públicos. Eso sigue siendo cierto, pero ya no es la primera frase más útil para un operador que quiere que un asistente haga investigación de marketing.
Un operador no pide «la familia de endpoints de SEO» ni «una llamada de Browser Markdown renderizado». Pide una auditoría de rank, un informe de visibilidad GEO, una lista corta de creadores, un brief de competidores, un escaneo de local pack o un memorando de oportunidades de contenido. La arquitectura Agent First empieza ahí.
Las cuatro capas
| Capa | Qué significa | Ejemplo |
|---|---|---|
| Agent | Un rol de marketing con nombre que ejecutas dentro de tu asistente | SEO Agent, AI Visibility Agent, Competitive Intelligence Agent |
| Skill | Una única capacidad implementada como un runbook SKILL.md | seo-audit, ai-answer-gap, competitor-profiling |
| MCP | La vía de conexión que permite al asistente llamar a UnifAPI | list_operations, get_operation, call_api |
| API | El contrato de datos públicos en vivo detrás del flujo de trabajo | /seo/serp, /geo/serp, /browser/markdown |
Este stack importa porque cada capa tiene un trabajo distinto. El Agent nombra el resultado. La Skill le dice al asistente cómo hacer el trabajo. MCP gestiona la autenticación, el descubrimiento y la invocación. La API devuelve registros que se pueden citar.
Esa separación mantiene honesto al producto. Si una Skill dice que puede comprobar la visibilidad en IA, la API de GEO debe devolver registros de respuesta, citación, mención y volumen. Si un SEO Agent dice que puede inspeccionar una página, la API de Browser debe devolver Markdown o HTML renderizado, no solo una cadena de URL.
Por qué los Agents van primero
Los Agents de UnifAPI no son bots alojados. Los ejecutas dentro del asistente que ya usas, como Claude o Codex. UnifAPI aporta el rol, las Skills y los datos públicos a través de MCP.
Esa redacción es deliberada. El runtime es tu asistente. El Agent de UnifAPI es el paquete de flujo de trabajo específico del rol. La capa de datos es UnifAPI.
Esto le da al operador un modelo mental sencillo:
- Elige el Agent que coincide con el trabajo.
- Conecta UnifAPI MCP una sola vez.
- Pega o carga el prompt del Agent.
- Deja que el asistente obtenga la evidencia pública que necesita.
- Revisa el brief con citas y decide qué hacer a continuación.
El mismo stack también puede servir a un desarrollador. Un desarrollador puede saltarse el flujo de trabajo en prosa y llamar directamente a la API HTTP, pero la superficie de marketing pública no debería obligar a cada persona no desarrolladora a aprender primero el catálogo de la API.
Qué cambió con las Skills
Las Skills ya no son solo temas de blog o ejemplos. Son los artefactos de implementación que hacen que un Agent sea repetible.
Una buena Skill nombra una capacidad concreta: auditar SEO, hacer seguimiento de menciones de LLM, investigar una cuenta de LinkedIn, construir una lista corta de creadores, escanear competidores locales o perfilar a un competidor. Debería incluir las frases de activación, la lista de comprobación de entradas, las llamadas de datos públicos a usar, la forma de salida, las reglas de confianza y los límites.
Por eso una Skill es más útil que un fragmento de prompt. Un prompt puede pedir un resultado. Una Skill puede codificar el flujo de trabajo, las decisiones sobre la fuente de datos y el estándar de evidencia esperado.
Por qué el catálogo de API sigue importando
El catálogo de API sigue siendo la fuente de verdad para los datos en vivo. SEO, GEO, Browser, local, redes sociales, noticias, viajes y eventos publican todos sus endpoints a través del contrato unificado.
La diferencia está en por dónde entra el operador:
| Intención del usuario | Mejor punto de entrada |
|---|---|
| «Auditar posiciones para estas keywords» | SEO Agent |
| «Hacer seguimiento de si ChatGPT nos cita» | AI Visibility Agent |
| «Leer esta página con mucho JavaScript» | Browser API o SEO Skill |
| «Construir una lista corta de creadores» | Influencer Marketing Agent |
| «Integrar datos públicos en mi propia app» | Documentación de la API HTTP |
La arquitectura permite a UnifAPI añadir más APIs sin convertir el producto en un gigantesco menú de endpoints. La nueva cobertura de API se vuelve más útil cuando está conectada a una Skill y a un resultado de Agent.
El límite de solo lectura
El producto actual es «ojos, no manos». UnifAPI lee datos públicos. No publica, no edita fichas, no compra anuncios, no envía mensajes a leads ni guarda credenciales de publicación de los upstreams.
Un Agent todavía puede recomendar pasos de acción. El SEO Agent puede decir qué página mejorar. El AI Visibility Agent puede explicar qué fuentes necesitan una mejor cobertura de citación. El Social Selling Agent puede redactar ángulos de acercamiento. El operador y sus propias herramientas ejecutan esas acciones.
Ese límite es buena disciplina de producto. Mantiene simple la autenticación, protege a los usuarios de acciones de escritura accidentales y hace que cada salida sea revisable.
Una ejecución de ejemplo
Dale al SEO Agent un dominio y un conjunto de keywords. El asistente carga las Skills de SEO, se conecta a través de UnifAPI MCP, llama a registros de SEO en vivo, usa Browser Markdown para la inspección de la página renderizada y devuelve:
| Sección | Evidencia |
|---|---|
| Resumen de rank | Posiciones de SERP orgánica y de IA por consulta |
| Brechas de visibilidad | Consultas donde los competidores posicionan o son citados |
| Diagnóstico de página | Encabezados, enlaces y bloques de contenido de la página renderizada |
| Plan de correcciones | Cambios priorizados etiquetados como recomendaciones, no acciones |
| Registro de fuentes | Operaciones llamadas, registros usados y notas de confianza |
El operador no tiene que conocer el árbol de endpoints antes de la primera respuesta útil. Pero el árbol de endpoints sigue ahí para trazabilidad y uso en producción.
Referencias principales
El encuadre arquitectónico de este artículo debería mantenerse alineado con la visión general oficial de la arquitectura del Model Context Protocol. MCP describe un modelo de host, cliente y servidor, con primitivos como herramientas, recursos y prompts; el lenguaje de producto de UnifAPI mapea esos primitivos en las capas orientadas al operador descritas arriba.
Para el contenido y el markup de entidades, las páginas de blog generadas usan metadatos de artículo compatibles con esquemas; compara el vocabulario público en Schema.org Article y Schema.org BlogPosting. Para los fundamentos de página orientados a la búsqueda, mantén la implementación alineada con la Guía de inicio de SEO de Google.
Qué leer a continuación
Auditorías de rank en vivo del SEO Agent - la versión role-agent del seguimiento clásico de posiciones.
AI Visibility Agent para GEO - cómo los registros de GEO respaldan el trabajo de visibilidad en motores de respuesta.
API de Browser para la lectura web de agentes - por qué las páginas renderizadas son una capacidad de apoyo para los Agents de marketing.