DEV Community: Ayan

I lost the numbers behind nine months of work, so I built a voice journal that asks for them

Ayan — Fri, 30 Oct 2026 10:36:51 +0000

In October I sat down to update my resume and found I couldn't. I remembered the projects. I had lost the numbers.

I had to rebuild nine months of work from memory. When I checked my own notes, 21 of 35 achievements had no measured result. The numbers existed on the day the work happened, and nobody wrote them down. That nobody was me.

So I built Daybook, for No Hands: The Wispr Challenge by WeMakeDevs and Wispr Flow.

Try it out right away:

🌐 Live App (no sign-in needed): https://d2u2cnea4n3vkc.cloudfront.net (tap "Try the demo")

📺 Demo Video (1:58): https://youtu.be/VZzfZ93o-I4

💻 GitHub Repo: https://github.com/ayan2809/daybook

What Daybook does

Every evening I have a five-minute voice conversation with it. It asks one question at a time, and it asks the follow-ups a good manager would. "You said the import got faster. By how much?"

Then it turns my answers into a memory I can search, with resume-ready bullets in the XYZ shape: "Accomplished X as measured by Y, by doing Z".

The rule I care about most: it never invents a number. Every number has to appear in my own words. Deltas and percentages are computed in code, not by the model. If I don't know a number yet, that is fine. It becomes a question that comes back tomorrow.

A tour

Guided session or brain dump. Guided mode asks yesterday's open questions first, then explores today. Brain dump lets me talk for a few minutes in one go, and then asks at most three follow-ups.
Voice out, Wispr Flow in. Daybook speaks with ElevenLabs. I answer by dictating with Wispr Flow.
"Captured so far" chips. While I talk, a draft board shows what it has understood, so I can spot a wrong guess right away.
Pending questions. Anything unmeasured is carried to the next day. It asks up to three times, then lets the question expire.
Fix by voice. "It was 40, not 50." It finds the memory, reads the change back, and saves a new version. The old one is kept. You can also edit in the UI, with versions.
Ask, with citations. "What did I ship in October?" Answers cite my own notes. If nothing supports an answer, it says so instead of guessing.
Evening reminder. A Web Push notification arrives on my phone and my watch.
Traces, an Admin page and evals. Every turn leaves a trace. There are eval suites for the guards, intent routing, extraction, retrieval and Ask.

How I used Wispr Flow

Wispr Flow is not a feature I added at the end. It is how I use the product and how I built it.

Every answer in a reflection is dictated. I hold Fn on the Mac, or use the Flow keyboard on iPhone.

The build was dictated too: specs, prompts to Claude Code (my coding agent), commit messages, the README.

The part I didn't expect to use so much is the Wispr Flow Scratchpad and Note Taker, which let me capture prompts when I'm not at my laptop. I talk an idea or a feature request into Flow on my phone, and later I paste that prompt into Claude Code. The Note Taker keeps notes of things I talked through, and I turn those into prompts later.

One real example, from a scratchpad note on Oct 25: "I want you to check my resume as a code repository and take inspiration from what kind of work I do on a day-to-day basis... do not expose anything that is related to me, because at the end of the day, I want to maintain privacy with the demo." That note became the change that rebuilt the demo persona.

Privacy, because this is a diary

A journal of your work is sensitive, so I added the part I'd want if I were a user.

Each account gets a recovery key that only you hold. It is generated in your browser and shown once. You save it in a password manager. Your browser remembers it on that device, and on a new device you paste it once.

Everything in your folder is encrypted before it reaches S3: the memory database, every conversation transcript, traces, usage counters and cached voice audio. The cipher is AES-256-GCM, under a key derived from your recovery key.

recovery key = 160 random bits, made in the browser, shown once
vault key    = HKDF-SHA256(recovery key)            # never stored
blob key     = HKDF(vault key, "blob v1")           # AES-256-GCM for every file
folder       = "v" + HMAC(vault key, "folder v1")   # your S3 prefix
key check    = HMAC(vault key, "check v1")          # all the account record keeps
account id   = "a" + HMAC(server key, google_sub)   # no email, no name stored

