DEV Community: Gautam K

Some pills are treating other pills: building Domino on FalkorDB

Gautam K — Sun, 18 Oct 2026 17:30:39 +0000

Graph Hacks 2026 · WeMakeDevs × FalkorDB · Try it live: domino.gautamkhosla.com · 3-minute video · Code

Beatrice is 84. In eighteen months she saw five prescribers. Her family doctor started amlodipine for her blood pressure. Seven weeks later her ankles were swollen, so a walk-in clinic prescribed furosemide. Her potassium dropped, so potassium chloride followed. The furosemide made her rush to the bathroom and sometimes not make it, so a urologist added oxybutynin. Oxybutynin is strongly anticholinergic, and a few months later she was confused enough that a geriatric clinic started donepezil for her memory.

Every one of those prescriptions was reasonable on its own. Together, four of her nine medicines may exist only because of the first one.

Beatrice is synthetic. The pattern is not. Geriatricians call it a prescribing cascade: a side effect is mistaken for a new illness and treated with another drug (Rochon and Gurwitz, BMJ 1997). In 2022, 38 clinicians from six countries agreed on nine cascades that usually do more harm than good (ThinkCascades). In 2025, a study of 533,464 older adults in Ireland found a diuretic was 1.93 times more likely to be started after a calcium channel blocker than before it.

I built Domino, a team of AI agents that find these chains in a FalkorDB graph, prove every link, and hand a pharmacist one question: could the swelling be from amlodipine?

The insight: a cascade is a path

Take the medicine out of it and a cascade is five things: drug A starts, a side effect of A appears in its usual time window, someone misreads it, drug B starts to treat it, and the whole thing repeats from B. Every fact needed to see this already exists: prescription dates in the pharmacy record, side effects and indications in public labelling. What's missing is the connection, because the facts are written by different people, months apart.

That's a graph problem. Drug → side effect → drug → side effect → drug. In SQL it's a pile of self-joins that breaks with every extra hop. In Cypher it's one pattern:

MATCH (p:Patient {id: $pid})-[:TAKES]->(m:Drug)
WITH p, collect(m.id) AS meds
MATCH (p)-[:TAKES]->(a:Drug)-[:CAUSES]->(:Effect)-[:TREATED_BY]->(:Drug)<-[:TAKES]-(p)
WITH DISTINCT a, meds
MATCH path = (a)-[:CAUSES|TREATED_BY*2..6]->(z:Drug)
WHERE z <> a AND all(n IN nodes(path) WHERE NOT n:Drug OR n.id IN meds)
RETURN [r IN relationships(path) | [startNode(r).id, type(r), endNode(r).id]] AS hops

On FalkorDB this returns all forty of Beatrice's candidate paths in about a tenth of a second.

Modelling choices that made the queries simple

Point both edges forward. CAUSES goes drug → effect and TREATED_BY goes effect → drug. With both directed "downstream", any directed path over those two types alternates drug, effect, drug, effect on its own. The query needs no alternation logic at all.

One node type for side effects and diagnoses. A cascade is a side effect being treated as a diagnosis, so "ankle swelling" is the same Effect node whether amlodipine causes it or a patient HAS it. That makes "does the second drug have another reason?" a two-hop pattern: (p)-[:HAS]->(c:Effect)-[:TREATED_BY]->(b).

Dates as integers. TAKES.start is a day number, so timing ("B started 48 days after A, inside amlodipine's 7 to 120 day window for edema") is arithmetic, and the population query can count "B after A within a year" in a single aggregate.

Knowledge as nodes, not code. The 27 documented cascades are Pattern nodes linked to drug classes and the effect between them. Matching a link to the literature is a traversal: (a)-[:IN_CLASS]->()<-[:INDEX]-(pt)-[:VIA]->(e). The same goes for dangerous combinations like the "triple whammy" (an ACE inhibitor, a diuretic and an NSAID together), and for class conflicts used when suggesting alternatives.

Agents that use the graph as their tools

Domino's three agents only know the world through fourteen tools, and every tool runs named, parameterised Cypher from a catalog of 105 queries. Read tools run as GRAPH.RO_QUERY, so the database itself refuses a write, even if a bug or a prompt injection tries one.

