What my GitHub repos are for
The views in this post are entirely my own and do not represent my employer or any organisation I am affiliated with.
My GitHub profile has become less a code shelf and more a map of what I am trying to understand.
The projects look scattered at first glance: an autonomous supervisor, an LLM evaluation harness, a ReAct loop tester, MCP servers for music and podcasts, an Android rain app, a video redaction tool, a DV archive script. I build small systems to answer questions I cannot answer by reading about them.
What does an AI agent need before it can be trusted to run in the background? What does an evaluation harness need before its scores mean anything? Can AI help a writer or musician develop an existing idea rather than replace the human who brought the taste? Can a personal tool stay local, useful, and honest about its limits?
This is a tour of the public repos: what each is for, based on their READMEs.
Agentic systems
The centre of gravity is agentic systems: not chatbots, not demos, but small autonomous loops with boundaries, logs, escalation paths, and human handoff.
supervisor is the clearest example: a two-layer monitoring system running through Hermes cron jobs. Worker jobs produce output files; a separate supervisor reads them, classifies what matters, writes a daily log, and sends a Signal message only when something is actionable.
That producer and verifier split matters. A worker should not be the final judge of whether its own output deserves attention. The supervisor also avoids the dashboard trap: it does not expect a human to poll a web UI. If something matters, it arrives where I already am.
react-harness started life as a way to compare coding models, but the real value turned out to be somewhere else: it forces you to build and read a full ReAct loop rather than treat “agent” as a black box. Observe, act, verify, repeat: tool calls, error recovery, bounded budgets, a verifier able to reject the whole transcript. That loop architecture is the same shape every agentic system on this list eventually needs, whether it’s the supervisor’s producer/verifier split above or the writing pipeline below.
Its July 2026 experiment compared GLM-5.2 and Claude Opus 4.8 across five coding tasks, measuring success rate, tool-call efficiency, error recovery, elapsed time, token use, and dollar cost. The README frames this as an anecdotal loop-engineering run, not a benchmark-grade verdict, which is honest: the real output of the project is the harness itself, and what it teaches about building loops, not the scoreboard.
podcastindex-mcp-server is infrastructure for agents that need to reason about podcasts. It exposes the Podcast Index API as Model Context Protocol tools: search, feed lookup, episode discovery, trending feeds, and Value4Value data. The design assumption is simple: if agents are going to research podcasts, they need podcast-native tools, not a web search pretending to be one.
Keeping models honest
hexapla isn’t leaderboard chasing. The instinct behind it is holding model providers to account: are the LLMs and LLM-based APIs I depend on actually fit for purpose? Do they hold up for the people and communities affected by decisions built on top of them? Leaderboards are blunt instruments that rarely tell you how a model behaves on the task, jurisdiction, cost profile, and operating pattern you care about.
It is an early-stage evaluation harness for repeatable benchmark runs and result matrices. It loads a JSONL evaluation set, runs systems under test, scores outputs with a separate verifier, captures cost and latency, records traces and per-item justifications, and writes versioned JSON and CSV matrices.
The README is deliberately restrained: not a finished benchmark, not a national evaluation programme, just the small executable core: run tests, score outputs, preserve evidence, compare results. That restraint is the point. I would rather have a scaffold that is honest about being early than a shinier tool that overclaims what its scores mean, especially when the stakes involve whether an API genuinely serves the people who depend on it, not just a vendor’s marketing claim.
voxtral-bedrock-sydney is a narrower cousin: a demonstration of Mistral’s Voxtral speech models running on Amazon Bedrock in the Sydney region. It’s one data point in the same question, not a project in its own right: is a model actually available and usable?
AI for creatives
This section runs on one question across two mediums: what should AI do when the human already has taste, intent, and constraints, whether the material is a draft paragraph or a chord progression?
bullpen applies that design taste to writing. It is a profile-driven AI writing pipeline built on Claude Code subagents: researcher, drafter, structure analyst, trimmer, safety reviewer, and image prompter each have a distinct job, with voice and constraints living in profile configuration rather than hardcoded into the agents.
That sounds like process machinery, but the point is editorial control: the human editor decides what runs next, and there is no fixed pipeline pretending every piece of writing needs the same treatment. It is a bullpen in the baseball sense: specialist relievers ready when the moment calls for them.
music21-mcp gives agents symbolic music tools through MCP. It exposes music21 operations for parsing MIDI, detecting key, transposing, replacing chords, reharmonising, analysing chord progressions, and detecting modulations. The README notes a spec-driven, test-driven build with 120 passing tests. This is not AI music as a prompt-to-song vending machine, more an assistant handed music theory tools to work on material a musician is already shaping.
reascript-mcp is the DAW-facing companion. The first working slice parses .rpp project files into compact JSON, generates Lua ReaScripts for supported actions, and writes ReaScript files to disk. The README describes it as the Reaper layer for the Asian Sentry agentic music tooling stack: music21 handles symbolic reasoning, ReaScript handles project-level control and state readback.
asian-sentry-techniques describes the creative frame around that tooling: a five-song EP built around the classical elements Wood, Water, Metal, Fire, and Earth. Each song starts with an existing idea: audio, MIDI, lyrics, a riff, or a progression. The AI’s job is to develop the seed into a finished demo, not generate the seed.
That distinction matters, for the writing pipeline as much as the music one: the interesting workflow is co-driving, not delegating. Agents can suggest arrangement logic, generate MIDI companions, reason about sonic palettes, extend lyrics, and critique mixes.
Personal utilities and experiments
A handful of smaller repos each answer one question, then get out of the way. simple-redact-video-tool blurs regions in video locally via ffmpeg, with a README blunt about what it doesn’t do: no authentication, no input sanitisation, watch the rendered output before sharing. rain-cast forecasts rainfall from Bureau of Meteorology radar out to 60 minutes ahead, with a plain warning not to use it where a wrong forecast matters.
simple-guitar-tuner and podcast-2-0-ai-player are both no-frills Android builds: a standard EADGBE tuner, and a privacy-first, GrapheneOS-optimised podcast player built almost entirely by AI as a thought exercise rather than a production app. dv-joiner solves one archival problem, turning .DV tapes from a 2002 Trans-Siberian trip into modern MP4s via ffmpeg.
Older repos round out the archaeology: a LoPy4 sensor project that sends data through The Things Network to AWS, a meditation timer, a GitHub Pages test, an old time-table voice skill. Less central, same instinct: small pieces built to test an idea.
The pattern
If there is a unifying pattern, it is this:
- build the smallest useful system that can expose the real problem
- separate production from verification
- keep the human in the loop where judgment matters
- preserve traces, costs, and evidence
- prefer local-first tools when the data is personal
- state limits plainly
The repos are not a finished portfolio. They are working notes in executable form: some polished enough to use, some early scaffolds, some caution labels wrapped around experiments.