The Zed Agent is the built-in agentic harness integrated with the Zed editor — not to be confused with the agents Zed has the capability to use through the Agent Client Protocol.

The built in Zed Agent has several fundamentally more advanced features than any other agent. It allows you to stay more involved in the process of writing, reading, and reviewing agent decisions and code changes without slowing your agent down, thus reversing the incentive toward vibe coding most other agents have. However, it is missing many other common features, since most of its advantages come from fundamental algorithms and data structures, not feature improvements.

To configure use of Synthetic with Zed, you can configure it as an OpenAI API Compatible Provider (instructions) using the information from the Synthetic developer docs. You’ll then have to set your API Key either in the agent sidebar > three dots > Settings > Synthetic > API key, or as an environment variable. (The former is recommended, so you don’t run into strange env issues).

• Pros:
  • CRDT based collaborative editing with the agent means that you can: edit files at the same time it edits them, or before you’ve accepted/rejected proposed changes from the agent; edit a file while the agent is in the process of editing it to propose changes; see the agent’s proposed changes in-line in the actual buffer you’d use to edit the file, instead of in a separate interface; and accept and reject proposed changes by hunk without confusing the model.
  • Multibuffer support means that when you look at the unified (live updating) view of all of your agent’s proposed changes as it makes them, you can actually edit that collected buffer.
  • Zed DeltaDB also allows agent suggested edits to not have to be accepted or rejected before it can move on to the next turn of reading source code and editing, meaning that you are not forced to accept all changes in one diff just to see where the agent is going, allowing you to let the agent build up a “stack” of changes for a complete feature on autopilot, without actually finally accepting those edits; and allowing the agent to iteratively refine proposed changes by writing the change, then looking at the resulting file with its changes in it — although you haven’t permanently accepted them yet — seeing problems, and iterating again.
  • Agent proposed edits are actually in the file, DeltaDB just records the information needed to perfectly revert those changes at the text edit operation level if you reject the changes, meaning that LSP diagnostics, compilation, benchmarks, test suites, fuzzing and son on can be run on an agent’s proposed changes all before accepting the agent’s changes. In fact, the Zed system prompt encourages the agent to run its LSP diagnostic tool on its edits after making them before they are accepted, feeding into the iterative process.
  • Zed uses a custom “intent to edit file with goal” tool call, and then runs a separate request with the same chat history and model to actually generate the code, and live-generates the diff from the agent’s search and replacement code, so that you can see the agent moving around and editing the file in real time, token-by-token.
  • Zed allows you to “follow” agents, so you can watch which files they’re currently reading, searching in, or editing.

• Cons: In-file live diff generation is laggy. The Zed Agent has subagents, but they’re forced to use the same model as the parent thread. The Zed Agent doesn’t currently have a todo list tool (although that is on the HEAD branch). It also doesn’t have Claude Code style templated slash commands or Agent Skills (although this feature is coming soon). Additionally, the “intent to edit” system means you’ll use 2x the input tokens and 2x the requests for edits.