Una solicitud, toda una tarea: así funciona Mangrove

El 4 de noviembre le encargamos algo pequeño a uno de nuestros agentes de prueba: el resumen de noticias de IA del día, con cinco noticias y una fuente para cada una.

Dos minutos y veintidós segundos después tenía una respuesta. Había hecho ocho búsquedas web e intentado una novena, que se le denegó. Había probado seis páginas, y tres de esas webs bloquearon el acceso automatizado. Cuando creyó que había terminado, una comprobación lo hizo volver al trabajo. Y al final de la respuesta indicó qué dos noticias se apoyaban solo en los resultados de búsqueda, porque no llegó a leer las páginas que había detrás.

La ejecución completa consumió 1,96 Wh de energía.

Esa ejecución explica muy bien qué es Mangrove, porque casi todo lo importante ocurrió donde no se veía.

Transcripción (traducida)

Un modelo de chat te da una respuesta. Casi ningún trabajo cabe en una sola respuesta: hay que buscar, leer, comparar, comprobar y, a menudo, volver a empezar. Mangrove es el endpoint de orquestación de GreenPT. Envías una solicitud. Averigua qué necesita la tarea, usa las herramientas adecuadas, revisa su propia respuesta y te entrega el resultado. No hay bucle de agente que construir ni herramientas que conectar. Como el mangle, el árbol que le da nombre, hace su trabajo bajo la superficie.

Un modelo de chat te da una sola respuesta

Una chat completion es una pregunta y una respuesta. La mayor parte del trabajo no funciona así: hay que buscar, leer, comparar, comprobar y, muchas veces, volver a empezar.

Puedes construir ese bucle por tu cuenta, y muchos equipos lo hacen. Conectas herramientas, escribes un bucle alrededor del modelo, añades un reintento aquí y un límite allá, y entonces descubres lo que de verdad sale caro: decidir qué pasa cuando una página tiene 1,3 millones de caracteres, cuando el modelo dice que ha terminado y no es cierto, cuando fallan todas las búsquedas y el modelo redacta una disculpa educada que tu sistema registra como un éxito.

Mangrove es el endpoint de orquestación de GreenPT. Envías una solicitud y lleva la tarea de principio a fin: averigua qué necesita, usa las herramientas adecuadas, revisa su propia respuesta y te entrega el resultado.

curl -X POST https://api.greenpt.ai/v1/agents/runs \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{ "question": "Summarise the EU grid carbon intensity news from this week" }'

Recibes un agentId al momento. Después consultas la ejecución cada cierto tiempo o recibes sus pasos en streaming a medida que ocurren. No hay bucle de agente que construir ni herramientas que conectar.

El nombre es literal: mangrove es el mangle, y un mangle hace su trabajo bajo la superficie. Lo que ves es un árbol; lo que lo sostiene todo es una red de raíces que se extiende en todas direcciones. Así entendemos la orquestación. Por encima de la superficie ves una tarea y un resultado.

Una distinción antes de seguir, porque afecta a todo lo que viene después. Mangrove no es un modelo. Es el sistema que ejecuta uno. El modelo que toma las decisiones tiene nombre propio.

Metis decide. Mangrove trabaja.

Transcripción (traducida)

Antes de que empiece una ejecución, hay tres preguntas que importan. ¿Qué dificultad tiene esta tarea? ¿Cuánto trabajo supone? ¿Cuántas fuentes necesita? Un modelo que adivina gasta demasiado o demasiado poco. Por eso Mangrove le pregunta a Metis, nuestro modelo de decisión. Metis no escribe nada. Lee la tarea una vez y devuelve una probabilidad para cada respuesta posible. Las tres preguntas, de una sola pasada. Unos sesenta y cinco milisegundos de tiempo de modelo y menos de cinco milésimas de vatio hora. Metis decide. Mangrove trabaja.

Antes de que empiece una ejecución, hay tres preguntas que importan. ¿Qué dificultad tiene la tarea? ¿Cuánto trabajo supone? ¿Cuántas fuentes necesita?

