Agentforce para Salesforce Administrator

El modelo mental: agente, trabajo, accion y contexto

Un agente de Agentforce es una experiencia conversacional o automatizada que puede responder, razonar sobre una solicitud y ejecutar tareas dentro de limites configurados. Para un Administrator, la lectura correcta empieza con cuatro preguntas: que trabajo debe hacer el agente, que acciones tiene permitido ejecutar, que datos puede usar como contexto y que limites evitan que responda o actue fuera del proceso.

Salesforce ha movido el vocabulario hacia subagents. En documentacion y pantallas todavia puedes ver la palabra topics durante la transicion, pero la idea de examen es la misma: un subagent representa un tipo de trabajo o area funcional que el agente puede manejar. Dentro de ese subagent viven instrucciones y acciones. Las instrucciones explican alcance, reglas y comportamiento; las acciones son las capacidades concretas que permiten consultar informacion o hacer cambios.

Piensa en Agentforce como una combinacion de configuracion, automatizacion y gobierno. No basta con decir "use AI". Una respuesta correcta suele mencionar estructura, datos confiables, permisos, pruebas, versionado y escalamiento humano. Si una opcion permite que el agente responda con datos no verificados o ejecute acciones sin permisos claros, normalmente no es la respuesta mas segura.

Regla practica: subagent define el trabajo, instructions definen el criterio, actions hacen cosas, grounding aporta contexto y guardrails limitan el riesgo.

Agentforce Builder

Agentforce Builder es el lugar donde se crean, personalizan, prueban y preparan agentes para uso real. La experiencia actual incluye una vista de Explorer para navegar configuracion, subagents, actions, variables, conexiones y datos; una vista Canvas para editar con lenguaje natural; una vista Script para control mas estructurado; y un panel Preview para probar comportamiento. Para el examen, no necesitas memorizar cada boton, sino entender el ciclo: construir, configurar, probar, versionar y activar.

El Builder ayuda a separar intencion de ejecucion. Puedes describir lo que quieres que el agente haga, pero luego debes revisar si los subagents, actions, instrucciones, variables y conexiones resultantes son correctos. Esto importa porque un agente no debe tener capacidades demasiado amplias. Si solo debe responder preguntas de soporte, no deberia tener acciones que modifiquen pedidos, cancelen servicios o editen cuentas sin necesidad.

En escenarios de examen, Agentforce Builder aparece cuando se pregunta donde crear o ajustar un agente, donde probar utterances, donde revisar que subagent o action uso el agente, donde depurar comportamiento inesperado o donde preparar una version que pueda activarse. Si el problema es disenar el comportamiento conversacional y las acciones disponibles, Builder es candidato natural.

Subagents, instrucciones y scope

Subagents agrupan trabajos relacionados. Por ejemplo, un agente de servicio podria tener subagents para preguntas de garantia, estado de pedido, devoluciones o soporte tecnico. Cada subagent debe tener una descripcion que ayude al agente a clasificar la solicitud del usuario y seleccionar el area correcta. Si dos subagents se parecen demasiado, el agente puede elegir mal; si un subagent es demasiado amplio, puede intentar cubrir casos para los que no tiene reglas suficientes.

Las instrucciones son el contrato operativo. Deben explicar que hacer, que no hacer, que datos pedir cuando falta informacion, que condiciones validar y cuando transferir a una persona. Una instruccion debil dice "ayuda al cliente con devoluciones". Una instruccion mas util dice que confirme numero de pedido, revise elegibilidad, explique opciones permitidas, no prometa excepciones fuera de politica y escale si el cliente reporta fraude, riesgo legal o informacion sensible.

Para Administrator, el punto de estudio es el alcance. Si el escenario pide que el agente maneje un caso nuevo de soporte, conviene definir un subagent con instrucciones claras. Si el escenario pide que el agente haga algo externo o actualice registros, necesitas actions. Si el problema es que el agente responde sobre temas que no deberia, ajusta scope, instrucciones, clasificacion o fallback, no simplemente agregues mas acciones.

Actions, Flow y capacidades reales

Actions son lo que permite que un agente haga algo mas que conversar. Una action puede consultar informacion, ejecutar un Flow, llamar Apex, usar una API o realizar una tarea especifica segun el tipo de agente y las capacidades disponibles. Salesforce describe las actions como las habilidades del agente: sin actions, el agente puede estar limitado a responder; con actions, puede consultar, crear, actualizar o iniciar procesos.

Para Administrator, la relacion con Flow es importante. Si ya existe un Flow mantenible que valida datos, crea registros o ejecuta un proceso, una action puede reutilizar esa logica en lugar de duplicarla en instrucciones. Tambien existen escenarios donde Flow Builder puede ejecutar o crear agentes, pero la idea de examen sigue siendo la misma: usa una capacidad nativa, prueba antes de activar y conecta outputs del agente con variables o logica cuando el proceso lo necesita.

La trampa es pensar que action equivale a permiso ilimitado. Una action debe tener descripcion, inputs, outputs y limites. Si el agente debe consultar el estado de una orden, la action debe pedir o recibir los datos necesarios y devolver una respuesta controlada. Si el agente debe actualizar un caso, debe respetar validaciones, permisos y proceso. En una pregunta, si aparece "perform task", "update record", "call flow", "retrieve order status" o "execute business process", piensa en actions.

Grounding: datos para reducir invenciones

Grounding significa fundamentar las respuestas del agente en datos concretos. Puede incluir datos estructurados de Salesforce, objetos estandar o personalizados, knowledge articles, Data 360, data libraries, retrievers, APIs u otros sistemas empresariales segun la configuracion. La razon de fondo es simple: un modelo de lenguaje puede producir una respuesta plausible, pero el negocio necesita una respuesta basada en registros, politicas y contexto real.