The Detective walks the paths, finds loops (oxybutynin causes confusion, which donepezil treats; donepezil causes incontinence, which oxybutynin treats), checks side-effect pile-ups and combinations, and records findings back into the graph.
The Pharmacist explains each root's evidence, looks for alternatives that treat the same diagnosis without that side effect and without clashing with anything else the patient takes, runs FalkorDB's betweenness centrality to find the chokepoint drugs where cascades meet, and simulates the untangle.
The Scribe writes review tasks, an SBAR note for the prescriber and a plain-language note for the family.

The untangle is my favourite piece. It's a fixed-point computation over the cascade links: a medicine stays justified if it has its own diagnosis or is reached by a strong link from a justified medicine. For Beatrice, "what if amlodipine were reviewed?" leaves 4 of 9 medicines, drops her anticholinergic burden from 4 to 0, and removes the triple whammy. It's labelled a simulation, because it is one.

Each agent is an LLM tool-calling loop when a key is set (Gemini, Claude, or anything OpenAI-compatible) and a deterministic planner when it isn't. The planner calls the same tools in the same order and stores the same audit trail. With no model at all, Domino still finds every cascade.

Does the graph actually matter? I test it live

The hackathon asks one question: is the graph doing work the agent could not do without it? So the landing page answers it live, not with a claim. Same question. Same model. One has a graph.

The language model gets Beatrice's whole record as plain text (every medicine, its start date, its prescriber and why it was started) and no FalkorDB. Domino's agents get the graph. Both are asked the same thing, and I slip a medicine that does not exist into the question: Zorbaxapril.

In my runs, the model on its own scored 5 of 8 and Domino scored 8 of 8. The plain model found the obvious link but missed the cascades that take several steps, like furosemide → leaking urine → oxybutynin. And it called Zorbaxapril "an ACE inhibitor" and warned it was unsafe with her other drugs: a confident answer about a medicine that was never real. Domino looked Zorbaxapril up in the graph, didn't find it, and said so.

Not in the graph is not the same as safe. That line became a rule across the whole product: any medicine a question, an EHR order or a pasted list names is resolved against the graph's full-text index, and one Domino doesn't know is named as not checked, never guessed at.

The page shows the exact prompt and the model's unedited answer, so anyone can read it and judge for themselves. Results vary from run to run, which is the point of running it live.

Memory and coordination, in the graph

Agents hand off through Handoff nodes. Each handoff is signed with HMAC-SHA256, written to FalkorDB, read back by the next agent and verified; a failed check stops the run. Before a review starts, the runner takes a lease on the patient in the graph: one MERGE with a guarded SET, atomic because FalkorDB runs writes one at a time per graph. Start twelve reviews of one patient at once and exactly one runs.

Memory comes in four kinds, all of them nodes and edges:

Episodic. Every run, every tool call (Step) and the catalog Query nodes it ran, every finding and handoff. Each run starts by saying what changed since the last review.
Semantic. Clinicians mark a link confirmed, intentional or not a cascade. Those signed Decision nodes hang off the patient and off the Pattern, so feedback accumulates across patients. Agents have no tool that writes one; a test writes a forged decision straight into FalkorDB and checks the agents ignore it.
Procedural. A Procedure node says who a review task goes to, how soon, and whether a "possible" link gets one at all. Every task a person approves or dismisses is an outcome; when the outcomes favour something else, a new version SUPERSEDES the old one and links to every task it LEARNED_FROM. At my demo clinic, prescribers acted on calcium-channel-blocker swelling tasks that pharmacists kept passing on, so those tasks now go to the prescriber, and the inbox says "routed by learned procedure v1".
Conversations. Every question and answer is a Message in a Conversation owned by one person, so "what could replace it?" resolves days later.

And because all of it is edges, provenance is a traversal: from any finding, back to the step that wrote it, the queries that step ran, the evidence and decisions it used, and forward to the handoffs that carried it and the tasks it led to. The workspace draws that as How Domino got here.

A care-team brain

Once tasks, notes, decisions and conversations live in one graph next to the prescriptions, the clinic itself becomes queryable. Who prescribed what (Prescriber nodes behind every TAKES), who on the team has handled each kind of cascade, where cascades cross from one prescriber to another, and one search over everything the team wrote, by words (full-text index), meaning (vector index) and the graph. A brain agent answers questions about all of it over MCP and cites every query. Each clinic is its own FalkorDB graph, so none of this leaks between tenants.

Did it work?

I generated 600 synthetic patients with 632 hidden cascades, plus the confounders a real record has: the same drugs prescribed for real diagnoses, deliberate pairs (stomach protection with an NSAID), and drugs started in the wrong order. Then I turned the graph signals on one at a time:

