heyNag

Software, design & a good what if

Hey, I’m Nag.

I’m Nagarjuna Boddu. I build tools to check AI answers, keep useful context, and figure out what happened when a service goes quiet.

Visit the workbench
Video & saved ideasAn answer you can check.Memory & conversationsA new chat, with context.Developer tools & servicesCheck what happened.

01 / Notes from the build

On my workbench.

Public experiments and a peek at private work.

Videos & saved ideas

A closer look.

I’m building tools that help coding agents explore videos and saved posts. A useful answer should give you somewhere to look closer.

One choice I made

I keep the timestamp with each frame so an observation can be checked.

Read the notebook

What changes when an answer comes with something you can check?

The video workflow brings in a transcript, frames and their timestamps, with local and cloud paths. A frame keeps its place in the video, so you can return to the moment behind an observation.

We used the local frame extractor on an early recording of this website’s moth. At one second, its wings were open but its hands still crowded the collar. The image beside this note is that actual frame; the observation came from our review.

That interest extends to saved posts: search and digests that help a collection become useful again.

Public tools · Local and cloud paths

Look inside the public experiment

From a local video review

The moth’s open wings and hands beside its collar in an earlier motion study.
Extracted frame
Source
Earlier motion study
Our review note

The wings open. The hands still crowd the collar.

One extracted frame. One review note.
Inspect the original frame

Earlier motion study · extracted at 00:01.00

A moment you can return to.

The complete original frame from an earlier website motion study, showing the moth’s open wings and hands held beside its collar.

Our review note: The wings open. The hands still crowd the collar.

The local video tool extracted this frame and its timestamp. The observation came from our design review. This is an earlier study, not the current opening.

Open the full image

Memory & conversations

Pick up the thread.

A new conversation can lose the thread of a good idea. I’m experimenting with readable notes and short briefs that give the next chat a place to begin.

One choice I made

I chose to carry the last recorded check into the brief, including a failed one.

Read the notebook

What is worth carrying into the next conversation?

The notes live in Markdown and Git. The resume brief is a separate, smaller thing: context to start from, with the source notes still there to inspect.

One public test captures a useful tension: the last reply says “Parser fixed,” while the last test command exited with 1. The expected brief keeps that recorded result visible. It doesn’t decide whether the later edits fixed the code; this is a synthetic test example, not a real incident.

The hard part is making saved context useful at the right moment. Capture and resume have been checked in some command-line paths. Automatic wiki updates and other live paths still need testing; the whole loop is still in progress.

An evolving memory experiment

Read the approach and its limits

Expected brief · synthetic public test

Last reply“Parser fixed.”

Tool activity (heuristic)

Last test or build command:

go test ./internal/...exit 1
The last recorded check failed.
Inspect the test’s expectation

Developer tools & services

A missing reply.

A service can make a change even when its reply never arrives. I’m working on the tooling around that awkward moment.

One choice I made

I let status checks retry. A change with a missing reply gets a state check, without automatically sending it again.

Read the notebook

Did the request fail, or did its reply get lost?

The useful distinction is between asking what is there and asking for something to change. In this workflow, a status read can retry within a limit. A change whose reply is lost is handled by checking the existing state.

The source includes synthetic tests for that missing-reply case. They model a change taking effect before the response disappears, and keep the original error visible while the workflow checks what exists.

This is a small part of private tooling. The sketch shows an implemented decision; it is not a live service view or a claim that every recovery path is finished.

Private tooling · One implemented decision

Behavior sketch from private tooling

When a reply is missing

Status check
Retry within a limit
Change request
Read back stateNo automatic replay
Check what exists before repeating a change.

The thread through these experiments? Leaving something you can come back to: a frame, a note, or a clearer picture of what happened.

02 / The person behind the moth

A little geeky.
A lot curious.

Often talkative. Happy to get very geeky about the details. The glasses come out for deep work. 🤓

Sometimes I’m figuring out a system. Sometimes I’m deciding whether a tiny character’s eyes feel right. With this moth, the eyes notice first, then the head and hand follow. Little choices like that are part of the fun.

It’s a bit of me: building, wondering, taking a breather, then coming back with another idea.

One little moth, three sides of Nag: building at a workshop, coding on a park bench, and taking a breather under a tree while small companions play.

Still curious.
Still making things.

Find me on GitHub