Cómo funciona

Herramientas y MCP

Cómo un agente pasa de responder a actuar: el ciclo de herramientas, los presupuestos de contexto y la conexión de tus propios sistemas a través de MCP.

Un agente que solo responde deja el trabajo en tus manos. Esta página cubre cómo la plataforma permite actuar: qué sucede dentro de un turno cuando se llama a una herramienta, qué evita que eso destruya la conversación y cómo se conectan tus propios sistemas.

El bucle de herramientas

Turn budget remaining82%
Look up the customer's orders18% of budget
Fetch the invoice12% of budget
Fetch the full order history78% of budget
Reply to the customer
iteration 1 / 4

Illustrative. Proportions are sketched to show accumulation. The per-result cap and the turn budget are tenant-configured, not fixed values.

Un turno no es una única llamada al modelo. El modelo puede responder, o puede pedir llamar a una herramienta; si llama a una, el resultado se anexa a la conversación y el modelo se ejecuta de nuevo con ese resultado en mano. Puede entonces llamar a otra. El bucle continúa hasta que el modelo produce una respuesta, o hasta que se alcanza un límite de iteraciones.

El límite importa: sin él, un modelo que sigue llamando a herramientas —un fallo genuinamente común— se ejecutaría indefinidamente, gastando tokens y dejando al cliente esperando una respuesta que nunca llega.

Lo que el bucle no hace es escribir la respuesta al cliente con todo lo que acumuló a lo largo del camino. Una vez que las herramientas han terminado, la solicitud se reconstruye limpia —las instrucciones del agente, un breve resumen, los hechos encontrados en este turno y la pregunta— y la respuesta se genera a partir de eso. La razón es medida, y es el tema de Why agents get worse as context grows.

Decidir qué herramienta antes de que el modelo se ejecute

El bucle anterior asume que el modelo pide la herramienta correcta. A menudo no lo hace —y la razón vale la pena precisarla, porque no es un problema de conocimiento.

Las personas no formulan las solicitudes de la manera en que el software quiere que se formulen. "¿Algo más como eso?" no nombra ninguna herramienta, ningún sujeto ni ninguna cantidad; eso fue hace dos mensajes. Un modelo al que se le entrega eso tiene que resolver a qué se refiere "como eso", decidir si hay una herramienta involucrada, averiguar cuál, rellenar sus argumentos, y escribir una buena respuesta —cinco trabajos en una muestra. El que se omite suele ser la llamada a la herramienta, y el cliente recibe un párrafo de prosa donde debería haber una lista de productos.

Esto cubre más de un tipo de solicitud. "¿Algo más como eso?" quiere que se muestren artículos; "muéstrame la distribución de libros por nivel de lectura" quiere que se cuente y dibuje el catálogo. Dejado a sí mismo en el segundo caso, un modelo narrará el trabajo en lugar de hacerlo —vimos a uno decir "déjame consultar la base de datos" seis veces y luego imprimir la declaración SQL en la respuesta, lo cual es la entrada de una herramienta y nunca algo que un lector debería ver.

Así que para las solicitudes donde una herramienta está claramente implícita, la plataforma da un paso primero. Una pequeña y barata llamada lee la conversación y devuelve solo hechos —lo que se está pidiendo, y cuántos. Ve la conversación y nada más: no las instrucciones del agente, no el material recuperado, por lo que no puede desviarse hacia responder. Entonces:

  • la plataforma escribe la instrucción, en la redacción que la herramienta responde realmente, con el contexto faltante rellenado de nuevo;
  • esa vuelta se muestra solo la una herramienta, para que no haya nada entre lo que elegir.

La primera de esas es la que importa, y es fácil equivocarse. Dejar que el modelo reescriba su propia solicitud no cambió nada que pudiéramos medir —la misma adivinanza en diferentes palabras. Que la plataforma componga esa oración, a partir de la propia definición de la herramienta, llevó a un modelo de 35B autoalojado del 16% al 70% en las mismas solicitudes. La redacción que llega a una herramienta es algo que el software puede calcular, por lo que el software lo calcula —el mismo razonamiento que mantiene los datos de los gráficos y los contenidos de las tarjetas en el servidor en lugar de en las manos del modelo.

Hay una tercera cosa que la plataforma deliberadamente no hace: forzar la llamada a nivel de protocolo. La opción existe, y sí eleva el número aún más. También, en un servidor autoalojado que lo implementa como una restricción de decodificación, empuja al modelo hacia bucles de repetición —aproximadamente una de cada cuatro vueltas cuando lo medimos, una de las cuales pasó dos minutos emitiendo el mismo fragmento. Una respuesta que nunca llega es peor que una que responde en prosa.

Dos consecuencias que vale la pena conocer. La respuesta sigue volviendo en el idioma del cliente aunque la instrucción compuesta esté en inglés —eso también lo fija la plataforma, no se deja a que el modelo lo note. Y cuando un turno debía entregar algo y entrega prosa en su lugar, la plataforma lo nota y pregunta una vez más, nombrando el paso que se omitió y ofreciendo una salida honesta ("si ninguno del material encaja, dilo") —porque un modelo presionado sin una salida inventará una. Un agente que describe ocho productos y no muestra ninguno se lee, para la persona que espera, exactamente como un agente que ignoró la pregunta.

