Agents

Machine translation of the French original.

The term "agent" refers to two distinct objects within the park, and confusing them can waste hours.

	What it is	Where it lives
The Executor	A program that receives a command, reads, thinks, and produces text	A machine within the park – a non-interactive claude -p, a Python service, or a workflow engine
The Definition	What it is, what model it is allowed to call, what it is allowed to read, and what it costs	The proxy LLM, within its agent registry

The park's rule, since 2026-09-13: the definition is the reference, and it is in the proxy. Submitting an agent now only requires its fallback plan – what remains when the proxy fails to respond.

Why separate the two?

An executor is attached to a machine: it needs the disk, the repository, and the authenticated session. A definition, on the other hand, must be readable by everyone – the UI, a script, another agent, or the expense tracker. Keeping them together forces you to clone the configuration file everywhere someone wants to know what the agent is doing.

A2A, in one page

A2A (Agent-to-Agent) is an open protocol that answers a specific question: how does a program talk to an agent that it hasn't written?

It can be described in three parts.

1. The Agent Card

A JSON document served by the agent itself, at a standard address: /.well-known/agent-card.json. It states its name, description, URL, the capabilities (skills) it exposes, the formats it accepts and produces, and how to authenticate with it.

It's the equivalent of an OpenAPI file for a REST API: a way to call it without having read the code on the other side.

2. A JSON-RPC call

There is only one method that works: message/send. A message is sent, consisting of parts (text, an image, a file), and the agent responds.

{
  "jsonrpc": "2.0", "id": "1", "method": "message/send",
  "params": { "message": {
      "role": "user",
      "parts": [{ "kind": "text", "text": "vérifie la continuité de la scène 1" }],
      "messageId": "f1e2d3"
  }}
}

3. A task with a lifecycle

An agent does not always respond in two seconds. A2A models a task with states — submitted, working, completed — and artifacts delivered over time. This is what distinguishes A2A from a simple HTTP call: the protocol anticipates that the work will take time.

The design trap, and it's structural

An agent that takes several minutes to respond is essentially out of sync. If the caller expects a response on the same connection, everything in between — proxy, reverse proxy, HTTP client — has its own timeout, and the first one to expire wins. A slow agent is designed with the task lifecycle, not against it.

What the LLM proxy adds

The park's proxy – the one that already serves all model aliases – also includes an agent registry. What it provides is not the protocol itself; it's everything we don't want to rewrite in each agent.

flowchart LR
    subgraph consommateurs
        s["Script · cron"]
        w["Moteur de workflows"]
        c["Interface de chat"]
        a2["Un autre agent"]
    end

    p["Proxy LLM<br/>registre + identité + limites + dépense"]
    ag["Agent<br/>serveur A2A"]
    m["Modèles<br/>locaux · souverains · API"]

    s --> p
    w --> p
    c --> p
    a2 --> p
    p -->|"A2A : message/send"| ag
    p -->|"OpenAI : chat/completions"| m
    ag -->|"ses propres appels,<br/>avec SA clé"| p

What the proxy provides	What it avoids
A directory – a list of agents, their map, and their skills	Each agent maintains its own list, and they would diverge
An Identity – a virtual key per agent	A single shared key, meaning a cost that cannot be attributed to anyone
Limits – per agent, whitelist of models, budget	An agent who goes around taking everyone's budget
The Cost – each call writes its line	A cost that is distributed proportionally, meaning a fabricated cost
Two Facades – A2A protocol and classic chat API	Rewrite a client for each agent

The two sides, and that's the key point

A registered agent can be contacted in two ways, without any changes on the agent's side:

• via A2A, as described in /a2a/<id>/message/send – this is the protocol, with its card and task cycle;
• via a chat API, simply requesting the model a2a/<nom> on /v1/chat/completions.

The second method is the one that matters in practice: any application within the park that can communicate with a model can then communicate with the agent, without any code changes. The chat interface, the workflow engine, a three-line script – they simply see a new model name in the list.

The bridge also works in the other direction: a registered agent can a limited model, and the proxy creates a façade for it to use.

What is true today, and what is not

A registry of external agents

The registry expects agents that already exist somewhere: an A2A server, or a commercial agent platform. There is no type of "command-line program".

Conséquence directe pour le parc : un agent qui est un claude -p lancé sur une machine ne devient joignable par les autres que si on lui met un serveur A2A devant. Tant que ce serveur n'existe pas, le registre sert de référence de définition — ce qui est déjà beaucoup — mais pas de point d'appel, et l'URL annoncée sur sa carte ne répond pas.

Un registre qui oublie au redémarrage

The list of agents that the proxy uses is stored in memory and is not read from the database when the process restarts. After a restart, the agents still exist, but the list is empty – and the resolution in a2a/<nom>, which reads the same registry, stops for all consumers. A periodic check that re-applies the definitions closes the gap; without it, the failure is silent and the service appears to be functioning normally.

The next step, field by field: Define an agent and consume it.

Dernière vérification de cette page : 2026-09-13