Guide11 min read

Nikos Dritsakos, Founder

Choosing a shared engineering knowledge base: Glen, Dosu and GitBook compared

Repository instructions hold rules, reviewed docs publish guidance and code search finds implementations. Session memory recovers the reasoning from earlier agent work. How Glen, Dosu and GitBook compare on capture, recall, permissions and freshness, and how to test them.

On this page
  1. TL;DR
  2. What a shared knowledge base adds that a wiki, repo files, and code search don't
  3. A hypothetical onboarding walkthrough: from an agent decision to a teammate's later recall
  4. Trust, permissions, and freshness: what to verify before you rely on it
  5. Comparing Glen, Dosu, and GitBook
  6. Comparison table: capabilities, ideal users, and limitations
  7. Requirements checklist for evaluating a shared knowledge base
  8. Where Glen fits, and what to verify before adopting it
  9. FAQs
  10. Next step: run the test yourself

TL;DR

  • Repository instructions give agents rules to follow, reviewed documentation publishes guidance, and code search finds implementations. Session memory helps you retrieve reasoning from earlier agent work that those sources may not contain.
  • A shared engineering knowledge base becomes worth evaluating when you switch agents or a teammate needs a decision recorded in someone else’s session. If you work alone with one agent, repository files and built-in memory may suffice.
  • Glen focuses on searchable session and team memory. Dosu supports cross-agent memory and documentation workflows, while GitBook supports maintained documentation.
  • The comparison tests what each tool captures, who can retrieve it, and how you check a changed decision. It does not rank products by benchmark results.

What a shared knowledge base adds that a wiki, repo files, and code search don't

A shared knowledge base helps you recover the reasoning behind a change when that reasoning lives in a past agent session. Suppose an engineer changes the CI shard count after weighing build time against cost. The code records the new value, but the engineer’s discussion with the agent may explain why they chose it.

Repository instructions such as AGENTS.md serve a different job. They give an agent rules it must follow on every task, so a standing requirement about CI belongs there rather than in a memory someone must search for. A reviewed wiki or documentation site publishes guidance that you maintain as decisions change. Neither needs to hold every discussion that led to that guidance.

Code search helps you find the shard setting and inspect its implementation. Searchable session memory helps a later teammate look for the earlier discussion. For example, Glen describes team memory that coding agents and teammates can search across sessions. A retrieved account still needs source checks, especially if a newer decision may have replaced the old one.

Use the four layers together. Keep rules in repository instructions, maintain current guidance in reviewed documentation, use code search to inspect what runs, and use session memory when someone needs the history behind a decision.

A hypothetical onboarding walkthrough: from an agent decision to a teammate's later recall

In this hypothetical example, an engineer asks an AI coding agent to change the CI shard count from eight to six. The engineer explains that starting eight workers adds overhead, while six keeps test runs within the team’s acceptable time. A Slack thread discusses the tradeoff, a GitHub PR changes the configuration, and a Linear issue records a planned review. Those sources could help explain the decision later if the team connects them and permits access.

Weeks later, a new teammate sees six shards in the repository and asks an agent why the team chose that number. A shared knowledge base could return the earlier session’s reasoning and point the teammate to the Slack thread, PR, and issue. Glen describes session and team recall with cited answers, but that claim does not establish that it captures every source in this hypothetical example or makes each one available to every teammate. In a trial, ask an authorized teammate to retrieve the decision and open the underlying evidence.

The teammate also needs to check whether six remains the right count. A later PR might have changed the configuration, or the Linear issue might document a new performance finding. In this hypothetical example, no product should be assumed to deduplicate the records or automatically resolve a conflict between them. The teammate can inspect the latest sources, then update the runbook or repository instructions if the operational rule has changed. That test shows whether another authorized person can recover the original reasoning and verify it against the current record.

Trust, permissions, and freshness: what to verify before you rely on it

Glen says it checks access for each memory when an agent recalls it, so an agent should surface only material its user can see. Its published Slack permissions allow public channels and shared sessions, but exclude DMs and private channels. In a demo, ask Glen to show what two users with different access rights receive for the same question. The site names GitHub and Linear as connected apps, but does not explain how private repository access or issue visibility carries over to recalled memories. Ask the vendor to demonstrate those cases before you connect restricted sources.

Glen shows citations in a sample answer that names a Slack thread, an agent session, and a pull request. Ask whether a user can open each cited source, inspect the original context, and see an access check when the citation appears. The published example does not establish those behaviors. A citation helps you check a decision only if you can reach the source and determine when it was made.

Incognito excludes a session from Glen’s store when a user turns it on. Glen describes ordinary operation as injecting context “silently,” but does not document a separate silent privacy setting. Ask what gets recorded before someone enables incognito and whether the control affects connected sources or only that agent session.

Decision freshness needs a live test. Glen’s example cites a newer Slack discussion alongside a pull request, but its site does not explain how the product flags an older decision as superseded. Change a decision during the demo, then ask a second authorized user’s agent for the current answer. Check whether the agent presents the newer source without hiding the older one.

Glen says users can export or delete their data and claims GDPR compliance. Ask how quickly a deleted source disappears from recall, whether deletion removes memories derived from it, and how long backups retain it. Confirm the hosting model and any data-residency requirements directly with Glen, since the published page does not specify them.

Comparing Glen, Dosu, and GitBook

Glen, Dosu, and GitBook have different documented strengths, so the comparison that follows is about fit rather than a ranking. Glen focuses on recalling reasoning from coding-agent sessions across teammates. Dosu also offers cross-agent memory, while its documented workflow emphasizes maintaining agent-readable documentation. GitBook centers on reviewed, published documentation that agents can read through its MCP endpoint.

Run one decision-change test across all three products. Record why your team chose a CI setting, then merge a PR that makes the decision outdated. Ask a different teammate’s agent for the current answer and inspect the sources it uses. Check whether each product surfaces the changed decision, updates documentation, or requires someone to review a proposed change.

Comparison table: capabilities, ideal users, and limitations

CapabilityGlenDosuGitBook
CaptureRecords supported coding-agent sessions. Verify what each agent records and which tool integrations your plan includes.Captures engineering activity and generates AGENTS.md, skills, and specs.Authors maintain docs directly or use Git Sync to sync Markdown with GitHub or GitLab.
Cross-teammate and cross-agent recallOffers searchable team session memory. Verify who can retrieve a recorded session and how access is checked.Offers scoped memory across sessions, repositories, and agents. Verify teammate access in a trial.Coding agents can read published docs through MCP. Drafts are excluded.
Documentation workflowSession history complements repo instructions and reviewed docs. Verify how you promote a decision into durable documentation.Monitors changes and proposes document updates. Auto-Accept Review defaults on, but a Library can require human review.Editors review and publish docs. Slack, GitHub, and Linear Channels can open or update change requests during an early-access rollout.
PermissionsVerify source permissions at recall, including GitHub and Linear access.Verify source access and Library membership against your own repositories.Published-site access governs MCP reading. Hidden pages remain accessible through MCP, so test visibility before publishing.
Governance and complianceVerify deletion, incognito scope, retention, and current trust documents.Check review settings, note deletion, and current trust documents.Check publication approvals, authenticated-site access, and current trust documents.
Setup effortCLI or agent-specific prompts. Verify integration setup and plan limits.Connect work sources. Verify connector availability and review settings.Configure Git Sync and published-doc access. Check eligibility before planning around Channels.
HostingDescribed as hosted. Verify deployment requirements with Glen.Verify available hosting options.Verify available hosting options.

Glen fits buyers who need shared recall of coding sessions. Dosu fits buyers who want agent-accessible knowledge and code-change-driven document maintenance. GitBook fits buyers who need reviewed, published documentation for people and agents.

Requirements checklist for evaluating a shared knowledge base

Run the same decision-change test against every candidate, including your wiki, repository instructions, and code search. In a test repository, record why an engineer chose a CI shard count, then merge a PR that changes it. Ask another authorized teammate to find the original reason, inspect the evidence, and identify the current decision. Record each result as pass, partial, or fail, and flag requirements you cannot compromise on.

  • Capture. Check which agent sessions, repositories, issues, and channels the product can capture on your plan. Record what enters automatically and what an engineer must add.
  • Recall. Ask a teammate using a different supported agent to find the decision without help from its author. Check whether both people can retrieve the same reasoning.
  • Provenance and permissions. Open the cited sources behind the answer. Repeat the search with an account that lacks source access, then change an account’s access and check what it can retrieve.
  • Freshness. After the merge, ask for the current shard count and the reason for the earlier choice. Record whether the product flags the conflict, which version the agent sees, and what a person must update.
  • Controls. Test no-capture or incognito settings with a new session. Ask an admin to demonstrate how retention and deletion work, including how to verify that removed material no longer appears in answers.
  • Deployment and hosting. Time the setup in your environment. Confirm connector availability and costs on the plan you would buy, and check whether its hosting options meet your requirements.

A connector logo cannot establish whether a teammate can retrieve an accurate, authorized answer after a decision changes. Use the test results, not the feature list, to compare products.

Where Glen fits, and what to verify before adopting it

Glen is worth testing if your teammates need to recover decisions made in earlier AI coding sessions, especially when they use different agents. The Glen homepage documents a CLI install command, npx @tryglen/cli@latest install, and setup through agent-specific prompts. Those are starting points for a trial, not documentation of how every integration works.

Before adopting Glen, ask for current setup and access documentation for GitHub, Slack, and Linear. The supplied homepage does not explain how GitHub or Linear permissions carry into recalled answers, how quickly deleted source material disappears, or how Glen handles a superseded decision. Ask to test those cases with two teammates who have different access. If you need to prevent teammates from finding one another’s recorded sessions, do not proceed without a demonstrated restriction that fits your policy. If you require self-hosting, first confirm that Glen offers it. The supplied source does not establish a hosting option. Keep rules that must apply on every agent turn in repository instruction files instead.

Glen reports 21% faster merges and 29% fewer tokens per task in a vendor-run benchmark. Treat both figures as unverified claims. The supplied research did not include the linked methodology URL, so request and review that methodology before using the figures in a purchase decision.

FAQs

  • Does session memory replace a wiki? No. A wiki holds reviewed guidance that you maintain for readers, while session memory helps a teammate find reasoning recorded during earlier work. The section on complementary knowledge sources explains where each belongs.
  • How is session memory different from code search? Code search finds what the repository contains now. Session memory can help you find why someone made a change, provided the relevant conversation was recorded and you can access it.
  • What happens when a decision is superseded? Do not assume a memory tool will identify the newer decision automatically. As the trust and freshness section explains, you should inspect cited sources and test how each vendor handles a changed decision after a merge.
  • What does Glen’s incognito control hide? Glen describes incognito as keeping that agent session out of its memory store entirely. The trust and freshness section covers why you should confirm how that control interacts with separately connected sources before relying on it for sensitive work.
  • Which plans include Slack, GitHub, and Linear? Glen lists connected-work-tool integrations on its Personal and Team plans, but you should confirm each connector’s availability before buying. Dosu says Slack requires Teams, while the supplied material does not establish its GitHub or Linear plan requirements. GitBook lists all three as early-access Channels, but its documentation does not establish plan eligibility.

Next step: run the test yourself

Your choice depends on which job your current tools leave undone. Run the same merge and decision-change test with each candidate, then ask a teammate to find the current decision and check its source. If shared session recall is the gap, Glen’s free tier lets up to three people try the test without a credit card.

More field notes

Fix your agents’ amnesia.

Start on your own or with up to two teammates. Your first 15,000 memories are free, no credit card.

Start free