Gitian

Teams

Your agent reads every knowledge base you belong to and writes to one. This page covers which ones those are.

Your personal knowledge base

Every account has one. An org seat never widens it: nothing in it reaches a teammate unless you invite them into it or link it to another knowledge base yourself. You can also create more knowledge bases of your own from the switcher in the web app.

Org knowledge bases

Each organization in Gitian has a knowledge base called team, addressed as <org>/team. Who belongs to it follows the GitHub org: there are no member lists to keep and nothing to revoke. When someone leaves the org or loses their seat, their access narrows on their next request.

  • Any member of the GitHub org can write to it.
  • Reading it takes one of the org's Gitian seats.
  • When an agent names no knowledge base, docs and journal entries about one of the org's repositories go to the org's knowledge base. Memories are never routed by repository.
  • The org's admin can create more org knowledge bases in Settings, and is the only one who can change their categories.

Write-only, and reading your own

Without a seat, an org knowledge base is write-only for you. Your writes still land, and you can always read back what you wrote, but not your teammates' items: nobody loses access to their own work. A search names such knowledge bases in own_only_kbs, and opening a teammate's item there answers read_requires_entitlement.

Linked knowledge bases

Two knowledge bases can be linked by an invite, which needs admin on both sides. A link lets each read the other and write to neither, and it never chains: a link of a link grants nothing. Items from a linked knowledge base show up in your searches, labelled with where they came from. Invites go to a GitHub login, so the person needs no Gitian account until they accept.

Reads span, writes go to one

search, list, neighbors and file_intents cover every knowledge base you can read and label each hit with its own. A write lands in exactly one knowledge base, chosen in this order:

1. kb
The knowledge base the agent names. Always wins.
2. repo
For a doc or journal entry about an org's repository, that org's knowledge base.
3. default
The connection's default knowledge base, set per token or connection in Settings.
4. personal
Your personal knowledge base.

Every write reports where it landed. Address a knowledge base by its slug or as <login>/<slug>; a wikilink such as [[acme/team/release-checklist]] can point at an item in another knowledge base you can read.

A knowledge base you do not belong to answers exactly like one that does not exist, so access itself reveals nothing. Agent-written markdown renders with raw HTML turned off.