Busabase x Factory DroidKnowledge Base for Factory Droid
Factory Droid can plan, edit, test, review, delegate to custom droids, load Skills, connect MCP servers, and move interactive work into headless execution. The control surface is strong, but a successful run is still evidence for a proposal, not self-approved organizational truth.
Control layers
Rules, procedures, delegated agents, and tools should not compete for the same job.
Factory gives each layer a specific role. Preserve that separation when you assemble evidence for a durable record.
| Layer | Primary job | Trust boundary |
|---|---|---|
| AGENTS.md | Always-on repository commands and guardrails | Instruction text, not runtime enforcement by itself |
| Skill | Reusable procedure loaded when relevant | Prompt guidance plus optional support files |
| Custom droid | Fresh-context subagent with model and tool policy | Runtime tool boundary; returns one result |
| MCP | Authenticated external tools and context | Server identity, tool policy, and credentials |
| Busabase | Human-reviewed canonical records | Permission-aware proposal, review, and merge |
Delegation
A custom droid isolates context and tools, not accountability.
A custom droid runs in a fresh context, can use a different model, and can be restricted to read-only, edit, execute, web, or selected MCP servers. It cannot ask the user or recursively create another subagent. Preserve the delegated task, effective tool set, model, and returned artifact before deciding whether the result is reusable knowledge.
subagent_typeCustom droid or built-in worker/explorertask_boundaryExact delegated question or checklistmodel_policyPinned model or inherited routingtool_policyCategory, exact tools, and MCP serversresultSingle return value to the parentparent_decisionHow the parent verified and used itMCP governance
Configuration scope, server fingerprint, and tool approval all matter.
Factory loads MCP definitions from user, folder, project, and organization-managed sources. Persistent approvals bind to the server's transport fingerprint, and enterprise policy may allow or block servers independently of their display name. Record the effective server, exact tool, permission, and response.
User, folder, project, or managed definition
Transport URL/command fingerprint
Enterprise allowlist and tool filtering
Persistent or per-call decision
Response plus external verification
Execution surfaces
Interactive, Exec, and Mission runs need different evidence.
The same prompt can run beside a developer, as a one-shot headless job, or through multi-agent orchestration. State the surface and autonomy level before comparing outcomes.
| Surface | Typical use | Evidence to retain |
|---|---|---|
| Interactive CLI/App | Exploration, implementation, live review | Prompts, approvals, diff, tests |
| Droid Exec | Scripts, CI, scheduled and batch tasks | Input, flags, exit code, structured output |
| Custom droid | Focused delegated analysis or work | Definition, tool boundary, return value |
| Mission | Planned multi-agent delivery | Milestones, workers, validators, final artifacts |
Reviewable delivery
Move from repository guidance to accepted knowledge through explicit checkpoints.
Droid can show a diff and wait before editing. Busabase adds a second boundary for facts and records that outlive the repository task.
Run evidence
Capture the effective Factory runtime, not only the final message.
The final message can omit a blocked tool, a delegated subagent, or a changed autonomy level. Store a compact execution digest beside the proposed knowledge.
session_or_runInteractive session, Exec run, or Missionrepository_refCheckout, branch, commit, worktreeguidance_refsAGENTS.md and loaded Skillsagent_traceParent and custom droidsmcp_traceServer fingerprints and material callsautonomyEffective risk level and approvalsverificationTests, review, and external readbackCanonical record
Accept the result separately from permission to execute it.
The record should stay meaningful even when the original session is retained for a shorter period or the underlying tool catalog changes.
record_keyStable identityproposed_stateResult another team may rely onexecution_refSession, Exec, Mission, and agent traceevidence_refsCode, tests, MCP responses, external sourcesownerAcceptance responsibilitydecisionAccepted, conditional, rejected, supersededvalid_untilFreshness or review boundaryControl semantics
Autonomy and tool policy reduce risk; they do not validate the claim.
Keep execution authorization and knowledge acceptance visible as separate decisions.
Limits mutations but can still produce an incorrect conclusion
Pre-authorizes classes of local or remote action
Controls which external tools may run
Controls whether a proposed record becomes canonical
Practical questions
Factory Droid knowledge base FAQ
Does Busabase replace AGENTS.md?
No. AGENTS.md tells Droid how to work in the repository. Busabase stores reviewed outcomes.
Is a custom droid a security sandbox?
It enforces a tool policy for that subagent, but process, filesystem, organization, and external service controls still matter.
Does a successful Exec exit code approve the result?
No. It proves the runner completed under its contract; record acceptance remains separate.
Can an MCP approval be reused after the URL changes?
Factory binds persistent approval to a transport fingerprint, so a changed URL or command requires a new decision.
Should a Skill include current project status?
No. Keep Skills procedural and fetch changing state from the owning system.
Start with one verified run
Let Factory Droid execute broadly and promote narrowly.
Choose one consequential outcome, retain the effective runtime and tests, and submit only the reusable state for accountable review.