AI Solutions Designer | Agent-Directed Product Development | Enterprise AI Enablement Albuquerque, NM · mwgrant21@gmail.com

Fifteen years in IT support taught me how systems fail in the real world and, more importantly, how people experience those failures. In late 2025 I volunteered to explore agentic AI for my department, and what started as an experiment became a new way to solve problems I'd been thinking about for years. AI didn't change how I approach technology. It finally gave me a practical way to build systems I had previously only been able to imagine.

Today I design AI-assisted systems, direct their implementation with Claude Code, and validate every result against real-world evidence. Every repository below documents which decisions were mine, what the AI implemented, and how those decisions evolved over time.

Jul 2026 – Present · Electron · TypeScript · Go

A desktop observability platform for Claude Code built around one question: is the agent actually making progress, or is it thrashing? Rather than treating AI activity as a black box, Aether makes agent behavior visible through live diagnostics, behavioral anomaly detection, and operational feedback.

• Four behavioral anomaly detectors over live session data
• Waste findings priced in dollars per week instead of abstract token counts
• Agent memory with tombstone invalidation, so reversed decisions are never treated as current
• Local-first architecture with no telemetry
• Go collector service with golden-file parity testing
• 590+ commits · 570+ tests · public progress ledger (PROGRESS.md)

Jul 2026 – Present · Electron · Node.js

TokenMonitor began after I saw repeated examples of runaway AI API costs. It gives individuals and teams clear visibility into token usage before waste becomes an expensive surprise, combining live token burn, budget tracking, cache efficiency, spending trends, and an embedded Claude Code terminal in one dashboard. The project currently has 200+ automated tests and Windows CI, and is being piloted within my IT department.

Apr 2026 – Present · Electron · Node.js · SQLite · Android (Kotlin)

A local-first AI tarot reader built around a persistent memory engine. Rather than treating every reading as independent, Miriel remembers previous conversations, recognizes long-term patterns, revisits earlier prophecies with honest verdicts, and lets each reading build on the last. The goal was not to make her seem more intelligent. It was to make each reading feel more thoughtful.

• Persistent structured memory with deterministic recall scoring, documented in docs/memory-engine.md
• Prophecy engine that revisits previous readings with honest verdicts: came to pass, partly, did not
• Six original symbolic decks with authored lore, alongside classical systems
• I Ching artwork mechanically verified against the King Wen truth table
• 200+ automated tests · everything remains on the user's machine

Jun 2026 – Present · PowerShell

A registry-driven repair and diagnostic framework built from years of recurring support work: more than one hundred utilities sharing a common architecture, Pester testing, risk classification, analyzer gates, and PDQ fleet deployment. The goal wasn't to write more scripts. It was to stop solving the same problems over and over again.

Jul 2026 · PowerShell

An experiment in preserving operational knowledge gained through AI-assisted work instead of treating every session as disposable. Lessons remain reviewable, version-controlled, and auditable instead of disappearing when the conversation ends.

While building Aether, a usage calculation reported roughly 4.82 billion tokens per month even though thirteen unit tests passed. Every fixture had accidentally zeroed the exact field responsible for the error. Comparing the result against real usage data exposed the issue and led to a permanent regression test. Passing tests are evidence. Reality is evidence too.

While validating Miriel's I Ching artwork, an automated verifier reported 64 of 64 correct even though some cards contained seven engraved lines. It never noticed, because it only asked which six lines existed, not whether there should have been six at all. Finding an answer isn't proof you asked the right question.

Three separate times I planned features around data that turned out not to exist. All three times, rather than hiding the limitation or inventing a replacement, I documented it openly and redesigned the feature around what could genuinely be supported. I'd rather ship something truthful than something impressive.

Most of my projects begin with something I can't quite let go of, whether it is a recurring support issue, an inefficient workflow, or a question that keeps returning until I decide to explore it. From there the process stays consistent: I define the problem, write the specification, establish constraints and acceptance criteria, direct implementation through Claude Code, and validate every result against observable behavior rather than assumptions.

I'm not a traditional software engineer, and I don't present myself as one. My contribution is recognizing patterns, designing systems around real operational problems, directing AI-assisted implementation, and deciding whether the result actually solves the problem I started with.

Everything claimed here can be verified in the repositories themselves. If this page and the code ever disagree, trust the code first. Then tell me, because I consider that a bug worth fixing.