Varios agentes

Un workspace puede correr más de un agente, cada uno con sus propias instrucciones, herramientas y conocimiento. Cuál le toca a un visitante lo decide el manifiesto, a partir de si tiene sesión iniciada y de lo que diga su token sobre él.

El caso para el que existe: un sitio de marketing y un portal de clientes que embeben el mismo widget. El visitante anónimo que pregunta precios y el cliente con sesión que pregunta por sus propios registros no son la misma conversación, y un solo set de instrucciones sirviendo a ambos termina no sirviéndole a ninguno. Antes de esto tenían que ser dos workspaces — dos manifiestos, dos bases de conocimiento, dos tokens que mantener sincronizados.

Pon los agentes bajo agents: y agrega una tabla entry::

agents:
  home:
    name: Ana
    instructions: |
      Answer product and pricing questions using knowledge_lookup.
      Nobody here is signed in: never ask for account details.
    tools: [knowledge_lookup]
    knowledge: [public_docs]

  portal:
    name: Ana
    instructions: |
      You are talking to a signed-in customer. Use my_orders and my_documents
      to answer about their own account, and knowledge_lookup for anything else.
    tools: [my_orders, my_documents, knowledge_lookup]
    knowledge: [portal_kb]

  # Cada agente nombra su propio conocimiento; no se hereda nada.

entry:
  - { authenticated: false, agent: home }
  - { claims: { role: staff }, agent: staff }
  - { agent: portal }

agent: es la forma corta de agents: { main: … }, así que un workspace con un agente no cambia en nada y sigue funcionando exactamente como hoy.

Dale el mismo name a todos los agentes cuando la división deba ser invisible. Para el visitante están hablando con una sola persona todo el tiempo, que es lo que las reglas de la plataforma ya asumen.

La tabla de entrada

Una lista ordenada. Gana la primera fila cuyas condiciones se cumplan, y esa es toda la regla — no hay especificidad, ni puntaje, ni nada que deducir. La política se lee de arriba abajo, y alguien que nunca usó Vatio puede revisarla en un pull request.

Clave	Significado
agent	Requerida. El agente que esta fila selecciona
authenticated	true o false — si el visitante llegó con un token válido
claims	Valores de claims que deben coincidir todos; una lista significa cualquiera de ellos

Una fila sin condiciones matchea a todos. La última fila debe ser una, porque un visitante que no matchee nada se quedaría sin nadie con quien hablar — y cualquier cosa escrita después de ella es inalcanzable.

Los claims se comparan como texto, así que role: 2 en el manifiesto matchea "2" en el token. vatio tools check advierte sobre un agente que ninguna fila puede seleccionar jamás.

Cuándo se decide

Antes de la primera respuesta, en todos los canales. Vatio verifica el token al abrirse la conversación — una verificación de firma, sin red — así que el agente correcto se elige antes de responder el primer mensaje del visitante, no después.

Si inicia sesión a mitad de la conversación, el identify() del SDK vuelve a correr la tabla. Alguien que preguntó algo de forma anónima, inició sesión y volvió conserva todo lo que escribió: mismo hilo, mismo historial y, desde el siguiente mensaje, el agente que corresponde a quien ahora es.

Lo que no es

entry: no es un control de seguridad y no debe usarse como tal. Un visitante sin token válido no tiene identidad verificada, así que ninguna herramienta access: private corre para él, caiga en el agente que caiga. Un error en la tabla le muestra a alguien el prompt equivocado; no puede mostrarle los datos de otra persona.

Protege los datos con access: private en la herramienta, siempre. La tabla de entrada es para darle a cada audiencia la conversación correcta.

Conocimiento y enlaces por agente

Cada agente declara los suyos, incluso cuando dos digan lo mismo:

agents:
  home:
    instructions: …
    knowledge: [public_docs]
    links:
      pricing: "https://acme.test/pricing"
  portal:
    instructions: …
    knowledge: [portal_kb]
    links: {}                   # no entrega ninguna url

No hay un valor por defecto a nivel de workspace del cual heredar, y la repetición es deliberada. Lo que un agente sabe y qué URLs puede entregar son las dos cosas que revisas cuando responde mal, y un valor heredado significa mirar en otra parte y después deducir si este agente lo sobrescribió. También importa en el prompt: cada url declarada aparece listada en él, así que un agente de portal cargaría toda la lista de enlaces del agente de marketing sin entregar jamás uno.