Investor brief Synaptic · 2026

AI can write code faster than it can understand the systems it changes.

Synaptic is the persistent, auditable code-intelligence layer for coding agents and engineering teams. It turns a repository into a source-linked graph, so a change can be scoped with real evidence — instead of re-reading the codebase every time.

Synaptic6,741 nodes · 21,327 edgesfind node…min degree  0all communities
KnowledgeGraphload_graph()query_graphExtractionResultNodeIdGraphDatato_html_string()predict_impactsynaptic-serversynaptic
KnowledgeGraph · struct317 links · community 16crates/synaptic-server/src/lib.rs:L491

A real excerpt from Synaptic's own repository graph — 6,741 nodes, 21,327 edges, 154 communities.

30+languages extracted with tree-sitter, each built and tested in isolation
30read-only MCP tools exposed to coding agents
~31×fewer tokens to answer a structural question vs. reading the files (reproducible; see Evidence)
FSL-1.1source-available core; converts to Apache-2.0 after two years

01 The problem

Agents generate code well. They understand systems poorly.

To make a change today, a coding agent searches, greps, and re-reads files, reconstructs the architecture inside its context window, then edits — often without a complete, system-wide view of what the change touches. The reconstruction is thrown away after every task.

  1. InputRepository

    A large, multi-language codebase.

  2. StepSearch / grep

    Guess at relevant files by name and text.

  3. StepRead files

    Load raw source into the context window.

  4. StepReconstruct

    Rebuild the architecture from scratch, every task.

  5. StepEdit

    Change code with a local, partial view.

  6. ResultDiscover breakage

    Find the downstream impact after it ships.

↻  Repeat for the next task — the understanding is never persisted  · and the cost grows with the codebase
large repositoriesmultiple languagesservicesHTTP & gRPC APIsdatabasesqueues & eventstestscross-repository dependenciesruntime handoffs

02 The Synaptic approach

A persistent structural model of the software.

One extraction turns a repository into a queryable graph of symbols, dependencies, APIs, SQL objects, events, and runtime relationships. Every edge keeps its source location and is labeled extracted, inferred, or ambiguous — so an answer is auditable, not a guess.

  1. SourceRepositories

    One repo, a monorepo, or a federated fleet.

  2. ModelStructural graph

    A persistent graph.json of nodes and typed edges.

  3. LayersWhat it captures
    • symbols & calls
    • imports & inheritance
    • HTTP · gRPC · queues · IPC
    • SQL tables, indexes, RLS
    • tests & ownership
  4. QueryAgent & team queries

    Ranked subgraphs, reverse impact, structural search — from CLI, REST, or MCP.

  5. AnswerSmall, cited context

    A relevant slice plus blast radius and evidence — not the whole codebase.

The difference
Instead of stuffing raw source into a context window for every task, an agent queries a model that already knows the structure — and each answer points back to the exact files and relationships it came from.

03 What it does

Four things it does for a change.

Grouped from the capabilities shipping in the product today.

Understandretrieve

Find the relevant slice, not the whole repo

Ranked subgraph search, source reading, shortest paths, community structure, and per-file outlines.

  • Relevance-ranked subgraph for a question query_graph
  • Structural search over kind, visibility, fan-in/out, paths SynQL
  • Read a symbol's source or a line range get_source
Predictforecast

See the blast radius before the edit

Reverse traversal connects a change to callers, references, dynamic risks, and the tests that cover it.

  • Reverse impact: what depends on this affected
  • Forecast at-risk APIs, tests, cycles, and risk score predict
  • Predictive test selection for a diff affected_tests
Verifyprove

Ground the answer in evidence

Provenance on every edge, real test execution, and honest handling of what static analysis cannot see.

  • Every edge tagged EXTRACTED / INFERRED / AMBIGUOUS
  • Run the at-risk tests for real in a throwaway worktree speculate
  • SQL performance & security audit over the graph sql audit
  • Flag unreliable “0 dependents” from dynamic dispatch hazards
Connectspan

Follow the handoff across the seam

Dependencies that are not imports — protocols, processes, languages, and repositories.

  • Cross-language edges: HTTP, gRPC, queues, IPC, FFI
  • Cross-repository federation with real edge resolution
  • Read-only MCP tools for coding agents 30 tools
  • Time-travel diff across git history diff

04 Benchmarks & evidence

Evidence, and its limits.

These are the current reproducible benchmarks — on Synaptic's own code and a hand-labeled corpus. They validate correctness on representative shapes, not universal production accuracy.

Token economy~31×

Fewer tokens to answer a structural question than reading the files it references (27–38× across six questions). Exact cl100k counts on Synaptic's 199-file, 510,966-token source.

Blast-radius recall100%

On the hand-labeled corpus, with 0 distractor nodes leaked — the impact walk is not over-broad.

Cross-language F1100%

Across five boundary kinds and six couplings, with six look-alike distractors correctly left unconnected.

Correctness metricResultScope
Call edges (P / R / F1)100 / 94 / 9617 labeled edges
Blast-radius recall / exclusion100% / 100%distractor nodes held out
Affected-test recall100%multi-hop; unrelated test excluded
Cross-language (P / R / F1)100 / 100 / 1006 couplings, 6 look-alike distractors
Corpus size11 fixtures · 6 language families · 41 labeled symbols (all resolved)
Read honestly
The correctness corpus is intentionally small and hand-verified. It validates extraction correctness on representative shapes, not internet-scale coverage.
Call-edge recall is 100% for Python, TypeScript, Java, and Go, and 50% on Rust, where cross-file call resolution is intra-file by design; reachability is still preserved through imports edges.
Change-forecast confidence is calibrated per repository. On this repo's own squash-heavy history the skill score is negative — the metric correctly refusing to trust a miscalibrated predictor.

