Keith's Lab

Some people find things annoying. I remove the annoying parts.

Sometimes that means writing a few lines of code. Sometimes it gets a little out of hand.

Things that got out of hand
01

SonicBooth

It started with a noisy dinner.

AI · Hardware · Accessibility
SONICBOOTH EXPERIENCE ENGINE ● ONLINE
Grandma
Oh, well hello there, sweet pea! Come on in and sit down for a spell and ask me anything.

This web demo recreates Grandma's behavior through prompting. The original SonicBooth personality was LoRA-trained, including her tendency to wander into unrelated stories.

AI-directed physical experiences

SonicML lets the AI direct dialogue, timing, lighting, sound and physical effects rather than simply generating text.

<experience state="ready" />

Description

SonicBooth started with a simple idea: What if artificial intelligence could do more than talk to you? What if it could see you, recognize you, interact with its surroundings, and become part of a physical environment?

I wanted to explore what happens when AI moves beyond a screen and becomes something people can interact with naturally. Rather than building another chatbot, I set out to create an environment where software, electronics, and artificial intelligence work together to produce a shared, interactive experience.

SonicBooth combines local large language models, computer vision, eye tracking, voice interaction, custom electronics, sensors, lighting, audio, airflow, and displays. I've designed and assembled electronic circuits, integrated microcontrollers and embedded computers, and developed the software that coordinates everything. The challenge isn't just getting individual components to work, but making them behave as parts of a single system.

At the center are four persistent AI personalities that can interact with visitors and with one another. Each has its own personality, humor, and relationships. Their conversations and storylines can develop over time rather than starting over with every interaction. I've even experimented with LoRA training to give the personalities unusual behaviors, including teaching Grandma, one of the characters, to get distracted and forget what she was talking about.

I also created SonicML, a custom XML-based language that allows AI to control the physical environment. Instead of generating only dialogue, the AI can describe sequences of speech, lighting, sound, timing, and physical effects. These instructions are interpreted and executed by the booth's hardware controllers. I also developed a Python and LLM-based pipeline that generates C++ code for ESP32 microcontrollers, making it easier to experiment with new hardware behaviors.

SonicBooth brings together many of the things I enjoy most about engineering: designing something from scratch, experimenting with unfamiliar technologies, building custom hardware and software, and figuring out how to make systems work together in ways they weren't originally designed to.

My long-term goal is to make SonicBooth an inclusive experience where people can interact with technology without needing to understand how it works. It's an ongoing experiment, and much of the fun comes from discovering what's possible along the way.

Why?

SonicBooth started with an annoying dinner.

A large party was seated near us at a restaurant, and pretty soon we could barely hear ourselves think. I started wondering whether you could create a booth that isolated the people inside from the noise around them.

The first ideas were mostly engineering: sound-dampening materials, active noise cancellation, directional audio, and even an air-blown barrier that could help separate the space without completely enclosing it.

Then something changed the direction of the project.

A family friend suffered a severe concussion. Loud noises and bright lights became debilitating for her. Going somewhere as ordinary as a restaurant could be difficult enough that she often preferred not to go out at all.

Later, my own daughter suffered a concussion after a fall. She developed many of the same sensitivities to light and sound.

At that point SonicBooth stopped being primarily about making a restaurant quieter.

The environment shouldn't decide who gets to enjoy it.
The design philosophy became Inclusiveness first.

Instead of designing an experience for the average person and then adding accessibility features, I wanted the environment itself to adapt to the person using it.

Someone sensitive to sound should be able to make it quieter. Someone sensitive to light should be able to change the brightness and color. Someone who has difficulty using conventional controls should have another way to interact.

Displays should adapt. Controls should be simple. The technology should accommodate the person rather than requiring the person to accommodate the technology.

Once the booth could control sound, light, displays and physical effects, another question followed: why couldn't all of that also become part of the entertainment?

That led to AI personalities, persistent storylines and experiences that can use the physical environment itself as part of the interaction.

What started as "this restaurant is too loud" became: can you build an environment that more people can enjoy because the environment adapts to them?

