Sinapt and the Queryable Company
Sinapt proposes a shared retrieval layer for engineering knowledge. The design questions are source coverage, access control, provenance, evaluation and usable interfaces—not an assumed productivity multiplier.
Engineering knowledge can be distributed across code, documents, tickets, chat and meeting records. An agent may need several of those sources to answer one question. The design problem is to retrieve relevant, authorized and current evidence without rebuilding the same context manually for every task.
Call it the knowledge tax. You pay it in re-explaining yourself to ChatGPT for the third time today. You pay it in the engineer who can't remember which Slack channel had the production decision. You pay it in the agent that hallucinates because the actual answer was in a Granola transcript nobody indexed. You pay it in every onboarding that takes three months because most of the company isn't written down anywhere a human, let alone a model, can find.
Reducing that repeated work is a hypothesis worth testing. It is not a guarantee that one knowledge architecture determines which companies succeed.
This is the bet behind Sinapt — the knowledge base I'm building, agent-first, for the AI-native era.
From scattered sources to usable context
Public web indexing offers a useful analogy: information becomes easier to use when it is discoverable. Internal knowledge adds a stricter requirement—discoverability must respect the reader’s authority to access each source.
For an internal system, the question is which sources an authorized agent needs, how fresh they must be, and how the answer will retain provenance. A single interface is useful only if it preserves those distinctions.
A retrieval layer can connect some of those sources. Existing documentation and human collaboration still matter; an index does not create knowledge that was never recorded.
A proposed distinction to evaluate
Existing knowledge platforms differ in their connectors, search, permissions, APIs and agent integrations. It would be inaccurate to treat Notion, Confluence and Glean as one product that only indexes pages created inside its own interface.
A meaningful comparison needs a dated feature matrix and representative tasks. Check supported sources, permission propagation, retrieval quality, API access, export behavior and operating cost for each candidate.
Sinapt’s proposed emphasis is a neutral retrieval layer that different agent runtimes can call. MCP, REST and CLI interfaces are design targets; they need implementation and compatibility testing. A web interface would support curation and administration.
| Design target | Evidence needed before claiming it works |
|---|---|
| Multiple source connectors | Freshness, failure recovery and source provenance tests |
| Agent and application interfaces | Versioned contracts and host compatibility checks |
| Portable Markdown export | A tested complete export and documented omissions |
| Scoped retrieval | Authorization and revocation tests, including derived content |
| Documented data handling | Applicable storage, retention and upstream provider terms |
The useful distinction is the intended integration and operating model. It does not establish that existing vendors cannot support agents or that a new product is superior before evaluation.
What "queryable by AI" actually means
For this proposal, queryable knowledge means several requirements must work together:
- Retrieve from authorized sources with provenance and freshness metadata.
- Enforce access controls before returning content, including summaries derived from restricted inputs.
- Persist source material independently of a single conversation.
- Offer documented interfaces for supported agents and applications.
- Provide tested exports and explicit data-retention and provider-processing terms.
These are design targets. An open-source CLI, an MIT license, connectors and hosting options should be described as available only after they have actually shipped.
A proof of concept should test the riskiest requirements first. A feature checklist alone cannot establish reliable infrastructure.
The knowledge tax compounds
Let me get specific about the cost of the alternative.
Consider a hypothetical 50-person team spending 30 minutes per person per working day assembling context. That is 25 person-hours daily. With an assumed 250 working days, it becomes 6,250 hours; at an illustrative fully loaded rate of $100 per hour, the associated effort is $625,000. This is arithmetic, not measured waste or fully recoverable savings.
Some context assembly is useful reasoning and cannot simply be removed. A trial should measure the portion changed by retrieval, the maintenance work added, and the effect on answer quality.
Evaluate time and correctness separately. A faster answer that retrieves stale or unauthorized evidence is not an improvement. No productivity percentage is established by the example above.
Why I'm building Sinapt myself
The product explores how a shared retrieval layer could reduce repeated context assembly across engineering workflows. That is the motivation to test, rather than a conclusion supported by personal usage totals.
The market already contains capable search and knowledge products. Sinapt needs to demonstrate a useful integration model and measurable results on its intended tasks, not rely on a generalized dismissal of competitors.
Sinapt is the bet that there's room for a clean stack — built agent-first, vendor-neutral by design, two decades of engineering judgment applied to a problem the AI-native era created. The manifesto is here, the landing page is here, and the architectural decisions are being published on this blog as I make them.
The roadmap is honest: Phase 1 (architecture lock-in — infrastructure, search engine, contract surfaces), Phase 2 (proof of concept), Phase 3 (MVP with team support, integrations, billing), Phase 4 (public launch). No deadlines. Each phase ships when it's ready. The Sinapt Cockpit — the unified driving surface for Claude Code, Codex, and your existing CLIs — comes after the knowledge base has paying customers.
Self-hosting, a portable source format and an open-source CLI are roadmap choices. Their final scope and terms must be documented as the implementation develops.
The deeper signal
Standards for agent integrations and workload identity make this design practical to investigate. Their existence does not establish product demand, adoption rates or a measured business benefit.
A useful pilot starts with a bounded source set and representative questions. Compare the proposed layer with the existing workflow, including maintenance and permission failures as well as successful retrievals.
More indexed material is not automatically better context. Evaluate relevance, duplicate or conflicting sources, freshness and the ability to abstain when the available evidence is insufficient.
Where to go from here
If any of this resonates — the knowledge tax you're paying, the gap between what your agents could do and what they actually do, the suspicion that the wiki paradigm isn't going to scale into the next era — go read the rest at sinapt.ai. The full thesis is there. The architecture, the integrations, the security model, the roadmap. Plus the alpha-drop list — single email when there's something to try, no marketing, no newsletter, just the signal.
If you want the longer-form thinking: the Sinapt manifesto walks through the two-products structure (knowledge base + cockpit). The Cockpit explains the unified-driving-surface pattern. The Knowledge Equation is the architectural prior on why context architecture matters more than prompt cleverness. The Knowledge Base That Builds Itself is the operational pattern Sinapt makes shippable for everyone.
For a team with fragmented context, the practical question is whether a shared retrieval interface can improve a defined workflow while preserving source permissions and provenance.
Sinapt is the bet that the answer can be yes.