Si te equivocas, lo pagas en cualquiera de los dos sentidos. Un agente sin sentido de la escala gasta un modelo grande y un presupuesto amplio en una consulta de una línea, o deja sin margen para terminar un trabajo de investigación de verdad.

Por eso Mangrove le pregunta a Metis, nuestro modelo de decisión. Metis no escribe. Le das un caso y una serie de preguntas, lo lee todo una vez y devuelve una probabilidad para cada respuesta posible. Mangrove envía las tres preguntas en una sola solicitud.

Esto es lo que devolvió con una tarea real el 5 de noviembre: “Resume en cinco puntos las noticias de esta semana sobre la intensidad de carbono de la red eléctrica de la UE, con una fuente para cada uno.”

Pregunta	Respuesta de Metis	El resto
¿Qué dificultad tiene?	estándar, 62 %	compleja 27 %, simple 12 %
¿Cuánto trabajo supone?	medio, 72 %	largo 15 %, corto 13 %
¿Cuántas fuentes?	varias, 71 %	muchas 14 %, pocas 9 %, ninguna 6 %

Esa decisión llevó 63 ms de tiempo de modelo y 0,0041 Wh, y no generó ningún token. Las cifras salen del informe de impacto que la API devuelve con la respuesta.

¿Por qué no pedirle sin más a un modelo de chat que clasifique la tarea? Lo probamos. En octubre comparamos ambos para enrutar el chat con 65 turnos etiquetados a mano. La precisión global fue parecida: un 77 % para Metis frente a un 80 % para un modelo general que respondía en JSON. La diferencia estuvo en los errores y en la espera. El modelo general tardó 2,3 segundos de mediana y subestimó el esfuerzo que necesitaba un turno el 20 % de las veces. Metis respondió a tres preguntas en unos 230 ms y subestimó el 2 % de las veces. Un orquestador hace este tipo de pregunta constantemente, y subestimar es el error caro: la tarea se queda sin margen y falla. Las probabilidades también ayudan, porque son un número con el que tu lógica puede actuar, sin nada que parsear.

Ese es el lugar de Metis. Metis juzga. Mangrove actúa según ese juicio. Un modelo de lenguaje razona dentro de la ejecución; Metis fija sus condiciones desde fuera.

Trabajo a medida

Transcripción (traducida)

No todas las tareas merecen el mismo esfuerzo. Pregunta por la capital de Finlandia y Metis lo valora como simple y corto. Pide una tabla con todas las empresas de tres índices bursátiles y lo valora como complejo y largo. Esas valoraciones dan forma a la ejecución. La dificultad elige el modelo, así que un trabajo fácil nunca despierta a uno grande. La longitud fija los límites de llamadas, tokens y tiempo. La profundidad de investigación fija hasta dónde puede buscar. Un resumen de noticias recibe ocho búsquedas, no diecisiete. Y si una valoración no llega, la ejecución conserva los límites con los que empezó. El trabajo justo, y nada más.

Difícil y largo son cosas distintas. Encontrar las webs de 250 empresas es simple en cada caso y largo en total. Un interbloqueo sutil es justo lo contrario. Por eso Mangrove mantiene separados los ejes, y cada uno controla algo distinto.

La dificultad elige el modelo. En un agente guardado, una tarea valorada como simple va a un modelo más pequeño y una compleja a uno más capaz, de modo que un trabajo fácil nunca despierta a un modelo grande. Si fijas un modelo en tu agente, manda tu elección.

La longitud fija los límites. Cada tarea recibe un presupuesto de llamadas al modelo, tokens y segundos acorde a su tamaño.

La profundidad de investigación fija hasta dónde puede buscar. Este eje salió de una medición. Antes de que existiera, un resumen de cinco noticias hacía entre 8 y 17 búsquedas web y hasta 9 lecturas de página, todas con consultas distintas, porque cada búsqueda que encontraba algo invitaba a otra. Una ejecución no sabía cuándo era suficiente.