Technologies Involved

Python JavaScript LLMs LoRA RVC Voice Cloning RAG MCP MediaPipe Computer Vision Eye Tracking ESP32 Orange Pi Custom Electronics SonicML Lighting Control Physical Effects

What I Learned

Accessibility isn't a feature. It's an architectural decision.

Building adaptability into the system from the beginning creates very different possibilities than building for an assumed average user and adding accommodations later.

AI gets much more interesting when its output isn't limited to text.

Once an AI can affect lighting, sound, displays, airflow and physical devices, the model becomes part of an environment rather than simply a chatbot.

Don't let the model directly control the hardware.

Giving an LLM access to physical devices requires a constrained layer between intent and execution. That problem eventually led to SonicML.

Apparently ChatGPT makes a pretty good soldering instructor.

SonicBooth required a lot more hands-on electronics work than I'd done before. I used ChatGPT to review photos of my solder joints and critique the results as I learned.

My early attempts were getting roughly 3/10. With practice and feedback, I eventually worked my way up to 9/10, at least according to ChatGPT.

The best version of the idea wasn't the original idea.

SonicBooth became considerably more interesting when the goal changed from blocking restaurant noise to adapting an entire environment around the person using it.

02

ASL Transformer

Can a tiny dataset teach a model the difference?

AI · Computer Vision
☝
01 CAMERA
→
02 MEDIAPIPE
→
03 303 FEATURES
→
04 30 FRAMES
→
05 TRANSFORMER
COOKIE or PIE

Description

A proof-of-concept American Sign Language recognition system using MediaPipe landmarks and a custom transformer.

The initial experiment deliberately used only two similar signs, COOKIE and PIE, and only 19 training videos from several signers.

Each video is converted into sequences of hand, finger, movement and body-relative features. The model sees 303 features per frame over a 30-frame sequence.

The transformer itself is intentionally small: roughly 89,000 trainable parameters.

Why?

SonicBooth was becoming increasingly focused on accessibility, and I wanted to explore interaction methods that didn't depend on conventional controls or spoken language.

ASL recognition also gave me a particularly interesting machine-learning problem because a sign isn't simply a picture of a hand.

Position matters. Finger configuration matters. The relationship to the body matters. Most importantly, movement through time matters.

I deliberately started with very little training data to see how far I could push the experiment before simply solving the problem by throwing more data at it.

Technologies Involved

Python Transformers MediaPipe Computer Vision TensorFlow Lite OpenCV NumPy Temporal Features Pose Landmarks Hand Landmarks

What I Learned

Small datasets expose shortcuts quickly.

The model could find correlations that produced the correct answer without necessarily learning the relationship I actually cared about.

Raw computer-vision data isn't stable enough for every problem.

Hand identity and handedness could become inconsistent during occlusion and complex movement. That problem led directly to HandFlow.

A correct prediction doesn't necessarily mean the model learned the correct thing.

That realization eventually became the experiment behind NDML.

03

HandFlow

MediaPipe kept losing my hands.

Open Source · Computer Vision
RAW MEDIAPIPE
LEFT
→
LEFT
→
???
→
RIGHT?
→
LEFT
↓ HandFlow ↓
STABILIZED STREAM
LEFT
→
LEFT
→
LEFT
→
LEFT
→
LEFT

Description

HandFlow is a stateful layer over hand-tracking data that adds temporal context to a stream of otherwise independent computer-vision frames.

It maintains frame history, timestamps, velocity, person grouping and handedness information so downstream applications have a cleaner and more consistent representation of what the hands are actually doing.

Why?

While building the ASL Transformer, I found that MediaPipe could lose track of hands during occlusion or confuse left and right when they reappeared.

Cross your arms and you can create exactly the sort of ambiguity that becomes a problem.

For many computer-vision applications, a momentary tracking error isn't particularly important.

For sign language, hand identity and movement history can be part of the meaning.

Rather than forcing every application to solve the same temporal tracking problem, I pulled that responsibility into its own library.

Technologies Involved

