L'agent et ses portails

La section agent s'écrit après la station et ses tests ; seuls ses evals la suivent. Elle décrit l'agent que Convoy déploie pour cette station. Cet agent est un client de la station comme un autre : il passe par les mêmes outils, les mêmes gardes, le même point de décision que Claude, ChatGPT ou l'agent d'une entreprise.

agent:
  name: Teranga
  persona: "un hôte chaleureux qui aide à composer le repas"
  tone: friendly
  rules:
    - "Proposer une boisson quand le repas est choisi."
  emoji: false                           # un emoji discret dans les réponses, ou aucun
  model: gemini-2.5-flash                # le modèle sur lequel tourne l'agent
  mode: assisted                         # assisted | autonomous — ce que lit `agent.mode` dans submitted_by
  portals:
    web:
      widget:
        origins: [https://teranga.example.sn]   # les seuls sites où le widget se charge
        theme: {primary: "#1B7A4B", secondary: "#F4E9D8", font: manrope}   # couleurs et police du widget
        identity: {auth: anonymous}
      pwa: {name: "Teranga & Moi"}
    whatsapp:
      number: "+221 77 000 00 00"
      identity: {auth: telephone}
    teams: {app: teranga-pro, identity: {auth: salaries}}
    slack: {workspace: teranga, channel: "#commandes", identity: {auth: salaries}}

Ce qui est à l'agent, et ce qui est à la station

à l'agent (agent)	à la station
sa voix : name, persona, tone	ce qui est permis : gardes, profils, politiques, budgets
ses consignes de comportement (rules)	ce que tout agent doit respecter
ses portails, leur thème, leur texte d'accueil	les outils, les parcours, le submit
comment chaque portail prouve qui parle	ce qu'on fait de cette identité (les profils)

Une consigne n'est pas une règle

« Ne jamais donner de conseil juridique contraignant » doit tenir pour Claude aussi. Ce n'est donc pas une consigne de notre agent : c'est une politique de la station (effect: rewrite sur la sortie). Dans agent.rules, ne mettez que ce qui concerne la façon de parler et d'aider.

Les portails

portail	pour qui	identité typique
web.widget	les visiteurs du site du tenant	anonymous, ou un fournisseur assertion si le site connecte ses clients
web.pwa	la room de la personne, installable sur son téléphone	celle de la room
whatsapp	les clients qui écrivent au numéro du tenant	un fournisseur otp sur le téléphone
teams, slack	les salariés d'une organisation	un fournisseur oidc : Okta, Auth0, Keycloak, Entra ID (l'annuaire donne rôles et équipes)

identity.auth nomme le fournisseur d'identité que le portail propose, ou anonymous. L'agent agit alors pour cette personne : ses profils, ses droits, ses budgets. Un visiteur anonyme du widget a le profil anonyme ; un manager dans Teams a ses rôles de l'annuaire.

origins nomme les seuls sites où le widget se charge : sans lui, le widget se chargerait sur n'importe quel site, avec la marque et la room du tenant.

Les fournisseurs d'identité

identity.auth nomme un fournisseur que la station déclare dans station.identity.providers : un code par SMS ou e-mail (otp), un SSO (oidc), le login du tenant (assertion). Ils sont décrits, avec la différence entre une room identifiée et une personne authentifiée, dans Identité. Quand une skill exige une preuve, le portail affiche le parcours de son fournisseur : voir Demander l'authentification.

Les portails ne sont pas les boîtes

Une boîte (inboxes) est l'endroit où la station demande à une personne de décider. Un portail est l'endroit où notre agent parle. Un manager approuve dans Teams que l'agent de la station y soit déployé ou non : les deux se configurent séparément.

La porte MCP

Elle appartient à la station, pas à l'agent : c'est par elle que les agents des autres se connectent. Elle existe toujours. Sans section agent, la station n'est joignable que par là.