Profundidad de investigación	Búsquedas web	Lecturas de página
Ninguna	1	1
Pocas	3	3
Varias	8	6
Muchas	sin límite	sin límite

Esa es la novena búsqueda que se le denegó a nuestro resumen. La ejecución conoce su límite desde el principio y, cuando lo alcanza, la herramienta responde que el presupuesto se ha agotado y le pide que redacte lo que tiene. Y las valoraciones de Metis para tareas muy distintas son, de verdad, muy distintas: “¿Cuál es la capital de Finlandia?” salió simple (98 %) y corta (96 %). Una tabla con todas las empresas cotizadas del AEX, el AMX y el AScX salió compleja (71 %) y larga (93 %).

Si una valoración no llega, no se rompe nada. Una ejecución sin valoración conserva los límites con los que empezó. Un clasificador que falla no dice nada sobre la tarea, así que no se le permite recortar nada.

Primero planifica, después actúa

Transcripción (traducida)

Una ejecución no empieza improvisando. Lo seguro va primero. Una grabación se transcribe y una imagen se mira antes de que el modelo llegue a ver tu pregunta. Una tarea de más de un paso recibe un plan escrito, de ocho pasos como máximo, antes de que empiece cualquier trabajo. Ese plan se comprueba con las herramientas que esta ejecución puede usar. Si no se puede llevar a cabo, la tarea sigue sin él. Luego toma el relevo el bucle agéntico: hasta veinte rondas de llamar a herramientas y leer resultados, con una lista de tareas que puedes seguir. Pasos fijos para lo seguro. Criterio para lo que no lo es.

Una ejecución no empieza improvisando.

Lo seguro va primero. Si envías una grabación, se transcribe antes de que el modelo llegue a ver tu pregunta. Si envías una imagen, se mira primero. El modelo nunca tiene que decidir hacer ninguna de las dos cosas, ni repetir un archivo de varios megabytes como argumentos de una herramienta, algo lento y caro en lo que un solo carácter alterado lo corrompería.

Una tarea valorada como algo más que un solo paso puede recibir después un plan escrito de ocho pasos como máximo, generado antes de que empiece cualquier trabajo. Hicimos que fuera una llamada aparte a propósito. Un plan elaborado a mitad del trabajo es una narración de lo que ya está ocurriendo; un plan elaborado al principio es una declaración de intenciones que se puede comprobar. Se valida con las herramientas que esta ejecución puede usar, y cualquier paso cuya entrada dependa de un resultado anterior se deja al criterio del modelo. Si la planificación falla, o si la tarea no se descompone en pasos que valga la pena fijar de antemano, el planificador se retira y la ejecución sigue como lo habría hecho sin él.

Luego toma el relevo el bucle agéntico: hasta veinte rondas de llamar a herramientas, leer resultados y decidir qué hacer a continuación, con una lista de tareas que puedes seguir en el stream.

Pasos fijos para lo seguro. Criterio para lo que no lo es.

Hasta dónde llega

Transcripción (traducida)

Un agente solo es útil en la medida de lo que tiene a su alcance. Mangrove busca en la web y lee las páginas que encuentra. Analiza documentos, mira imágenes y transcribe reuniones. Escribe y ejecuta Python en un sandbox aislado, para cálculos, gráficos y archivos de Word, Excel y PowerPoint. Guarda valores entre ejecuciones, para que la siguiente pueda comparar. Con tu permiso, llega a tu propio trabajo: Outlook, OneDrive, SharePoint y cualquier servidor MCP que conectes. Puede redactar un borrador de respuesta en Outlook. Enviarlo, nunca.

Un agente solo es útil en la medida de lo que tiene a su alcance. De serie, Mangrove puede:

