Connect Agents Without Surrendering Control
Let Claude, Codex, and other tools share the wiki through narrow interfaces, policy, and reviewable writes.
By the end
You can expose safe read and write operations, coordinate concurrent agents, protect private scopes, and prove which tool changed what.
Expose capabilities, not the whole machine
An agent does not need unrestricted filesystem access to answer a question. Define narrow operations such as search_sources, read_page, propose_page, apply_approved_patch, and run_lint. Start read-only, add proposed writes next, and reserve direct mutation for deterministic reversible work. Tool inputs, outputs, user scope, and failure behavior are part of the security boundary.
Use MCP as an interface, not a trust shortcut
Model Context Protocol can expose the same resources and tools to multiple compatible clients. It solves transport and discovery, not authorization, correctness, or auditability. Describe tools precisely, validate inputs server-side, restrict roots and user scopes, return stable IDs, and make proposal and apply operations unmistakably different.
Keep one durable operating contract
Claude, Codex, and other tools may use different instruction files, but knowledge rules should derive from one canonical policy. Preserve the same schema, retrieval order, approval gates, and verification expectations across clients. Tell agents how to recover from ambiguity: search the index, read the schema, stop before destructive work, and report missing evidence.
Coordinate writers with revisions and patches
Two agents can read the same page and propose incompatible updates. Every write should declare the revision it read; if the page changed, reject the stale patch. Use Git branches or worktrees for multi-file changes and optimistic revision checks for smaller operations. Preserve authorship, source IDs, and the reason for each edit.
Match approval to consequence
Reading a public reference is low risk. Deleting a source, merging identities, changing a current decision, exporting private content, or publishing externally has greater consequence. Ask approval at the point where the exact patch and impact are known. Record actor, client, tool, scope, files read, files changed, validation, and rollback reference in the receipt.
Working reference
Commands and patterns
[Starter repo] Create a review branch
git switch -c agent/wiki-update-001
An isolated branch makes a multi-file agent edit reviewable and reversible.
[Starter repo] Review exact wording changes
git diff --word-diff main...HEAD -- vault/Wiki vault/System
Word-level review exposes changed claims and instructions rather than only file counts.
When the happy path breaks
Failure modes
Symptom
One agent can modify private knowledge unrelated to its task.
Likely cause
Its tool is scoped to the whole vault and relies on prompt instructions for safety.
Recovery
Use least-privilege roots and typed operations, enforce scope server-side, and test denied paths.
Symptom
Two valid edits silently overwrite each other.
Likely cause
Writes lack expected revisions and merge review.
Recovery
Reject stale writes and merge through an inspectable patch.
Symptom
An approval says update wiki without explaining the impact.
Likely cause
Approval is requested too early and broadly.
Recovery
Show exact pages, claims, links, and access changes before asking for bounded approval.
Hands-on lab
Give two agents safe access to one vault
Share reads and proposals while keeping application under operator control.
- 01Define read, search, propose, lint, and apply operations with structured inputs and outputs.
- 02Expose only read and search to both clients at first.
- 03Ask both clients the same question and save citations and retrieval paths.
- 04Let both propose a change to the same revision of one page.
- 05Apply one proposal and prove the second is rejected as stale.
- 06Regenerate, approve the bounded patch, and save the operation receipt.
Deliverable: A two-client demo with shared reads, conflict-safe proposals, one approval, and one denied stale write.
Reusable artifact
Agent knowledge-access policy
A capability matrix for every agent and integration.
Client or agent: User and project scope: Allowed source classes: Allowed read operations: Allowed proposal operations: Direct-write operations: Always-requires-approval operations: External model and data-transfer policy: Expected revision requirement: Receipt destination: Revocation procedure:
Before you move on
Receipt checklist
- Capability matrix for each connected client.
- Shared read with identical stable citation IDs.
- Rejected stale-write attempt.
- Approved patch and receipt with rollback reference.
Primary sources
