Salesforce abre sus agentes de IA a MCP y a Slack

El 21 de agosto, Tech in Asia publicó que Salesforce amplía el acceso a sus agentes de IA a través de MCP y de Slack (Salesforce expands AI agent access via MCP, Slack). El titular suena corporativo, pero el cambio técnico es concreto: el agente deja de vivir encerrado en la interfaz de Salesforce y pasa a ser algo que otro cliente puede invocar desde fuera.

Quien haya montado una integración con un CRM sabe por qué esto no es cosmético. La parte cara nunca fue el modelo, fue el pegamento: autenticación, mapeo de objetos, permisos por perfil, control de qué puede escribir un proceso automático y registro de lo que hizo. MCP traslada buena parte de ese trabajo del lado del integrador al lado del proveedor.

Qué significa exponer agentes por MCP

MCP (Model Context Protocol) es el estándar que publicó Anthropic para que un modelo llame a herramientas externas con un contrato común. Un servidor MCP expone herramientas, recursos y prompts, y cualquier cliente compatible los descubre y los usa sin conocer de antemano la API que hay detrás. La diferencia práctica es clara: en vez de un conector por cada pareja de sistemas, un servidor que vale para todos los clientes del estándar.

Aplicado a un CRM, el efecto es que el sistema deja de ser un destino al que el usuario entra y empieza a comportarse como una capa de datos y acciones a la que se llama. Un agente en Claude Code, un asistente dentro del IDE o un flujo propio pueden pedir la cuenta, la oportunidad o el caso sin que nadie abra una pestaña.

La pata de Slack

La otra mitad del movimiento es Slack, propiedad de Salesforce desde 2021. Sacar el agente al canal donde el equipo ya trabaja resuelve un problema de adopción que ninguna demo enseña: casi nadie entra en el CRM si no le obligan. Cuando la respuesta aparece en el hilo donde se está discutiendo la cuenta, la fricción baja de golpe.

También sube el riesgo, y conviene decirlo. Un agente con permiso de escritura conectado a un canal es un agente al que cualquiera con acceso a ese canal puede pedirle cosas. La gobernanza deja de ser una casilla de configuración y pasa a ser diseño: qué scopes, qué acciones exigen confirmación humana y qué queda registrado.

Para quién es útil

Equipos de RevOps con los datos repartidos entre CRM, soporte y facturación: la consulta cruzada deja de necesitar un informe a medida.
Equipos de producto e ingeniería que ya viven en Claude Code o en un IDE con soporte MCP y quieren contexto de cliente sin cambiar de herramienta.
* Consultoras e integradores: el trabajo se desplaza de construir conectores a diseñar permisos, límites y flujos de aprobación.

Para un equipo pequeño que no usa Salesforce la noticia también dice algo: marca dirección. Cuando un proveedor de este tamaño publica servidores MCP, el estándar deja de ser cosa de entusiastas y empieza a aparecer en los pliegos de compra.

Lo que vigilaríamos

Tres cosas antes de llevar esto a producción. La granularidad de permisos: si el servidor hereda el perfil del usuario, bien; si trabaja con una identidad de servicio con permisos amplios, hay que acotarla a mano. Los límites de llamada y la latencia, porque un agente hace muchas más peticiones pequeñas que una persona y las cuotas se agotan antes de lo previsto. Y la trazabilidad: saber qué agente escribió qué, cuándo y a partir de qué instrucción no es opcional en un sistema de registro.

En ElephantPink llevamos meses montando servidores MCP a medida y el patrón se repite: la integración se resuelve en días y las semanas se van en decidir qué puede tocar el agente. Que Salesforce publique la suya ahorra la primera parte, no la segunda.