• Buscar en la web y leer páginas, y quedarse solo con los pasajes que importan para lo que busca.
• Analizar documentos, como PDF y archivos de Word, desde un enlace o un archivo subido.
• Mirar imágenes directamente, de modo que los gráficos y la maquetación se ven como imágenes en lugar de extraerse como texto.
• Transcribir reuniones y trabajar después con la transcripción, con sus participantes, decisiones y acciones pendientes.
• Ejecutar Python en un sandbox aislado, para cálculos, análisis de datos y gráficos, y para generar archivos reales de Word, Excel, PowerPoint y PDF.
• Guardar un valor entre ejecuciones con un nombre, para que la ejecución de la semana que viene pueda compararse con la de esta.

Con tu permiso, también llega a tu propio trabajo: búsqueda y lectura en Outlook, tus archivos de OneDrive y SharePoint, y cualquier servidor MCP que conectes. Puede volver a guardar archivos en OneDrive y redactar un borrador de respuesta en Outlook.

Lo que no puede es enviarlo. No hay ninguna herramienta de envío, y el endpoint que hay detrás de la herramienta de borradores tampoco puede enviar. La respuesta llega a tu carpeta de Borradores y te espera allí. Es un límite que pusimos a propósito, y preferimos explicarlo a quitarlo.

No decide por sí solo que ha terminado

Transcripción (traducida)

La mayoría de los agentes deciden por sí mismos cuándo han terminado. Mangrove no deja eso en manos del modelo. Todo plan termina con una comprobación que ningún plan puede quitar. ¿Responde esto del todo a la pregunta? ¿Cerraría algún hueco una herramienta que no hayas usado? Volver al trabajo cuenta. Limitarse a marcar la lista de tareas, no. Y cuando una tarea no se puede hacer, la ejecución lo dice. Termina como no hecha, con el motivo, en lugar de con una disculpa marcada como éxito. Si todas las herramientas a las que ha llamado han fallado, la ejecución termina como no hecha, por muy segura que suene la respuesta. Un final honesto forma parte del trabajo.

Esta parte de Mangrove nace de ver fallar a los agentes.

En un bucle de agente sencillo, el modelo decide cuándo ha terminado: deja de llamar a herramientas, y lo último que ha dicho es la respuesta. Mangrove no deja eso en manos del modelo. Todo plan termina con una comprobación, y ningún plan puede quitarla, porque el runtime la añade después de que se escriba el plan.

La comprobación pregunta si la respuesta cubre del todo la pregunta y si una herramienta que el modelo no ha usado podría cerrar algún hueco. El modelo no se pone la nota a sí mismo. Si vuelve atrás y llama a una herramienta, eso cuenta como trabajo. Si solo marca su lista de tareas, no cuenta, porque cuando lo medimos eso es exactamente lo que hacían algunos modelos: marcaban todos los puntos como completados y paraban.

En la ejecución de nuestro resumen, la comprobación mandó al agente a por dos lecturas de página más. Una estaba bloqueada. La otra chocó con el presupuesto de páginas. La respuesta que escribió después lo contaba.

Luego está el fallo del que a nadie le gusta hablar. Sin una forma de informar de un fallo, la única manera de terminar una ejecución es dar una respuesta. Así, una ejecución que no encontraba nada acababa en succeeded, con una disculpa, y a su propietario se le decía que había funcionado. Lo medimos en un agente real con todas las herramientas disponibles: la mayoría de las ejecuciones en las que fallaron todas las búsquedas escribieron aun así una disculpa con forma de resumen.

Mangrove le da al modelo una salida. Puede terminar una ejecución como no hecha, con un motivo escrito para la persona a la que va dirigida. Y hay una red de seguridad para los modelos que no la aprovechan: si una ejecución llamó a herramientas y todas fallaron, termina como task_not_done, por muy segura que suene la respuesta.

Un final honesto forma parte del trabajo.

Límites que no dependen del buen comportamiento

Transcripción (traducida)

