Two agent patterns running on Neo4j: a fraud investigation agent and a claims and CRM intelligence agent. Each answers in plain language and renders the connected entities as a live graph. Every screen below is the working software.
How the agents actually work, under the chat window: a prompt-driven query engine that turns a question into a validated, read-only query and narrates the result with every number traceable to a row.
And the full stack under each bot. Two agents, two frontends, one discipline: known intents short-circuit to deterministic queries, only novel questions reach the LLM (PII-sanitized on the API boundary), the user sees full results because the bot is gated to their own database access, and a semantic cache learns past questions to trim the prompt over time.
The same investigative pattern as a fraud ring, on a different graph. A multi-agent on-chain forensics pipeline: 10,000+ ledger events across six chains, scam-token filtering, FIFO cost-basis reconstruction, liquidations hash-verified twice against pool logs, and live liquidation risk read straight from the lending contract, not an indexer. Below is a sample report on synthetic data, so you can see the output.
The same build discipline runs a second live system: a decade of NBA data, queried in plain English, served over the same kind of OAuth-secured MCP layer. Public data in, plain-English answers out.
One HTTPS port. Every request is identity-checked, entitled per service, and read-only enforced at the backend before it ever reaches a database. This is the reference pattern I deploy, drawn generic.
Consulting firms bill $200K and up per contractor a year to find someone who can turn your data into working AI. One of them offered to place me with a client at $130 an hour to build exactly that.
Fixed price, proven in production at Fortune 50 scale, ops and governance included. One principal who has shipped the exact pattern. No firm in the middle.
An independent lab build, run solo on my own time. The full entity-resolution and knowledge-graph governance stack Vertex delivers: 58.8 million records resolved into 44.5 million entities on Neo4j, with survivorship, ontology enforcement, validation, access policy and audit on top. Every number below was measured.
%%{init: {"theme":"base","themeVariables":{
"background":"#0d1826",
"primaryColor":"#16293f","primaryTextColor":"#eaf2fa","primaryBorderColor":"#3d6690",
"secondaryColor":"#16293f","tertiaryColor":"#16293f",
"lineColor":"#7fa8cf","textColor":"#eaf2fa",
"clusterBkg":"#101f31","clusterBorder":"#3d6690",
"edgeLabelBackground":"#0d1826",
"fontSize":"16px","fontFamily":"ui-monospace,SFMono-Regular,Consolas,monospace"
},"flowchart":{"useMaxWidth":false,"nodeSpacing":45,"rankSpacing":60,"padding":14}} }%%
flowchart TB
subgraph OUT["OUTSIDE THE GRAPH"]
SRC["Source systems
CRM · SupportDesk · Snowflake"]
TTL["customer.ttl
the ontology, in git"]
WH["Warehouse
bulk rows never enter"]
AG["Orchestrator / agent
MCP · External Service · Apex"]
end
subgraph BATCH["RUNS ON A SCHEDULE"]
SR["SourceRecord
immutable, never edited"]
PII["Email · Phone · Address · GovId
shared value nodes, not properties"]
TB["Ontology compiled in
23 classes · 13,500 entailments"]
MAP["Mapping registry
versioned · 29 bindings"]
SC["Score · tier · hard guards
hard identifier vetoes"]
CE["CanonicalEntity
one person, N sources"]
PE["PersistentEntity
durable id · held across reruns"]
SV["Survivorship
ranked per-attribute authority"]
DE["DecisionEvent
why every choice was made"]
end
subgraph ASK["RUNS WHEN SOMETHING ASKS"]
RT["Semantic router
graph · vector · push-down"]
CA["Cache with literal guard"]
QP["Query planner
traverse or push down"]
TI["Governed tool call
policy checked · refusals recorded"]
end
SRC --> SR
TTL --> TB
SR --> PII
TB --> SR
MAP --> TB
PII --> SC
SC --> CE
CE --> PE
CE --> SV
SV --> DE
PE --> DE
AG --> TI
TI --> RT
RT --> CA
RT --> QP
QP --> WH
RT --> CE
TI --> DE
style OUT fill:#101f31,stroke:#3d6690,color:#9fc4e5
style BATCH fill:#101f31,stroke:#4a7fb5,color:#9fc4e5
style ASK fill:#101f31,stroke:#3f9c85,color:#8fd4c0
style SC fill:#1b3550,stroke:#6ea8e0,color:#eaf2fa
style PE fill:#1b3550,stroke:#6ea8e0,color:#eaf2fa
style RT fill:#14332c,stroke:#4fb89c,color:#eaf2fa
style TI fill:#14332c,stroke:#4fb89c,color:#eaf2fa
style QP fill:#14332c,stroke:#4fb89c,color:#eaf2fa
style CA fill:#14332c,stroke:#4fb89c,color:#eaf2fa
Five sources disagree about who your customers are. The build decides which records are the same person, which value survives when they disagree, and writes a record saying which source won and what it beat. Source records are never overwritten, so every merge is reversible. Ambiguous cases escalate to a data steward instead of merging on a guess.
Most pipelines key a customer on a cluster id that changes every run, so nothing downstream can hold a stable reference. identities held across 26 reruns, two perturbation scenarios and a corpus migration. Every disappearance carries an event explaining it.
Legal does not say "protect this column." They say people like this should not see data like that. The rules live as data, not code, and the realistic case is not blocking a query but returning the customer with one field masked. Changing one rule flipped two outcomes with no deployment.
The ontology lives in git as OWL 2, with hasKey and functional-property semantics. HermiT checks the class model, OWL 2 RL cross-checks the reasoning, and the same constraints compile to Cypher that runs conformance over the full 44.5M-entity graph. SHACL validates the shapes on top. The schema is enforced, not just documented.
PII sits in a vault with materialised masks, behind attribute-based access policy stored as graph data and a native two-entitlement RBAC floor. Every read gets a per-field audit decision: who asked, which rule fired, what was masked.
Memory-bound stages rewritten to stream. Vector index builds sharded to fit the hardware. Deploys audited for drift against the mapping registry, and every check paired with a negative control, so a pass proves the check can actually fail.
A diagnostic against your real environment, where governed AI query access surfaces what your current workflow misses.
A working agent on your data. The fraud, call-center, or document pattern applied to your use case, with the ops and governance layer included.
A standing monthly engagement after a build lands: architecture reviews, governance oversight, and a roadmap that keeps the system healthy.
A 30-minute walkthrough shows governed AI on your Neo4j or MongoDB, live, on real data.
tarikalem10@gmail.com ›