TypeScript MediaPipe Computer Vision Temporal State Frame History Velocity Handedness Person Tracking

What I Learned

History can correct ambiguity that a single frame can't.

A frame may not contain enough information to determine identity reliably, while the frames before and after it often do.

Libraries become useful when they remove a repeated annoyance.

HandFlow emerged because temporal cleanup shouldn't have to be reimplemented by every application consuming the same tracking data.

04

NDML

My transformer was learning the wrong thing.

Machine Learning Experiment
THE WIND Lots of movement. Not the pattern.
THE PUNCH A relationship propagates across layers.

Description

NDML — N-Dimension Machine Learning — is an experiment in finding meaningful relationships across dimensions and time while suppressing unrelated dimensional changes.

Instead of treating every change as equally important, the experiment looks for structured relationships that persist or propagate across dimensions.

Why?

The ASL Transformer could learn that a particular finger configuration correlated with COOKIE.

But COOKIE isn't just a finger configuration. The movement is part of the sign.

That made me interested in distinguishing a meaningful relationship from all the other dimensional changes happening at the same time.

The analogy I use is a bedsheet hanging from a clothesline, folded into several layers.

Wind can move the entire sheet. Lots of things change, but none of that movement is necessarily interesting.

Now punch the sheet.

The disturbance propagates through the layers in a related way.

Ignore the wind. Find the punch.

Technologies Involved

Python Machine Learning Transformers Temporal Data N-Dimensional Features Pattern Detection Custom Modeling

What I Learned

Getting the answer right and learning the right relationship are different things.

A model can exploit a convenient correlation while completely missing the underlying pattern you intended it to learn.

Noise isn't necessarily random.

Real dimensional data contains legitimate changes that may simply be irrelevant to the particular relationship you're trying to detect.

05

KnowMy.biz

I wanted to really learn RAG and MCP.

RAG · MCP · Knowledge
ROLE DISCOVERY INTERVIEW ● ACTIVE
KNOWMY

Walk me through what happens when a production issue is reported to your team.

EMPLOYEE

Usually support opens the ticket and sends it to our queue. I review it first and decide whether it belongs to us.

KNOWMY

If it does belong to your team, what do you do next?

EMPLOYEE

I check the logs and usually ask one of the application owners whether anything changed recently.

GROUNDED KNOWLEDGE CAPTURED
Responsibility Initial production issue triage
Workflow Support → Team Queue → Triage → Application Owner
Tool / Evidence Application logs
Open Question How is the correct application owner identified?

Description

KnowMy.biz is an AI interview system designed to learn how work actually happens inside an organization.

It conducts conversational role-discovery interviews and turns employee answers into structured organizational knowledge: roles, responsibilities, workflow steps, handoffs, tools, people and unresolved questions.

Learned facts remain grounded in the source excerpts that produced them rather than becoming detached AI-generated assertions.

Why?

I'd experimented with RAG and MCP inside SonicBooth, but it barely scratched the surface.

I wanted a project that forced me to understand the difficult parts rather than another small demonstration where the interesting problems could be avoided.

Organizational knowledge gave me exactly that. Retrieval, grounding, authority, identity, persistence, tenancy and AI interpretation all mattered.

So instead of building a toy RAG application, I gave myself a problem complicated enough that I had to learn it properly.

Technologies Involved

RAG MCP Gemini Python TiDB MongoDB Grounding Multi-Tenancy Secure Sessions

What I Learned

Retrieval is the easy part.

Deciding what information is authoritative, preserving provenance and separating AI interpretation from verified knowledge are much more interesting problems.

Real problems are better teachers than toy demos.

Once identity, tenancy, persistence and conflicting knowledge mattered, the architectural tradeoffs stopped being hypothetical.

06

Jobhunt

Three of my kids were looking for jobs.

AI Agents · MCP · Search
JOBHUNT AGENT ● SEARCHING
SEARCH
Interesting smaller local companies

Find businesses first, then investigate their own career pages.

$0.02
DISCOVER
✓ Company website found ✓ Careers section located ✓ Open positions discovered
INVESTIGATE
Careers page