05 Why now

The bottleneck is moving.

Models keep getting better and cheaper at generating code. As agents take on larger changes across bigger systems, reliable understanding of those systems — not generation — becomes the constraint. That layer looks like infrastructure.

YesterdayHuman understands, human writes

A person holds the mental model and makes the change.

TodayHuman + AI write

Agents draft code; a person still supplies and checks the system context.

TomorrowAgents plan and modify large systems

Larger, multi-file, cross-service changes made with less human mediation.

Required infrastructure
persistent understandingimpact analysisverification

06 Technical moat

Why this is hard to copy.

The value is in the extraction and the graph, not a prompt wrapper. This is infrastructure work.

01

Deterministic extraction

Structure comes from tree-sitter parsing across 30+ languages, each grammar built and tested in isolation in CI — not from a model that might hallucinate an edge.

02

Typed cross-language edges

Calls, imports, inheritance, HTTP/gRPC/queue/IPC/FFI handoffs, and SQL lineage as first-class typed relationships, resolved across service and language boundaries.

03

Evidence & provenance

Every relationship is labeled EXTRACTED, INFERRED, or AMBIGUOUS, and unresolved dynamic dispatch is surfaced as a hazard rather than invented.

04

Cross-repo federation

Separate repositories federate into one graph with real cross-repo edge resolution, so architecture stays visible past a single repo boundary.

05

Incremental indexing

File watching, git hooks, and per-commit caching keep the graph current without a full rebuild; an AST cache makes warm rebuilds fast.

06

Agent-native surface

A read-only MCP 2026-07-28 server with stateless discovery and 30 tools gives agents ranked, cited context. The graph is built for machines and humans alike.

07 Who we're building for

Who uses it, and who could pay.

The product capabilities ship today. The commercial packaging below is where they turn into what an organization buys.

  • 01Engineering organizations deploying coding agents at scale
  • 02Teams on large, multi-service or multi-language codebases
  • 03AI-native development platforms that need structural context
  • 04Platform and developer-infrastructure teams
  • 05Organizations where an incorrect automated change is expensive

Where this becomes enterprise value

  • Agent context infrastructure
  • CI change-risk & affected-test selection
  • Architecture intelligence & ownership
  • Cross-repository dependency analysis
  • Governance, audit, and provenance

Current product capability and future commercial packaging are called out deliberately. Nothing here implies traction that does not yet exist.

08 Business model

Open-core to infrastructure.

This is the current strategy, not a finished go-to-market. The engine is source-available; the hosted and enterprise control plane is where revenue is designed to sit.

01 · CoreOpen source

The source-available engine (FSL-1.1-ALv2) drives adoption and trust with individual developers.

02 · TeamsHosted platform

A managed control plane adds shared graphs, hosted MCP access, history, and roles.

03 · EnterprisePrivate infrastructure

Self-hosted deployment, signed licensing, identity, governance, and support.

Developer$0forever
Developer MCP$10per account / mo
Team$18per seat / mo
Business$32per seat / mo
Enterprise~$48kper year, scoped

09 Traction & velocity

Built solo, shipping fast.

The story here is development velocity and surface area, not vanity metrics. Everything below is verifiable in the repository.

37tagged releases, v0.1.0 → v0.6.4
30+languages · 30 read-only MCP tools
2deployment modes: managed Cloud and self-hosted Enterprise
1founder — engine, platform, and docs
Release cadence
v0.1.0v0.2.12v0.3.15v0.4.0v0.5.0v0.6.0v0.6.4

10 Competitive landscape

A category between search and analysis.

Synaptic does not replace the editor, code search, or the security scanner. It preserves a structural answer those tools can consume.

01Code search & navigation

Sourcegraph · SCIP

Strength

Compiler-backed definitions and references.

Synaptic adds

Dependency and impact paths, including inferred runtime handoffs, with source-linked caveats.

02AI coding context

Cursor · Copilot

Strength

Semantic retrieval into a coding session.

Synaptic adds

A persistent graph queryable again from editor, CLI, CI, REST, or MCP.

03Static & security analysis

CodeQL · Semgrep

Strength

Purpose-built data-flow and taint analysis.

Synaptic adds

Everyday architecture, blast-radius, test-selection, and SQL-lineage questions.

04Embeddings / RAG over code

Vector retrieval

Strength

Fuzzy recall of similar-looking code.

Synaptic adds

Exact, typed relationships with provenance — not similarity.

Synaptic's thesis: persistent, queryable, source-linked structural intelligence designed for both humans and agents — the layer underneath coding agents, not another wrapper around them.

11 Team

One founder, full stack.

FounderColin VaughnSolo founder & engineer

Designed and built Synaptic end to end: the Rust extraction engine and graph, 30+ language extractors, the reproducible benchmark suite, the MCP integration, and the hosted Next.js control plane deployed on GCP.

See the work on GitHub

Synaptic is a solo-built project, and the surface area above is the case for the founder: a source-available engine, a hosted platform, and a reproducible benchmark suite shipped to public release v0.6.4 — engineering-led, with evidence over claims.

The near-term hiring plan follows the work — extraction coverage, platform reliability, and go-to-market — as usage warrants it.

12 Current investors

None yet.

Synaptic has taken no outside investment. It has been built independently by its founder. The zero here is deliberate — a starting point, not a placeholder.

Code intelligence is becoming infrastructure. Let's talk.

We're beginning conversations with investors who believe reliable, auditable understanding of software will be core infrastructure for autonomous development. No round terms are set here — this is the opening of that conversation.