Skip to content

Agent Architecture

Zed

Zed is a desktop editor host with three AI paths: the built-in Zed Agent, External Agents through ACP, and Terminal Threads that run CLI/TUI agents directly. Its MCP story depends on which path receives the tool server.

Source reviewed #19Checked 2026-07-06
Run type
Desktop
Adapter
mcp-only
Source
OSS · zed-industries/zed
Stars
★ 90k

Archive Context

This page is one host entry inside the full architecture archive and keeps multi-surface products visible instead of collapsing them into a single run type.

42 host archive
Host page
zed
Run cohort
Desktop: 9
Archive route
/agents

Host Surface Perspectives

The host is the primary architecture boundary. Each runnable surface below separates what the host owns from what agent-connector can safely install for Zed.

1 surface entry

Desktop

desktop
Host entry
A desktop app or standalone editor owns window state, sign-in, project indexing, embedded terminal behavior, and local product storage.
Host owns
The desktop host owns orchestration UI, model routing, approval UX, background jobs, and any cloud or app-store managed extension points.
Connector role
agent-connector can write documented workspace/global config and content files, but it does not replace the desktop runtime or UI shell. Current wired connector surfaces: MCP server, Skills, Memory, Action affordances.
Implementation consequence
Desktop surfaces need source-review separation because product pages often document capabilities while runtime state lives in app-managed storage. No visible host-native gap is currently tracked for this surface.

Verified Architecture

Source-checked on 2026-07-06. These notes are intentionally separate from the generated surface matrix below.

Sequence #19

Source pass

Current source review findings are kept as the first architecture section so readers can separate external evidence from the generated local coverage model.

  • Zed is an open-source high-performance editor, so its host row is a desktop editor surface rather than a terminal CLI.
  • The page models Zed as MCP/content/action capable without claiming a lifecycle hook bridge for the agent panel.
  • Task-backed actions are tracked as host-only affordances separate from MCP and memory.

Runtime boundary

The adapter target is the desktop Zed host. Zed owns editor panes, tool permissions, profiles, skills, instructions, and the choice between built-in agent, ACP external agent, and Terminal Thread execution.

  • Zed Agent is the built-in path with tools, profiles, skills, instructions, and MCP servers.
  • External Agents are ACP-integrated and may have their own capabilities.
  • Terminal Threads run a CLI or TUI agent directly in the editor terminal.

MCP registration

Zed's MCP docs are unusually explicit: Zed supports MCP tools and prompts, watches list_changed notifications, and can expose MCP to built-in or ACP paths depending on configuration. agent-connector must model the recipient path, not only the server entry.

  • Custom MCP servers are configured through `context_servers` settings.
  • MCP servers can also be packaged as Zed extensions.
  • External Agents may receive MCP through ACP forwarding or through their own native configuration.

Hook bridge

Zed is currently represented as MCP-only in the connector matrix. The editor has rich AI controls, but there is no current agent-connector hook bridge that intercepts Zed Agent lifecycle events through generated files.

  • Tool permission UI is host-owned and should not be documented as a connector hook.
  • ACP forwarding is a protocol bridge to another agent, not a Zed-native PreToolUse hook surface.

Content surfaces

Zed's study value is high because it separates instructions, skills, profiles, MCP, External Agents, and Terminal Threads. Those content surfaces should be shown as editor-native organization rather than forced into the CLI command/skill model.

  • Skills and instructions are native Zed Agent context surfaces.
  • Terminal Threads can inherit the downstream CLI agent's files, creating a layered-host example.

Marketplace and host-only affordances

Zed's host-only affordances include extension-packaged MCP servers, ACP external agents, profiles, native editor collaboration, and terminal-thread hosting. These make it a key desktop architecture case even though the connector coverage remains MCP-first.

  • The diagram should show two possible tool paths: Zed Agent MCP and external agent MCP.
  • Students should not treat Terminal Threads as proof that Zed itself implements the downstream agent's hooks.

Host-specific shape

