{"slug": "computer-use-agents-and-mcp-what-agent-to-agent-commerce-reveals-about-protocol", "title": "Computer-Use Agents and MCP: What Agent-to-Agent Commerce Reveals About Protocol Boundaries", "summary": "A developer's analysis of computer-use agents in production argues that MCP (Model Context Protocol) occupies a narrow slice of the stack between the model's reasoning loop and tool execution, and that agent-to-agent commerce exposes protocol boundaries MCP does not address out of the box. The writeup details harness state-management trade-offs across in-memory, external store, event log, and hybrid approaches, and recommends layering idempotency keys, async job polling, and distributed tracing with OpenTelemetry onto MCP for multi-agent chains.", "body_md": "Computer-use agents are moving from demos to production, and the plumbing is more interesting than the headlines suggest. When an agent needs to call another agent or interact with external tools, the protocol layer matters. MCP (Model Context Protocol) is one answer, but it sits in a specific slice of the stack between the model's reasoning loop and the tool execution boundary.\n\nThe conversation between Chris Benson and Demetrios Brinkmann on Practical AI surfaces the architectural choices that matter when agents start talking to each other, especially around commerce, enterprise deployment, and failure recovery.\n\nAn agent harness is the runtime wrapper that sits between the LLM and the outside world. It handles:\n\nThe harness is not the model. It's the orchestration layer that decides when to call the model, what context to pass, and how to handle the model's output (text, tool call, or error).\n\n| Approach | State Location | Failure Recovery | Multi-Agent Coordination | \n|---|---|---|---|\n| In-memory | Harness process | Lost on crash | Requires external sync | \n| External store (Redis, Postgres) | Centralized DB | Survives restarts | Shared state possible | \n| Event log (Kafka, NATS) | Append-only stream | Replay from offset | Natural audit trail | \n| Hybrid (local + remote) | Both | Complex reconciliation | Best observability | \n\nMost production harnesses use a hybrid model: ephemeral state in-memory for speed, durable checkpoints in Postgres or S3 for recovery.\n\nMCP defines how agents discover and invoke tools across process boundaries. It's not a replacement for HTTP or gRPC. It's a schema layer on top that standardizes:\n\nWhen Agent A calls Agent B via MCP, the protocol handles:\n\nMCP servers expose a `/tools` endpoint that returns JSON schemas. This lets agents introspect capabilities at runtime instead of hardcoding API contracts.\n\n```\n{\n  \"tools\": [\n    {\n      \"name\": \"get_inventory\",\n      \"description\": \"Fetch current inventory levels\",\n      \"parameters\": {\n        \"type\": \"object\",\n        \"properties\": {\n          \"warehouse_id\": {\"type\": \"string\"},\n          \"sku\": {\"type\": \"string\"}\n        },\n        \"required\": [\"warehouse_id\"]\n      }\n    }\n  ]\n}\n```\n\nThe calling agent can pass this schema directly to the LLM's function-calling interface. The model generates a tool call, the harness validates it against the schema, and the MCP client sends it to the remote server.\n\nThis is cleaner than parsing OpenAPI specs or writing custom adapters for every API.\n\nWhen agents start paying each other for services, the protocol boundaries get real. Commerce introduces:\n\nMCP doesn't solve these problems out of the box. You need to layer on:\n\n`get_market_data(symbol=\"AAPL\")`\nIf step 3 times out, Agent A's harness retries with the same idempotency key. Agent B's gateway sees the duplicate and returns the cached result without re-executing.\n\nMCP works well for synchronous, short-lived tool calls. It struggles with:\n\nFor long-running work, you need an async pattern:\n\n`start_job(params)` and gets a job ID`get_job_status(job_id)` until complete`get_job_result(job_id)` to fetch output\nThis is clunky but works. Some teams use webhooks: Agent B calls back to Agent A when the job finishes. That requires Agent A to expose an MCP server of its own, creating a bidirectional dependency.\n\nWhen Agent A calls Agent B, which calls Agent C, you need distributed tracing. Each harness should:\n\nWithout this, debugging a failed agent chain is impossible. You see the final error but not which intermediate call failed or why.\n\n``` python\nimport uuid\nfrom opentelemetry import trace\n\ntracer = trace.get_tracer(__name__)\n\ndef call_mcp_tool(server_url, tool_name, params):\n    trace_id = str(uuid.uuid4())\n    with tracer.start_as_current_span(\"mcp_call\") as span:\n        span.set_attribute(\"mcp.server\", server_url)\n        span.set_attribute(\"mcp.tool\", tool_name)\n        span.set_attribute(\"trace.id\", trace_id)\n\n        headers = {\"X-Trace-ID\": trace_id}\n        response = requests.post(\n            f\"{server_url}/call\",\n            json={\"tool\": tool_name, \"params\": params},\n            headers=headers\n        )\n\n        span.set_attribute(\"http.status\", response.status_code)\n        return response.json()\n```\n\nEach MCP server should extract `X-Trace-ID` from incoming requests and include it in its own downstream calls.\n\nBringing computer-use agents into enterprise environments surfaces:\n\nThe harness is where you enforce these policies. Before executing a tool call, the harness checks:\n\nIf any check fails, the harness returns an error to the model instead of executing the tool.\n\nThe model generates tool calls. The harness decides whether to execute them. This separation is critical for safety.\n\nSome teams use a \"human-in-the-loop\" harness that pauses before executing high-risk tools (delete database, send email, transfer money). The harness sends a notification to Slack or PagerDuty and waits for approval.\n\nOther teams use a \"guardrail\" harness that runs a secondary model to validate tool calls. If the validator flags a call as risky, the harness rejects it and asks the primary model to try again.\n\nBoth patterns require the harness to maintain state across multiple model invocations. This is why in-memory state is fragile: if the harness crashes mid-approval, the context is lost.\n\n**Use MCP for agent-to-agent tool calls when:**\n\n**Avoid MCP when:**\n\nThe agent harness is where the real work happens. MCP is just the wire protocol. Invest in harness observability, state management, and failure recovery before you scale agent-to-agent interactions.", "url": "https://wpnews.pro/news/computer-use-agents-and-mcp-what-agent-to-agent-commerce-reveals-about-protocol", "canonical_source": "https://dev.to/mech_app_ai/computer-use-agents-and-mcp-what-agent-to-agent-commerce-reveals-about-protocol-boundaries-29b2", "published_at": "2026-10-11 00:07:08+00:00", "updated_at": "2026-10-11 00:17:40.267273+00:00", "lang": "en", "topics": ["ai-agents", "agent-protocols", "ai-tools", "mlops", "developer-tools"], "entities": ["Model Context Protocol", "MCP", "Chris Benson", "Demetrios Brinkmann", "Practical AI", "OpenTelemetry", "Redis", "Kafka"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/computer-use-agents-and-mcp-what-agent-to-agent-commerce-reveals-about-protocol", "markdown": "https://wpnews.pro/news/computer-use-agents-and-mcp-what-agent-to-agent-commerce-reveals-about-protocol.md", "text": "https://wpnews.pro/news/computer-use-agents-and-mcp-what-agent-to-agent-commerce-reveals-about-protocol.txt", "jsonld": "https://wpnews.pro/news/computer-use-agents-and-mcp-what-agent-to-agent-commerce-reveals-about-protocol.jsonld"}}