Busabase x Amp coding agentKnowledge Base for Amp
Amp can carry one coding task across a project, a thread, a remote Orb, the CLI, and several devices. That continuity is useful execution context. It is not the same as a reviewed fact that another team or agent should reuse without reopening the whole thread.
Execution map
Project, Thread, and Orb answer different questions.
An Amp Project identifies a codebase and its shared runtime settings. A Thread holds one task's prompts, replies, tool calls, and changed files. An Orb is the isolated remote machine that executes the work. A knowledge record should reference those layers without pretending any one of them is the accepted conclusion.
| Amp layer | What it owns | Durability limit |
|---|---|---|
| Project | Repository, project settings, shared execution defaults | Tracks a codebase, not every approved business fact |
| Thread | Conversation, tools, files, changes, handoffs | Can be shared, archived, exported, or deleted |
| Orb | Remote machine, filesystem, services, runtime proof | An execution environment, not a policy authority |
| Reviewed record | Accepted outcome, evidence, owner, freshness | Changes only through a reviewable proposal |
Thread boundary
A shareable Thread is provenance, not automatic truth.
Amp Threads are rich records of work: prompts, replies, tool calls, files, device handoffs, and links back from commits. Their visibility can be private, workspace, group, or unlisted. Preserve the exact Thread URL as evidence, but promote only the decision-sized result another person needs.
Instruction surfaces
Keep operating guidance, reusable procedures, runtime code, and accepted facts separate.
Amp loads each surface for a different job. Combining them into one giant context file creates stale claims and broad permissions.
| Surface | Use it for | Do not use it for |
|---|---|---|
| AGENTS.md | Repository layout, commands, conventions, review steps | Changing customer, release, or incident status |
| Skill | Focused procedure with scripts and references | Accepting the procedure's latest output as fact |
| Plugin | Tools, commands, events, UI, policy hooks | Silent ownership of canonical records |
| MCP | External tools, resources, and authenticated calls | Treating a tool response as approved knowledge |
| Busabase | Reviewable records, Docs, files, Skills, and Apps | Replacing repository-local code review |
Extension boundaries
Skills load procedures, Plugins run code, and MCP reaches external systems.
Amp recommends bundling focused MCP servers inside Skills so their tools stay hidden until relevant. Plugins can register tools, commands, events, UI, and Skills, but execute code in the active environment. Treat a Plugin as executable software, a Skill as a versioned workflow, and an MCP response as evidence that still needs interpretation.
Lazy-loaded instructions, scripts, references, optional MCP
Executable TypeScript/JavaScript with tools and lifecycle events
Local or remote server with scoped tools and authentication
Reviewed outcome that none of those layers can self-accept
Orb boundary
Remote execution changes where credentials and tools must live.
An Orb starts as a fresh remote environment and can keep working after your laptop closes. Local Amp settings do not automatically appear there. Put project-safe configuration in the repository, use remote MCP definitions for browser-based OAuth, and keep secrets in the intended secret store rather than in a committed config file.
May use machine-local Amp config and browser OAuth
Uses repository config, Orb secrets, or remote MCP definitions
Carries conversation and execution references across clients
Carries only reviewed claims across tasks and teams
Evidence bundle
Keep enough of the Amp run to challenge the conclusion later.
A compact bundle should identify the Project and Thread, execution location, repository revision, instructions and extensions, material tool calls, and verification. It should not copy every token of the conversation.
project_refAmp Project and repository URLthread_refStable Thread URL or IDexecutorOrb, runner, or local CLIinstruction_refsAGENTS.md and relevant Skill revisionstool_traceMaterial Plugin or MCP callsrepository_refBase branch, commit, diff, and shipped revisionverificationTests, portals, screenshots, or external readback
Knowledge contract
Promote an outcome that survives after the Thread stops being convenient.
The record should state what changed, why it is believed, who accepts it, and when it becomes stale. A later Agent can use it without inheriting unrelated prompts or broad Orb access.
knowledge_keyStable identity for the reusable claimproposed_stateThe concise outcome Amp producedsource_refsThread, code, Docs, and external evidencescopeProjects, services, or teams affectedownerPerson accountable for acceptancedecisionAccepted, conditional, rejected, or supersededverified_atLast evidence checknext_review_atFreshness checkpointDo not promote
Most Thread content should remain execution history.
Promote only knowledge with consequences outside the current task.
Exploration paths, failed commands, temporary notes, intermediate hypotheses
Source code, configuration, tests, and repository-local instructions
Architecture decisions, verified runbooks, release facts, incident conclusions
Claims without evidence, owner, scope, or a freshness boundary
Practical questions
Amp knowledge base FAQ
Does Busabase replace Amp Threads?
No. Threads preserve task history and collaboration. Busabase stores selected reviewed outcomes.
Should every Amp Thread create a record?
No. Create a proposal only when the result should guide later work outside that Thread.
Can an unlisted Thread be the only source?
Use it as provenance, but retain durable code, test, or external evidence that survives visibility changes.
Do Amp Skills enforce approval?
A Skill guides execution. Acceptance is enforced by Busabase permissions and Change Requests, not by prose in the Skill.
Can an Orb use my local MCP setup?
Not automatically. Current Amp docs distinguish local config from Orb-safe repository or remote MCP definitions.
Start with one Thread
Turn one verified Amp outcome into reviewed team knowledge.
Choose a completed task, attach its Thread and repository evidence, then let the accountable owner review one bounded proposal.