Los límites de un agente no deberían depender de su buen comportamiento. Por eso Mangrove los mantiene en el runtime, no en el prompt. Una herramienta que esta ejecución no puede usar no se le muestra nunca al modelo. Si el modelo la llama de todos modos, la llamada se rechaza. Las llamadas, los tokens y el tiempo se cuentan en toda la ejecución. Y los límites solo se estrechan. Una solicitud puede pedir menos de lo que permite la plataforma, nunca más. Cuando se agota el presupuesto de tokens, el trabajo no se tira. La ejecución escribe una última respuesta y nombra lo que no ha alcanzado. Has pagado por el trabajo, así que te quedas con lo que ha encontrado.

Puedes pedirle con buenas palabras a un modelo que respete los límites. Es una mala manera de dejar algo funcionando sin supervisión, así que Mangrove mantiene sus límites en el runtime.

Una herramienta que una ejecución no puede usar no se le muestra nunca al modelo. Si el modelo la llama de todos modos, la llamada se rechaza igual que la de una herramienta desconocida. Las llamadas al modelo, los tokens y el tiempo se cuentan en toda la ejecución, incluida la comprobación final, así que nada puede dar vueltas gratis. Por defecto, una ejecución recibe 100 llamadas al modelo, 1.000.000 de tokens y 900 segundos, y los límites propios de una tarea pueden ser más bajos: nuestro resumen se ejecutó con 60 llamadas, 600.000 tokens y 600 segundos.

Los límites solo se estrechan. Una solicitud puede pedir menos de lo que permite la plataforma, nunca más.

Algunos detalles de esta parte los aprendimos a base de incidentes reales. Una sola página extraída con scraping, de 1,3 millones de caracteres, convirtió una conversación de 5000 tokens en una solicitud de 347.000 tokens, así que cada resultado de herramienta tiene un tope de 50.000 caracteres, y se avisa al modelo cuando se ha recortado alguno. El presupuesto de tokens tampoco es un umbral fijo: reserva espacio para un paso tan grande como el mayor que la ejecución ya ha pagado, porque el prompt crece con cada resultado.

Lo que ocurre al llegar al límite quizá sea lo más útil para quien construye agentes. Cuando se agota el presupuesto de tokens, la ejecución no muere. Descartarla sería el resultado más caro posible, porque pagarías todas las llamadas y recibirías un mensaje de error. En lugar de eso, deja de trabajar y hace una última llamada sin herramientas disponibles, de modo que no puede empezar nada nuevo, redacta lo que tiene y nombra lo que no ha alcanzado.

Has pagado por el trabajo, así que te quedas con lo que ha encontrado.

Actúa por ti, y solo como tú

Transcripción (traducida)

Una ejecución actúa por ti. Por eso solo puede actuar como tú. Antes de empezar, una ejecución adopta la identidad de su propietario y comprueba que es la correcta. Si esa comprobación falla, la ejecución no empieza. Los valores guardados están ligados a ese propietario. Al correo y a los archivos se llega mediante referencias creadas para esa única ejecución. Las herramientas de tus servidores conectados quedan aisladas, y se le indica a la ejecución que trate lo que devuelven como datos, no como órdenes. Python se ejecuta en su propio sandbox aislado. Outlook puede guardar un borrador, sin ninguna forma de enviarlo. Y cada conexión espera a que la actives tú. Puede hacer mucho. Pero solo como tú.

Una ejecución que puede leer tu correo necesita tener muy claro de quién es el correo que está leyendo.

Antes de empezar, una ejecución adopta la identidad de su propietario y comprueba que la identidad recibida coincide con la del propietario que figura en la ejecución. Si no coincide, la ejecución no empieza. No hay ninguna cuenta de reserva. El almacén de valores guardados no tiene ningún campo que indique de quién son los datos, así que una llamada a una herramienta no puede apuntar a los de otra persona. Al correo y a los archivos se llega mediante referencias creadas para esa única ejecución, de modo que el modelo maneja una referencia, no un buzón.

Los servidores que conectas por MCP se mantienen a distancia. Sus descripciones de herramientas quedan aisladas, y se le indica a la ejecución que lo que devuelven son datos, no órdenes. El worker que ejecuta tu agente nunca ve sus direcciones. Cada conexión, y cada permiso de escritura, como guardar borradores o archivos, espera a que lo actives tú.