Esa comprobación mira lo que volvió, no lo que parece. Un modelo que ha aprendido la forma de un resultado escribirá la forma sin hacer el trabajo —un bloque vacío, o una referencia a una búsqueda que nunca realizó. Ambos se tratan como nada entregado.

El paso extra cuesta una fracción de segundo y solo se ejecuta en mensajes que parecen necesitarlo —una pregunta ordinaria no paga nada. Mientras se ejecuta, la conversación dice lo que está haciendo. Si alguna parte de la decisión es clara, el turno procede exactamente como lo habría hecho sin ello.

Dos presupuestos, no uno

Los resultados de las herramientas son la forma más común en que el contexto de una conversación se destruye. Una sola consulta de CRM puede devolver más texto que la ventana de contexto completa del modelo.

Limitar cada resultado individual es la defensa obvia, y no es suficiente. Los resultados se acumulan a través de las iteraciones —la conversación solo crece—, por lo que el peor caso es el límite de iteraciones multiplicado por varias herramientas por iteración multiplicado por el límite por resultado. Cada resultado pasa su propio límite y el total aún se desborda.

Así que hay dos presupuestos: un límite por resultado, y un presupuesto agregado para todo el turno. Una vez que el agregado se agota, los resultados adicionales se reemplazan con un marcador de posición corto en lugar de anexarse.

Lo que hay en ese marcador de posición importa tanto como la truncación en sí. Un resultado truncado silenciosamente es peor que ninguno, porque el modelo no tiene forma de saber que está razonando a partir de medio registro. Tanto el aviso de truncación como el marcador de posición de agotamiento indican explícitamente que el contenido es incompleto y le instruyen al modelo que responda con lo que tiene y no invente la parte faltante —la diferencia entre un agente que dice "solo pude ver las primeras órdenes" y uno que las inventa con confianza.

La truncación también se registra con el nombre de la herramienta y los tamaños, porque una herramienta que regularmente desborda el presupuesto es una herramienta que debería devolver menos campos —un problema de configuración que vale la pena ver.

Modelos que no emiten llamadas a herramientas adecuadas

No todos los modelos producen de manera confiable llamadas a herramientas estructuradas; algunos emiten la llamada como texto en la respuesta. En lugar de tratar eso como un turno fallido, el bucle también analiza las llamadas a herramientas del contenido del mensaje, y elimina los fragmentos malformados antes de que la respuesta llegue al cliente —para que un modelo que tenga un momento de distracción degrade en un turno ligeramente más lento en lugar de filtrar JSON en una conversación.

Conectando tus propios sistemas

Las herramientas provienen de dos lugares.

Herramientas integradas vienen con la plataforma —programar un seguimiento, crear un recordatorio, capturar detalles de contacto, invocar una habilidad, editar un documento, dibujar un gráfico, buscar en la web.

La mayoría de estas no son una decisión que tomas. Están disponibles para cada agente y se adjuntan al turno que las necesita, lo cual es lo que mantiene que tenerlas no cueste nada: una herramienta que el mensaje del visitante no da razón para usar no está en la lista de ese turno en absoluto, por lo que no ocupa nada del contexto y no ofrece al modelo nada que elegir por error. No hay una lista de verificación de ellos para mantener, y no hay configuración en la que un agente carezca silenciosamente de la capacidad de tomar un número de teléfono.

Las herramientas propias de una habilidad son la excepción, y deliberadamente así: llegan solo una vez que esa habilidad está cargada, nunca antes. Un paquete de capacidades es una forma de trabajar, y las herramientas son parte del método —entregarlas por separado permite al modelo omitir el método. Ver Skills and how one gets chosen.

La que es una decisión es responder desde fuentes públicas —si este agente puede buscar en la web y leer lo que encuentra, en lugar de responder solo desde tu propio material. Es un único interruptor porque es una única pregunta: buscar y buscar están activados juntos, ya que un agente que puede encontrar una página pero no leerla es mediblemente el peor de las tres configuraciones. Está desactivado por defecto, y lo que un agente hace con ello activado —el etiquetado, la cola de revisión— se describe en Retrieval.

Tus sistemas se conectan mediante MCP. Un inquilino registra servidores MCP, y sus herramientas se vuelven disponibles para los agentes de ese inquilino. Se admiten tres transportes: stdio para un subproceso local, y streamable_http y sse para servidores remotos. Un servidor HTTP remoto es la opción habitual para un CRM alojado o una API interna —nada que instalar junto a la plataforma, y la conexión es por inquilino.

Debido a que las definiciones de herramientas se registran por inquilino, los agentes de un inquilino nunca pueden ver las herramientas o puntos finales de otro.

Driving the platform itself from a coding agent is the same MCP mechanism pointed the other way — see Agent-native docs.

Lo que esto significa en la práctica

  • Un agente puede buscar algo a mitad de una frase y responder con el valor real.
  • Puede reservar, archivar y registrar en los sistemas que ya ejecutas, en lugar de decirle al cliente que lo haga.
  • Cuando una herramienta devuelve más de lo que el turno puede contener, el agente dice que su visión fue parcial en lugar de llenar el vacío con ficción plausible.

El argumento empresarial para actuar en lugar de responder está en Agents that act.