El desarrollo de software clásico piensa primero en interfaces: lista de clientes, página de proyectos, botón de carga, formulario de facturas, vista de calendario. Para las personas tiene sentido. Para los agentes de IA, las automatizaciones y los sistemas externos es el modelo de abstracción incorrecto.
Un agente no debería necesitar saber en qué página se encuentra un botón.
Lo que un agente realmente necesita
Un agente no navega por interfaces. Invoca capacidades. Las preguntas relevantes son:
- ¿Qué acciones existen?
- ¿Qué entradas espera una acción y qué salidas produce?
- ¿Qué permisos son necesarios?
- ¿Qué acción es de riesgo o irreversible?
- ¿Cuándo se necesita una consulta al usuario?
- ¿Qué se audita?
El software UI-first no responde ninguna de estas preguntas. El software MCP-first las responde todas.
Klassisch
- Webapp
- Mobile App
- Admin UI
- API
- Automation
- AI-Integration
MCP-first
- Domain Model
- Action Layer
- Permission Layer
- MCP Tools
- MCP Resources
- MCP Workflows
- Audit Layer
- Webapp · Mobile · Admin · API · Automation
Tesis 1: Los agentes de IA no usan el software como los humanos
Las personas hacen clic, se desplazan, leen e interpretan. Los agentes necesitan capacidades estructuradas que puedan invocarse directa y de forma segura.
El segundo enfoque es determinista, tipado, con verificación de permisos y auditable. El primero genera automatización de navegador frágil que se rompe con cada actualización de UI.
-
schedule_follow_up(contactId, projectId, datetime, note) -
contacts.search(query, tenantId) -
reminders.create(contactId, datetime, note, assignedTo) -
calendar.find_free_slot(participantIds, duration, after)
Tesis 2: La interfaz de usuario se convierte en uno de muchos clientes
En el pasado, la UI era el acceso principal al software. En el futuro habrá múltiples accesos equivalentes, todos utilizando la misma capa de capacidades:
- Persona a través de la aplicación web
- Persona a través de la app móvil
- Agente de IA a través de MCP
- Automatización a través de Worker
- Proveedor externo a través de API
- Sistemas internos a través de Events
- CLI a través de la capa de acciones
Quien construye primero la aplicación web y arrastra el resto, construye la misma capa de acciones varias veces, cada vez ligeramente diferente, cada vez con su propia lógica de permisos.
Tesis 3: El software sin capacidad para agentes se vuelve difícil de integrar
Si el software solo funciona a través de interfaces, inevitablemente surgen soluciones alternativas frágiles:
- Automatización de navegador y screen scraping
- Importaciones CSV y procesos manuales de copiar y pegar
- Flujos de trabajo semiautomáticos
- Soluciones especiales por cliente o proyecto de integración
Estas soluciones se rompen con los cambios de UI, no escalan y no pueden auditarse. MCP-first elimina la razón de su existencia al hacer que el sistema sea controlable de forma estructurada desde el principio.
Tesis 4: La mejor interfaz para muchas tareas no es ninguna interfaz
Muchas tareas son dialógicas, contextuales y basadas en flujos de trabajo, ya no necesitan una página:
«Crea un resumen de todos los deals abiertos.» «¿A qué clientes debería contactar hoy?» «Verifica si le faltan documentos a este empleado.» «Crea un informe sobre todos los proyectos con riesgo.» «Compara las dos últimas nóminas.»
Para estas tareas, un agente conversacional con acceso a una capa de capacidades es más eficiente que cualquier página con filtros y tablas. El requisito previo: las capacidades están modeladas de forma limpia, tipadas y con niveles de riesgo.
Low Generar resumen, Medium Crear documento, Critical Exportar nómina, el sistema debe conocer estas diferencias.
Tesis 5: MCP-first reduce el desarrollo duplicado
Si una funcionalidad se construye primero como una acción, cualquier cliente puede usar la misma acción, sin implementación doble:
create_project(name, templateId, ownerId, tenantId)Esta única acción es utilizable desde:
- Aplicación web
- App móvil
- UI de administración
- Agente MCP
- CLI
- Worker
- Proceso de importación
- Integración
- Suite de pruebas
Esto no solo reduce el esfuerzo, elimina las inconsistencias entre los clientes que de otro modo se acumulan con el tiempo.
Tesis 6: MCP-first impone una arquitectura mejor
Quien construye MCP-first debe modelar de forma más limpia de manera automática. Cada capacidad necesita:
- acciones de dominio claras con intención de usuario inequívoca
- esquemas de entrada y salida tipados
- permisos claros y gestión de errores
- efectos secundarios definidos
- Audit Events y niveles de protección
Esto obliga a asignar claramente la responsabilidad funcional antes de escribir una sola línea de código de UI.
-
Input Schema, tipado, validado -
Output Schema, determinista -
Permission Scopes, qué rol puede invocar -
Risk Level, low / medium / high / critical / forbidden -
Side Effects, efecto externo, sí o no -
Audit Event, qué se registra -
Confirmation Policy, autónomo o aprobación humana
API-first era para desarrolladores. MCP-first es para agentes.
El software construido primero como un sistema de capacidades completamente descrito, con verificación de permisos y auditado, es a la vez mejor para las personas, mejor para los agentes y mejor para todo lo que hay entre medias.