Signal	Precision	Recall
Graph links only	0.30	1.00
+ time order	0.44	1.00
+ onset window	0.59	1.00
+ other reasons	0.58	0.96
Domino	0.75	0.96

And zero of the 227 deliberate pairs were flagged. The honest caveat: the generator and the engine share one knowledge graph, so this tests the reasoning, not clinical truth. The interesting row is "+ other reasons": a charted indication raises confidence in real cascades and in deliberate pairs, so it doesn't help on its own. Only the pattern layer, which knows gastroprotection is good care, separates them.

Then the question that matters more: would it have prevented them? I replayed every prescription in the cohort as the record stood the day it was written, with the prescriber check in the way. It would have stopped 401 of the 534 cascade drugs it met at the first downstream prescription, and 510 prescriptions might never have been written. 95% of its cascade stops were real cascades. The same check runs inside an EHR as a CDS Hooks 2.0 service: sign a new order, and Domino can pause it with a card that explains why.

I also checked the medical knowledge against the real world. A script pulls current FDA drug labels from openFDA and looks for every side effect the graph claims: 249 of 265 (94%) are named in the label. The other 16 are listed in the repository with the reason for each, mostly class effects in older adults that labels word differently. Diuretic labels say "increased and urgent urination", not "incontinence", but in an 84-year-old that's what it becomes. I'd rather show that list than claim 100%.

On a single FalkorDB instance on my laptop, Domino runs about 100 to 125 full patient analyses a second, about 1,000 to 1,250 graph queries a second.

What I learned

Let an algorithm decide, and say why. FalkorDB's algo.betweenness found the chokepoints: the symptoms and drugs that sit on the most cascade routes. Among drugs, those chokepoints now set priority: a review task for a cascade through one is due in half the usual time, and the task says so. A ranking you can explain beats a ranking you have to trust.
Sequence symmetry without a graph is noisy. "Anticoagulant then beta blocker" is a strong signal in my cohort, and it's just the normal order of care for atrial fibrillation. Joining each signal to a mechanism path in the graph is what separates cascades from care pathways.
The best place to break a cascade is before it starts. The prescriber check (type a new drug, see if it treats a side effect of something already taken) became one of the most useful screens.
Fact-check the model with the graph. In one run, the model wrote a handoff calling furosemide a "chokepoint". It isn't. Now every handoff that says "chokepoint" is checked against the betweenness result before it is signed, and a wrong claim is flagged.
An honest gap beats a perfect score. The evaluation's caveats, the 16 unmatched label edges and the comparison's "results vary" note are all on the page. That's what makes the rest believable.

Try it

Open domino.gautamkhosla.com and press Take the 3-minute tour, or press Run it live to see the comparison for yourself. Six synthetic patients each tell a different story, including Dorothy: same two drugs as Beatrice, but her furosemide came first, for heart failure. Domino checks, finds the reasons, and stays quiet. That's the one I'd show a pharmacist first.

The code, the graph model and every Cypher query are on GitHub, and the demo is on YouTube.

Domino is a hackathon prototype on synthetic data. It raises questions for clinicians, and it never tells anyone to stop a medicine. I built it with an AI coding assistant (Claude, by Anthropic); the README says what I did myself.

The bug a security tool must never have

Gautam K — Mon, 05 Oct 2026 17:48:48 +0000

My security tool said SUCCESS 100 times. It kept 12.

That's not a figure of speech. It's the first entry in the changelog of mcp-pin, the tool I built and released in September, and it's the reason the changelog entry for version 0.1.0 ends with one line: Do not use it.

This post is about that bug: what happened, why it's the worst possible failure for this kind of software, and what I changed so it can't come back quietly.

If you'd rather watch than read, here's the 7 minute film about this bug and the problem mcp-pin exists for:

What mcp-pin is for

AI agents use tools through MCP servers. Each tool comes with a description, and the model reads that description as instructions. You approve a tool once. Your agent re-reads its description at the start of every session, and nothing tells you if it changed in between.

mcp-pin is a small proxy that sits between your client and a server. The first time it sees a server, it fingerprints every tool (name, description, input schema, annotations) and pins that fingerprint. Every session after that, it checks. If anything changed, the session is blocked and you get a diff.

So the whole product is one promise: I will remember what you approved.

The test

I ran one hundred pins at the same time, for one hundred different servers. Every single one reported success.

Then I looked at what was actually on disk:

log.ndjson had 100 entries with 100 unique server ids.
pins.json had 12 keys.

Eighty-eight approvals were gone. The hash chain in the log also broke five times, because log appends had the same problem.

Why it happened

0.1.0 kept every pin in one file, and updated it like this (simplified):

const pins = JSON.parse(fs.readFileSync(PINS_FILE, 'utf8'));
pins[serverId] = record;
fs.writeFileSync(PINS_FILE, JSON.stringify(pins));

Read the file, add your key, write the file back. With one process that's fine. With two processes at the same moment, both read the same old file, both add their own key, and the second write erases the first. That's a lost update, one of the oldest bugs there is. With a hundred processes, most of them lose.

Nothing threw an error. Each process wrote its own version of the file successfully. Each one printed that it had pinned the server. Each one was telling the truth about its own write and wrong about the outcome.

Why this is the worst bug a tool like this can have

A tool that crashes makes you go and look. A tool that fails loudly gets fixed.

A tool that reports success while dropping the thing it exists to keep does the opposite. It makes you stop looking. You were careful, you put a pin in front of your most dangerous server, and the tool told you it was handled.

Here's what a lost pin means in practice. To the proxy, a server with no pin looks like a first run, and a first run pins whatever the server says that day. So if the server changed its tool after you approved it, which is the exact attack mcp-pin exists to catch, the next session would quietly accept the new version as the baseline. No block. No diff.

A version of it that loses approvals while telling you everything is fine is worse than not having it, because you'd trust it. That is the worst possible failure mode for this category of software, and I shipped it in the first version.

The irony isn't lost on me. mcp-pin catches a change that happens with no signal. This bug was a change that happened with no signal.

What I changed

The fixes are in 0.1.1 and 0.1.2. None of them are clever, which is the point.

One file per server, replaced atomically. Each pin now lives in its own file, pins.d/<server_id>.json. It's written to a temp file, fsynced, and renamed into place. Two different servers can't touch the same file anymore, and a reader never sees half a write.

The log takes a lock. Appending to the log means taking an exclusive lock, reading the tail, appending, fsyncing, and unlocking. Two processes can't extend the hash chain at the same time.

Windows contends differently. The lock is a file opened with the exclusive create flag. On Linux, a held lock shows up as EEXIST. On Windows it can also be EPERM, EACCES or EBUSY, and 0.1.1 only expected the first. That shipped in a tagged release, which I withdrew before it reached npm; 0.1.2 handles all four.

The record comes first. The first pin used to write the pin file and then the log entry. If the append failed, you had a trusted pin with no public record of it. The test matrix caught it on Windows with Node 20: 16 pin files, 15 log lines. Now the log entry is the commitment, and the pin is written only after it succeeds.

Corruption fails closed. 0.1.0 treated a truncated pins.json or a garbage log as "no pins yet". For a pinning tool that's the same lost-pin failure through a different door. Now corrupt state is a hard error that names the file. A missing file is still allowed, because that's a genuine first run.

The client waits until the check is done. 0.1.0 forwarded the client's first message straight away and checked the tools in parallel, so a fast client could call a tool before the block arrived. Now client messages are queued from the start, the client gets no answer until the tools match the pin, and on drift the queue is thrown away.

What I'd tell anyone building a security tool

Test the concurrent path on day one. The bug only existed when two writes overlapped, and real setups start several servers at once.

Only claim success after the durable write. "Pinned" should mean the bytes are fsynced and the record exists, not that a function returned.

Fail closed when you can't read your own state. If a security tool doesn't know what you approved, it should stop, not assume.

Write your failures down where users will see them. The changelog for 0.1.0 doesn't soften it. If you're trusting a tool with your approvals, you should know how it has failed before.

See it work

The whole failure the tool exists for, in about ten seconds, with a harmless bundled server and nothing to configure:

npx mcp-pin@0.1.4 demo

The first session pins a tool. The second session, the tool's description starts asking for notes from your conversation, and mcp-pin blocks it with the diff.

The code, the changelog and the public log of tool changes are at github.com/GautamTalksDev/mcp-pin. The film above covers the problem and both bugs I shipped while building it.

If you run it and something looks wrong, open an issue. I'd much rather hear about it loudly.

We are building an OS for AI-built software. Here's what that means

Gautam K — Thu, 09 Apr 2026 02:59:35 +0000

