Bissig & Grasso GbR

kaiboKnowledge AI Backoffice

Your team's engineering doctrine, one command from every coding agent.

kaibo keeps how your team builds software in one place. Coding agents load it when they start a kind of work and research it before they decide something. What they propose to add goes to your team for review.

Source on GitHub

Early release, used internally. Open source under the MIT licence.

The problem

Every team has a way it builds things: how tests are tiered, what a base image is pinned to, what a pull request has to show, which shortcuts were tried and dropped. Most of it lives in a few people's heads. The rest is pasted into each repository's AGENTS.md, and the copies drift apart.

Coding agents never see the version that was agreed on. They produce work that is plausible and locally consistent, and quietly not how your team decided to do things.

Who it is for

  • For leads and CTOs

    One definition of how your organisation builds software, with an owner per domain and a review on every change. Any standard can be marked binding.

  • For engineers

    Stop copying conventions from repository to repository. Write them down once. Every agent session can then cite them and propose additions.

What it looks like

An agent about to touch your test suite looks up what has been decided first:

$ kaibo query "should integration tests hit the network"
self-heal: not needed
result: 2 hit(s)
- engineering-practices/reference/lean-hermetic-test-pyramid.md - The Lean Hermetic Test Pyramid (relevance 0.84, status current)
...

When nobody has written the answer down, kaibo says so instead of guessing. Exit code 3 means your team has no position yet. The same session can close the gap by proposing an addition for review.

$ kaibo query "how do we version database migrations"
self-heal: not needed
result: gap, no hits
known domains: kaibo, ai-systems, observability, infrastructure, ...
$ echo $?
3

Capabilities

  • Load doctrine

    When an agent starts observability, deployment or testing work, it loads that domain's standards in one call.

  • Research with sources

    Questions return passages with their source. The agent writes the answer and cites it.

  • Name the gaps

    Where nothing is decided, kaibo reports a gap with its own exit code instead of making an answer up.

  • Add by review

    Agents and people propose new pages. kaibo checks them against the conventions and submits them for review.

  • Binding standards

    A standard can be a must or a should, and carry checks that run locally with no AI involved.

  • Runs on your machine

    Search runs locally, in a single binary that needs no server.

What it is not

Not a chatbot
kaibo retrieves passages. It holds no language model and no API key. Your agent writes the answer.
Not a wiki for everything
It holds what your team decided should be true, not everything anyone ever wrote down.
Not an enforcer
kaibo keeps doctrine ready to read. Whether an agent reads it depends on the agent invoking the skill, which we measure rather than promise.

What you can rely on

Breaking one of these would make kaibo a different product.

Content is data
Anyone who can contribute can write into the doctrine. Retrieved content reaches the agent fenced, and it can never change which commands kaibo runs.
Nothing is discarded
No code path throws away uncommitted work. When in doubt, kaibo stops and says what to do.
No foreign scripts
The knowledge repository never executes code on your machine.
Telemetry on request
Usage data stays local unless you name your own OpenTelemetry collector.

Get started

For macOS and Linux. You need a repository for your team's doctrine. The guide shows how to start one.

brew install tenex-hq/tap/kaibo
npm install -g @tobilu/qmd@2.8.3
export KAIBO_REPO=your-org/knowledge
kaibo install && kaibo sync

Getting Started, step by step

Questions about kaibo

Want to try kaibo with your team, or have a question? Write to us.