Skip to main content

Tools y actions: darle a un agente la capacidad de actuar

Cómo actúa un agente: tool (function) calling, donde el nombre de la tool, la descripción y el schema tipado son la interfaz sobre la que razona el modelo. Diseñar tools seguras — least privilege, validación de argumentos, idempotencia, y un gate de aprobación más kill switch en las acciones con consecuencias. Agentforce Actions (Flow, Apex, Prompt Template) dentro del modelo de seguridad de la plataforma, y MCP como el protocolo abierto para conectar modelos con tools entre sistemas. Compuestos, no rankeados.

Referencia·Actualizado 2026-06-01·Escrito por Lira · Editado por German Medina

Un agente que solo puede leer es una caja de búsqueda con mejores modales. En el momento en que puede actuar — actualizar un registro, mandar un mensaje, mover plata — se convierte en algo que tenés que gobernar. Esta página es sobre esa capacidad: cómo actúa un agente (tool calling), cómo diseñar las tools para que un modelo confundido no pueda hacer daño real, y las dos superficies que Cleon compone para darle manos a un agente — Agentforce Actions dentro de Salesforce, y MCP como el protocolo abierto que deja que una tool viaje entre sistemas.

Son instrumentos complementarios, no bandos rivales. Un agente construido sobre Agentforce, uno cableado sobre MCP, y uno que llama tools directo a través de la Claude API comparten todos el mismo mecanismo de fondo y la misma disciplina. La habilidad está en componerlos según el problema, no en jurarle lealtad a uno.

Tool calling: el mecanismo de fondo

Toda forma en que un agente actúa se reduce al mismo loop. Exponés un conjunto de tools. Cada tool tiene un nombre, una descripción y un schema tipado de argumentos. Le pasás esas definiciones al modelo junto con el pedido del usuario. El modelo — cuando decide que una acción se justifica — responde no con prosa sino con una llamada estructurada: esta tool, estos argumentos. Tu código recibe esa llamada, la valida, ejecuta el trabajo real, y devuelve el resultado. El modelo lee el resultado y sigue.

La parte que importa, y la parte que la mayoría de los equipos hace mal: el nombre, la descripción y el schema son toda la interfaz sobre la que razona el modelo. El modelo no ve tu implementación. Ve las palabras que escribiste describiendo qué hace la tool y la forma de los argumentos que acepta. Una descripción vaga — "actualiza la cuenta" — no le da al modelo nada con qué razonar, y va a llamar la tool en situaciones que nunca pensaste o llenar un argumento con una adivinanza plausible. Una descripción precisa — qué hace la tool, cuándo usarla, cuándo no, qué significa cada argumento — es la diferencia entre una tool que el modelo usa bien y una que abusa.

Una definición de tool es data. Si mostrás una, mantenela en un bloque cercado para que los angle brackets de cualquier tipo queden afuera de la prosa:

{
  "name": "update_case_status",
  "description": "Set the Status of ONE support case the user is currently viewing. Use only when the user explicitly asks to change status. Does not create cases, does not close cases owned by another agent.",
  "input_schema": {
    "type": "object",
    "properties": {
      "case_id": { "type": "string", "description": "The 18-char record Id of the case to update." },
      "status": { "type": "string", "enum": ["New", "Working", "Escalated", "Closed"], "description": "The new status." }
    },
    "required": ["case_id", "status"]
  }
}

Fijate cuánto trabajo hace el schema. El enum significa que el modelo no puede inventar un status que no existe. La descripción acota la tool a un caso, pedido explícitamente, y descarta dos acciones vecinas. No le estás confiando al modelo que se porte bien — estás escribiendo una interfaz lo suficientemente angosta como para que la llamada equivocada sea difícil de expresar.

Diseñar tools seguras

El tool calling es también donde aterriza el principio 5: cada tool que un agente puede llamar es un blast radius. El modelo, tarde o temprano, va a elegir la tool equivocada o llenar la correcta con un argumento malo. El diseño seguro asume eso y lo contiene. Cuatro reglas cargan con casi todo el peso.

  • Least privilege. Dale a cada tool el scope más angosto que igual haga el trabajo. Una tool que necesita actualizar un campo no debería poder borrar el registro. Una tool que le escribe al contacto actual no debería poder escribirle a cualquiera. Acotala en el límite de la tool, en código y en el modelo de permisos de la plataforma — no en el prompt, donde es un pedido amable que el modelo puede ignorar.
  • Validá cada argumento antes de ejecutar. El modelo puede pasar un valor malformado, un Id que no existe, o un número fuera de cualquier rango sensato. Chequeá la llamada contra el schema y contra tus propias reglas de negocio antes de que corra el trabajo real. Cuando la validación falla, decidí deliberadamente qué pasa — reintentar, preguntarle al usuario, o frenar — y nunca dejes que un argumento sin validar llegue a la acción.
  • Idempotencia donde la puedas conseguir. Los agentes reintentan. Los loops vuelven a entrar. Una tool que es segura de llamar dos veces — con una key tal que una repetición sea un no-op en vez de un segundo cargo o un registro duplicado — convierte toda una clase de bugs de reintento en nada. No toda acción puede ser idempotente, pero las que mueven plata o mandan mensajes son las que más se benefician.
  • Un kill switch y un gate de aprobación en cualquier cosa con consecuencias. Las lecturas son recuperables; los envíos, los cargos y los borrados no. Las acciones con consecuencias necesitan un paso de aprobación humana antes de dispararse y un control de operador que pueda frenar un agente en marcha ahora. No es trabajo del modelo hacerlos cumplir — viven en tu código y tu plataforma, afuera de cualquier cosa que el modelo pueda esquivar con labia.

