Agent ZeroBusabase × Agent Zero

Knowledge Base for Agent Zero

Agent Zero can isolate files, instructions, secrets, memories, knowledge, repositories, and model presets by project while delegating work to focused subagents. Busabase is the narrower layer for facts that must cross those project boundaries with evidence, ownership, and a change history anyone can inspect or roll back.

Cross-project Change RequestDiff and history
Busabase Change Request showing the message, a before/after diff of a record, and Approve or Request changes
An Agent can remember and delegate inside a project. Each change to a shared record arrives as a Change Request with its message and diff, so other projects can see what changed and who changed it.

Project isolation

A project keeps context from leaking; it does not make every project memory authoritative.

Agent Zero Projects isolate workspace files, instructions, memory, secrets, knowledge, repositories, and model-preset choices. Preserve that boundary. Promote only the claims that another project or team genuinely needs.

Project assetLocal purposeCross-project rule
Workspace filesTask inputs and generated artifactsLink immutable outputs
InstructionsProject-specific Agent behaviorDo not store changing status
MemoryUseful learned contextCurate before promotion
KnowledgeImported and searchable materialRetain source and freshness
SecretsProject credentialsNever copy into knowledge records
RepositoriesCode and revision historyReference Git instead of duplicating
Model presetsExecution configurationRecord model/runtime only as provenance

Memory and knowledge

Recall improves continuity, but stale memory can poison every later step.

Agent Zero's own guide describes memory as useful remembered information from conversations and imported knowledge, and tells users to search, review, edit, remove, and back up entries. Treat curation as routine operations rather than assuming recall is self-correcting.

MEMORY

Learned facts, patterns, and prior solutions

KNOWLEDGE

Imported reference material available for retrieval

BUSABASE RECORD

Shared claim with owner, evidence, history, and lifecycle

Delegated work

A subordinate Agent returns a result, not an independent source of authority.

Multi-agent cooperation can delegate research, coding, analysis, or review to focused subagents. Preserve the delegation tree and the evidence each worker actually produced. The parent summary alone should not erase uncertainty or conflicting findings.

01DelegateDefine task, expected evidence, and limits.
02ExecuteSubagent works in its bounded context.
03ReturnCapture result, artifacts, and unresolved risks.
04ReconcileParent compares outputs and source coverage.
05ProposeSubmit one concise cross-project claim.
06MergeIt merges with a write key, or waits in the Inbox when the agent has a proposal-only key.

Skills and profiles

Skills teach procedures; Agent Profiles configure behavior; neither should own changing operational facts.

Agent Zero exposes inspectable prompts, tools, plugins, Skills, settings, and model presets. Skills may load on demand or remain pinned for a chat. Keep repeatable execution knowledge there, and make each procedure query current Busabase records when facts change.

01

SKILL

Reusable task procedure and support files

02

AGENT PROFILE

Role, prompts, tools, and model choices

03

BUSABASE RECORD

Current inputs, decisions, and ownership, with history

Container and host boundary

Record where the action actually ran, not only which Agent requested it.

Agent Zero commonly runs in Docker and can use A0 CLI to reach host terminal, files, browser, and real repositories. Container output, host output, and external service responses have different trust and reproducibility properties.

CONTAINER

Agent runtime, project workspace, isolated tools

HOST BRIDGE

Real repository, terminal, browser, local files

EXTERNAL SYSTEM

API or service state reached by a tool

RECORD LAYER

Evidence-backed claim with an owner and an attributed history

Memory operations

Keep durable context small enough to inspect and easy enough to correct.

Review memory when behavior repeats a mistake or recalls the wrong context. Remove test data, update inaccurate entries, keep project-specific information in project memory, and back up before large cleanup.

SEARCH

Find the entry influencing current behavior

TRACE

Locate its project, source, and creation context

CORRECT

Edit or remove inaccurate memory

BACK UP

Preserve recovery before bulk cleanup

PROMOTE

Send only verified reusable claims to Busabase

Cross-project promotion

Do not copy an entire memory directory into a shared knowledge base.

A promotion should narrow one useful claim, attach its source and runtime evidence, identify the responsible owner, and define when it needs another review.

01 · PROJECT OBSERVATION

A result appears useful beyond one project

02 · SOURCE CHECK

Files, messages, repository, or external response

03 · CONFLICT CHECK

Compare memories and project-specific assumptions

04 · CHANGE REQUEST

Message, diff, author, and key travel with the proposal

05 · MERGED RECORD

Other Agents reuse the merged state; history and rollback remain

Agent knowledge contract

Preserve enough lineage to challenge a claim after the original chat or subagent is gone.

The record links project-local context to the stable state shared across projects.

knowledge_keyStable identity across projects and Agents
project_refOrigin project and workspace
agent_treeParent and subordinate Agent references
memory_refsEntries or imported knowledge used
execution_surfaceContainer, host bridge, or external service
artifact_refsFiles, repository revisions, logs, and responses
claimConcise proposed cross-project state
ownerPerson accountable for acceptance
freshnessObserved, effective, and next-review dates
decisionAccepted, conditional, rejected, or superseded
Busabase Base record list (a Labeling Queue), one row per record, the kind of table that holds cross-project knowledge records

Trust boundaries

A powerful host bridge increases evidence requirements, not authority.

Projects isolate context, but tools can still affect repositories, files, browsers, and services. Use least privilege, inspect shell commands and authorization flows, and separate the ability to execute from the authority to merge shared records when that matters to you.

BoundaryControl
Project boundaryPrevent unrelated memories, secrets, and files from mixing
Tool boundaryLimit terminal, filesystem, browser, and service access
Credential boundaryGrant only the required account and scope
Change boundaryEvery write is an attributed, reversible Change Request

Practical questions

Agent Zero knowledge base FAQ

Does Busabase replace Agent Zero memory?

No. Agent Zero memory supports one project's continuity. Busabase stores selected facts, with their source and change history, for use across projects, people, and Agents.

Should imported knowledge be treated as current?

Not automatically. Preserve its source and freshness, then review any claim that becomes operational state.

Does a subagent result count as independent verification?

Not by itself. Record its sources, execution context, and unresolved conflicts before promotion.

Should Skills contain current customer or production status?

Usually not. Keep the procedure in the Skill and retrieve changing facts from Busabase records.

Can Agent Zero merge canonical records directly?

With a write-level key it can; each change is still a Change Request with a diff, author, and rollback. If you want a person to approve first, give it a proposal-only key so its changes wait in the Inbox. How Change Requests work

Start with one project-local memory

Promote the smallest fact that another project truly needs.

Choose one curated Agent Zero memory with durable evidence. Identify its project, execution surface, owner, and freshness rule, then propose it as a Change Request for cross-project reuse.