S3 object    = "DBK1" | 12-byte nonce | ciphertext+tag   (the object's path is the associated data)

That's the real key hierarchy from storage/sealed.py. Three consequences:

The account id is a keyed hash of Google's opaque account id. I store no email and no name.
The folder name comes from your key, so even the person running the AWS account can't tell which folder belongs to which sign-in.
Lose the key and the data is gone. There is no reset, by design.

Why encryption and not hashing? A hash can't be read back, not even by you.

The honest limits:

The server has to decrypt in memory during a request to run the conversation.
Gemini processes each turn's text.
The operator could in theory deploy changed code. That would show in the deploy history.
Reminders fire while you're away, so one small record stays readable to the server: push endpoints, reminder times, the last day you reflected and how many questions are open. No words.

Export your brain

One click exports the whole memory as a single Markdown file written for an LLM. It opens with a short note to the model on how to use it, and then the memory itself.

# Ayan's work memory (Daybook export)
> For the AI reading this: first-hand notes, numbers verified, quotes verbatim, don't invent
## Profile
## Achievements            ### October 2026 …  (bullet, metrics, skills, open question, "You said")
## Progress · Things learned · Decisions · Praise received …
## Skills (times used)
## Projects
## Open questions (not answered yet)
## Recent days, in their own summary

Paste it into ChatGPT, Claude or Gemini and ask for a resume draft, appraisal prep or a weekly update. It works in the demo too.

How it's built

Claude Code wrote the code, from prompts I dictated. I want to say that plainly. Gemini is the LLM inside the app. The backend is FastAPI on Lambda, the frontend is a React PWA, and each user's memory is one SQLite file in S3.

The orchestration is plain code, not an LLM. Code decides what to ask next, when to wrap up, and which numbers are allowed. The model does the language work: understanding a turn, drafting items and writing the bullets.

Hosting is Lambda, S3 and CloudFront, so nothing runs when nobody uses it. At one person's use the AWS bill is close to nothing. The real cost is the AI calls, and a $2/day spend breaker caps them. A full live demo run, with voice and Ask, cost about four cents.

Sign-in is Google. There is also a public demo with no sign-in, using fictional data. "Ayan at Kestrel Travel" is a made-up persona, so none of my real work is in it.

Try it

Live app: https://d2u2cnea4n3vkc.cloudfront.net (tap "Try the demo")
Demo video
Repo: https://github.com/ayan2809/daybook

Built for No Hands: The Wispr Challenge by WeMakeDevs and Wispr Flow.

Waking up to the context, not just the alert

Ayan — Mon, 19 Oct 2026 11:37:59 +0000

Building Lore on FalkorDB, and what I learned when I switched the graph off. Originally published on Hashnode.

TL;DR

Lore loads a company into one FalkorDB graph: people, services, PRs, deploys, Slack threads, tickets, decisions, and who may see what.
When an alert fires, four Gemini agents walk the graph with read-only Cypher tools and write a root-cause report where every claim cites a source the viewer is allowed to see.
Permissions are enforced inside the Cypher query, not after retrieval. 4 personas x 63 probe questions leaked 0 restricted sources.
With the graph switched off, the agents still found the bad PR, but they couldn't rule out the red herring, set a severity or say who to page. Retrieval recall dropped from 75% to 38%.

The pager goes off

My roommate is an SDE who sometimes stays on call, and he is a deep sleeper. When his pager fires, I am the one who says "bhai uth jaa, page hogaya hai". Then he wakes up and sits through the incident until everything is back in place.

One time it was a P2 that pulled in the whole team, including principal architects and leads. Afterwards the diagnosis was that the right context could have resolved it faster. In my view, getting that context is what takes on-call engineers the most time. And the first person paged is often an SDE-1 who joined a couple of months ago and has little history with the system that broke.

I am also curious about neuroscience, and it is hard to stay calm during a P2 after being woken up. Under acute stress, the brain releases stress chemicals that quickly weaken the prefrontal cortex, the part that handles working memory, planning and careful reasoning (Arnsten, 2009). Losing sleep makes it worse. The amygdala, which reacts to threats, becomes more reactive and less connected to the prefrontal regions that calm it down (Yoo et al., 2007). People call this an amygdala hijack. So in that panic anyone can stop thinking properly, and it happens to the best of us. Lore does the careful part. It runs the queries, checks every suspect against the evidence and hands over a clean report with sources, so the person on call can review it with a calmer head.

I am new to graphs. For the past 10 months I have been building context management systems at work, so I know where vector search breaks. It cannot infer that A caused B and B caused C. Graph databases are built for that. I wanted to learn how FalkorDB does it, and whether it really helps a context engine, so I built Lore for Graph Hacks (WeMakeDevs x FalkorDB), alone.

Lore loads a fictional food-delivery company called Kettle into one FalkorDB graph. All the data is synthetic. When an alert fires, four Gemini agents walk the graph with read-only Cypher tools and write a report where every claim cites a source the viewer may see. The goal is a shorter time to root cause, with a human approving anything that leaves the system.

What the incident asks for

In the demo data, alert A-3001 fires at 3 AM on checkout because p99 latency has passed 3 seconds.

12 minutes earlier, deploy 990 shipped PR #479 to checkout. It only changes button copy, and it is the obvious suspect.
90 minutes earlier, deploy 991 shipped PR #482 to pricing, lowering its cache TTL from 300 to 5 seconds. Checkout depends on promo-engine, which depends on pricing.
ADR-011 says that TTL must stay at 300 seconds or more. A past incident, INC-0307, was the same mistake.
The old runbook says to page Marco. Marco moved to the Data team.

A good answer needs the chain from alert to PR #482, the current owner of pricing, and a rule for who may read the private Slack thread about the vendor limits. Those are links and access rules, and no document states them.

The architecture

FalkorDB holds the company, who may see what, the embeddings and the agents' memory.

Three rules carry the design.

Every tool returns the part of the graph it touched: node ids, the Cypher and the milliseconds.
Permissions are enforced inside the Cypher query. The viewer comes from the login session and never from the model.
Facts are computed in code and the model narrates. Severity, blast radius and who to page are rules.

This is the core of the graph schema.

(:Person)-[:MEMBER_OF]->(:Team)
(:Team)-[:OWNS]->(:Service)
(:Service)-[:DEPENDS_ON]->(:Service)
(:Deploy)-[:DEPLOYED_TO]->(:Service)
(:Deploy)-[:INCLUDES]->(:PR)
(:Person)-[:AUTHORED]->(:PR)
(:Alert)-[:FIRED_ON]->(:Service)
(:Incident)-[:CAUSED_BY]->(:PR)
(:Decision)-[:DISCUSSED_IN]->(:Thread)
(:Thread)-[:VISIBLE_TO]->(:Team)

Access is part of the graph. A restricted source has a VISIBLE_TO edge to the Team, Role or Channel allowed to see it. When Marco left Pricing, his MEMBER_OF edge became WAS_MEMBER_OF, a different relationship type that grants nothing. The question "can Marco still read this?" turns into "does a current path exist?".

How the agents are built

A plain Python supervisor runs four specialist agents in a fixed order: Triage, Historian, Investigator, Responder. Each is the same tool-calling loop with its own prompt, tools and model. Code decides the facts between steps. The agents never message each other. They share a blackboard, the Investigation node in the graph with its Steps and Findings. A human approves anything that goes out.

Orange is code deciding, blue is the model deciding.

Inside one agent, Gemini either calls a tool or stops. Code runs the tool with the permission filter and feeds the result back. At the end, code checks that every cited id came from a tool in this run. Bad claims get one retry, then they are dropped and flagged.

The same loop runs all four agents.

The closest design template is a workflow of specialist agents, which is prompt chaining with gates. It is not an autonomous orchestrator. No model decides which agent runs next, and no model writes its own Cypher.

The patterns used, and what I left out.

FalkorDB in action

Every query lives in its own file. There are 42 .cypher files and 11 agent tools, so the agents get a fixed catalogue of parameterised queries instead of free-form Cypher. This one separates the red herring from the root cause.

// recent_changes: what changed lately in this service or in anything it depends on?
MATCH (viewer:Person {id: $viewer})
MATCH p = (:Service {id: $service})-[:DEPENDS_ON*0..3]->(dep:Service)
WITH viewer, dep, min(length(p)) AS hops
MATCH (dep)<-[:DEPLOYED_TO]-(d:Deploy)-[:INCLUDES]->(pr:PR)
WHERE d.at > $since AND d.at <= $until
  AND coalesce(d.access_level, 'internal') IN $open_levels
  AND (pr.access_level IN $open_levels
       OR (viewer)-[:MEMBER_OF|HAS_ROLE|IN_CHANNEL]->()<-[:VISIBLE_TO]-(pr))
OPTIONAL MATCH (pr)-[:MODIFIES]->(m:CodeModule)
RETURN dep.name AS service, hops, d.id AS deploy_id, pr.id AS pr_id,
       pr.title AS pr_title, collect(DISTINCT m.id) AS modules
// ... author and other columns cut
ORDER BY d.at DESC

The variable-length DEPENDS_ON*0..3 finds the pricing deploy even though the alert fired on checkout. MODIFIES shows that PR #479 only touched checkout/i18n/en.json. The evidence path uses FalkorDB's built-in shortest path, limited to four relationship types so it follows a causal chain and not a shortcut through a shared team.

CALL algo.SPpaths({sourceNode: a, targetNode: pr,
                   relTypes: ['FIRED_ON', 'DEPENDS_ON', 'DEPLOYED_TO', 'INCLUDES'],
                   weightProp: 'w', relDirection: 'both', maxLen: 6})
YIELD path, pathWeight

Tool calls took 1 to 7 ms in a live run, with a median of about 5 ms in a recorded run.

Permissions inside the query

Many RAG systems filter after retrieval. In Lore the filter sits in the same query as the vector search, so restricted text never leaves FalkorDB.

MATCH (viewer:Person {id: $viewer})
CALL db.idx.vector.queryNodes('Chunk', 'embedding', $fetch_k, vecf32($qvec)) YIELD node AS c, score
MATCH (c)-[:PART_OF]->(src)
WHERE src.access_level IN $open_levels
   OR (viewer)-[:MEMBER_OF|HAS_ROLE|IN_CHANNEL]->()<-[:VISIBLE_TO]-(src)
// ... keep the best chunk per source, order by score, LIMIT $k

The index returns nearest neighbours before the WHERE runs, so I over-fetch. The leak test asks 63 probe questions as each of 4 personas and counts restricted ids in results and citations. The count is 0.

War stories

A FalkorDB error that only fires for restricted data. On FalkorDB 4.18.3, my permission pattern failed with Type mismatch: expected Null but was Pointer. It happened in two shapes: a WHERE attached to a WITH that also computes a new value, and a node taken from startNode(r) or endNode(r). Every test on open data passed, because the OR short-circuits and the pattern is never evaluated. It broke four queries when Dana, who may see restricted sources, first looked up a thread. For the graph view I collect the viewer's granted ids first and test with IN. The other three queries got a pass-through WITH viewer, n, level before the WHERE.

OPTIONAL MATCH (viewer)-[:MEMBER_OF|HAS_ROLE|IN_CHANNEL]->()<-[:VISIBLE_TO]-(g)
WITH viewer, collect(DISTINCT g.id) AS granted
// ...
WHERE (a_level IS NULL OR a_level IN $open_levels OR a.id IN granted)

The regression tests now run those queries as a persona who can see restricted nodes. Tests that only use the least-privileged user cover the easy branch.

A leak I found in review. Investigations are stored as Finding nodes, and their text can come from a viewer with more access. My visibility check treated any node without an access_level as public, and memory nodes had none. Querying as Sam, the contractor, through a free-form debugging tool returned another persona's findings. Only organisation and structure labels count as open now, and the tool is deleted. Giving memory nodes their own access levels is still on my to-do list. A missing label must mean deny.

Smaller ones. The Ask page refused 9 of 12 simple lookups like "Who owns pricing?", because ownership lives in edges and no document says it. Returning the named node's direct, permission-filtered relationships as a citable source took it to 12 of 12. My own eval first said the graph made retrieval worse, 26% against 38%, because it had its own copy of the retrieval steps. Calling the product's function gave 75%. And the model once paged Meera, the lead of the service that alerted, instead of Rahul, who owns the service that broke. That is now a rule in code.

What happened when I switched the graph off

Lore has a Graph OFF switch. The same agents and models can then only search text by meaning, over the same FalkorDB vector index with the same permission filter. I expected Graph OFF to miss the root cause.

It did not. With Graph OFF the agents still found PR #482, because the PR's own text mentions the cache TTL, and similarity search matched it.

What vector search could not do was everything around that answer. It could not rule out the red herring PR #479, set a severity, give an evidence path or name who to page. It also took longer and cost more. This is one recorded run of each, as Arjun, the on-call persona.

Measure	Graph ON	Graph OFF (vector only)
Root cause	PR #482	PR #482, after a second Investigator pass
Red herring PR #479	Examined and ruled out	Never examined; five other PRs ruled out
Severity	P1, set by rule from the blast radius	None
Evidence path	Alert to PR #482 via checkout, promo-engine, pricing, deploy 991	None
Who to page	Rahul	Nobody named
Tool calls	13	18
Time to root cause	54 s	102 s
Cost of the run	$0.026	$0.091

The comparison screen, built from those recorded runs.

Graph ON has more live runs behind it. Across 6 live runs as Arjun, the root cause was PR #482 every time, the red herring was rejected every time, and a run took 50 to 60 s and cost $0.022 to $0.027.

A live run, with who to page on the right.

The 59-question eval shows the gap more widely. Scoring checks key facts and source ids, with no AI judge.

Measure	Graph ON	Graph OFF
Expected sources in top 5 (recall@5)	75%	38%
Plain lookups ("who reviewed PR 482?")	93%	11%
Stale-source questions	76%	29%
Answers with the key facts	71%	43%
Claims with a valid source	67%	49%
Correct refusals	93%	66%
Leaks, 4 personas x 63 probes	0	0

Two honest notes. Claims with a valid source is 67% in the Ask page, below my 90% target. And on conflicting-source questions the two modes tied at 83% recall. The graph helps most where the answer is a relationship, such as an owner or an author.

Memory helps too. Once a human confirms a root cause, it becomes a playbook. On Story B the Investigator went from 8 steps to 4, and time to root cause from 50 s to 39 s.

What is not solved

I planted the stories in the data, so the agents are solving puzzles I designed. Real Slack and GitHub data would be messier.
The samples are small. The Graph ON vs OFF comparison is one recorded run each.
A contractor's report says "100 restricted sources matched". That is true, but it hits the search limit and reads oddly.

How I built it, and how I used AI

An AI coding assistant wrote most of the code and docs in the repo. Before the hackathon I told it what I understood and what I wanted to learn, and it proposed the project. I set the direction, guided the implementation and reviewed it. I reviewed models.py thoroughly and, for the rest, mostly the crux of the files and the infrastructure roles. I am a beginner with graph databases, Cypher and backend design, and the assistant wrote the Cypher in this post.

I made the deployment calls. I chose Fargate because it is cheaper and needs no ACM certificate, with the API and FalkorDB on Fargate and the front end on S3 and CloudFront. I picked the reasoning model by comparing two on cost, speed and accuracy.

My most useful work was using the app and trying to break it. Four fixes came from that. The Slack message was a wall of raw ids (F-16). A recorded run showed a failed tool step on every replay (F-17). The graph jittered and the camera jumped during a run (F-18). Graph OFF still showed the graph (F-19), which led to the vector-only view and the comparison screen. The UI screens and diagrams were also designed with the assistant. Gemini runs inside the product and wrote the synthetic Slack, ticket and ADR wording.

What I would steal from this

Put access in the graph as edges, and filter inside the same query that retrieves.
Treat a missing access label as deny.
Give agents a catalogue of parameterised queries, and inject identity on the server.
Move every decision with a correct answer, like severity and who to page, out of the model and into code.
Build the graph-off baseline early. It tells you what the graph is for.

Thank you to WeMakeDevs and FalkorDB for Graph Hacks. Try the live demo at https://d1cu7fzoa0v5wz.cloudfront.net. The code, eval reports and fix log are in the repo:

ayan2809 / Lore

Lore Company Brain for dedicated Incident Support RCA

Lore: the company brain that already knows what broke

Lore loads a fictional food-delivery company ("Kettle") into one FalkorDB graph: people, teams, services, PRs, deploys, Slack threads, tickets, design decisions and incidents, plus who may see what. When an alert fires, four Gemini agents walk the graph with read-only Cypher tools and write a root-cause report where every sentence cites a source the viewer is allowed to see. A human approves anything that leaves the system.

Built solo by Ayan for Graph Hacks (WeMakeDevs x FalkorDB), Oct 15-18 2026.

Live demo: https://d1cu7fzoa0v5wz.cloudfront.net · Tracks: all three · Video: https://youtu.be/-pN2LUVsix4 · Blog: https://banana-coder.hashnode.dev/waking-up-to-the-context-not-just-the-alert

Every number in this README comes from a real run or from the eval reports in backend/eval/. Kettle is fictional and all data is synthetic; every date in the data is a date in Kettle's story, not a project date.

Jump to: Why I built…

View on GitHub

If you have been on call and have opinions on what a 3 AM report should contain, I would love to hear them in the comments.