Sharing a Knowledge Backend Across Coding Assistants
How to connect Claude Code, Cursor, and custom coding agents to a shared MCP knowledge backend, manage client configuration boundaries, and handle concurrent knowledge updates without vendor lock-in.
Key takeaways
- Share knowledge, not live conversations: Each assistant keeps its own conversation and runtime state.
- Distinguish storage layers: AKB's current native backend uses PostgreSQL for revisions, text, metadata, and table state; file storage and derived search indexes are separate. Bare-Git document storage is a legacy backend.
- Test the deployed connection path: Backend, client, and proxy versions determine the protocol handshake, authentication path, and transport behavior. A local stdio child can proxy to a shared remote backend; it is not necessarily an offline copy.
- Treat updates and access as operational tests: MCP transport support alone does not establish authorization, write-conflict behavior, or indexing speed.
For software engineering teams using multiple AI coding assistants, a shared knowledge backend can give each client access to maintained records without maintaining a separate knowledge base for every tool. Start with a representative document and two clients, then test identity, permissions, update visibility, concurrent edits, and recovery. Shared access to stored knowledge does not synchronize active conversations.
Shared backend, distinct storage layers
Teams using several coding assistants may connect them to a common knowledge backend rather than maintaining separate copies of internal documentation for each tool. The Model Context Protocol (MCP) provides a way for compatible clients to call shared knowledge tools, but it does not decide how the backend stores data or handles concurrent writes.
AKB's current README describes a PostgreSQL-native architecture: PostgreSQL is the source of truth for document revisions, text, metadata, and tabular state. Attached files use separate file storage, while semantic search uses a derived vector index; the README also describes hybrid dense and keyword retrieval. Bare-Git vault storage is identified as a legacy backend, so Git should not be presented as the version-history layer for every current deployment. See the AKB architecture and key concepts.
A revision history is not, by itself, concurrency control or a complete audit of agent runs. Keep storage behavior, authorization, and tool-call auditing as separate operational concerns.
Connection behavior depends on deployed versions
Do not assume one handshake, authentication flow, or transport behavior from the MCP label alone. The deployed backend, client, and proxy versions determine which protocol revision and connection path are in use. Check those versions and their documented compatibility before testing. HTTP connections may carry JSON requests and responses or use Server-Sent Events (SSE); support for a transport does not establish service capacity or authorization policy. See the MCP transport specification and AKB's protocol compatibility notes.
With AKB's stdio setup, the client starts a local child process that acts as a proxy to the shared backend. The local process does not make the remote knowledge store an offline copy. Client approval prompts are also not server authorization: use scoped credentials for each principal and enforce access at the backend.
Two-client acceptance tests
Run these checks with two representative clients against a controlled workspace. These are test criteria, not claims about pre-tested outcomes. Record what the deployed versions actually do; do not assume a conflict response, automatic merge, fixed indexing time, or particular error code.
| Scenario | Test setup | Expected observation | Evidence to record |
|---|---|---|---|
| Same known document revision | Have both clients request a known URI and revision A, then repeat with revision B if available. | Confirm whether each client can retrieve the requested revision and whether the returned content and revision identifiers agree. | Backend, client, and proxy versions; principal; URI; requested and returned revision; timestamps; results. |
| Allowed and denied principal | Use one principal configured for access and another without the relevant permission. | Verify access for the permitted principal and denial for the other at the backend boundary. | Versions; principal and assigned scope; URI; request time; observed result and server-side record. |
| Reader cannot write | Use a read-only principal to attempt a write to a controlled document. | Confirm whether the write is denied and whether stored state remains unchanged. | Principal and scope; URI and starting revision; request time; response/result; state before and after. |
| Revocation and rotation | Revoke or rotate a test credential, then make a new request with the old and replacement credentials. | Observe whether each credential is accepted or rejected under the deployed validation and session behavior. | Versions; principal; credential identifier (not secret); change time; request times; observed results. |
| Update visibility and index lag | Client A updates a known document; Client B checks the document and searches for it. | Record when the document read reflects the update and when search results reflect it; do not presume the same timing. | URI and revision; writer/reader principals; write, read, and search times; results and index status if exposed. |
| Concurrent edits from one base revision | Both clients prepare edits from the same starting revision and submit them in a controlled test. | Record the actual outcome and resulting state; do not assume conflict detection, serialization, or automatic merge. | Base and resulting revisions; versions; principals; submission/response times; response/result; final state. |
| Lost write response | Interrupt or simulate loss of the client response after a write attempt. | Inspect current document state and revision before deciding whether to retry. | Request identifier if available; URI; principal; attempt and inspection times; observed state; retry decision. |
| Reconnect or restart | Reconnect a dropped HTTP stream or restart the local stdio proxy and client. | Record whether the deployed client re-establishes its supported connection and what state or credentials it requires. | Versions; principal; process/session details available; disconnect, restart, and reconnect times; observed result. |
Shared knowledge and client-owned state
A shared backend makes stored knowledge available to multiple clients; it does not synchronize their live conversations or guarantee that they produce the same answer. Retrieval results and responses can differ because clients may use different instructions, context, and tool workflows. Optional lifecycle plugins are separate integrations for session events; they are not required for ordinary knowledge tools and should not be confused with MCP's shared record access.
| Concern | Shared backend | Individual assistant |
|---|---|---|
| Stored knowledge | Shared records and permissions, subject to the backend's storage and access rules | Reads and writes through the configured tools |
| Conversation state | Not automatically shared between clients | Active conversation, context, and reasoning state remain client-owned |
| Credentials | Scoped per-principal credentials are checked by the backend | Local client approval is not a substitute for backend authorization |
| Lifecycle behavior | Optional lifecycle integrations may be configured separately | Client-specific session events and plugins |
Rollout, ownership, and stop/go checks
Assign an owner for backend operations, credentials and access review, client/proxy version tracking, and the test record. Roll out to two clients first; expand only after the team has reviewed the actual results and accepted any observed limitations.
- Pin and document the deployment: Record backend, client, and proxy versions, selected transport, and the supported authentication path.
- Define access and ownership: Assign a backend operator and set scoped credentials for named principals. Document who grants, rotates, and revokes access.
- Run the two-client checks: Test revision reads, allowed and denied access, read-only behavior, revocation, index visibility, same-base edits, lost responses, and reconnects. Preserve the observed results and evidence.
- Go or stop: Expand to a pilot group only when access boundaries and recovery procedures behave as intended and the team accepts measured index lag and write behavior. Stop and investigate any unexpected access, state change, or unrecoverable result.
- Review after expansion: Monitor the agreed operational signals and review access, version changes, and test coverage before adding more clients or teams.
Check the applicable AKB LICENSE for deployment terms.
FAQ
Does a shared backend share live conversations between assistants?
No. Shared records can be read through configured knowledge tools, but live conversations, context windows, and reasoning state are not automatically synchronized. Optional lifecycle plugins are separate integrations and should be evaluated independently.
Why can two assistants give different answers from the same backend?
A common backend does not ensure identical retrieval or answers. Clients may send different queries, apply different instructions, or assemble context differently. Compare the actual retrieved URI, revision, and content in each test rather than assuming the responses will match.
What happens when two clients edit from the same document revision?
The outcome depends on the deployed backend's write behavior. Do not assume that the protocol provides a conflict response or automatic merge. Record the base revision, each request and result, and the final stored state; inspect current state before retrying a write whose response was lost.
How should credential revocation be tested?
Use a test principal with a scoped credential, revoke or rotate it, and make new requests with the old and replacement credentials. Record when the change was made and how the backend treats each request. Do not treat a client approval prompt as proof that the server has authorized a principal.
Check AKB client compatibility
Review the supported clients, protocol adapters and setup guidance for your deployment.