Agent Client Protocol (ACP)
agentclientprotocol.com
agentclientprotocol.com
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, and this only helps to make costs of switching between offerings even smaller.
I welcome them openly collaborating.
This is the top rated discussion on Github though: https://github.com/zed-industries/zed/discussions/26770
Like, I agree that that’s the thing I want most out of Zed right now, but not enough to do it myself.
Yes, Zed's startup time is way better, and it definitely feels snappier. But when I work on code, I need to jump around the code. I want the debugger to show me the current line in the file, annotating the value of every variable right in the source. I want to jump to property usages. I want to automatically rename a function everywhere intelligently, not using search-replace. I want to get completion for my database tables, and browse them from the IDE. And lots more.
I use zed with the inbuilt terminal, additional terminals + tools like pgcli and docker. I would feel trapped/impotent using an IDE, esp combined with the lack of snappiness a java app gives you.
Maybe it’s just a difference in working style. I would feel exhausted by having to learn and maintain a bunch of tools instead of just one, sprinkled with occasional anxiety if there is a better or upstart competing tool that I should be using.
I do use VSCode too, but mostly for quick scripting or non-programming projects. and even then i installed a bunch of extensions to make it more like Pycharm.
But you have this with any modern language that have LSP and debugger, no? Zed,VS Code, neovim - pretty much any modern editor have those features either out of the box or via a plugin.
It's almost like you can get that experience with other editors too, not just IDEs :) I'm using vim/neovim and have the same stuff I see others do with IDEs, but I can definitely see why a bunch of people use IDEs anyways, I'm not blind got the fact that other more barebones editors need a bit more fiddling to get to your liking.
And this will pile up the bloat stack, similar to js libraries, because new problems will rise from the wrong solutions, requiring even more wrong solutions to be incorporated in the stack.
The question doesn't even make sense, there is no overlap between LSP and ACP
Edit: Ok elaboration for the well intended. There is a HUGE overlap of LSP and ACP. LSP solves the problem of "oh we have many IDEs and many language integration plugins, we have an NxM problem, let's make it a N+M". ACP goes to do exactly that but for agents (which is an implementation detail), which means they could very well piggy back on top of LSP
I ask AI to write a feature (or fix a bug, or do a refactoring) and then I read the commit. If the commit is not to my liking, I "git reset --hard", improve my prompt and ask the AI to do the task again.
I call this "prompt coding":
https://www.gibney.org/prompt_coding
This way, there is no interaction between my coding environment and the AI at all. Just like working with a human developer does not involve them doing anything in my editor.
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.
The new models are much better at reading the codebase first, and sticking to "use the APIs / libraries already included". Also, for new libraries there's context7 that brings in up-to-date docs. Again, newer models know how to use it (even gpt5-mini works fine with it).
I've had much more success with things under 20k LOC but that isn't the stuff that I really need any assistance with.
The real issues I'm struggling with are more subtle, like unnecessary code duplication, code that seems useful but is never called, doing the right work but in the wrong place, security issues, performance issues, not implementing the prompt correctly when it's not straight forward, implementing the prompt verbatim when a closer inspection of the libraries and technologies used reveals a much better way, etc. Mostly things you will catch in code review if you really pay attention. But whether that's faster than doing the task yourself greatly depends on the task at hand
The famous "It compiles on my machine." Is that where engineering is going? Spending $billions to get the same result as the laziest developer ever?
That obviously does not mean that it's good software. That's why the rest of my comment exists. But "AI is hallucinating libraries/APIs" is something that can be trivially solved with good software practices from the 00s, and that the AI can resolve by itself using those techniques. It's annoying for autocomplete AI, but for agents it's a non-issue
We used Claude Code the other day to add a new record type to an API and it was mostly right. CC decided (for some weird reason) to use a slightly different return shape on a list endpoint than the entire rest of the API. It changed two field names (count/items became total_count/data). This divergence was missed until the code was released because it 'worked' and had full tests and everything. But when the standard client lib code was used to access the API it failed on the list endpoint. Didn't take long to discover the issue. Luckily, it was a new feature so nothing broke, but it was a very clear reminder that you have to be very thorough when reviewing coding agent PRs.
FWIW, I use CC frequently and have mostly positive things to say about it as a tool.
> with popular languages
Don't know, don't care. I write C++ code and that's all I need. JS and React can die a painful death for all I care as they have injected the worst practices across all the CS field. As for Python, I don't need help with that thanks to uv, but that's another story.
there is a learning curve, it reminds me of learning to use Google a long time ago
Agents use multiple models, can interact with the environment, and take many steps. You can get them to reflect on what they have done and what they need to do to continue, without intervention. One of the more important things they can do is understand their environment, the libraries and versions in use, fetch or read the docs, and then base their edits on those. Much of the hallucinating SDKs can be removed with this, and with running compile to validate, they get even better.
Models typically operate in a turn-by-turn basis with only the context and messages the user provides.
You're never going to get all, you don't have all today. Humans make mistakes too and have to run programs to discover their errors
Anecdotes are not facts, they are personal experiences, which we know are not equal and often come with biases
My Python work has to be told we are using uv, and sometimes that I am on a mac. This is not that different to what you would have to tell another programmer, not familiar with you tools.
And don't respond with a childish "skill issue lol" like it's Twitter. What specific skill do you think people are lacking?
I have extreme intolerance to boredom. I can't do the same job twice. Some people don't care.
This pain has caused me to become incredibly effective with LLMs because I'm always looking for an easier way to do anything.
If you keep hammering away at a problem - i.e. how to code with LLMs - you tend to become dramatically better at other people who don't do that.
LLMs only have so much context available, so larger projects are harder to get good results in.
Some tools (eg a fast compiler) are very useful to agents to get good feedback. If you don't have a compiler, you'll get hallucinations corrected more slowly.
Some people have schedules that facilitate long uninterrupted periods, so they see an agent work for twenty minutes on a task and think "well I could've done that in 10-30 minutes, so where's the gain?". And those people haven't understood that they could be running many agents in parallel (I don't blame people for not realizing this, no one I talk to is doing this at work).
People also don't realize they could have the agent working while they're asleep/eating lunch/in a meeting. This is why, in my experience, managers find agents more transformative than ICs do. We're in more meetings, with fewer uninterrupted periods.
People have an expectation that the agent will always one-shot the implementation, and don't appreciate it when the agent gets them 80% of the way there. Or that, it's basically free to try again if the agent went completely off the rails.
A lot of people don't understand that agents are a step beyond just an LLM, so their attempts last year have colored their expectations.
Some people are less willing to attempt to work with the agent to make it better at producing good output. They don't know how to do it. Your agent got logging wrong? Okay, tell it to read an example of good logging and to write a rule that will get it correct.
Maybe it's because the libraries I use are made from small files which easily fit into the context window.
Prompt / context engineering is still an underrated and underutilized activity (imo)
AI is no more capable of reliably one shotting solutions that you are.
Most of the time I don't bother reprompting it either. If it doesn't understand the first time then I'm better off making the change myself, rather than sink time into a cycle of reprompting and rejection.
On the other hand, if it understands what I want the first time I have more confidence that it's on the same wavelength as me.
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.
As you suggest, I've had a moderately successful time trying to get AI to write its own Sublime Text plugins so our favorite editor doesn't get left behind, so might be cool to try with this too?
Currently, my environment uses Claude Code on bare metal, and my application runs in a container, and the agent can do "docker compose exec backend" without any restrictions (YOLO).
My biggest obstacles to adopting workflows with git worktree are the need to share the database engine (local resource constrains) and the initial migration time. Offloading to cloud might be interesting for that.
https://github.com/zed-industries/zed/blob/main/crates%2Fage...
https://www.npmjs.com/package/@zed-industries/claude-code-ac...
Even though that doesn't seem to be mentioned on the site yet.
https://lfaidata.foundation/communityblog/2025/08/29/acp-joi...
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?
You need to define an interface for Ai to click buttons? Or to create keyboard macros that simulate clicking buttons? We are all doomed!
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 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.
The IDE is in-between because it asks the user for confirmation before doing anything, if that's what you are asking. It's not adding any indirection or something, this is just how coding agents talk to the IDE already, all this does is standardize the language they speak which would be a win for everybody.
It's like the Jupyter protocol, from which people do derive utility.
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 seminal RFC specs without independently considering the substance.
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. Once the space matures and stabilizes, that’s when standardization will make more sense. Right now, it feels too early.
One great reason is to avoid M*N problem: https://matklad.github.io/2022/04/25/why-lsp.html
I actually prefer something like opencode which is one TUI to rule them all (albeit still lacking in some area), it also provides an an SDK that abstracts away the underlying model.
Helix has been my favorite editor ever since I started using it, but the lack of integrated AI features has been becoming more of a deal-breaker for me lately. Though, I can see why the maintainers are hesitant to build for it, because there hasn't been a standardized protocol. I hope ACP changes that.
Are people who assert that JSON-RPC is "heavy" writing code we all rely on?