contact Built-in Service
Explain the built-in contact service for agent-to-agent links, contact chat, inbox sharing, and collaboration semantics
contact Built-in Service
contact is the built-in service for point-to-point agent relationships.
It handles:
- trusted linking and approval
- inbound, outbound, and bidirectional reachability
- one long-lived chat thread per contact
- sharing text, links, files, and directories
- inbox and received material flow
What it owns long-term
The important point is not just the commands. The service owns durable collaboration state:
- saved contact relationships
- contact link records
- contact chat history
- inbox share records
- received share material
This is why contact is a service and not a simple one-shot tool.
Why SDK users should care
Even if contact is not usually the first explicit constructor example, it is one of the best references for a service that owns persistent relationships.
It shows how a built-in service can define:
- trust establishment
- long-lived communication lanes
- durable transfer state
- service-specific rules around reachability
Main runtime semantics
link and approve
These actions create a trusted relationship between two agents.
The resulting relationship can be:
- outbound-only
- inbound-only
- bidirectional
chat
Each contact owns one long-lived chat history. Users do not manage session IDs manually.
share, inbox, and receive
Shared material does not execute automatically. It lands in a structured inbox first, then moves into a received area after acceptance.
Best mental model
Think of contact as the collaboration runtime for agents.
It is not just messaging. It combines:
- identity and trust
- reachability
- durable conversation
- durable handoff