Synapse, an AI company brain that can't leak across teams

IncrediPets is a pet-care services company of about 300 people. Its operating knowledge lived in Notion pages, Slack threads, spreadsheets and people’s heads. There was also a “company brain”: a set of markdown files that people read and edited in Obsidian and synced by hand. It worked for people who were comfortable with git. It shut out everyone else, and it had no way to keep finance or HR material away from people who should not see it. In June 2026 I built Synapse to replace it.

The problem#

• Answers were slow to find. New joiners took weeks to find basic process answers, and department leads answered the same questions again and again.
• The existing brain needed technical skills. Reading or updating it meant a manual pull, an edit and a manual push. Non-technical teams such as CX, supply, HR and sales could not realistically use it.
• There was no segmentation. Anyone with access to the repository saw everything, or nothing. There was no way to ask for one section.
• Sensitive material was stuck. Finance and HR documents could not go into any shared search tool, because nothing controlled who could read them.

So the real question was not “how do we add AI search?” It was “what would it take for leadership to trust that a question from one department can never be answered from another department’s documents?”

The first design, and why I dropped it#

My first design, built as a proof of concept on 13 June, made GitHub the source of truth: one private repository per segment, a desktop app running git underneath, and repository collaborators as the access layer. The proof of concept worked. It had per-user access, locked and unlocked views, a request-access flow and a linked graph of documents.

It did not survive review. Leadership questioned whether it was feasible, and on 16 June, after a review with the CTO, we dropped it for three reasons:

1. Every user would need a GitHub account and a separate grant for each segment. The audience was mostly non-technical staff, so that cost fell on exactly the wrong people.
2. Git was leaking into the experience. Merge states, conflicts and per-repository cloning are concepts I wanted to hide, not teach.
3. Access was tied to repository boundaries. Every change was a collaborator edit, and a company-wide view for leadership needed a bot to keep the repositories in step.

The replacement was a single server that owns the content, with one folder per department. It signs people in with phone and OTP and decides access on the server. Git left the runtime entirely, and the first build on the new design shipped the next day.

The access model came first#

I treated segmentation as the product, and the answers as a feature on top of it.

• Seven departments: HR, supply, finance, operations, tech, product and marketing. The first version had nine content segments. I collapsed them into seven departments, which are the units people already belong to.
• Two tiers. Admins see every department plus an admin-only area. Everyone else sees only the departments on their record, and one person can belong to several. An earlier design had a third “lead” tier between them. I cut it, and admins approve access instead.
• Identity from the existing employee directory. A person’s role and departments are fields on the record the company already keeps. There is no separate access file to drift out of date, and someone removed from the directory can no longer sign in.
• Decided once, at sign-in. The session token carries the user’s resolved departments. The server returns files only from those departments, refuses the admin area to everyone else, and rejects any file path that tries to escape the content folder.
• Asking for access is part of the product. A locked department shows a “Request access” button. An admin approves it in the app, the department is added to that person’s record, and their next sync picks it up.
• A scanner before content goes in. An admin-only check looks for email addresses, phone numbers, Aadhaar numbers, database connection strings, API keys and tokens in every document, so sensitive data is caught before a department is opened up.

I showed this hierarchy to leadership before the AI was tuned. Trust in the walls was the adoption blocker, not answer quality.

Grounded answers on top#

People ask questions in plain language. The answer layer retrieves from the synced company documents and generates an answer only from what it retrieved. Because the department scope is applied at retrieval, a finance document never reaches the model for someone outside finance, however the question is worded. When nothing relevant comes back, Synapse says “I don’t have that” instead of producing a fluent guess. A wrong answer about a process costs more trust than a missing one.

Distribution with no IT in the loop#

• A desktop app, not another tab. Part of the audience was field-operations staff on shared machines. An Electron app with a tray icon and tolerance for patchy connections fit that better than one more browser tab. A web client covers browsing, editing, the document graph and the admin panel.
• Sync that stays out of the way. The desktop client pulls only the departments a person can see, compares file hashes and uploads local edits. In testing, a local edit reached the server in about a second. It syncs on login, every 30 minutes and on “Sync now”. If the local copy is newer, it is queued for upload and never overwritten.
• Silent auto-update. Internal tools die when updating needs IT. The app checks a version feed and updates itself, so weekly releases reached people without anyone noticing.
• Sign-in on the existing directory. Mobile number and OTP, matched to the employee record. Nobody had a new password.

Results#

• 290+ users registered across the company, in 7 departments, each with its own retrieval scope.
• 6 days from proof of concept to company-wide launch: proof of concept on 13 June, production OTP and the seven-department model live on 19 June.
• Weekly releases shipped through auto-update, up to v0.4.

What is still open#

• Concurrent edits. The conflict rule is “newest file wins”, which is fine for one editor and crude for several. Leadership asked for a proper conflict-resolution layer. I specced a write gate with a moderator agent for each department, and it was approved on 22 June. Switching moderation on depended on my review of a brief for each department, and that review was still pending at the end of June.
• No audit trail for writes yet, and access requests do not notify admins. Admins have to check the requests view.
• What I’d do differently: I would write down who the users are before choosing the source of truth. I started with GitHub because that is where the brain already lived, and I spent three days proving a design whose cost fell on the people least able to pay it.