Busabase × ZooWork
Knowledge Base for ZooWork
Records with sources and history that survive the next agent run
ZooWork runs managed agents with files, tools and a workspace. Busabase holds the records, with their sources and change history, that another run or delivery team can read. Use a supported authenticated route to those records; ZooWork’s public, unauthenticated MCP integration is not a direct connection to Busabase Cloud.
The Assets library in Busabase: every file in the workspace in one place.
A run result and a delivery record have different owners
The ZooWork workspace holds execution files and task output. A delivery record preserves the recommendation, source date, accepted scope and responsible reviewer. Keep the run ID as provenance, while giving the business conclusion its own state: completed execution can still leave evidence unresolved.
Execution context
Keep working files, instructions and temporary observations with the task.
Evidence references
Preserve the source, observation time and exact scope that support a claim.
Shared team record
Hand the current values, their change history and the open questions to the next task through a record reference.
A completed run is not an accepted delivery record
Illustrative delivery: a research run proposes a supplier recommendation, but its source is outdated. Save the candidate, source date and unresolved check as a proposal. The delivery owner accepts only the verified scope. The next run reads that record rather than inferring approval from the previous run’s completed status.
Illustrative example, not a real customer result or test.
Example proposal ledger
| Field | Illustrative value | Evidence / decision |
|---|---|---|
| run_result | supplier recommendation | proposal |
| source_date | older than current contract | stale |
| review_decision | request current contract | not accepted |
| next_run | read record; do not infer from completed | required |
- 01run result: proposed recommendation
- 02source freshness: unresolved
- 03review: accept only verified scope
- 04next run: current record and evidence
Hand off the recommendation with a source check
For the supplier example, preserve the original recommendation and the outdated source. Request a current source for the exact delivery region and service being selected. The owner can accept supported fields and leave price or coverage unresolved. The next run should read that bounded decision before extending the recommendation.
What the next agent should receive
Suggested record fields
delivery_id, run_id, source_url, source_date, scope, reviewer, accepted_record, head
Use the agent’s shell with the documented Skill/CLI route, or an application-executed custom tool whose backend holds the Busabase credential. Do not put a key into an unauthenticated MCP URL. A new sandbox may need sign-in again: persistence of the CLI credential outside /workspace has not been established. Verify identity and scope before each resumed delivery.
Source + observation time
Link the exact file, row, commit or URL and state when it was inspected.
Scope + acceptance state
Name the environment or delivery affected; keep unsupported fields unresolved.
Owner + next check
Assign who maintains the conclusion and what evidence would require revisiting it.
From a finding to a shared record
- 01Read the existing record and verify Space, Base and head.
- 02Propose only supported fields; include evidence and unresolved questions.
- 03Use changeRequest permission when review must precede acceptance. A write grant is broader authority, not a mandatory human gate.
- 04Once the change merges (at once with a write key, or after someone approves it in the Inbox), read the record back. Carry its version and open questions into the next task.
Recheck identity before reusing a delivery
Use a supported authenticated CLI or backend-executed tool, then verify the Space and Base available to that identity. A new sandbox must not be assumed to inherit credentials. After the update merges, retrieve the current record again and include its reference in the handoff so future runs can find the current decision.
Practical questions
Why not paste the Busabase URL into ZooWork MCP?
ZooWork documents public unauthenticated MCP endpoints, while Busabase Cloud requires authentication. Use the documented shell Skill/CLI path or an application-executed custom tool with backend-held credentials. Recheck the provider’s current authentication support before changing that design.
Does this replace native memory?
No. Keep native instructions and session memory for execution. Store shared facts here with their sources and change history, and read their current version when needed.
How do concurrent updates work?
Read the current head before proposing. If it changes, inspect competing edits and revise the proposal rather than overwriting new evidence.
Connect one bounded task
Connection guideHow MCP updates and optional approval workHow Change Requests work