Latent Space publicó una entrevista con Andrew Qu, Chief of Software en Vercel, sobre una idea que conviene tomar en serio: los agentes no son simplemente aplicaciones web con un cuadro de chat encima. Para Qu, son una nueva forma de software.

La entrevista, publicada en Latent Space, explica cómo Vercel pasó de facilitar el despliegue de sitios y aplicaciones web a construir herramientas para agentes. El recorrido incluye una librería para MCP, skills.sh, el trabajo en v0 y eve, un framework interno para construir agentes.

De páginas web a agentes

Vercel nació alrededor de una promesa clara: hacer más fácil que los developers publiquen sitios y aplicaciones. Pero Qu dice que la compañía empezó a ver un cambio: de gente construyendo páginas a gente construyendo agentes.

En v0, su producto de vibe coding, Vercel encontró problemas prácticos que las herramientas existentes no resolvían bien: cambiar modelos o proveedores, agregar fallbacks, reanudar ejecuciones y manejar trabajos más largos. Esas soluciones se fueron convirtiendo en primitivas reutilizables. Con el tiempo, ese conjunto tomó forma en eve.

La parte interesante es que Vercel no está pensando solo en UI. Está pensando en infraestructura para sistemas que deciden, usan herramientas, recuperan contexto, se ejecutan en sandboxes y pueden continuar una tarea.

Por qué Qu habla de una nueva forma de software

Qu distingue agentes de aplicaciones web tradicionales por previsibilidad. Una app web normal tiene rutas, estados y outputs relativamente controlados. Un agente trabaja con lenguaje, contexto, herramientas y decisiones que pueden variar. La infraestructura puede parecer similar, pero la interacción y el resultado son mucho más dinámicos.

Eso exige nuevas piezas: contexto bien empaquetado, herramientas seguras, trabajos resumibles, evaluación, observabilidad, compaction, subagentes y sandboxes. No es casualidad que estos temas también aparezcan en nuestra guía sobre cómo usar agentes de código sin romper tu proyecto.

La palabra “agente” se usa demasiado, pero aquí hay una distinción útil. Un chatbot responde. Un workflow ejecuta pasos definidos. Un agente mezcla intención, contexto, herramientas y decisiones parcialmente abiertas. Eso lo vuelve potente y también incómodo para el software tradicional, porque el output no siempre está completamente determinado por una ruta o un formulario.

Por eso la infraestructura importa. Si un agente puede escribir archivos, llamar APIs, cambiar una base de datos o abrir un pull request, el problema ya no es solo UX. Es permisos, rollback, logs, evaluación, costos, seguridad y responsabilidad. Un agente que parece “mágico” en demo puede ser peligroso en producción si nadie sabe qué hizo, por qué lo hizo y cómo revertirlo.

Skills: conocimiento portable y actual

Uno de los puntos más concretos de la entrevista es el papel de las skills. Qu las describe como conocimiento portable y bajo demanda. Los modelos suelen contener información vieja: por ejemplo, pueden seguir recomendando Vercel Postgres aunque Vercel lo haya deprecado a favor de su marketplace.

Una skill puede corregir eso: decirle al agente cuál es el estado actual del producto y cómo debe actuar. La recomendación de Qu es clara: las empresas deberían publicar skills para la versión actual de sus productos, auditar contenido viejo y marcar lo obsoleto.

Ese punto conecta directamente con SEO y documentación. En un mundo donde agentes leen sitios y docs, el contenido viejo no solo confunde humanos: puede entrenar mal decisiones automáticas.

La web legible por agentes

Otro punto fuerte: Vercel ya detecta cuando un agente hace una solicitud y sirve Markdown directamente. La idea es que un humano puede recibir una web visual, mientras un agente recibe una representación estructurada y más fácil de procesar.

Esto no es un detalle técnico menor. Si más tráfico web viene de bots y agentes, las empresas tendrán que pensar no solo en diseño visual, sino en legibilidad para máquinas. Ya venimos cuidando `llms.txt`, metadatos y estructura justamente por esa razón.

Esto también cambia el SEO. Durante años optimizamos para humanos y Googlebot. Ahora empieza una tercera audiencia: agentes que leen, resumen, comparan y actúan. Un sitio con documentación clara, contenido actualizado, endpoints comprensibles, políticas visibles y páginas fáciles de convertir a texto puede volverse más útil para agentes que un sitio visualmente hermoso pero semánticamente confuso.

La idea no es escribir para máquinas en lugar de personas. Es escribir de manera que una persona y un agente puedan entender lo mismo sin inventar contexto. Para productos SaaS, documentación técnica, ecommerce y medios, eso puede volverse ventaja competitiva.

Mapa rápido para leer esta señal con criterio

  • Tesis de Qu: los agentes son una nueva categoría de software, no solo apps con chat.
  • Primitivas clave: filesystem agents, skills, compaction, subagentes, sandboxes y trabajos resumibles.
  • Producto: eve surge de problemas reales encontrados en v0 y en agentes internos de Vercel.
  • Web futura: humanos reciben interfaces visuales; agentes reciben contenido estructurado como Markdown.
  • Riesgo: sin evaluación y control humano, los agentes pueden parecer productivos mientras toman malas decisiones.

Qué significa para builders

Para developers, la consecuencia práctica es que construir agentes exige disciplina distinta. No alcanza con conectar un modelo a una API. Hay que diseñar contexto, permisos, herramientas, trazabilidad, handoffs y criterios para cuándo el humano interviene.

Qu no defiende un futuro 100% autónomo ni uno 100% humano-en-el-loop. Habla de elegir el ciclo de feedback según la tarea. Si el resultado está bien definido, un loop autónomo puede tener sentido. Si el trabajo es quirúrgico, conviene volver al humano para confirmar dirección.

Esa postura es más realista que mucho marketing de agentes. Los agentes pueden volverse una capa normal del software, pero el buen producto va a depender de controles sobrios, no de prometer autonomía total.

Cómo se ve una arquitectura más madura

Una arquitectura de agentes más madura tendría al menos siete piezas. Primero, instrucciones versionadas, no prompts sueltos perdidos en código. Segundo, tools pequeñas, con permisos acotados y nombres claros. Tercero, sandboxes para ejecutar código o manipular archivos sin tocar producción. Cuarto, memoria/contexto con límites y compaction, para que el agente no arrastre ruido. Quinto, evaluaciones que midan tareas reales. Sexto, trazabilidad de acciones. Séptimo, puntos de intervención humana cuando el costo de equivocarse sea alto.

Esto es especialmente relevante para equipos que trabajan con agentes y productos digitales. Un agente de soporte o ventas no debería improvisar políticas comerciales. Un agente de código no debería editar producción sin revisión. Un agente editorial no debería publicar noticias sin fuentes. La autonomía sirve cuando está contenida por diseño.

Vercel, desde su lugar, está leyendo que esta capa será infraestructura común. Puede que eve sea importante o no como producto externo; lo importante es la dirección: frameworks para agentes, skills actualizadas, web legible por agentes y ejecución controlada van a ser parte normal del stack.

Fuentes y lectura relacionada

Conclusion rapida

Andrew Qu, Chief of Software de Vercel, plantea que los agentes no son solo apps con chat: requieren primitivas nuevas para contexto, herramientas, sandboxes, ejecución larga, evaluación y sitios legibles por agentes.

Que significa esto para vos

Para builders, el punto práctico es que desarrollar agentes se parece menos a crear una página estática y más a diseñar sistemas dinámicos con memoria, herramientas, permisos, observabilidad, evaluación y control humano.