Spec 15: Interoperability
DWS Spec 15: Interoperability
Digital Worker Standard — DWS Specification
Version: 1.0 Tier: 4 — Governance Status: Release Candidate Dependencies: Spec 1 (Worker Identity), Spec 3 (Skill Specification), Spec 7 (Coordination Protocol)
1. Overview
This specification defines how DWS workers interact with external protocols and systems. DWS is the governance layer; it does not replace the tool access layer (MCP), the inter-agent communication layer (A2A), or the identity layer (IETF AIMS, W3C DID). It complements them.
This spec formalises the boundaries between DWS and each external protocol, defines the mapping points, and specifies how a DWS runtime should integrate with these systems.
2. Protocol Stack
DWS operates within a layered protocol stack:
| Layer | Standard | What it does | DWS’s relationship |
|---|---|---|---|
| Tool access | MCP (Model Context Protocol) | Connects workers to external tools and data sources. | DWS skills reference MCP tools by URI. The runtime dispatches tool calls via MCP. |
| Inter-worker comms | A2A (Agent-to-Agent Protocol) | Enables communication across organisational boundaries. | DWS defines internal coordination (Spec 7). A2A handles external coordination. |
| Identity | IETF AIMS / W3C DID / SPIFFE | Authenticates and authorises workers at runtime. | DWS defines identity (Spec 1). The runtime maps to AIMS/DID for cross-boundary auth. |
| Observability | OpenTelemetry | Exports telemetry to monitoring infrastructure. | DWS events (Spec 11) are an OTel superset. The runtime exports via OTel. |
| Events | CloudEvents | Standard event envelope for enterprise infrastructure. | DWS events can be wrapped in CloudEvents envelopes (Spec 11, Section 9). |
| Governance | DWS | Defines what a worker is, what it can do, and how it is held accountable. | This is DWS’s unique layer. |
3. MCP Integration
3.1 Tool Binding
DWS skills (Spec 3) reference MCP tools by URI in their execution steps:
{ "name": "fetch_data", "type": "tool_call", "tool_uri": "mcp://salesforce/query", "input_mapping": { "query": "$.input.soql_query" }}The runtime resolves the MCP tool URI to a running MCP server. Connection details (URL, auth) are runtime configuration, not part of the job spec definition.
3.2 MCP Server Discovery
Runtimes SHOULD support MCP server discovery via:
- Static configuration (server list in runtime config)
- DNS-based discovery (SRV records)
- Registry-based discovery (MCP registry)
3.3 Guardrails as MCP Middleware
DWS guardrails (Spec 1, Section 2.5) can wrap MCP tool calls. When a guardrail references a tool_ref validator, the runtime evaluates the guardrail before dispatching the MCP call:
- Worker requests tool call.
- Runtime evaluates
inputguardrails for the tool. - If guardrails pass, runtime dispatches to MCP server.
- MCP server returns result.
- Runtime evaluates
outputguardrails on the result. - If guardrails pass, result is returned to the worker.
4. A2A Integration
4.1 Worker Descriptor to Agent Card Mapping
When a DWS worker needs to participate in an A2A ecosystem (cross-organisational coordination), its Worker Descriptor maps to an A2A Agent Card:
| DWS Worker Descriptor | A2A Agent Card |
|---|---|
identity.name | name |
identity.description | description |
identity.domain | capabilities[].name |
skills[*].capability.tags | capabilities[].tags |
artifacts.produces | outputModes |
artifacts.consumes | inputModes |
| Computed from skills | supportedProtocols |
4.2 External vs Internal Coordination
| Aspect | Internal (DWS Spec 7) | External (A2A) |
|---|---|---|
| Workers are defined | In the same job spec or workspace | In separate organisations/systems |
| Trust model | Shared trust boundary | Opaque agents, no shared trust |
| Context sharing | Coordination-scoped (Spec 7) | Message-based only |
| Contracts | Worker-to-worker contracts | A2A task negotiation |
| Identity | DWS identity (Spec 1) | A2A Agent Cards |
DWS coordination (Spec 7) governs workers within a trust boundary. A2A governs communication across trust boundaries. When a DWS worker needs to communicate with an external system, the runtime uses A2A as the transport layer and applies DWS’s authority and guardrail checks before sending and after receiving.
5. Identity Federation
5.1 W3C DID Mapping
For cross-organisational scenarios (marketplace, federated coordination), DWS workers can be assigned W3C Decentralized Identifiers:
did:dws:{org-id}:{worker-name}:{version}The DID Document contains:
- Worker Descriptor metadata (name, role, domain, capabilities)
- Verification methods for authenticating the worker’s identity
- Service endpoints for reaching the worker
5.2 IETF AIMS Mapping
DWS authority levels map to AIMS authorisation scopes:
| DWS Authority Level | AIMS Scope |
|---|---|
escalate-only | Read-only scopes. No write permissions. |
restricted | Enumerated operation scopes. |
supervised | Broad scopes with audit logging. |
autonomous | Full scopes within declared domain. |
The runtime issues Transaction Tokens (TxTokens) that carry the worker’s authority level as a claim. Downstream services can validate the token to enforce DWS authority at the protocol level.
5.3 SPIFFE for Runtime Identity
For runtime-to-runtime communication, SPIFFE IDs provide workload identity:
spiffe://org.example.com/dws/contract-reviewer/v1.2.0The runtime maps the DWS worker identity to a SPIFFE ID and obtains short-lived certificates (SVIDs) from a SPIRE server. This eliminates static credentials for inter-runtime communication.
6. Compile Targets
A job spec definition is portable across runtimes. The dws compile command translates a DWS definition into a runtime-specific configuration.
6.1 Supported Targets
| Target | Command | Output |
|---|---|---|
| Claude Managed Agents | dws compile --target managed-agents | Anthropic agent config, session configs, memory store setup |
| Claude Code / Agent SDK | dws compile --target claude-agent-sdk | Agent SDK configuration files |
| CrewAI | dws compile --target crewai | CrewAI agent and task definitions |
| AWS Bedrock Agents | dws compile --target bedrock | Bedrock agent configuration |
| Docker (self-hosted) | dws compile --target docker | Dockerfile, docker-compose, runtime config |
6.2 Mapping to Claude Managed Agents
| DWS Concept | Managed Agents API |
|---|---|
| Worker Descriptor | POST /v1/agents (name, model, system prompt, tools) |
| Skills | skills array on agent config |
| Knowledge entries | Memory stores (/v1/memory_stores) |
| Authority levels | Permission policies (always_allow / always_ask) |
| Workflow phases | Sequences of outcome-driven sessions |
| Verification gates | Outcome rubrics |
| Worker-to-worker coordination | callable_agents |
| MCP tools | mcp_servers array on agent config |
7. References
- MCP (Model Context Protocol) — Tool access layer.
- A2A (Agent-to-Agent Protocol) — Cross-organisational agent communication.
- IETF AIMS Framework (draft-klrc-aiagent-auth) — Agent identity and authorisation.
- W3C Decentralized Identifiers v1.1 — Federated identity for workers.
- SPIFFE/SPIRE — Runtime workload identity.
- Claude Managed Agents — Anthropic’s managed agent runtime.
- Spec 1: Worker Identity — Identity and authority model.
- Spec 3: Skill Specification — MCP tool references in skills.
- Spec 7: Coordination Protocol — Internal coordination model.
- Spec 11: Events & Telemetry — OTel and CloudEvents compatibility.