Knowledge Base for Continue
Continue Agents are assembled from models, context, Rules, Prompts, Docs, and MCP servers in versionable YAML. That makes execution reproducible. Busabase adds a different guarantee: selected outcomes become shared records only after evidence and an accountable reviewer agree.
One config, seven blocks
Treat configuration as an execution manifest, not a warehouse for changing facts.
Continue's v1 config composes distinct blocks. Each should point to the right source instead of duplicating data with another lifecycle.
| Block | Owns | Keep out |
|---|---|---|
| models | Provider, model, roles, capabilities | Business status |
| context | Files, code, diff, terminal, HTTP context | Accepted conclusions |
| rules | Always-applied guidance across Agent, Chat, Edit | Changing customer facts |
| prompts | Invokable slash workflows | Current workflow state |
| docs | Indexed documentation sources | Unverified decisions |
| mcpServers | External tools and live data access | Automatic authority |
| data | Development event destinations and filters | Secrets or canonical records |
Versioned agent configuration
A pinned config can reproduce behavior while the knowledge it reads continues to change.
Record the config name, version, schema, model roles, enabled blocks, and repository revision. Resolve changing values at run time from their owning system instead of committing snapshots into Rules or Prompts.
name + version + schema
Exact YAML and local block files
Chat, edit, apply, autocomplete, embed
Referenced securely, never copied into records
Rules
Rules tell the Agent how to behave; they do not prove what is true.
Continue applies Rules in Agent, Chat, and Edit modes. Local `.continue/rules` files can be version-controlled for project or organization guidance. Use them for standards, security checks, and paved paths. Make changing facts queryable instead of embedding them as permanent instructions.
After a schema change, generate and test a migration.
Customer X is on plan Y and renewal is approved.
Prompts
A slash command is a reusable request template, not a completed workflow record.
Continue Prompts are invoked on demand with `/`. Keep the repeatable task framing there. Store each run's inputs, outputs, evidence, owner, and acceptance state in the systems that own them.
Docs and context
Retrieval can show the relevant page without certifying its freshness or applicability.
The Docs block indexes sites, while context providers can expose code, files, diffs, terminal output, and HTTP resources. Capture which source and revision informed the result. A reviewer still decides whether the retrieved guidance applies to this case.
Which documentation root was crawled?
Which page or chunk supported the answer?
Which repository revision was in context?
Who confirmed the guidance fits this environment?
Agent-only MCP
Continue's MCP tools run in Agent mode; successful execution still does not equal record acceptance.
MCP servers can be declared in `config.yaml` or standalone files under `.continue/mcpServers/`. Continue supports stdio, SSE, and streamable HTTP. Locally stored secrets should be referenced rather than written into shared YAML or evidence.
Server block parses and loads
The runtime identity may call the tool
The call returns bounded evidence
The proposed state is accepted
Mode boundaries
Agent, Chat, Edit, and Autocomplete produce different evidence surfaces.
Do not describe every Continue interaction as an autonomous Agent run. Record the mode, model role, tool availability, and whether files or external systems could change.
| Mode | Job | Evidence |
|---|---|---|
| Agent | Plans and uses tools for development tasks | Tool calls, diffs, tests |
| Chat | Explains and discusses code | Cited context and answer |
| Edit | Changes selected code sections | Before/after diff |
| Autocomplete | Suggests inline code | Accepted suggestion and repository diff |
Run evidence
Connect the config revision to the exact output that is being promoted.
The same config can produce different results as models, repositories, docs, and external systems change. Preserve enough runtime evidence to challenge the claim later.
agent_configConfig identity and revisionmode_modelExecution mode and model rolecontext_refsFiles, docs, diff, and source recordstool_callsMCP actions and returned evidenceverificationTests, review, and downstream checksKnowledge contract
Promote a small outcome, not the entire YAML graph or conversation.
Continue remains the execution client. The record represents only the state another team or Agent needs to trust.
outcome_keyStable identity for the shared claimconfig_refContinue config version and repository revisionrun_refMode, model, and session referencesource_refsDocs, code, and external recordsevidenceDiffs, tests, logs, and tool responsesproposed_stateConcise interpretation of the resultownerPerson accountable for acceptancedecisionAccepted, conditional, rejected, or supersedednext_review_atFreshness checkpointPractical questions
Continue knowledge base FAQ
Does Busabase replace config.yaml?
No. Continue config defines the Agent's models, context, rules, prompts, docs, and tools. Busabase stores selected reviewed outcomes.
Should changing business facts go into Rules?
No. Rules are persistent behavioral guidance. Query changing facts from their owning reviewed system.
Can MCP be used in Chat mode?
Continue's current documentation states that MCP can only be used in Agent mode.
Does a versioned Prompt prove a run was completed?
No. It proves the task template. Preserve run evidence and review the outcome separately.
Can one record link several Continue modes?
Yes, when the evidence distinguishes what each mode contributed and which run produced the proposed state.
Start with one reproducible run
Pin the Agent config, preserve the evidence, and review only the outcome that needs shared trust.
Choose one Continue workflow with a stable config revision and completed verification. Submit a concise result record before another team or Agent consumes it.