Zed is a desktop editor host with MCP, skills, memory, and task-backed actions; hooks, prompt-command files, and subagent authoring are not confirmed for the agent panel.

  • Form factor: Desktop.
  • Native surfaces: MCP server, Skills, Memory, Action affordances.
  • Wired surfaces: MCP server, Skills, Memory, Action affordances.
  • Visible gaps: none.

Hooks

No user-installable lifecycle hook boundary is confirmed for this host.

MCP

The adapter writes this host's native MCP registration dialect, including its root key, scope, transport fields, and environment syntax.

Memory

Managed memory text is written into the rules or memory file this host actually reads, with ownership markers for reversible uninstall.

Marketplace and affordances

Current install is a direct native-file write path; any package artifact is manual unless a driver is added.

  • Runtime handlers: Action affordances.
  • User-visible affordances: Users see managed skills + actions + memory surfaces after install; runtime-only surfaces stay behind the host boundary..

Known Limits

  • Zed Agent, External Agents, and Terminal Threads must remain separate runtime paths.
  • MCP forwarding through ACP should not be counted as Zed-native hook support.
  • A downstream CLI's capabilities should not be promoted into Zed coverage without layer-specific evidence.

Architecture Diagram

Host-specific flow for the Desktop surface.

mcp-only
Host-owned architecture flowHost surfaceDesktopRuntimemcp-onlyNative artifactsMCP + content + memory + handlersConnector boundaryMCP clientUser surfaceskills + memory + actionsagent-connector writes only documented host artifacts; the host owns the agent loop.
  1. 1
    Entry point: Desktop

    Desktop or standalone editor app reads global/product storage plus workspace files before handing control to its embedded agent runtime.

  2. 2
    Connector package

    defineConnector package declares server, hooks, content, memory, and actions.

  3. 3
    Adapter module: zed

    mcp-only renderer at src/adapters/zed/index.ts.

  4. 4
    Native host artifacts

    Adapter writes MCP config + content files + memory/rules + actions through this host's native file, package, or marketplace surface.

  5. 5
    Runtime boundary

    host calls MCP tools through its client

  6. 6
    User-visible surface

    Users see managed skills + actions + memory surfaces after install; runtime-only surfaces stay behind the host boundary.

  7. 7
    Coverage ceiling

    4/4 native surfaces wired. No visible host-native gap in the current coverage matrix.

Component Diagram

Static parts of the Zed integration and which side owns each one.

Components and ownershipZed hosthostagent-connector packageconnectorzed adaptermcp-onlyNative artifactsartifactsRuntime bridgeruntimeUser-visible surfaceuser
  • Zed host

    Desktop surface owns the model loop, UI shell, config discovery, and native lifecycle for this integration.

  • agent-connector package

    Normalizes connector declarations into MCP, hook, memory, content, and action payloads before delegating to a host adapter.

  • zed adapter

    Implements the mcp-only translation layer in src/adapters/zed/index.ts.

  • Native artifacts

    Adapter writes MCP config + content files + memory/rules + actions through this host's native file, package, or marketplace surface.

  • Runtime bridge

    host calls MCP tools through its client

  • User-visible surface

    Users see managed skills + actions + memory surfaces after install; runtime-only surfaces stay behind the host boundary.

Runtime Sequence Flow

Message order from install to runtime for the Desktop surface.

User / projectagent-connectorzed adapterZedAgent runtimeCoverage matrix1. Choose host adapter2. Resolve connector declaration3. Render host-native shape4. Host loads artifacts5. Run through host boundary6. Expose remaining ceiling
  1. 1 · User / project
    Choose host adapter

    Install or update starts against Zed; the selected surface is Desktop.

  2. 2 · agent-connector
    Resolve connector declaration

    The package reads connector metadata and routes it to the zed adapter instead of exposing a generic host contract.

  3. 3 · zed adapter
    Render host-native shape

    Adapter writes MCP config + content files + memory/rules + actions through this host's native file, package, or marketplace surface.

  4. 4 · Zed
    Host loads artifacts

    host calls MCP tools through its client

  5. 5 · Agent runtime
    Run through host boundary

    Users see managed skills + actions + memory surfaces after install; runtime-only surfaces stay behind the host boundary.

  6. 6 · Coverage matrix
    Expose remaining ceiling

    4/4 native surfaces wired. No visible host-native gap in the current coverage matrix.