No vamos a decir que eso haga imposible engañar a una ejecución. Un agente lee cosas escritas por desconocidos, y ese riesgo no desaparece porque hayas escrito un prompt cuidadoso. Por eso también limitamos lo que podría hacer una ejecución engañada: no puede enviar tu correo, su código se ejecuta de forma aislada y solo puede usar lo que has conectado.

Una ejecución que puede esperar a que la electricidad sea más limpia

Transcripción (traducida)

Hay trabajo que no tiene por qué hacerse ahora mismo. Añade un campo y una ejecución puede empezar hasta veinticuatro horas más tarde. Mangrove lee la previsión de la red eléctrica y busca el inicio más limpio dentro de ese margen. Si esperar ahorrara menos de un cinco por ciento, empieza enseguida. Si no se puede leer ninguna previsión, también empieza enseguida. Una comprobación de carbono nunca retrasa ni hace fallar una ejecución. En cualquier caso, la respuesta te dice qué se ha decidido y cuánto se ahorra. El mismo trabajo, a una hora más limpia.

Esta es la función que más dice de quién la ha construido.

Hay trabajo que no tiene por qué hacerse ahora mismo. Un informe semanal puede esperar unas horas. Añade un campo y una ejecución puede empezar hasta 24 horas más tarde:

{
  "question": "Summarise the EU grid carbon intensity news from this week",
  "greenShiftWindowHours": 8
}

Mangrove lee la previsión de intensidad de carbono de la red en la que funcionan sus modelos y retiene la ejecución hasta el inicio más limpio de ese margen. Se fija bien en cuándo merece la pena. Si esperar ahorrara menos de un 5 %, la ejecución empieza enseguida, porque por debajo de esa cifra el retraso te cuesta más de lo que le ahorra a la red. Si no se puede leer ninguna previsión, también empieza enseguida. Una comprobación de carbono nunca retrasa ni hace fallar una ejecución.

La respuesta te dice qué se ha decidido: held, run_now o unavailable, el inicio previsto, la intensidad de carbono en gCO₂e/kWh con y sin la espera, y el ahorro. En una red que ya es limpia y estable, la mayoría de las ejecuciones simplemente empezarán a su hora. Así funciona la regla, y puedes comprobarlo en la respuesta.

Agentes que conservas

Transcripción (traducida)

Una ejecución es una tarea. Un agente es un trabajo que conservas. Describe el trabajo en el chat. GreenPT pregunta lo poco que necesita saber y redacta el agente: sus instrucciones, su programación y una tarea para probarlo. Consérvalo y tendrá su propia página, con cada ejecución y cada resultado. En una ejecución programada no hay nadie para responder. Por eso la ejecución no recibe ninguna forma de preguntar. Por API, es una llamada para crearlo y una dirección para ejecutarlo. Un trabajo que describes una vez y se hace una y otra vez.

Una ejecución es una tarea. Un agente es un trabajo que conservas.

Describe el trabajo en el chat de GreenPT y te preguntará lo poco que necesita saber: cuándo debe ejecutarse, cómo debe llegarte el resultado y si el trabajo puede esperar a que la electricidad sea más limpia. Después redacta el agente, con sus instrucciones, su programación y una tarea para probarlo. No se guarda nada hasta que lo aceptas. Consérvalo y tendrá su propia página, con cada ejecución y cada resultado.

Una ejecución programada es distinta de una que estás viendo, porque no hay nadie para responder. Por eso no recibe ninguna forma de preguntar. Cumple el encargo con lo que tiene e informa de lo que no ha podido hacer.

Si desarrollas, consigues lo mismo con dos llamadas: una para crear un agente y otra para ejecutarlo en su propia dirección.

POST /v1/agent-profiles
POST /v1/agent-profiles/weekly-report/runs

Cada paso queda registrado

Transcripción (traducida)

