Álvaro Ramírez

Thanks to ACP, we can now build agent-agnostic experiences by configuring our clients to route traffic to their respective agent. You get multiple agents powering a consistent and familiar experience.

Configuring different agents from agent-shell boils down which agent we want to run in the comms process. Here's an example of Gemini CLI vs Claude Code configuration:

(defun agent-shell-start-gemini-agent ()
  "Start an interactive Gemini CLI agent shell."
  (interactive)
  (agent-shell--start
   :new-session t
   :mode-line-name "Gemini"
   :buffer-name "Gemini"
   :shell-prompt "Gemini> "
   :shell-prompt-regexp "Gemini> "
   :needs-authentication t
   :authenticate-request-maker (lambda ()
                                 (acp-make-authenticate-request :method-id "gemini-api-key"))
   :client-maker (lambda ()
                   (acp-make-client :command "gemini"
                                    :command-params '("--experimental-acp")
                                    :environment-variables (list (format "GEMINI_API_KEY=%s" (agent-shell-google-key)))))))

(defun agent-shell-start-claude-code-agent ()
  "Start an interactive Claude Code agent shell."
  (interactive)
  (agent-shell--start
   :new-session t
   :mode-line-name "Claude Code"
   :buffer-name "Claude Code"
   :shell-prompt "Claude Code> "
   :shell-prompt-regexp "Claude Code> "
   :client-maker (lambda ()
                   (acp-make-client :command "claude-code-acp"
                                    :environment-variables (list (format "ANTHROPIC_API_KEY=%s" (agent-shell-anthropic-key)))))))

I've yet to try other agents. If you get another one running, I'd love to hear about it. Maybe submit a pull request?

While I now have an early ACP client available, I'm still fairly new to the protocol. I often inspect traffic in both directions to see what's going on. After staring at json for far too long, I figured I may as well build some tooling around acp.el to make my life easier, so I added a traffic buffer for that. From agent-shell, you can invoke it via M-x agent-shell-view-traffic.

Developing agent-shell against paid agents got expensive quickly. Not only expensive, but my edit-compile-run cycle also became boringly slow waiting for agents. While I knew I wanted some sort of fake agent to work against, I fought the urge to go down that route. Ok not really, I was lazy, but I did work out a good compromise. Remember that traffic buffer I showed ya? I can save that traffic to disk and then replay it later. This enabled me to run problematic sessions once and quickly replay multiple times to fix bugs. While re-playing has its quirks and limitations, it's done the job for now.

You can see a Claude Code session below, followed by its replayed counterpart via fake infrastructure.

Took quite a bit of work to get here. Having said that, it's only a start. I myself need to get more familiar with agent usage and evolve the package UX however it feels most natural within its new habitat. Lately, I've been experimenting with a quick diff buffer, driven by n/p keys, shown along with the permission dialog to apply changes.

While I've implemented enough parts of the Agent Client Protocol Schema to make the package useful, it's hardly complete. I've yet to fully familiarize myself with all the features.

Both of my newest Emacs packages, agent-shell and acp.el, are now available on GitHub. As an end-user, go straight to agent-shell. If you're a package author and would like to build a different ACP experience, then give acp.el a try. Both packages are brand new and may have rough edges. Be sure to file bugs or feature requests as needed.

I've been heads down working on these packages for some time. If you're using cloud LLM services, you're likely already paying for tokens. If you find my work useful, consider routing some of those coins to fund the work. Maybe my tools make you more productive at work? Get your employer to fund the work. These packages take time and effort, but also cost me money. Help fund the work.