Inspect roles directly instead of relying on a major job-board listing.

EVALUATE
Compare against candidate profile

Skills, location, role type and other preferences become part of the evaluation.

REMEMBER
company → saved jobs → saved evaluation → saved discovery → saved
SEARCH RESULTS 10 SEARCH COST ≈ $0.02

Description

Jobhunt is an agentic job-hunting system that searches for companies rather than starting with job postings.

It looks for interesting smaller businesses, finds their websites, investigates their career pages, discovers openings, evaluates them against a candidate profile, and remembers what it has already found.

The goal is to uncover opportunities that might never rise above the noise on the major job boards.

Why?

I had three kids looking for jobs.

Indeed was crowded with the same employers, promoted listings and lots of people competing for the same visible positions.

I started wondering what they weren't seeing.

There are plenty of smaller local businesses with their own websites and career pages. Instead of searching another giant job board, why not find interesting companies first and then ask whether they're hiring?

Naturally, this became an agent.

Technologies Involved

Python MCP AI Agents Parallel Search API MongoDB Web Search Job Evaluation Persistent State Company Discovery

What I Learned

Agentic search can get expensive surprisingly quickly.

A search returning ten results costs roughly two cents. That doesn't sound like much until an agent starts exploring companies, following leads, checking career pages and deciding what it wants to search for next.

Curiosity needs a budget.

Once each additional search has a real cost, deciding whether another search is actually useful becomes part of the architecture.

Autonomous agents need memory.

Without persistence, an agent can happily spend money rediscovering companies and jobs it already investigated.

07

Live DDL

I ran out of free credits.

Developer Tool · Databases
Live DDL database design interface
Live Demo ↗
Username: demo@groupboard.app Password: demouser

Description

Live DDL is a visual database-design application that keeps SQL, the interactive database model, metadata, relationships and generated changes synchronized.

Tables can be moved and explored visually, relationships reroute automatically, and related tables can be isolated into smaller working views.

Direct SQL editing and visual editing stay synchronized in both directions.

Why?

I was using a free online DDL editor while building another application.

Then I ran out of free credits.

I could have paid for more.

Instead, I built my own.

More importantly, I wanted a database design tool built around the way a developer works with databases rather than the way a dedicated DBA works with them.

I build applications quickly. I didn't want the database-design tool becoming the slowest part of the process.

Relationships should be clickable. Common actions should be obvious. SQL and the diagram should agree with each other. And it should work naturally on a phone instead of assuming everyone is sitting in front of a giant monitor.

About 12 hours later, I had my database editor.

Technologies Involved

JavaScript SQL DDL Parsing Graph Layout Relationship Routing Responsive UI Multi-Tenancy Revision History

What I Learned

Synchronizing two representations is harder than rendering either one.

The SQL and visual model both need to be editable without allowing them to drift apart.

Responsive database visualization is mostly a geometry problem.

Automatic layout and relationship routing become considerably more interesting when the viewport can be a phone.

08

Plasma Rings

I got tired of the ads.

Game · Custom Rendering
Plasma Rings game

Description

Plasma Rings is a custom HTML5 puzzle game with its own rendering, sprite and geometry systems.

It includes multiple game mechanics, visual effects, progression, fuel rods and meltdown modes without using an off-the-shelf game engine.

During its early release, players completed more than 3,500 levels.

Why?

I liked playing a Nuts & Bolts-style puzzle game.

I didn't like watching an ad between seemingly every level.

So I wrote my own.

That turned into considerably more mathematics than I expected.

One requirement became particularly important: screen size shouldn't matter.

I didn't want separate desktop, tablet and phone layouts held together with a collection of breakpoints. The viewport itself became the coordinate system.

Every object's location and size is derived from the available screen dimensions so the entire game recomposes itself for the device.

Technologies Involved

HTML5 JavaScript SVG Custom Rendering Dynamic Geometry Particle Effects Responsive Scaling Custom Sprites

What I Learned

Responsive design can be mathematical instead of breakpoint-driven.

