La infraestructura agente y el nuevo backend.

spinny:~/writing $ less agentic-infrastructure-stack.md

1 
2A menudo hemos hablado de marcos agentes. LangGraph, CrewAI, AutoGen, varios SDK, bucle, llamada de herramientas, memoria, planificador, crítico, supervisor. Todas palabras útiles, por el amor de Dios. Pero cuanto más miro los agentes realmente utilizados, más me parece que la parte interesante se ha movido por debajo del nivel del marco.
3 
4La pregunta ya no es sólo: ¿qué biblioteca uso para hacer pensar un modelo de pasos?
5 
6La verdadera pregunta es: ¿dónde vivirá este agente cuando deje de ser demo?
7 
8Porque un agente serio no es una función que llama a un modelo y devuelve texto. Es un pequeño sistema distribuido. Debe leer el contexto, usar herramientas, ejecutar código, tocar archivos, recordar decisiones, pedir permiso, fallar bien, reiniciar, dejar registros, no quemar el presupuesto y no convertirse en una excavadora dentro del repositorio de producción.
9 
10El marco es el volante. La infraestructura es la carretera, los frenos, el garaje, el seguro y la persona que sabe dónde están las llaves.
11 
12## Porque ahora se habla mucho de ello.
13 
14En 2023 y 2024 la conversación estuvo muy centrada en los modelos. ¿Qué LLM? ¿Cuánto contexto? ¿Cuánto cuesta? ¿Qué tan bueno es en programación?
15 
16En 2025 y 2026 la conversación ha cambiado. Los modelos son lo suficientemente buenos para hacer un trabajo real, pero es por eso que las partes aburridas se vuelven visibles: tiempo de ejecución, seguridad, conectores, identidad, observabilidad, ejecución de código, implementación, reversión.
17 
18Es la transición natural de la magia a la ingeniería.
19 
20Cuando un agente sólo necesita generar una respuesta, un chat es suficiente. Cuando necesita abrir una solicitud de extracción, consultar una base de datos, llamar a un CRM, iniciar un trabajo, navegar por un sitio, leer Slack, compilar código y actualizar un documento, necesita un sistema operativo a su alrededor.
21 
22No en un sentido literal. En un sentido organizativo.
23 
24## La primera pieza: un tiempo de ejecución donde el agente puede durar
25 
26Un agente suele trabajar por pasos. Mira el estado, elige una acción, usa una herramienta, observa el resultado, actualiza el plan, repite.
27 
28Si este bucle se encuentra dentro de una única solicitud HTTP, inmediatamente tienes un problema. Algunas acciones son lentas. Algunos esperan la aportación humana. Algunas fracasan y deben intentarse nuevamente. Algunos deben sobrevivir a un despliegue o a un tiempo de espera.
29 
30Aquí es donde entran en juego flujos de trabajo duraderos, colas, antecedentes laborales y máquinas de estado. No son glamorosos, pero marcan la diferencia entre un agente que parece inteligente en la demostración y uno al que puedes dejar trabajando mientras vas a tomar un café.
31 
32Para mí, el tiempo de ejecución agente debe responder preguntas muy concretas:
33 
34- ¿Dónde guardo el estado entre un paso y otro?
35- ¿Qué pasa si el proceso muere a la mitad?
36- can I pause and ask for approval?
37- ¿Puedo repetir una carrera para entender por qué tomó esa decisión?
38- ¿Puedo limitar la duración, la memoria, las herramientas y el costo?
39 
40Vercel está presionando mucho en este frente con SDK, funciones, flujos de trabajo y herramientas de IA para crear agentes dentro de aplicaciones web. Pero la cuestión no es sólo Vercel. La cuestión es que el agente necesita un hogar operativo, no un único punto final.
41 
42## La segunda pieza: sandbox, porque el agente debe poder ensuciarse sin romperse
43 
44Tan pronto como un agente escribe código o ejecuta comandos, se necesita un entorno limitado.
45 
46Parece una palabra técnica, pero la idea es doméstica: le das un banco de trabajo. Puede abrir archivos, instalar dependencias, ejecutar pruebas, realizar experimentos y generar resultados. Si se equivoca, habrás contenido el daño. Si funciona, promociona el resultado.
47 
48Un sandbox agente debería tener algunas propiedades:
49 
50- sistema de archivos aislado;
51- CPU, memoria y límites de tiempo;
52- red controlada;
53- secretos montados sólo cuando sea necesario;
54- registros completos;
55- posibilidad de exportar artefactos;
56- reinicio limpio entre ejecuciones, cuando sea necesario.
57 
58Vercel Sandbox va exactamente en esta dirección: entornos aislados para ejecutar código, instalar dependencias, trabajar con archivos y producir artefactos sin ejecutar todo en el tiempo de ejecución de la aplicación principal.
59 
60Esto es más importante de lo que parece. Muchos prototipos agentes saltan directamente del modelo al sistema real. El modelo puede llamar a la herramienta. Las herramientas pueden hacer cosas. Todo parece elegante hasta el primer comando incorrecto, la primera dependencia instalada en el lugar equivocado, el primer token que termina en un registro.
61 
62El arenero es la forma adulta de decir: adelante, pero aquí dentro.
63 
64## La tercera pieza: MCP y el problema del conector
65 
66El Protocolo de Contexto Modelo se ha convertido en una de las partes más interesantes del ecosistema porque intenta estandarizar algo que de otro modo rápidamente se vuelve inmanejable: cómo un modelo descubre y utiliza herramientas externas.
67 
68Sin un estándar, cada integración es una pequeña isla. Un conector para GitHub hecho de una manera, uno para Slack hecho de otra, uno para bases de datos con semántica diferente, uno para la automatización del navegador que parece nada.
69 
70MCP propone un lenguaje común entre cliente y servidor: herramientas, recursos, avisos, autorizaciones, transporte, descubrimiento. No resuelve mágicamente la gobernanza y la seguridad, pero proporciona una gramática.
71 
72Y la gramática importa. Cuando un agente puede conectarse a muchas herramientas, la pregunta no es simplemente "¿puede hacerlo?". El problema es "¿entiende qué puede hacer, con qué límites, en nombre de quién y dejando qué huella?".
73 
74Para mí, MCP no es una exageración porque "hace llamadas a herramientas". Eso ya lo hicimos. Es una exageración porque cambia el centro de gravedad de la integración única al catálogo operativo de herramientas.
75 
76En una buena arquitectura agentic, MCP se convierte en una especie de panel de conexiones:
77 
78- GitHub para código y problemas;
79- Slack para contexto conversacional;
80- Linear o Jira para trabajos planificados;
81- base de datos de sólo lectura para análisis;
82- navegador o raspador controlado para sitios externos;
83- almacenamiento de documentos;
84- entornos de ejecución aislados;
85- sistemas internos expuestos con permisos estrictos.
86 
87La parte complicada es que un catálogo de herramientas sin políticas es simplemente una forma más elegante de crear caos.
88 
89## La cuarta pieza: identidad y permisos
90 
91Esta es el área donde muchas demostraciones hacen la vista gorda.
92 
93Un agente actúa en nombre de alguien. Por eso debe quedar claro quién es el sujeto de la acción.
94 
95¿Está utilizando permisos de usuario? ¿De una cuenta de servicio? ¿De un espacio de trabajo? ¿Tiene acceso temporal o permanente? ¿Puedes leer todo o solo algunos recursos? ¿Puedes escribir? ¿Puedes cancelar? ¿Puede enviar mensajes de texto a personas reales?
96 
97Si no respondes bien a estas preguntas, tarde o temprano te construirás un asistente con las llaves de la casa y sin recordar quién se las dio.
98 
99La regla general que me gusta es la siguiente: el agente debe poder hacer menos que el humano, no más que el humano. Y cuando tiene que hacer algo más arriesgado, tiene que pararse y preguntar.
100 
101Esto significa OAuth, ámbito de token, gestión de secretos, registro de auditoría, política de herramientas, lista de permitidos y paso de aprobación. Cosas no muy románticas. Cosas necesarias.
102 
103## La quinta pieza: memoria y contexto, pero sin acumular basura
104 
105Los agentes necesitan memoria, pero la memoria es peligrosa cuando se convierte en un ático.
106 
107Existen al menos tres tipos de memoria:
108 
109- memoria de ejecución: qué pasó en esta ejecución;
110- memoria del proyecto: convenciones, decisiones, limitaciones;
111- memoria personal o de equipo: preferencias, tono, rituales, procesos.
112 
113Poner todo en el mensaje es el atajo. Funciona hasta que ya no funciona. Hay que cuidar la memoria útil: indexarla, actualizarla, caducarla, verificarla, hacerla citable.
114 
115Un agente que recuerda mal es peor que un agente que no recuerda. Porque habla con confianza.
116 
117Por lo tanto, la infraestructura debe incluir recuperación, archivos de instrucciones, base de conocimientos, incrustación cuando sea necesario, pero también limpieza. Necesitamos una cultura de la memoria: qué entra, quién lo aprueba, cuándo decae, cómo lo corrijo.
118 
119## La sexta pieza: observabilidad, evaluación y repetición.
120 
121Si un agente comete un error, el registro "llamado modelo" no es suficiente.
122 
123Quieres ver la ruta. ¿Qué contexto recibió? ¿Qué herramientas estaban disponibles? ¿Qué herramienta elegiste? ¿Con qué argumentos? ¿Qué respuesta obtuviste? ¿Cuánto costó? ¿Dónde se quedó atascado? ¿El humano aprobó algo? ¿Es el modelo de error, la herramienta, el mensaje, los datos o el error de permiso?
124 
125Aquí los agentes se parecen más a sistemas distribuidos que a chatbots.
126 
127Necesita rastros legibles, no sólo registros de texto. Necesitas poder repetir una carrera. Es necesario comparar dos versiones del mismo agente en tareas conocidas. Necesitamos medir las regresiones: no sólo "responde mejor", sino que "cierra el ticket correcto sin tocar archivos no solicitados".
128 
129Las evaluaciones agentes son más difíciles que las evaluaciones de texto porque incluyen acciones. No basta con comparar una cadena esperada. Hay que tener en cuenta las secuencias, los efectos secundarios, la calidad del artefacto, el tiempo, el coste y el número de intervenciones humanas.
130 
131Lo curioso es que siempre volvemos a eso: la ingeniería de software. Pruebas, entornos, rastreos, rollbacks. Excepto que el código ahora también decide qué hacer a continuación.
132 
133## La séptima pieza: interfaces humanas
134 
135El agente no tiene por qué vivir simplemente en un chat.
136 
137Algunos agentes necesitan una junta. Otros una página con estado y registro. Otros de un botón de “aprobar”. Más comentarios en línea. Otros más de una CLI.
138 
139La interfaz de usuario cambia de comportamiento. Si la única forma de controlar a un agente es escribir un mensaje largo, el usuario le dará instrucciones vagas al agente. Sin embargo, si ve el plan, las diferencias, las fuentes, los riesgos y las próximas acciones, podrá intervenir con precisión.
140 
141Una infraestructura de agente decente incluye superficies de control:
142 
143- estado actual;
144- plano editable;
145- artefactos producidos;
146- diferencia;
147- solicitudes de aprobación;
148- cronología;
149- botón de parada;
150- botón de reintento;
151- permisos visibles.
152 
153Parece trivial, pero no lo es. La diferencia entre una "IA espeluznante" y un "asistente confiable" suele ser que este último te muestra dónde tiene sus manos.
154 
155## La pila mental
156 
157Si lo sacara hoy, la pila mínima de agentes sería la siguiente:
158 
1591. Modelo: razonamiento, generación, llamada de herramientas, multimodal si es necesario.
1602. Orquestación: bucle, paso, planificador, política, ser humano en el circuito.
1613. Tiempo de ejecución duradero: flujo de trabajo, cola, reintento, pausa, reanudación.
1624. Sandbox: ejecución de código, sistema de archivos aislado, limitaciones, artefactos.
1635. Capa de herramientas: MCP, API interna, navegador, base de datos, repositorio.
1646. Capa de identidad: OAuth, alcance, secreto, auditoría, política.
1657. Capa de memoria: contexto del proyecto, recuperación, instrucciones, caducidad.
1668. Observabilidad: métricas de seguimiento, reproducción, evaluación, costes y calidad.
1679. Superficie del producto: chatee cuando sea suficiente, panel cuando sea necesario, revise cuando sea importante.
168 
169El marco agente cubre principalmente el punto 2 y una parte del punto 1. El resto es el trabajo real.
170 
171## Lo que haría en la práctica
172 
173Si un equipo me dijera "queremos agentes en producción", no comenzaría con diez agentes.
174 
175Comenzaría con un flujo de trabajo pequeño, repetitivo y observable. Por ejemplo: abrir relaciones públicas de mantenimiento, actualizar la documentación de problemas cerrados, preparar una revisión semanal, clasificar errores duplicados, generar pruebas para los archivos afectados.
176 
177Entonces yo pondría límites muy claros:
178 
179- no se puede escribir sin ramas o sandbox;
180- no hay secretos en el mensaje;
181- herramientas en la lista de permitidos;
182- aprobación humana de acciones externas;
183- registro y seguimiento obligatorios;
184- presupuesto por ejecución;
185- salida siempre inspeccionable.
186 
187Sólo entonces me expandiría.
188 
189Los agentes no fracasan sólo porque los modelos se equivocan. Fracasan porque los ponemos en ambientes vagos, con permisos confusos y expectativas teatrales.
190 
191## Mi lectura
192 
193La infraestructura agente es aburrida en el mejor de los sentidos.
194 
195No es la parte que te hace aplaudir en la demostración. Es la parte que te permite usar la demostración el lunes por la mañana, con personas reales, datos reales y consecuencias reales.
196 
197El futuro de los agentes no lo decidirá únicamente quién tenga el mejor modelo a seguir. Lo decidirá quien construya el mejor lugar para hacerlo trabajar: aislado cuando experimente, conectado cuando sea necesario, siempre observable, autorizado con criterio y humilde para detenerse cuando no sabe.
198 
199Ahí es donde los agentes dejan de ser un juguete y se convierten en infraestructura.
200 
201## Fuentes
202 
203- [Vercel: Cómo crear agentes de IA con Vercel y el SDK de IA](https://vercel.com/kb/guide/how-to-build-ai-agents-with-vercel-and-the-ai-sdk)
204- [Documentos de Vercel: Sandbox] (https://vercel.com/docs/sandbox)
205- [Vercel Docs: Trabajar con Sandbox](https://vercel.com/docs/sandbox/working-with-sandbox)
206- [Documentos de Vercel: MCP](https://vercel.com/docs/mcp)
207- [Model Context Protocol: Specification](https://modelcontextprotocol.io/specification)
208- [OpenAI: Nuevas herramientas para agentes de construcción](https://openai.com/index/new-tools-for-building-agents/)
209- [Blog de Cloudflare: Agentes en Cloudflare](https://blog.cloudflare.com/agents-on-cloudflare/)
210

:La infraestructura agente y el nuevo backend.lines 1-210 (END) — press q to close

2A menudo hemos hablado de marcos agentes. LangGraph, CrewAI, AutoGen, varios SDK, bucle, llamada de herramientas, memoria, planificador, crítico, supervisor. Todas palabras útiles, por el amor de Dios. Pero cuanto más miro los agentes realmente utilizados, más me parece que la parte interesante se ha movido por debajo del nivel del marco.

4La pregunta ya no es sólo: ¿qué biblioteca uso para hacer pensar un modelo de pasos?

6La verdadera pregunta es: ¿dónde vivirá este agente cuando deje de ser demo?

8Porque un agente serio no es una función que llama a un modelo y devuelve texto. Es un pequeño sistema distribuido. Debe leer el contexto, usar herramientas, ejecutar código, tocar archivos, recordar decisiones, pedir permiso, fallar bien, reiniciar, dejar registros, no quemar el presupuesto y no convertirse en una excavadora dentro del repositorio de producción.

10El marco es el volante. La infraestructura es la carretera, los frenos, el garaje, el seguro y la persona que sabe dónde están las llaves.

12## Porque ahora se habla mucho de ello.

14En 2023 y 2024 la conversación estuvo muy centrada en los modelos. ¿Qué LLM? ¿Cuánto contexto? ¿Cuánto cuesta? ¿Qué tan bueno es en programación?

16En 2025 y 2026 la conversación ha cambiado. Los modelos son lo suficientemente buenos para hacer un trabajo real, pero es por eso que las partes aburridas se vuelven visibles: tiempo de ejecución, seguridad, conectores, identidad, observabilidad, ejecución de código, implementación, reversión.

18Es la transición natural de la magia a la ingeniería.

20Cuando un agente sólo necesita generar una respuesta, un chat es suficiente. Cuando necesita abrir una solicitud de extracción, consultar una base de datos, llamar a un CRM, iniciar un trabajo, navegar por un sitio, leer Slack, compilar código y actualizar un documento, necesita un sistema operativo a su alrededor.

22No en un sentido literal. En un sentido organizativo.

24## La primera pieza: un tiempo de ejecución donde el agente puede durar

26Un agente suele trabajar por pasos. Mira el estado, elige una acción, usa una herramienta, observa el resultado, actualiza el plan, repite.

28Si este bucle se encuentra dentro de una única solicitud HTTP, inmediatamente tienes un problema. Algunas acciones son lentas. Algunos esperan la aportación humana. Algunas fracasan y deben intentarse nuevamente. Algunos deben sobrevivir a un despliegue o a un tiempo de espera.

30Aquí es donde entran en juego flujos de trabajo duraderos, colas, antecedentes laborales y máquinas de estado. No son glamorosos, pero marcan la diferencia entre un agente que parece inteligente en la demostración y uno al que puedes dejar trabajando mientras vas a tomar un café.

32Para mí, el tiempo de ejecución agente debe responder preguntas muy concretas:

34- ¿Dónde guardo el estado entre un paso y otro?

35- ¿Qué pasa si el proceso muere a la mitad?

36- can I pause and ask for approval?

37- ¿Puedo repetir una carrera para entender por qué tomó esa decisión?

38- ¿Puedo limitar la duración, la memoria, las herramientas y el costo?

40Vercel está presionando mucho en este frente con SDK, funciones, flujos de trabajo y herramientas de IA para crear agentes dentro de aplicaciones web. Pero la cuestión no es sólo Vercel. La cuestión es que el agente necesita un hogar operativo, no un único punto final.

42## La segunda pieza: sandbox, porque el agente debe poder ensuciarse sin romperse

44Tan pronto como un agente escribe código o ejecuta comandos, se necesita un entorno limitado.

46Parece una palabra técnica, pero la idea es doméstica: le das un banco de trabajo. Puede abrir archivos, instalar dependencias, ejecutar pruebas, realizar experimentos y generar resultados. Si se equivoca, habrás contenido el daño. Si funciona, promociona el resultado.

48Un sandbox agente debería tener algunas propiedades:

50- sistema de archivos aislado;

51- CPU, memoria y límites de tiempo;

52- red controlada;

53- secretos montados sólo cuando sea necesario;

54- registros completos;

55- posibilidad de exportar artefactos;

56- reinicio limpio entre ejecuciones, cuando sea necesario.

58Vercel Sandbox va exactamente en esta dirección: entornos aislados para ejecutar código, instalar dependencias, trabajar con archivos y producir artefactos sin ejecutar todo en el tiempo de ejecución de la aplicación principal.

60Esto es más importante de lo que parece. Muchos prototipos agentes saltan directamente del modelo al sistema real. El modelo puede llamar a la herramienta. Las herramientas pueden hacer cosas. Todo parece elegante hasta el primer comando incorrecto, la primera dependencia instalada en el lugar equivocado, el primer token que termina en un registro.

62El arenero es la forma adulta de decir: adelante, pero aquí dentro.

64## La tercera pieza: MCP y el problema del conector

66El Protocolo de Contexto Modelo se ha convertido en una de las partes más interesantes del ecosistema porque intenta estandarizar algo que de otro modo rápidamente se vuelve inmanejable: cómo un modelo descubre y utiliza herramientas externas.

68Sin un estándar, cada integración es una pequeña isla. Un conector para GitHub hecho de una manera, uno para Slack hecho de otra, uno para bases de datos con semántica diferente, uno para la automatización del navegador que parece nada.

70MCP propone un lenguaje común entre cliente y servidor: herramientas, recursos, avisos, autorizaciones, transporte, descubrimiento. No resuelve mágicamente la gobernanza y la seguridad, pero proporciona una gramática.

72Y la gramática importa. Cuando un agente puede conectarse a muchas herramientas, la pregunta no es simplemente "¿puede hacerlo?". El problema es "¿entiende qué puede hacer, con qué límites, en nombre de quién y dejando qué huella?".

74Para mí, MCP no es una exageración porque "hace llamadas a herramientas". Eso ya lo hicimos. Es una exageración porque cambia el centro de gravedad de la integración única al catálogo operativo de herramientas.

76En una buena arquitectura agentic, MCP se convierte en una especie de panel de conexiones:

78- GitHub para código y problemas;

79- Slack para contexto conversacional;

80- Linear o Jira para trabajos planificados;

81- base de datos de sólo lectura para análisis;

82- navegador o raspador controlado para sitios externos;

83- almacenamiento de documentos;

84- entornos de ejecución aislados;

85- sistemas internos expuestos con permisos estrictos.

87La parte complicada es que un catálogo de herramientas sin políticas es simplemente una forma más elegante de crear caos.

89## La cuarta pieza: identidad y permisos

91Esta es el área donde muchas demostraciones hacen la vista gorda.

93Un agente actúa en nombre de alguien. Por eso debe quedar claro quién es el sujeto de la acción.

95¿Está utilizando permisos de usuario? ¿De una cuenta de servicio? ¿De un espacio de trabajo? ¿Tiene acceso temporal o permanente? ¿Puedes leer todo o solo algunos recursos? ¿Puedes escribir? ¿Puedes cancelar? ¿Puede enviar mensajes de texto a personas reales?

97Si no respondes bien a estas preguntas, tarde o temprano te construirás un asistente con las llaves de la casa y sin recordar quién se las dio.

99La regla general que me gusta es la siguiente: el agente debe poder hacer menos que el humano, no más que el humano. Y cuando tiene que hacer algo más arriesgado, tiene que pararse y preguntar.

100

101Esto significa OAuth, ámbito de token, gestión de secretos, registro de auditoría, política de herramientas, lista de permitidos y paso de aprobación. Cosas no muy románticas. Cosas necesarias.

102

103## La quinta pieza: memoria y contexto, pero sin acumular basura

104

105Los agentes necesitan memoria, pero la memoria es peligrosa cuando se convierte en un ático.

106

107Existen al menos tres tipos de memoria:

108

109- memoria de ejecución: qué pasó en esta ejecución;

110- memoria del proyecto: convenciones, decisiones, limitaciones;

111- memoria personal o de equipo: preferencias, tono, rituales, procesos.

112

113Poner todo en el mensaje es el atajo. Funciona hasta que ya no funciona. Hay que cuidar la memoria útil: indexarla, actualizarla, caducarla, verificarla, hacerla citable.

114

115Un agente que recuerda mal es peor que un agente que no recuerda. Porque habla con confianza.

116

117Por lo tanto, la infraestructura debe incluir recuperación, archivos de instrucciones, base de conocimientos, incrustación cuando sea necesario, pero también limpieza. Necesitamos una cultura de la memoria: qué entra, quién lo aprueba, cuándo decae, cómo lo corrijo.

118

119## La sexta pieza: observabilidad, evaluación y repetición.

120

121Si un agente comete un error, el registro "llamado modelo" no es suficiente.

122

123Quieres ver la ruta. ¿Qué contexto recibió? ¿Qué herramientas estaban disponibles? ¿Qué herramienta elegiste? ¿Con qué argumentos? ¿Qué respuesta obtuviste? ¿Cuánto costó? ¿Dónde se quedó atascado? ¿El humano aprobó algo? ¿Es el modelo de error, la herramienta, el mensaje, los datos o el error de permiso?

124

125Aquí los agentes se parecen más a sistemas distribuidos que a chatbots.

126

127Necesita rastros legibles, no sólo registros de texto. Necesitas poder repetir una carrera. Es necesario comparar dos versiones del mismo agente en tareas conocidas. Necesitamos medir las regresiones: no sólo "responde mejor", sino que "cierra el ticket correcto sin tocar archivos no solicitados".

128

129Las evaluaciones agentes son más difíciles que las evaluaciones de texto porque incluyen acciones. No basta con comparar una cadena esperada. Hay que tener en cuenta las secuencias, los efectos secundarios, la calidad del artefacto, el tiempo, el coste y el número de intervenciones humanas.

130

131Lo curioso es que siempre volvemos a eso: la ingeniería de software. Pruebas, entornos, rastreos, rollbacks. Excepto que el código ahora también decide qué hacer a continuación.

132

133## La séptima pieza: interfaces humanas

134

135El agente no tiene por qué vivir simplemente en un chat.

136

137Algunos agentes necesitan una junta. Otros una página con estado y registro. Otros de un botón de “aprobar”. Más comentarios en línea. Otros más de una CLI.

138

139La interfaz de usuario cambia de comportamiento. Si la única forma de controlar a un agente es escribir un mensaje largo, el usuario le dará instrucciones vagas al agente. Sin embargo, si ve el plan, las diferencias, las fuentes, los riesgos y las próximas acciones, podrá intervenir con precisión.

140

141Una infraestructura de agente decente incluye superficies de control:

142

143- estado actual;

144- plano editable;

145- artefactos producidos;

146- diferencia;

147- solicitudes de aprobación;

148- cronología;

149- botón de parada;

150- botón de reintento;

151- permisos visibles.

152

153Parece trivial, pero no lo es. La diferencia entre una "IA espeluznante" y un "asistente confiable" suele ser que este último te muestra dónde tiene sus manos.

154

155## La pila mental

156

157Si lo sacara hoy, la pila mínima de agentes sería la siguiente:

158

1591. Modelo: razonamiento, generación, llamada de herramientas, multimodal si es necesario.

1602. Orquestación: bucle, paso, planificador, política, ser humano en el circuito.

1613. Tiempo de ejecución duradero: flujo de trabajo, cola, reintento, pausa, reanudación.

1624. Sandbox: ejecución de código, sistema de archivos aislado, limitaciones, artefactos.

1635. Capa de herramientas: MCP, API interna, navegador, base de datos, repositorio.

1646. Capa de identidad: OAuth, alcance, secreto, auditoría, política.

1657. Capa de memoria: contexto del proyecto, recuperación, instrucciones, caducidad.

1668. Observabilidad: métricas de seguimiento, reproducción, evaluación, costes y calidad.

1679. Superficie del producto: chatee cuando sea suficiente, panel cuando sea necesario, revise cuando sea importante.

168

169El marco agente cubre principalmente el punto 2 y una parte del punto 1. El resto es el trabajo real.

170

171## Lo que haría en la práctica

172

173Si un equipo me dijera "queremos agentes en producción", no comenzaría con diez agentes.

174

175Comenzaría con un flujo de trabajo pequeño, repetitivo y observable. Por ejemplo: abrir relaciones públicas de mantenimiento, actualizar la documentación de problemas cerrados, preparar una revisión semanal, clasificar errores duplicados, generar pruebas para los archivos afectados.

176

177Entonces yo pondría límites muy claros:

178

179- no se puede escribir sin ramas o sandbox;

180- no hay secretos en el mensaje;

181- herramientas en la lista de permitidos;

182- aprobación humana de acciones externas;

183- registro y seguimiento obligatorios;

184- presupuesto por ejecución;

185- salida siempre inspeccionable.

186

187Sólo entonces me expandiría.

188

189Los agentes no fracasan sólo porque los modelos se equivocan. Fracasan porque los ponemos en ambientes vagos, con permisos confusos y expectativas teatrales.

190

191## Mi lectura

192

193La infraestructura agente es aburrida en el mejor de los sentidos.

194

195No es la parte que te hace aplaudir en la demostración. Es la parte que te permite usar la demostración el lunes por la mañana, con personas reales, datos reales y consecuencias reales.

196

197El futuro de los agentes no lo decidirá únicamente quién tenga el mejor modelo a seguir. Lo decidirá quien construya el mejor lugar para hacerlo trabajar: aislado cuando experimente, conectado cuando sea necesario, siempre observable, autorizado con criterio y humilde para detenerse cuando no sabe.

198

199Ahí es donde los agentes dejan de ser un juguete y se convierten en infraestructura.

200

201## Fuentes

202

203- [Vercel: Cómo crear agentes de IA con Vercel y el SDK de IA](https://vercel.com/kb/guide/how-to-build-ai-agents-with-vercel-and-the-ai-sdk)

204- [Documentos de Vercel: Sandbox] (https://vercel.com/docs/sandbox)

205- [Vercel Docs: Trabajar con Sandbox](https://vercel.com/docs/sandbox/working-with-sandbox)

206- [Documentos de Vercel: MCP](https://vercel.com/docs/mcp)

207- [Model Context Protocol: Specification](https://modelcontextprotocol.io/specification)

208- [OpenAI: Nuevas herramientas para agentes de construcción](https://openai.com/index/new-tools-for-building-agents/)

209- [Blog de Cloudflare: Agentes en Cloudflare](https://blog.cloudflare.com/agents-on-cloudflare/)

210