Agentforce Actions: actuar dentro de la plataforma

Agentforce es la forma Salesforce-native en que un agente actúa, y su fortaleza es exactamente de lo que trata la sección de arriba: la acción corre dentro del modelo de seguridad de la plataforma que ya tenés. Una Agentforce Action es la definición de tool — un nombre, una descripción sobre la que razona el modelo, e inputs y outputs tipados — cableada a uno de unos pocos tipos de ejecución:

  • Flow actions — un Flow autolaunched corre el trabajo de forma declarativa. Sirve cuando la lógica ya vive en un Flow o es lo bastante simple como para armarla así.
  • Apex actions — un método invocable de Apex corre el trabajo en código. Sirve cuando necesitás lógica que un Flow no expresa limpio, o cuando ya tenés el método.
  • Prompt Template actions — la action llama a un prompt template fundamentado, generando texto contra Data 360 u otra data de Salesforce a través del grounding propio de la plataforma.

Lo que ganás por quedarte on-platform es la gobernanza y la auditoría que vienen de fábrica: la action ejecuta como un usuario bajo los permisos de ese usuario, las sharing rules y la field-level security siguen aplicando, y la plataforma registra qué corrió. La disciplina de least-privilege y audit-trail de arriba la hace cumplir en parte la plataforma en vez de armarla a mano. Ese es un instrumento complementario — el correcto cuando el trabajo vive en el modelo de seguridad de Salesforce y necesita acciones gobernadas y auditables sobre data de clientes. Ver agentes de Agentforce para cómo se ensambla el agente alrededor de estas actions.

MCP: un protocolo, muchos hosts

El Model Context Protocol (MCP) es un estándar abierto para conectar modelos con tools y fuentes de datos entre sistemas. Donde el tool calling es el mecanismo que usa un modelo individual, MCP es el protocolo que deja que una tool — y la data detrás de ella — se exponga una vez y se reuse desde cualquier host que lo hable. Escribís un servidor MCP que expone una tool (con la misma disciplina de nombre, descripción y schema que cualquier otra tool); cualquier host que hable MCP puede entonces descubrirla y llamarla.

La razón por la que un protocolo compartido importa es la misma por la que importa cualquier estándar: mata el problema de integración N por M. Sin él, cada tool se vuelve a implementar para cada framework de agentes que la quiera — la misma tool de "buscar una orden" escrita una vez para un host, otra vez para otro, otra vez para un tercero. Con MCP, escribís esa tool una vez detrás del protocolo y todo host que cumple la reusa. La tool y el agente dejan de estar soldados; podés cambiar el host sin reescribir las tools, y agregar una tool sin tocar el host.

Para Cleon eso hace de MCP el tejido conectivo cuando un agente necesita tools que abarcan sistemas que Salesforce no alcanza, o cuando querés la misma tool gobernada llamable desde más de un lugar. Es complementario a las Agentforce Actions, no un reemplazo: las Agentforce Actions son cómo un agente actúa dentro de la plataforma; MCP es cómo las tools interoperan entre hosts. Las mismas reglas de tool segura — least privilege, validación, idempotencia, gates en las acciones con consecuencias — aplican a una tool expuesta por MCP exactamente igual que a cualquier otra, porque del otro lado del protocolo sigue siendo código real tomando una acción real.

La disciplina, otra vez

El mecanismo es simple y las superficies difieren, pero la regla debajo de todas es una sola oración: una tool que puede borrar, enviar o cobrar necesita un gate de aprobación, un límite de blast radius, y un audit trail. El tool calling le da alcance a un agente; ese alcance es todo el riesgo. Ya sea que la acción corra como un Flow de Agentforce, un método de Apex, o una función expuesta por MCP, la pregunta a responder antes de shipear es la misma — qué es lo peor que esta tool puede hacer, quién la aprueba cuando tiene consecuencias, y si alguien la puede frenar y reconstruir después. Acertá eso y el resto del diseño es detalle. Erralo y "el agente lo hizo" se vuelve un incidente sin dueño. (Ver gotchas de agentes para las otras formas en que esto sale mal en producción, y el Style Guide de Agentes para la vara que un agente pasa antes de shipear.)

Related

Reference: