Question 1

Why not just use Atlassian Rovo or Microsoft Copilot?

Accepted Answer

Because they answer a different question. Rovo and Copilot search what your team already wrote down. The knowledge that costs you most was never written down at all. Stackbridge captures it at the moment it exists: the Slack thread where the incident was actually solved, the ticket as it closes, the interview with the engineer working their notice period. A human then approves it, so what comes back was checked by someone on your team, with a named approver and a tamper-evident trail behind it. Rovo searches what you wrote down; Stackbridge makes sure it got written down, and can prove who knew what, when. In practice they sit side by side: keep Rovo for finding documents, use Stackbridge for the operational knowledge that never becomes one.

Question 2

Could we not just build this ourselves?

Accepted Answer

You could, and the search box is a quarter’s work. The rest is what the same engineers are still building a year later: a person approving every entry before it is answered from, capture from tickets and threads rather than only pages, every claim traced to its passage, a hash-chained record of who approved what, connectors kept working as Slack, Jira and Confluence change, and a security review your reviewers can read today. At the fully-loaded hour we use elsewhere on this page, two engineers for six months is about 182,000 euro to build, then one engineer at half time, about 91,000 euro every year, to keep. If your team wants to own that, build it. If they would rather own your platform, that is what Stackbridge is for.

Question 3

How is this different from Confluence or a wiki?

Accepted Answer

A wiki depends on someone remembering to write things down, and someone else remembering the page exists. Stackbridge captures knowledge from the tools your team already uses, structures it into a typed schema, and pushes it back at the moment of need: into the Slack thread, the search box, or your coding agent. And you do not have to migrate: point it at your existing Confluence space and it syncs hourly, so the knowledge base is not empty on day one. When a page there goes out of date, flag it from Stackbridge: once a colleague agrees, it is labelled outdated or obsolete in Confluence itself and stays out of answers until someone updates it.

Question 4

Isn’t this just ChatGPT with our documents in it?

Accepted Answer

No. A general assistant answers from a pile of text you pasted in. Stackbridge extracts every incident into structured fields: severity, service, error signature, root cause, fix, prevention. That is what lets it match a new incident to an old one by symptom and by exact error signature, then post that match into the channel unprompted. And when it answers, every claim cites the approved entry it came from, the citation opens that passage, and anything in the answer that no entry holds is listed under it rather than passed off as yours. A link you paste into a question is read as your page and named as such, never as the record. None of that falls out of a chat window.

Question 5

Where does our data live?

Accepted Answer

On your infrastructure. On-premises is how Stackbridge is primarily sold: deployed via Helm on your own Kubernetes, air-gapped if you need it, with no inbound ports required. Your knowledge never has to leave your network. We never train on customer data, and you can bring your own LLM (a private Claude key or a fully local model), so no content is sent to any third party you have not chosen yourself. If starting on your own infrastructure is not practical yet, we can host it for you, single-tenant in the EU, on request. That is a conversation rather than the default.

Question 6

Our security team will not open a port for this. Does it still work?

Accepted Answer

Yes. The whole platform runs inside your network, and the Slack integration can dial out to Slack rather than waiting to be called, so the bot, slash commands and thread capture all work with nothing exposed to the internet. The AI runs on hardware you choose: a local model on your own box, or your own API key.

Question 7

Who decides what actually enters the knowledge base?

Accepted Answer

A person, and that is the product. Everything captured lands as a draft; nothing is published by the AI alone. The exception is documentation your team already published: pages synced from Confluence or Google Drive arrive approved and stay read-only in Stackbridge, so they are corrected at the source, and an administrator can mark a GitHub or Bitbucket source as trusted. Review is built to take seconds rather than minutes: approve, reject or jump to the next entry from the keyboard, or straight from the Slack thread where the work actually happened. Every review decision is attributed to a named person and written to a tamper-evident, hash-chained audit trail, so months later you can show who approved a fact and that the record has not been altered since. Read-only roles exist for people who should see the knowledge base but never change it. That approval layer is also the part nobody can copy: anyone can re-index your Confluence, but only your team has the judgment about what was worth keeping.

Question 8

Does it work inside Claude Code, Cursor, and other AI tools?

Accepted Answer

Yes, over the Model Context Protocol. Each person adds Stackbridge to their own tool (Claude Code, Claude Desktop, Codex, Cursor, VS Code or another MCP client) and signs in through the browser, under your single sign-on, with nothing secret to copy. A tool that cannot open a browser, such as one on a server, uses a personal token instead. Your agent can then search past incidents, get answers with the entries they came from, and file new fixes as drafts for a person to review, without leaving the editor. While you debug in the terminal, ask your agent to start a Stackbridge debug session: it logs each command, what it showed and what you learned, and when you end it the session becomes a draft incident write-up with the commands exactly as you ran them, for a teammate to approve. It acts as the person who connected it, with their role, inside your organisation only. Read-only viewers cannot connect a tool, anyone can disconnect theirs from their settings, and removing someone ends every tool they connected.

Question 9

What else do our AI agents get from it?

Accepted Answer

The team’s skills, the team’s MCP servers and the artifact hub. A skill is a set of instructions your agents check before a task, such as how images are built here or how a runbook is written, kept in git with every version and who made it. It can be drafted from approved entries, each one cited, and can pull in the latest approved entries each time it is read; for a chat tool that cannot connect, such as ChatGPT, it copies out as one Markdown document. An administrator describes each MCP server your agents use once, and every member gets the steps for Claude Code, Claude Desktop, Cursor, VS Code or Codex, supplying their own credentials, since none is stored. The artifact hub keeps the dashboards, pages and diagrams people and their agents publish: versioned, shown in a sandbox, with live data read as the person looking at it.

Question 10

How long until it is useful?

Accepted Answer

Connect your tools in an afternoon. Point it at the Confluence space you already have and it structures what is already written down, so it answers questions from day one; the incident memory then compounds from every ticket that closes after that.

Question 11

What does it cost to run our own model?

Accepted Answer

Nothing extra from us. Bring-your-own-model is part of every deployment. Embeddings run locally by default on a small open model, and chat and search can point at different machines, so a shared GPU box handles the heavy model while embeddings stay next to the app. On CPU-only hardware it is slower, not broken; extraction is queued and given a longer budget precisely for that case.

Supplier information

1.Who you would contract with

2.What is supplied

3.Support and maintenance

4.Accessibility

5.Security and vulnerability handling

6.Data protection

7.Continuity and exit

8.The tender file

Who we are