Every AI code generator on the market solves the same problem: turning a prompt into code. Lovable, Bolt, v0, Replit Agent, they all race to generate faster, generate better, generate more. And they're good at it. The generation problem is increasingly solved.

But generation is maybe 20% of the software lifecycle.

The other 80%, deploying, monitoring, debugging, patching, scaling, and governing, still falls entirely on you. The moment your AI-generated app hits production, you're back in the same ops hell that existed before AI: waking up at 2am to a PagerDuty alert, tracing through logs, writing a fix, pushing to CI, hoping the deploy works. AI has made building software faster. It did nothing about maintaining it.

That's the problem we are building Solen to solve.

What Solen actually is
Solen is a platform that manages the full lifecycle of AI-built software. You describe what you want in plain language. Solen interprets it, plans the architecture, generates the code, builds a container, deploys it to a live URL, monitors it in production, and when something breaks, diagnoses the failure and repairs it autonomously.

Not a code generator. A control plane for autonomous software.

The key difference from everything else in the market: Solen doesn't stop at deployment. Deployment is where it starts. The most valuable work happens after your app is live, keeping it alive, keeping it healthy, improving it based on what actually happens at runtime.

The architecture: four layers, one closed loop

Solen is built as four subsystems that form a continuous cycle.
The intelligence layer takes your natural language description and converts it into a structured deployment plan. It classifies the app type dashboard, landing page, CRUD app, API, e-commerce store, and loads a category-specific generation pipeline that produces production-quality output, not generic boilerplate. This isn't one prompt to one response. It's a multi-stage pipeline: intent parsing, architecture planning, spec generation, prompt construction, code generation, diff analysis, build execution, self-heal checks, deployment, runtime verification, impact assessment, and final validation. Twelve stages, each with its own logic.
The execution engine runs the build pipeline with durable job queues, retry logic, and real-time status events streamed to the UI. When a build fails, the error context is automatically fed back to the AI, which generates a corrected version and retries. Not blind retries, intelligent self-correction with the actual error in context.

The deployment runtime builds containers from the generated code, assigns subdomains, provisions SSL, runs health checks, and returns a live URL. The oversight layer monitors every deployed application continuously. When it detects a failure, a crash, an error spike, an out-of-memory event, or degraded latency, it triggers the self-healing loop.

The self-healing loop: the part nobody else has built
This is Solen's core differentiator. Here's how it works:
Monitoring detects an anomaly and fires a structured event to the diagnostic engine with full error context stack trace, recent logs, and affected component. The AI diagnoses the root cause and returns a structured assessment: what broke, why, and a confidence score. If confidence is high enough, it generates a targeted code patch. The build pipeline applies the fix and rebuilds the container. The deployment runtime does a health-gated redeploy to the same URL. Monitoring confirms the app is healthy again and logs the entire action chain to an immutable audit trail.

The whole loop runs in minutes. Every action is recorded. Users choose supervised mode (approve fixes before they're applied) or autonomous mode (the platform handles it end-to-end). As of today, Solen has completed 9 autonomous self-heals with a 100% build success rate. No human intervention required.

Why this matters beyond the demo
The maintenance burden is the largest cost in software engineering. Industry estimates put 60-80% of engineering time on maintaining existing systems rather than building new ones. Every tool that helps you build faster just creates more software you have to maintain. Solen inverts that. The more software you deploy on it, the more the platform handles for you. Each self-heal makes the system smarter about that failure pattern. The runtime data feeds back into the intelligence layer. It's not a static tool, it's a living system that improves from the software it manages.

This is what we mean by "operating system for AI-built software." Not a tool you use once. An infrastructure layer your software lives on.
The agentic era needs this

Here's the bigger picture. We're heading towards a world where AI agents build and deploy software autonomously. When Claude or GPT or any future agent needs to ship something it created, it needs infrastructure that can receive that deployment, run it safely, monitor it, and fix it when it breaks without a human in the loop. That's the infrastructure layer Solen is building toward. An API that any AI agent can call to deploy, monitor, and manage software. The control plane for the agentic era.

Where it stands today
The dashboard lets you describe an app, watch it build in real time through the 12-stage pipeline, and get a live URL. The activity page shows deploy stats, active processes, and self-heal history. Governance controls let workspace owners set agent policies for what the AI can do autonomously versus what requires approval.

It's early. The waitlist is open. We are building this in public.
If you've ever shipped an AI-generated app and then spent the next week babysitting it in production, you know the problem. Solen is the fix.

solenai.ca