{
  "video": {
    "id": "YkNulwcc5jk",
    "title": "ACP: The Universal Remote Control for AI Agents — Alex Hancock, Block",
    "duration": 661,
    "upload_date": null,
    "channel": "AI Engineer",
    "source": "AI Engineer"
  },
  "analysis": {
    "video_id": "YkNulwcc5jk",
    "title": "ACP: The Universal Remote Control for AI Agents — Alex Hancock, Block",
    "one_liner": "Block's Alex Hancock argues that MCP standardised agents reaching out to tools but nothing standardises client software telling agents what to do — and pitches ACP (the Agent Client Protocol, from the Zed and JetBrains folks) plus a new remote HTTP/websocket transport as that missing layer.",
    "summary": "Hancock, a Goose maintainer and MCP Rust SDK maintainer at Block, says harnesses today have custom, bespoke interfaces — in the worst case exactly one client app can drive a given harness — which he likens to needing a specific browser and protocol per website. MCP solved the agent-goes-out-and-does-things half of the problem, but there is no standard for client software to send tasks, get results and receive updates. ACP, originally proposed by Zed and JetBrains so a single editor client could drive any harness, is his proposed answer: JSON-RPC, sessions, tool-call notifications, permission requests, and underscore-prefixed custom methods so real usage can be promoted onto the standards track. He demos two different clients (Zed and a Poolside AI terminal client) driving the same Goose agent over stdio, then a client he live-coded the night before talking to Goose over the newly specified HTTP/websocket remote transport.",
    "key_points": [
      "The gap he names: 'we don't yet have a good solution or a standard for client software to tell agents what to do' — giving it tasks, telling it what to work on, and getting updates back.",
      "MCP's power is not its design but its ubiquity — thousands or tens of thousands of servers that every agent can connect to; standards create ecosystems and markets.",
      "ACP came from the editor companies: Zed and JetBrains teamed up so they could write one high-quality client implementation (Zed, IntelliJ) and control any harness with it — sending tasks, getting results, seeing which files are edited. The Goose team thinks it is neutral enough to go far beyond editors.",
      "ACP design: capability-negotiated connections, then sessions; user messages in; agent replies with text, images or audio; tool-call notifications with metadata; permission requests so the client can ask the user 'should I do this tool call, yes or no?'. Transport-level it's plain JSON-RPC.",
      "Extensibility convention: custom methods are prefixed with an underscore, so Codex, Goose and others can each add their own — then the community can see what's converging and promote it into the protocol itself, shaping the standard by usage.",
      "Demo 1 (stdio, local): typing 'tell me about this project' into Zed and into a Poolside AI terminal client, both getting the same streamed text and tool-call display from the same Goose agent via Goose's ACP interface — one harness implementation, any client.",
      "Remote was missing, so the Goose team specified an HTTP transport with a websocket upgrade — same messages, same protocol semantics, new transport, 'just landing now'. Demo 2 was a client he live-coded the night before, sending Goose instructions over the network with the same library.",
      "The four-component agentic stack — client, harness (the tool-calling loop), tools (usually MCP), model — can all be relocated independently once each layer has a remote transport story: harness on another machine, only the model remote, only the tools remote, etc.",
      "Predicted payoff: personal clients orchestrating your agents exactly how you want, domain- or company-specific and white-label clients, and rising client quality because 'users can vote with their feet' in a real marketplace.",
      "Context on the speaker: Goose started as an internal Block project, was open sourced and donated to the Linux Foundation; he opened by joking that MCP clients lack task support not because maintainers are smart but because he's lazy."
    ],
    "takeaways": [
      "If you build a harness, expose an ACP interface rather than a bespoke one — that's the single implementation that lets every client (editor, desktop, mobile, terminal, headless) drive it.",
      "If you build client software, you no longer need a per-harness integration; write one ACP client and point it at any conforming agent.",
      "Use the underscore-prefixed custom-method escape hatch when the vanilla protocol falls short, but treat those methods as candidates for standardisation rather than permanent private forks.",
      "Design your stack so client, harness, tools and model are separately relocatable — with ACP's new HTTP/websocket transport plus MCP remote transports and remote model endpoints, switching a component between local and remote should be a config change, not a rewrite.",
      "Get started via the Agent Client Protocol site, which lists existing clients and agent servers across editors, desktop, mobile and terminal."
    ],
    "topics": [
      "agents",
      "protocols",
      "acp",
      "mcp",
      "interoperability",
      "open-source",
      "developer-tools",
      "remote-transports"
    ],
    "tools": [
      "ACP (Agent Client Protocol)",
      "MCP (Model Context Protocol)",
      "Goose",
      "Block",
      "Cash App",
      "Square",
      "Linux Foundation",
      "Zed",
      "JetBrains",
      "IntelliJ",
      "Poolside AI",
      "Codex",
      "JSON-RPC",
      "Rust SDK for MCP"
    ],
    "quotes": [
      {
        "text": "the most powerful thing about MCP is not anything about MCP itself, but it's that everyone uses MCP.",
        "at": "02:46",
        "url": "https://www.youtube.com/watch?v=YkNulwcc5jk&t=166s"
      },
      {
        "text": "I would say that we don't yet have a good solution or a standard for client software to tell agents what to do.",
        "at": "03:02",
        "url": "https://www.youtube.com/watch?v=YkNulwcc5jk&t=182s"
      },
      {
        "text": "You wouldn't have something like the open web if that were the reality with browsers. And so I think we can do better.",
        "at": "02:14",
        "url": "https://www.youtube.com/watch?v=YkNulwcc5jk&t=134s"
      },
      {
        "text": "aligning on standards and making sure that they have good transport stories is what's going to let us move all the pieces of this agentic stack around.",
        "at": "08:34",
        "url": "https://www.youtube.com/watch?v=YkNulwcc5jk&t=514s"
      }
    ],
    "words": 2358
  },
  "summary_url": "/#YkNulwcc5jk",
  "transcript": {
    "html": "/transcripts/YkNulwcc5jk.html",
    "txt": "/transcripts/YkNulwcc5jk.txt",
    "vtt": "/transcripts/YkNulwcc5jk.vtt"
  }
}