Busabase × ZedKnowledge Base for Zed
Zed can run parallel Agent threads, isolate work in Git worktrees, review edit hunks, restore checkpoints, and call MCP tools. Busabase turns the small set of outcomes that must survive those threads into evidence-backed records with an accountable owner.
Five editor surfaces
Keep conversation, restoration, code review, isolation, and shared state separate.
Zed exposes several useful control surfaces. Their jobs overlap during execution but their retention and authority differ.
| Surface | Best used for | Not a substitute for |
|---|---|---|
| Agent thread | Reasoning and tool trajectory | Durable team record |
| Checkpoint | Return files to a prior message boundary | Accepted decision |
| Change review | Keep or reject edit hunks | Cross-system approval |
| Git worktree | Isolate concurrent repository work | Operational ownership |
| Busabase record | Reviewed state across projects and systems | Source code or thread history |
Parallel thread topology
One project can have many active narratives but only one current state for a given claim.
Each Zed thread has its own agent, context window, and conversation history. Threads can be summarized, compacted, archived, restored, or isolated in worktrees. Promote a stable claim only after reconciling the thread that produced it with the repository and external evidence.
Feature implementation
worktree/feature-a
Regression investigation
worktree/debug
Documentation update
main workspace
Edit review is local
Accepting a hunk answers a code question, not an organizational one.
Zed's review surface shows files and edited lines and lets a person keep or reject individual hunks. A checkpoint can restore the codebase to a prior message. Preserve that evidence, then separately review claims such as release readiness, customer impact, migration status, or support policy.
Changed files
Accepted or rejected hunks
Checkpoint boundary
Repository revision
Impact claim
Evidence references
Responsible owner
Effective status
Two independent gates
Tool permission controls whether an action runs; record review controls whether its result can be trusted downstream.
Zed can confirm, allow, or deny built-in and MCP tools, with per-tool rules and hardcoded terminal protections. A successful tool call still needs evidence and an accountable reviewer before it changes canonical state.
May this command, edit, fetch, or MCP tool run?
May this result become reusable operational truth?
Three Agent paths
Native Agent, External Agent, and Terminal Thread do not share one automatic configuration contract.
Zed Agent uses Zed-configured MCP servers. External Agents may receive those servers through ACP and may also read native configuration. Terminal Threads rely on the CLI or TUI's own configuration. Record the path that executed the work instead of assuming tools and approvals were identical.
| Path | MCP/config owner | Evidence to retain |
|---|---|---|
| Zed Agent | Zed settings and Agent Profile | Thread, profile, tool calls, revision |
| External Agent | ACP forwarding plus agent-native config | Agent identity, forwarded tools, native session |
| Terminal Thread | CLI/TUI configuration | Command, environment, repository revision |
Decision envelope
Package the outcome so a reviewer does not need the original editor session.
The record connects Zed's execution artifacts to the state that another project or Agent may consume.
state_keyStable identity for the claimprojectZed project and repositoryagent_pathZed Agent, External Agent, or Terminal Threadthread_refThread or exported Markdown referenceworktree_revisionExact code statetool_evidenceCommands, MCP responses, tests, and diffsproposed_stateConcise cross-system outcomeownerPerson accountable for acceptancedecisionAccepted, conditional, rejected, or supersededInstruction ownership
Instructions and Skills shape future Agent behavior; they should not quietly become a fact database.
Zed uses personal and project instruction files for always-on guidance and Skills for reusable task procedures. Keep coding conventions and workflows there. Store evidence-backed product, operational, or customer state in reviewed records.
AGENTS.md / project instructions
Always-on behavior and project guidance
SKILL.md
On-demand reusable task procedure
Busabase
Reviewed claims, decisions, and ownership
Connection boundary
The connection guide owns OAuth and context_servers; this page owns the handoff contract.
A remote MCP server without an Authorization header triggers Zed's standard OAuth flow. Use the maintained guide for setup, then test one read and one review-gated proposal in the exact Agent path and profile your team will use.
Practical questions
Zed knowledge base FAQ
Does Busabase replace Zed threads?
No. Threads preserve the working conversation. Busabase keeps selected reviewed outcomes that must survive across threads, projects, or tools.
Is Restore Checkpoint an approval?
No. It is a local restoration boundary for files. It does not accept or reject an operational claim.
Does accepting every diff hunk make the result canonical?
No. It accepts edits in the editor. Shared state still needs its own evidence and owner.
Do all Zed Agent paths use the same MCP configuration?
No. Zed Agent, ACP External Agents, and Terminal Threads have distinct configuration boundaries.
Should project instructions contain changing business facts?
Usually not. Keep behavior guidance in instructions and promote changing shared facts to reviewed records.
Start with one cross-thread claim
Let Zed own the editing experience and give shared state a reviewable destination.
Choose one outcome that must outlive its originating thread. Attach its revision, tool evidence, and owner, then review it before another project or Agent acts on it.