Agent Setup Protocol

A platform publishes what a person is entitled to as two JSON documents. A client reads them and writes the agent’s configuration files. The platform publishes data; the client owns every file edit.

Running it again is the whole update story: a rotated credential, a project added, one left behind, a model the platform has started offering.

Configuring an agent is a text-editing job, and it should not be.

Pointing an agent at a different project, a different customer or a different model means finding a JSON or TOML file, pasting a key into it, and knowing what a base URL and a wire protocol are. That is a reasonable thing to ask of an engineer and an unreasonable thing to ask of everyone else now running agents.

People who hold several of these switch by hand, and nothing in the tool says afterwards which one is in force. A platform that wants to fix it today ships an installer for one tool and one of itself, so the knowledge ends up in a script instead of in a document, and the next platform starts over.

This specification is the document that script should have been.

Four steps, and only the last one touches the disk.

Two of them, and the first is public.

{
  "v": 1,
  "platform": {
    "name": "Example Platform",
    "documentation": "https://platform.example/docs"
  },
  "tools": ["codex", "claude-code"],
  "profiles": "https://platform.example/asp/v1/profiles",
  "authorization":
    "https://platform.example/.well-known/oauth-protected-resource",
  "loopback_redirect_uris": ["http://localhost:51789"],
  "publishes_provider": true
}

{
  "v": 1,
  "source": {
    "id": "example",
    "display_name": "Example Platform",
    "origin": "https://platform.example"
  },
  "default": "acme",
  "profiles": [{
    "id": "acme",
    "display_name": "Acme (production)",
    "group": "Acme",
    "provider": {
      "base_url": "https://gw.platform.example/openai/v1",
      "wire_api": "responses",
      "auth": { "env_var": "ACME_API_KEY" }
    },
    "mcp_servers": [
      { "name": "acme", "url": "https://platform.example/acme/mcp" }
    ],
    "credential": "https://platform.example/asp/v1/acme/credential"
  }]
}

Every field name is snake_case. A platform serving camelCase is not conforming, though a client is wise to tolerate it.

The protocol describes agents; a binding describes one tool.

A profile is tool-independent. It says there is a model endpoint of a given wire shape, a set of servers, a credential to fetch. What that becomes on disk is specific to the thing being configured, so each tool gets its own binding, and a platform names in tools which ones it publishes for.

Nothing restricts this to coding agents. Any harness that reads configuration from a file or an environment is a binding target: a research or strategy agent, a chat harness, a personal assistant, an in-house runtime.

Three roles, so an implementer can tell which half is theirs.

A role is defined by its obligations, never by who implements it.

What a platform may never put in a document.

• MUST NOT  a credential value. Documents carry variable names. They are expected to be logged, cached and shown.
• MUST NOT  a path on the person’s disk. The platform does not know the machine and must not guess at it.
• MUST NOT  a command to run. A profile is a description the client may apply, reject, or partly ignore.

This is the line that lets a person point the protocol at a host they do not administer. It is also what makes the documents safe to log and to show.

And what a client owes

• MUST  edit configuration files rather than rebuild them, leaving keys it does not own untouched.
• MUST  keep a session on the profile it started with, because resuming reads state from the directory it began in.
• MUST  make the active profile visible. The failure being prevented is silent: the wrong profile does not raise an error, it produces ordinary work in the wrong place.

Draft, and honest about it.

The path, the schemas and the rel URI may still change before v1 is cut. No implementation listed anywhere is conforming yet, and the registry is empty for that reason rather than because nobody has asked.

The mechanism here is the one everyone converges on, a JSON document at a well-known path, and A2A’s agent card is the pattern it follows. The gap is the motivation: the tools that exist for switching between agent accounts were built for quota rather than for customers, and none of them is specified, so no platform can implement against them. The IETF chartered a working group for agent discovery in October 2026; its charter covers an agent’s initial public properties, which is a different question from what a signed-in person is entitled to configure, and it has no adopted draft.