Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Agent Client Protocol (ACP)

agentclientprotocol.com

Post reply on HN
Print view View original

41–50 of 104 posts

Re: Agent Client Protocol (ACP)

#41

Post by jmull »

baggiponte wrote: post #11
fijiaarone wrote: post #6

The protocol for interacting with code is files and text. You need to define an interface for Ai to click buttons? Or to create keyboard macros that simulate clicking buttons? We are all doomed!

I’m afraid you missed a bit the mark :( This is the equivalent of LSP but for coding agents. So any editor does not have to rebuild an interface to support each and every new one.

The question is why…

The purpose of an ide is to pull together the tools a developer needs to develop software… first, reading/navigating and writing code, next running and debugging code, then (potentially) a variety of other tools: profilers, doc browsers, etc… all into a unified UI.

But coding agents seem to already be able to use the command line and mcp quite well to do this.

So why mediate using these tools through an IDE (over a new protocol) rather than just using the tools directly through the command line or mcp? It’s two extra levels of indirection, so there needs to be a really good reason to do it.

There may very well be some actual problem this solves, but I don’t know what it is.

Re: Agent Client Protocol (ACP)

#42

Post by triyambakam »

hari-trata wrote: post #26

I don’t see why we need so many protocols. In such a greenfield tech, many are eager to define rules. There’s already a protocol called AG-UI that does the similar thing, but even its purpose isn’t entirely clear to me. Rather than rushing to create standards, I think the focus should be on building practical implementations, AI-centric UI components that actually help developers design more AI-friendly interfaces. O…

I do agree it seems like too many protocols. I wonder why this couldn't be mcp. But regarding ag-ui in its name it's for UI - streaming from a backend agent to a client frontend. I actually have been working a lot with it this week.

Re: Agent Client Protocol (ACP)

#43

Post by WD-42 »

cube2222 wrote: post #4

Fingers crossed for this - it seems like Zed is kinda “going back to the roots” (of working on collaboration) and leaving this in place to disrupt the agentic IDE category (and make themselves not have to spend time on competing in it). Curious to see how adoption among cli agents will go (it’s nice to see Gemini cli already in). The level of competition in the LLM and coding assistant market is always nice to see, a…

Seriously. I really hope this puts an end to the crappy VS Code forks so Zed can start getting the credit it’s due. These ai editors have really sucked all the air out of the room.

Re: Agent Client Protocol (ACP)

#44

Post by willm »

quotemstr wrote: post #36
acomagu wrote: post #28

I would love it, but please don't add JSON-RPC to the world... It's too heavy for editor.

Anyone else noticing an uptick in confidently stated nonsense on HN? To write that JSON-RPC is "too heavy for editor", you have to not only misunderstand the cost of JSON encoding (trivial) but also the frequency of editor-tool interaction (seldom) and volume of data transferred (negligible). In addition, you have to look at LSP, MCP, and other JSON-y protocols and say "yep. There's where the UI latency is. Got it.".…

Harsh. But fair. JSON-RPC is one of the leanest protocols out there.

Re: Agent Client Protocol (ACP)

#45

Post by derefr »

schwentkerr wrote: post #39
darkbatman wrote: post #20

With already https://agentcommunicationprotocol.dev (ACP) same name seems confusing now. even though differences are there in both.

IBM announced in March 2025 its Agent Communication Protocol (ACP) but is now abandoning the ACP name and merging ACP efforts with Google’s Agent2Agent (A2A) protocol at the Linux Foundation. The ACP team is winding down as the industry backs A2A for open, community-driven AI agent interoperability under Linux Foundation governance. This move aims to unify protocols and avoid fragmentation in AI agent standards. http…

That seems odd. Even with an A2A protocol, don’t you still need to standardize a client “surface” or “API” or whatever, so agents can describe IDE actions they want to trigger in the expected terms over that protocol?

Or is A2A like USB, where it acts as both a registry of, and “standardized standardization process” for, suites of concrete message types for each use-case?

Like, yeah, when a "client" drives an "agent", that's no different than what any generic "agent" would be doing to drive an "agent"; an IDE or what-have-you can just act as the "parent agent" in that context.

But when an "agent" is driving a "client", that's all about the "agent" understanding that the "client" isn't just some generic token-driven inference process, but an actual bundle of algorithms that does certain concrete things, and has to be spoken to a certain way to get it to do those concrete things.

I had assumed that IBM's older ACP was in large part concerned with formalizing that side of interoperation. Am I wrong?

Re: Agent Client Protocol (ACP)

#46

Post by ivanjermakov »

hari-trata wrote: post #26

I don’t see why we need so many protocols. In such a greenfield tech, many are eager to define rules. There’s already a protocol called AG-UI that does the similar thing, but even its purpose isn’t entirely clear to me. Rather than rushing to create standards, I think the focus should be on building practical implementations, AI-centric UI components that actually help developers design more AI-friendly interfaces. O…

> I don’t see why we need so many protocols

One great reason is to avoid M*N problem: https://matklad.github.io/2022/04/25/why-lsp.html

Re: Agent Client Protocol (ACP)

#47

Post by PhilipRoman »

quotemstr wrote: post #29

I see they've also caught the RFC2119 bug. This "MUST", "SHALL", "MAY" thing is a linguistic blight on our standards landscape and should be eradicated. HTML5 is written without this unnecessary level of linguistic pretense and works fine. If your proposed spec is full of "SHALL", "MUST", and "MAY", I'm going to dock you ten points of credibility from the outset. It's a signal you've set out to imitate the vibes of s…

I don't know if your complaint is specifically about the capitalization, but I find these clear rules useful when interpreting specifications.

Re: Agent Client Protocol (ACP)

#48

Post by brulard »

mg wrote: post #19
Disposal8433 wrote: post #13

Earlier quoted context omitted.

> Nowadays, it is better to write prompts Very big doubt . AI can help for a few very specific tasks, but the hallucinations still happen, and making things up (especially APIs) is unacceptable.

Do others here encounter that problem? I never do. I can't remember the last time I saw a hallucination in a commit. Maybe it's because the libraries I use are made from small files which easily fit into the context window.

Same here, very low hallucination rate and it can pretty quickly correct itself (Claude Code). To force it to use recent versions of libraries instead of old ones, it's good to have it specifically required in CLAUDE.md and also having docs MCP (like context7) can help.

Re: Agent Client Protocol (ACP)

#49

Post by bsimpson »

awestroke wrote: post #22

Claude, come up with a protocol for communicating between AI agents and IDEs/editors. Create node, python and rust libraries. Create a website with a landing page

Honestly, I'm tempted to see if Gemini can write a Sublime Text plugin that implements this protocol.

Feels like a lot of mindshare has shifted towards VSCode, so that's where the tooling investment goes. I don't want to be forced off of subl because new tools stop supporting it - it's a great editor, and it's not sponsored by a massive company.

Re: Agent Client Protocol (ACP)

#50

Post by vlaaad »

I love this idea; I hope it gains traction. One thing that is not clear to me is file search vs unsaved files. It's common for agents to use, e.g., ripgrep to search the file system. But if the communication protocol includes read/write access to unsaved files, there is a desync in terms of accuracy.. rg can't search unsaved files.
Post reply on HN