Architecture Archive

The same five study axes are rendered for every host: runtime shape, hooks, MCP, memory, and host-only affordances.

Host-specific shape

Zed is a desktop editor host with MCP, skills, memory, and task-backed actions; hooks, prompt-command files, and subagent authoring are not confirmed for the agent panel.

  • Form factor: Desktop.
  • Native surfaces: MCP server, Skills, Memory, Action affordances.
  • Wired surfaces: MCP server, Skills, Memory, Action affordances.
  • Visible gaps: none.

Hooks

No user-installable lifecycle hook boundary is confirmed for this host.

MCP

The adapter writes this host's native MCP registration dialect, including its root key, scope, transport fields, and environment syntax.

Memory

Managed memory text is written into the rules or memory file this host actually reads, with ownership markers for reversible uninstall.

Marketplace and affordances

Current install is a direct native-file write path; any package artifact is manual unless a driver is added.

  • Runtime handlers: Action affordances.
  • User-visible affordances: Users see managed skills + actions + memory surfaces after install; runtime-only surfaces stay behind the host boundary..

Special Feature Inventory

Host-specific capabilities separated from the generic surface matrix: lifecycle hooks, MCP registration, memory/rules, marketplace delivery, and UI or content affordances owned by the host.

Lifecycle hooks

Not confirmed

No user-installable lifecycle hook boundary is confirmed for this host.

MCP registration

Wired

The adapter writes this host's native MCP registration dialect, including its root key, scope, transport fields, and environment syntax.

Memory and rules

Wired

Managed memory text is written into the rules or memory file this host actually reads, with ownership markers for reversible uninstall.

Marketplace delivery

Direct files

Current install is a direct native-file write path; any package artifact is manual unless a driver is added.

Host-only affordances

2/2 wired

Wired host affordances: Skills, Action affordances. Host-native gaps: none. Not confirmed: Commands, Subagents, Statusline handler.

Source Review Notes

Latest source pass for host-specific architecture details. This is separate from generated adapter coverage and local drift guards.

Checked 2026-07-06Open review source
zed-industries/zed repository
  • Zed is an open-source high-performance editor, so its host row is a desktop editor surface rather than a terminal CLI.
  • The page models Zed as MCP/content/action capable without claiming a lifecycle hook bridge for the agent panel.
  • Task-backed actions are tracked as host-only affordances separate from MCP and memory.

Evidence Map

Each host page ties public source evidence to the local adapter and drift guards that keep the rendered archive aligned with code.

Public source: zed-industries/zed

Primary public repository or product source used for current host status and source links.

external
Open source

Local adapter implementation

Defines the install/uninstall behavior, native config rendering, capability flags, and any runtime parse/format bridge for this host.

local
src/adapters/zed/index.ts

Platform metadata and host-native matrix

Records the form factor, public source target, ranking source, native host surfaces, and current agent-connector coverage cells.

local
site/src/platform-data.ts

Architecture drift guard

Asserts that every registered host has a page, diagram, host-specific brief, source link, form-factor band, and adapter-aligned surface data.

local
tests/docs/platform-drift.test.ts

Runtime Shape

The host accepts MCP registration, but has no confirmed hook bridge for agent-connector to call.

MCP registration
Wired through this adapter
Hook bridge
No confirmed hook surface

Connector Surfaces

Static content

MCP server, Skills, Memory

Runtime handlers

Action affordances

Surface Matrix

Wired means agent-connector installs it now. Host native marks support we know about but have not wired yet.

SurfaceStatus
MCP server
Static content
agent-connector installs this surface today.
Wired
Hooks
Static content
No confirmed host-native surface.
N/A
Commands
Static content
No confirmed host-native surface.
N/A
Skills
Static content
agent-connector installs this surface today.
Wired
Subagents
Static content
No confirmed host-native surface.
N/A
Memory
Static content
agent-connector installs this surface today.
Wired
Statusline handler
Runtime handler
No confirmed host-native surface.
N/A
Action affordances
Runtime handler
agent-connector installs this surface today.
Wired