Knowledge Base CLI: Managing Assets with kt knowledge-base
If your team treats knowledge as an operational asset, the terminal often becomes the fastest place to manage it. That is exactly where kt knowledge-base fits. The command group, with the short alias kt kb, gives you a local-first workflow for creating, mining, uploading, syncing, and binding Knowledge Base assets without leaving the CLI.
Use this page when
- You want to manage knowledge assets from scripts, CI jobs, or a local engineering workflow.
- You need a faster path than the console for repeatable create, upload, and bind operations.
- You want a terminal-native way to prepare source content before it reaches the API.
Primary audience
- Primary: Technical Engineers and platform operators
- Secondary: Knowledge owners, AI agents, technical leaders
The problem
Knowledge systems tend to start with a UI and then outgrow it. That is not a criticism of the UI. It is just what happens once the workflow becomes routine. A team updates a product policy every week. Another team refreshes runbooks from a repo. A third team needs to bind different assets to different assistants as environments change.
At that point, clicking through a console for every update becomes fragile and slow. Teams need automation, reviewable scripts, and local inspection before content is published. They also need the workflow to stay governed. Terminal speed is useful only if it does not bypass the lifecycle, bindings, and auditability that make Knowledge Base trustworthy in the first place.
That is why kt knowledge-base matters. It gives teams a workflow where content can be prepared locally, uploaded intentionally, and attached to the right assistant without turning the knowledge layer into a black box.
The solution
The kt knowledge-base command group covers the asset lifecycle in practical units of work. You can list assets, get an asset, create one, update metadata, delete old material, bind and unbind assets, and move content through a local mining and upload loop.
The standout commands are the local-first ones:
minebuilds a manifest from source content without calling the API.uploadpushes the reviewed manifest into an existing asset.synccombines mining and upload in one step.
That split is useful because it gives teams a review checkpoint between source material and published asset content. For knowledge workflows, that checkpoint is often more valuable than raw speed.
Implementation
Here is a realistic workflow for a support team maintaining an FAQ asset from local Markdown files:
kt kb create --name "Shipping FAQ" --scope org --kind upload --write-mode facts_only
kt kb mine --source ./knowledge/shipping-faq --output kb-shipping-faq.json
kt kb upload --manifest kb-shipping-faq.json --asset-id kb_shipping_faq_2026
kt kb promote --id kb_shipping_faq_2026 --to active
kt kb bind --id kb_shipping_faq_2026 --target-type agent --target-id agent_support_assistant
That flow captures most of what teams actually need. The asset exists as a first-class record. The source content can be inspected locally. Activation is explicit. Binding scopes the asset to the assistant that should use it.
The command group also supports inspection and basic governance checks during day-to-day operations:
kt kb list --scope org --kind upload
kt kb get --id kb_shipping_faq_2026
kt kb sync --source ./knowledge/shipping-faq --asset-id kb_shipping_faq_2026
There are two operational habits worth keeping.
First, mine locally before upload when the content is changing in meaningful ways. sync is convenient, but mine plus upload gives reviewers a chance to inspect the manifest and catch obvious issues before the asset changes.
Second, do not confuse creation with runtime availability. An asset can exist and still not be eligible for recall. The recall path depends on promotion and binding, not just on creation.
That distinction becomes important in CI. A strong automation lane often looks like this:
- Source documents change in Git.
- A job runs
kt kb mineand validates the manifest contents. - Reviewers approve the source change.
- The pipeline uploads and promotes the new version.
- The asset remains bound only to the intended assistant.
This is also where kt kb works well with the broader Keeptrusts model. The terminal handles asset operations. The gateway handles recall. Policies such as Citation Verifier handle output-side grounding. The result is automation without losing governance boundaries.
Results and impact
Teams that move knowledge operations into kt knowledge-base usually gain three things quickly.
The first is speed with consistency. Engineers stop reinventing one-off upload processes because the CLI exposes a stable path for common tasks.
The second is better reviewability. When local mining becomes part of the workflow, knowledge changes can be inspected before they affect live systems. That reduces the chance of accidental low-quality content reaching production.
The third is cleaner automation. Once the workflow is in the CLI, it becomes much easier to wire into CI/CD, nightly sync jobs, or release pipelines. That matters because knowledge is not static. Product docs, policy summaries, and runbooks drift unless the system for maintaining them is routine enough to be used consistently.
There is also a governance dividend. Terminal workflows often get blamed for bypassing guardrails. In Keeptrusts, the opposite is true when teams use the supported commands. The CLI makes the lifecycle, bindings, and upload process explicit, which usually improves operational discipline instead of weakening it.
Key takeaways
kt knowledge-baseandkt kbare the terminal-native surface for governed knowledge operations.mineis local-only and is the safest review checkpoint before upload.uploadandsyncare the commands that push content to the API.- Promotion and binding are separate from creation, which keeps runtime eligibility explicit.
- The CLI is the easiest way to turn knowledge maintenance into a repeatable automation workflow.