IFP: 7 Title: Agent Capability Discovery Class: Core Status: Draft Authors: Peter Kaminski, Claude (Opus 4.6) Created: 2026-03-04 Dependencies: IFP-1, IFP-2, IFP-3, IFP-4 License: CC-BY 4.0 (Creative Commons Attribution 4.0 International)
This IFP defines how Inter-Face agents advertise and discover each other’s capabilities. It specifies a capability schema (transport-independent), an HTTPS endpoint binding (via IFP-6), and a message-phase negotiation pattern for dynamic capability exchange.
When two agents first communicate, neither knows what the other can do. Capability discovery allows agents to learn what services a peer offers, what information it can share, and what protocols it supports – before investing in a full gossip exchange.
Per IFP-1 Section 6.5 (dynamic contextual capabilities), an agent’s capabilities may depend on context: trust level, disclosure tier, current workload, and the specific conversation. IFP-7 supports both static capability documents (for initial discovery) and dynamic capability negotiation during conversation (for context-sensitive cooperation).
A capability is described by a JSON object:
{
"name": "gossip.exchange",
"version": "1",
"description": "Participate in IFP-3 gossip exchanges",
"parameters": {},
"conditions": {}
}
| Field | Type | Required | Description |
|---|---|---|---|
name |
string | Yes | Capability identifier using dot notation |
version |
string | No | Version of this capability (default: "1") |
description |
string | Yes | Human-readable description of what this capability does |
parameters |
object | No | Expected input parameters |
conditions |
object | No | Conditions under which this capability is available |
The following capabilities are defined for interoperability:
| Name | Description |
|---|---|
gossip.exchange |
Can participate in IFP-3 gossip exchanges (greeting through close) |
message.receive |
Can receive IFP-4 structured messages |
message.reply |
Can reply to messages with correct threading |
identity.verify |
Supports IFP-5 message signing and verification |
capabilities.get |
Returns capability information (this protocol) |
ping |
Responds to connectivity tests |
Additional capabilities MAY be defined by agents. Capability names SHOULD use dot notation to indicate category (e.g., calendar.availability, doc.summarize, translate.text).
Capabilities may be conditional on context:
{
"name": "calendar.availability",
"description": "Share calendar availability windows",
"conditions": {
"min_disclosure": "professional",
"min_auth_level": 1
}
}
The conditions object describes when the capability is available. Standard condition fields:
| Field | Type | Description |
|---|---|---|
min_disclosure |
string | Minimum disclosure tier required |
min_auth_level |
integer | Minimum IFP-5 authentication level required |
temperature |
string | Required conversation temperature (cool, warm, hot) |
Agents receiving a capability document SHOULD respect the stated conditions. Requesting a conditional capability without meeting its conditions SHOULD result in an error phase message explaining the mismatch.
A capability document is a JSON object listing an agent’s capabilities:
{
"ifp": 7,
"agent_id": "pete-agent",
"capabilities": [
{
"name": "gossip.exchange",
"version": "1",
"description": "Participate in IFP-3 gossip exchanges"
},
{
"name": "message.receive",
"description": "Accept IFP-4 structured messages"
},
{
"name": "identity.verify",
"description": "IFP-5 message signing (Ed25519)"
},
{
"name": "capabilities.get",
"description": "Return this capability document"
}
],
"ifp_support": [3, 4, 5, 6, 7],
"updated": "2026-03-04T12:00:00Z"
}
The ifp_support field lists the IFP numbers this agent implements. This allows quick compatibility checking before attempting communication.
IFP-7 supports two discovery methods. Both return the same logical information; they differ in transport and timing.
An agent MAY publish its capability document at the well-known HTTPS endpoint:
GET /.well-known/iface/capabilities
This returns the capability document as JSON with Content-Type: application/json.
This method is suitable for initial discovery before any conversation has started. It returns the agent’s base capabilities without context-dependent conditions.
Agents MAY exchange capabilities during the greeting phase of an IFP-3 conversation. This works over any transport (IFP-6 HTTPS, IFP-8 relay, or others).
An agent includes capability information in the greeting message body:
I’m Pete’s agent. I support IFP-3 gossip exchanges, IFP-5 signing (Ed25519), and can share calendar availability at the professional disclosure tier.
For machine-processable capability exchange, the agent MAY include a capability document as a body part in the IFP-4 message:
"body": {
"text": "I'm Pete's agent. Here are my capabilities...",
"parts": [
{
"content_type": "application/json",
"name": "capabilities",
"content": {
"ifp": 7,
"capabilities": [ ... ]
}
}
]
}
This method is preferred when:
| Situation | Recommended method |
|---|---|
| First contact, both have HTTPS endpoints | Endpoint discovery, then greeting exchange |
| Communicating via relay (IFP-8) | Message-phase discovery in greeting |
| Context-dependent capabilities | Message-phase discovery |
| Automated compatibility checking | Endpoint discovery |
Agents MAY use both methods. The endpoint document provides a baseline; the greeting exchange can refine it based on context.
Capability documents include an updated timestamp. Agents SHOULD cache capability documents and refresh them periodically or when a conversation suggests capabilities have changed.
Individual capabilities include an optional version field. When a capability’s behavior changes, its version SHOULD be incremented.
ifp_support field provides a quick way to check protocol compatibility without examining individual capabilities.The capability discovery concept was outlined in a conversation between Peter Kaminski and ChatGPT in February 2026 (archived in the inter-face-bootstrap repository). The dual discovery model (static endpoint + message-phase negotiation) was developed during plan review with Claude (Opus 4.6) on 2026-03-04.
This is IFP-7, Draft status. The standard capability set will grow as implementations discover what agents need to advertise.