Treating the viewport as the foundation of the coordinate system allowed the game itself to scale rather than merely rearranging UI elements.

Game development hides a surprising amount of geometry.

What looked like a simple puzzle quickly became an exercise in positioning, collision, movement, scaling and visual composition.

SVG is perfectly happy being drawn in a text editor.

The reactor artwork was manually created as SVG rather than produced with a graphics package.

09

Egor

Give the house a memory.

AI · Property Intelligence
E
EGOR · PROPERTY INTELLIGENCE Give the house a memory.

Identify equipment, capture specifications, track maintenance, preserve documents and remember the history of a property.

Description

Egor is a property intelligence and maintenance platform that models the physical systems and history of a home.

Properties, rooms, equipment, ownership, maintenance responsibility, documents, warranties, service schedules and repair history can all be connected rather than scattered across paperwork and separate applications.

AI can scan equipment labels to identify assets and extract specifications, while maintenance can be recorded conversationally.

Why?

Houses accumulate knowledge, but they don't have anywhere to keep it.

Who installed the water heater? When was the HVAC serviced? Which filter does it take? Is that appliance still under warranty? Which document contains the information?

I wanted the property itself to have a persistent history that could survive individual owners, service calls and piles of paperwork.

Technologies Involved

AI Vision LLMs Image Recognition Document Storage Conversational Input Structured Property Data Multi-User Access

What I Learned

Physical objects become much more useful when they have digital history.

An appliance isn't simply a row in a database. Its documents, service history, location, ownership and maintenance requirements all form part of its identity.

10

GroupBoard

Communication should know who it's talking to.

Communication Platform
notifyLunch.js JavaScript
await groupboard.send({
  group: "Kitchen Staff",
  title: "Lunch is Ready!",
  body: "Orders are ready for pickup.",
  autoTheme: true
});
Generated using group theme
G
🍔 Lettuce celebrate!

Lunch has landed. Grab it before it makes a great escape.

Description

GroupBoard is a mobile-first group communication platform supporting push notifications, email, read/open tracking, invitations, roles, quiet hours and organization-specific theming.

It also experiments with audience-aware AI rewriting, allowing an application to communicate the intent of a message rather than requiring every caller to provide the final wording.

Why?

Sending a message isn't the same thing as communicating.

I wanted to experiment with communication as a higher-level application capability: who should receive something, when should they receive it, how should it be phrased for that audience, and did they actually see it?

Technologies Involved

JavaScript Push Notifications Email AI Rewriting REST APIs Multi-Tenancy QR Enrollment Delivery Tracking

What I Learned

APIs can accept intent instead of only accepting strings.

Giving the communication layer context about the audience and purpose creates opportunities to adapt the final message without making every calling application responsible for that logic.

11

You Can't Make This Stuff Up

The internet is weird. Let the AI find the evidence.

Autonomous AI Agent
YCMTSU AGENT FEED —
Loading latest stories…

Description

An autonomous research agent that searches for bizarre-but-true current news.

The agent runs a research, evaluate and decide loop rather than executing a predetermined list of searches.

It evaluates source quality, recency, duplication and absurdity, determines whether its objective has been satisfied, and chooses what to search for next when it hasn't.

Why?

I wanted to experiment with an agent that was actually responsible for deciding what to do next rather than an LLM inserted into a conventional scripted workflow.

Searching for strange-but-true news gave it a useful objective because relevance alone wasn't enough. The agent also had to judge credibility, novelty and whether something was actually weird enough to qualify.

Technologies Involved

AI Agents LLMs Search Grounding Autonomous Planning Self-Evaluation Source Scoring

What I Learned

An agent becomes interesting when it can decide that it isn't done.

The important part wasn't generating the search query. It was evaluating the evidence, recognizing that the objective hadn't been satisfied, and deciding what information it needed next.

The pattern

Find the annoying part.
Remove it.
See what breaks next.

Most of these aren't finished in the traditional sense. They're experiments. I build enough to answer the question, discover the next question, and then decide which rabbit hole looks interesting.