En Service Cloud, grounding puede usar datos de Case y Knowledge para ayudar a resumir, clasificar o proponer pasos. En experiencias mas amplias, Data 360 puede aportar perfiles unificados y datos armonizados. En preguntas de Administrator, busca frases como answer using company policy, use current case details, reduce hallucinations, retrieve approved articles, use CRM data, or ground responses in enterprise data. Esas pistas apuntan a grounding, knowledge, data libraries o Data 360, no a escribir instrucciones mas largas sin fuente de datos.

No todos los datos deben estar disponibles. Un buen administrador selecciona campos y fuentes necesarios para el trabajo. Si el agente solo necesita responder sobre garantia, quizas necesita producto, fecha de compra, region y articulo de politica; no necesita salario, margen comercial o campos sensibles. Grounding y seguridad van juntos: mas contexto no siempre significa mejor configuracion.

Seguridad, permisos, Trust Layer y escalamiento humano

Agentforce vive dentro de un modelo de confianza. El agente debe respetar permisos, datos permitidos, seguridad de campo, politicas de la organizacion y limites definidos por instrucciones y guardrails. Salesforce tambien destaca el Einstein Trust Layer como parte del enfoque de seguridad para generative AI, con mecanismos relacionados con proteccion de datos, grounding, deteccion de toxicidad, auditoria y uso responsable.

En examen, esto se traduce en sentido administrativo. Si el agente necesita ejecutar una action, revisa que el usuario o agente tenga acceso adecuado. Si el agente usa datos, revisa que solo use fuentes aprobadas. Si la conversacion llega a una situacion sensible, legal, medica, financiera, de enojo extremo o fuera de alcance, la respuesta correcta puede ser escalamiento humano. Si la pregunta menciona audit trail, feedback, confianza, privacidad, datos sensibles o compliance, no ignores gobierno y monitoreo.

Guardrails no son decoracion. Son limites para que el agente no prometa cosas imposibles, no revele datos no autorizados, no ejecute acciones peligrosas y no sustituya a una persona cuando el proceso requiere juicio humano. Un agente confiable no es el que responde todo; es el que sabe cuando actuar, cuando pedir informacion, cuando consultar datos y cuando transferir.

Testing, preview, versiones y activacion

Un agente se debe probar antes de publicarse. Agentforce Builder incluye preview y herramientas para ver como el agente decide, que subagents selecciona, que actions usa y que informacion considera. Esto permite detectar instrucciones ambiguas, clasificacion incorrecta, acciones demasiado amplias, variables mal mapeadas o respuestas que no siguen politica.

La distincion entre prueba y produccion es importante. Simular permite validar configuracion sin afectar datos; live test o pruebas con acciones reales pueden ejecutar cambios en la org segun la configuracion. Por eso, una respuesta de examen que active un agente sin pruebas o sin revisar comportamiento suele ser debil. Primero se definen escenarios, luego se prueba, se revisa el trace o interaction details, se ajusta y despues se activa una version.

El versionado tambien importa. Una version comprometida puede activarse para usuarios, mientras que los cambios posteriores se hacen en un draft. Esto protege estabilidad: no conviene modificar un agente activo sin ciclo de revision. Si el escenario habla de publicar cambios confiables o mantener una version estable mientras se mejora otra, piensa en versioning, draft, testing y activation.

Errores comunes al estudiar Agentforce

El primer error es responder "Agentforce" a cualquier pregunta que mencione AI. Muchas veces el examen pide Flow, Knowledge, assignment rules, reports o permissions. Agentforce entra cuando hay agente conversacional, reasoning, subagents, actions, grounding o automatizacion asistida por agente.

El segundo error es confundir instructions con grounding. Instrucciones explican como debe comportarse el agente; grounding le da datos para responder con contexto real. Si el problema es que el agente inventa politicas o responde sin informacion actual, no basta con escribir mas texto: necesita fuentes aprobadas, Knowledge, Data 360, data libraries o acciones de consulta.

El tercer error es olvidar seguridad. Si una action actualiza registros, debe respetar permisos y validaciones. Si un agente responde con datos de clientes, debe usar fuentes permitidas. Si una solicitud queda fuera de alcance, debe escalar. El cuarto error es no probar. Los agentes se configuran con lenguaje natural, pero se validan con escenarios reales, preview, trace, feedback y versionado.

Checklist de decision rapida:

La pregunta pide conversacion, clasificacion, ejecucion de acciones o solo automatizacion tradicional?
El agente necesita subagent nuevo, action nueva, instrucciones mejores o datos de grounding?
La action debe llamar Flow, Apex, API o consultar datos?
Que permisos, campos y fuentes de datos necesita realmente?
Como se prueba antes de activar y cuando debe escalar a humano?

Recursos oficiales y practica

Para practicar, toma un caso de soporte simple: "el cliente pregunta por el estado de su garantia". Disena un subagent, escribe instrucciones, define que datos se necesitan, decide si requiere una action para consultar informacion, limita campos sensibles, crea casos de prueba y define cuando debe escalar. Despues cambia el escenario a algo fuera de alcance, como una amenaza legal o solicitud de reembolso especial. Si puedes explicar por que el agente no deberia resolverlo solo, estas estudiando Agentforce como administrador.

BlueForce no esta afiliado a Salesforce. Esta guia es contenido editorial original basado en experiencia de estudio, objetivos publicos y recursos oficiales.