No deberías tener que fiarte de la palabra de un agente. Cada ejecución transmite en streaming lo que hace: cada paso, cada llamada a una herramienta y cada resultado. También registra lo que ha decidido sobre sí misma: cómo se valoró la tarea, qué plan siguió y qué presupuesto recibió. Catorce reglas se cumplen en todas las trazas, elija lo que elija el modelo, y las pruebas se encargan de exigirlas. Sus llamadas al modelo informan de su energía y sus emisiones, así que una ejecución se resume en una cifra, en vatios hora. Cada paso, registrado.

No deberías tener que fiarte de la palabra de un agente.

Cada ejecución transmite en streaming lo que hace: cada paso, cada llamada a una herramienta y cada resultado. También registra lo que ha decidido sobre sí misma, como eventos decision: cómo se valoró la tarea y con qué seguridad, qué plan siguió, qué presupuesto recibió y por qué se detuvo. Si un clasificador agotó el tiempo de espera, la traza lo dice, porque “nunca se clasificó” y “se clasificó como general” son hechos distintos.

Catorce reglas se cumplen en todas las trazas, elija lo que elija el modelo: una llamada a una herramienta siempre recibe respuesta, los pasos nunca se solapan, un plan siempre va antes de la ejecución, una ejecución nunca termina dos veces. Las pruebas obligan al runtime a cumplirlas, así que una regresión aparece como una regla incumplida y no puede esconderse en la variación normal de un modelo.

Y una ejecución se resume en una cifra. Las llamadas al modelo de una ejecución informan de su energía y sus emisiones con el mismo informe de impacto que cualquier respuesta de la API de GreenPT, y la ejecución conserva el total. Nuestro resumen consumió 1,96 Wh y 0,14 g CO₂e. En 21 ejecuciones terminadas de una prueba comparativa en nuestro entorno de pruebas, el rango fue de 0,49 Wh a 13,61 Wh, con una mediana de 4,7 Wh. Estos totales cubren las llamadas al modelo del propio bucle de la ejecución. La valoración de Metis y las herramientas que no son modelos, como la búsqueda, no están incluidas.

Por qué creemos que esto es diferente

La mayoría de los frameworks de agentes te dan piezas. Mangrove te da la ejecución completa, con criterio propio:

• Juzga antes de gastar. Un modelo de decisión dimensiona cada tarea en milisegundos, sin escribir una palabra.
• Sabe cuándo es suficiente. Los presupuestos salen de la tarea y se aplican fuera del modelo.
• No puede apuntarse un éxito en silencio. Una ejecución que ha fallado dice que ha fallado, con un motivo.
• Conserva lo que has pagado. Quedarse sin presupuesto termina en una respuesta que nombra sus huecos.
• Sabe lo que ha consumido. La energía y las emisiones llegan con la ejecución, en Wh y gramos.
• Puede esperar. Una ejecución puede aguardar a una hora más limpia y decirte cuánto ha ahorrado.

Lo que Mangrove no hace

Una ejecución es un solo intercambio. Empieza de cero, no se puede reanudar y una pregunta de seguimiento es una ejecución nueva, así que cita la parte de la última respuesta sobre la que quieras seguir.

El coste de una ejecución no se conoce al empezar, porque Mangrove decide cuántos pasos necesita una tarea. Dos ejecuciones de la misma pregunta pueden costar cantidades distintas.

Una tarea que necesita más de veinte rondas vuelve con menos sustancia en lugar de fallar. Ayuda dividirla en preguntas más concretas.

En qué punto está

Mangrove está en beta privada en los planes Pro, Pro Max, Teams y Enterprise, y las ejecuciones se pagan con tus créditos de API. Durante la beta, no todas las funciones de este artículo están activadas en todas las cuentas. La ejecución del resumen del principio de este artículo se hizo en nuestro entorno de pruebas, con todas activadas.

Si quieres probarlo, la documentación de Mangrove incluye una guía de inicio rápido y ejemplos completos, y puedes pedir acceso en nuestro Discord.

Cuéntanos qué le encargarías primero.