Busabase × WarpKnowledge base for Warp
Warp already gives Agents rich context through Rules, Workflows, Notebooks, Skills, Prompts, MCP servers, and execution environments. Busabase gives the result a cross-system record with evidence, an owner, and a review decision.
Keep Warp Drive useful
Rules, Workflows, Notebooks, Skills, and records are different operational objects.
Warp Agents can automatically retrieve relevant Warp Drive objects and show them under References or Derived from. Busabase should not copy that library. It should receive the small state change that must survive beyond the session or coordinate another system.
Context with visible provenance
References explain why the Agent acted. The record explains what the organization accepted.
When Warp injects a Drive object into Agent context, the conversation can identify the reference. Preserve that provenance in the handoff. Link the Rule, Notebook, Workflow, Skill, MCP record, and run rather than flattening them into an unsupported summary.
Referenced by Agent
Which Warp Drive object shaped the response?
Produced by run
Which command, diff, artifact, or external action occurred?
Verified by evidence
Which test, log, API response, or human observation supports it?
Accepted by owner
Who decided the state can drive the next workflow?
Local and cloud are different contracts
A tool that works on the desktop is not automatically available to a cloud run.
Warp documents separate MCP paths for local Agents, third-party CLI Agents, and cloud Agents. Local sessions may use desktop-authenticated services. Cloud runs need reachable endpoints, Agent Secrets or managed authorization, and an execution environment that contains the required repository and tools.
| Surface | Typical job | Required boundary |
|---|---|---|
| Local Warp Agent | Interactive terminal or editor work | Desktop settings, Warp Drive, or file-based MCP |
| Third-party CLI Agent | Claude Code, Codex, OpenCode, or another harness in Warp | Harness-specific or shared file configuration |
| Cloud Agent run | Background, scheduled, integration, CI, or API execution | Run config, shared MCP UUID, secrets, and cloud environment |
| Busabase review | Cross-run state acceptance | Proposal credential, Base policy, and accountable reviewer |
Operational handoff
Turn a successful run into a state transition another system can inspect.
A terminal transcript or cloud-run page contains execution detail. The handoff should extract only the status, evidence, owner, and next action needed by support, product, security, finance, or another Agent.
Run-to-record contract
Use a stable record to compare work across terminals, environments, and Agents.
The record is intentionally smaller than the transcript. It retains enough provenance to reopen the exact run and enough structure for another workflow to filter, notify, or act.
| Field | Purpose |
|---|---|
| work_key | Stable identity for the incident, release, request, or operation |
| run_ref | Warp local/cloud run and conversation URL |
| execution_surface | Local Agent, third-party harness, cloud run, or schedule |
| environment_ref | Repository, revision, host, runner, and relevant profile |
| context_refs | Rules, Notebooks, Workflows, Skills, prompts, and MCP sources |
| evidence | Artifacts, tests, logs, diffs, and external responses |
| proposed_state | Agent's concise operational interpretation |
| decision | Accepted, conditional, rejected, blocked, or superseded |
| owner | Person accountable for the canonical state |
| next_action | Downstream work authorized by the decision |
Three control planes
Agent Profiles, run permissions, and record review govern different risks.
Warp Agent Profiles and team settings control model, autonomy, tools, permissions, and execution behavior. MCP controls access to external capabilities. Busabase review controls whether the resulting fields become shared truth.
EXECUTION PROFILE
What may this Agent do in this environment?
MCP / SECRET BOUNDARY
Which external systems and credentials may the run use?
CHANGE REQUEST
Which proposed state may become canonical?
Connection and reachability
Test the exact execution surface, not an abstract MCP configuration.
A local OAuth connection may fail in an unattended cloud run, and a secret in your shell may not exist in the selected environment. Follow the connection page, then test identity, read scope, proposal scope, evidence links, and reviewer assignment in the same surface that will run production work.
Questions from Warp teams
Warp knowledge base FAQ
Does Busabase replace Warp Drive?
No. Warp Drive is the right home for Agent-facing Rules, Workflows, Notebooks, Prompts, Plans, environment variables, and shared MCP configuration. Busabase stores reviewed cross-system state and its decision history.
Should a Workflow write canonical records directly?
For governed data, no. Let the Workflow or Agent create a proposal with evidence, then assign the relevant domain owner to review it.
Are References or Derived from enough evidence?
They are valuable provenance, but acceptance may also need an immutable repository revision, command output, test, artifact, external API response, or human observation.
Can the same workflow run locally and in the cloud?
Often, but the contracts differ. Confirm repository availability, environment, credentials, endpoint reachability, MCP authorization, and tool support for each surface.
What belongs in the Busabase record instead of the Warp transcript?
Store the stable work identity, accepted state, evidence references, owner, effective time, and next action. Keep detailed reasoning and execution steps in the original run.
Start with one handoff
Let Warp execute the work and Busabase establish the state others can trust.
Choose one recurring local or cloud run whose result affects another team. Define the run-to-record contract, use proposal-only access, and review the first transition before automating the next step.