MCP on my.pgnd.dev

Training with an agent

Tue, 17 Mar 2026 00:00:00 +0000

For the past months, I have been training with an agent. I expected the agent to do well on traditional weightlifting and be plain on the rest. The insights I got on my Calisthenics program really impressed me.

To set the stage, I am a fairly active person. Bouldering twice a week, Calisthenics on the side, working on my levers and hoping to land a planche one day, Snowboarding in the winter.

Interested in sports, training and performance. I don’t read much, yet, Overcoming Gravity and the New Encyclopedia of Modern Bodybuilding are among my readings. I have been paying attention at how I train for a while now. I don’t have professional training but I like to think I have a good understanding of the fundamentals.

I got exposed to the idea of an agent coach. It didn’t strike me as something I was into. I like managing my workouts, understanding the exercises and progressions, figuring out the good position and tension for a better performance, the corrective exercises to compensate the muscle imbalance that could be impeding progress. Working through the reporting, note taking, and doing the agent suggested program. Delegating a lot of this to an agent takes away part of the fun.

Boy, was I wrong.

One day, I figured I could try a Claude project where I’d feed in my training profile. I also detailed my weekly exercise program. Then, I logged a few feedback from my sessions. Finally, I went for asking suggestions to improve my routines, along with some observations about what could be hindering me.

I was pretty impressed when it picked up on my tuck planche hold times, started suggesting that I was actually around the transition point to the advanced tuck planche. Overall, most of the feedback was very aligned with what I was thinking. Now, here comes the kicker, when trying to work towards the progression to the next level. The agent makes it easier to bounce ideas and select my next set of exercises. It cuts down my research and integrates variants I had totally forgotten.

The same way I code heavily with an agent, the agent has been a great coaching partner to help structure my workouts. So much that I found myself giving out notes to the agent about my sessions after them on a daily basis. As usual, context is key. My notes are also focused that way, rather than expending on everything I did, since the program is known. I can focus on high level effort perception, hone in on specific weaknesses or new found improvements. This led to identifying a weaker posterior chain and the corrective program. I haven’t worked on a planche in a couple of month, yet, coming back to it, I could feel it improved from the correction.

Fast forward a few month, circumstances made it so that I was full time snowboarding. This meant having to trying to maintain my upper body strength while I lost access to most equipment and that my focus and energy would shift entirely. With the agent, I designed a plan to maintain upper body stimulus while I would, in practice, mostly doing leg work. After a few month of low intensity, I am glad to say that I feel the strength loss has been minimal and I enjoyed the planning aspects.

In the last month, I started to get a sense of what information made sense, what goes into a profile, some of the interaction flow. Also ideas about how to reduce some of the friction.

Free text program is more ambiguous. Structure is lacking, precise references are harder to anchor. I was mostly on my phone, typing markdown or structure isn’t the best. When discussing one set in the middle of a program, and how to adjust it, at times, it felt like we were talking past each other. If only I had a structured way of iterating on my programs with the agent.

One side project I attempted a few times was a tool to manage my session and assist me while doing them. At the time, I was doing a lot of HIIT, most of the progression was time based exercise and timed rest more than target reps. So this structure just made it easier for a stream with a timer, exercise and hint about the upcoming exercise. What if I revived this structured model and use it as a base to work on the program with the agent.

With the help of my favorite agent, in a different context, I put together a quick database model, api, MCP server to populate the structure. I wired the MCP server into the context where I have been discussing my workouts and asked the agent to populate my session. It got 90% of the program right. The errors were actually the friction points I have been fighting for a month. I corrected the session, told the agent to look again. Boom, we’re both aligned, for the first time in a while.

One project of my playground is slowly taking form. Agent assisted coaching, low key, help me manage my workouts and plan their evolution according to my current form, goals and time. I am not missing out on the fun, I am coming out swinging stronger than ever.

More to come.

whackAmole, a task manager for my agents and myself

Sun, 15 Mar 2026 00:00:00 +0000

I was setting up a side project, agents hard at work for me. In those early moments, changes often cover more ground than expected, codebase is new and standards are not as defined. I got into the habit of asking a different agent to review the ongoing work. Like most things, it’s not perfect but it captures good signals.

The issue: I’d often end up with a stream of 10 or more issues to fix. While a lot of it deserved attention, like any review, they can be loaded: quick fixes, things needing iteration, items better left for later or tied to a bigger refactor. That’s where a single Claude or Gemini prompt started to fall short.

The initial POC: an stdio MCP server backed by a table of tasks in SQLite. I reloaded the session that gave me my last review with 10+ comments, and asked the agent to create tasks from the feedback. Now I had a filterable list, editable descriptions, easy to reorganize and hand off to different agents across different sessions.

This could all go into regular issues, but it never felt worth it. Most of it needs to be addressed within the same PR… suddenly you’ve got 10 issues linked to a single PR. I enjoy the local iteration. It serves me well as short/medium TODO tracking.

After dogfooding this across a couple of projects, including whackAmole itself, my workflow matured alongside the features I added. Below are the ones that stood out for my day to day.

CLI vs MCP vs UI

Maybe obvious, MCP for agents, CLI/UI for myself, cli was good to create projects, add tasks. Viewing started to feel limited, especially when agents started feeding tasks with 30 lines of description. That’s where the UI started to shine for me.

Overall, they play well with each other. CLI enables me to quickly add tasks or update status when I am heads down. That’s how everything started.

MCP was always a goal. Yes, the agent could use the CLI, however, it means that I need to document in each project how to use it. The agent does a better at picking up from the tool name and description what to do with it. Sadly, that’s also what removed some of the whimsicality of the project where Project were Yards full of Moles to whack. Conventional naming makes it easier to understand, what is true for humans is also true for agents.

The UI became my command center. Whenever I see an Agent producing a big review or plan, I will likely ask it to create tasks. I find it more comfortable to read, and also, for better or worse, easier to multitask between projects. I find myself writing the task in the UI rather than directly prompting the Agent more and more.

Projects

Project enables an easy breakdown, agents publish, view and edit tasks from a single project. The trick is the scoping. I found it awkward to always have to add the project to the CLI, so I added a whack config set-local project <projectKey>. This has been a life saver for me, each project root has a config file with the project key. I no longer have to add the project key to any commands.

Agent setup, the project key being a very local thing, it didn’t feel right to add it to the AGENTS.md or any global agent spec. I started leveraging CLAUDE.local.md and GEMINI.local.md. Those files contain a quick guide, typically:

You have access to the whackAmole MCP server for task management.
whackAmole project key is whack

MCP.instructions

Claude picked up pretty naturally on the tasks, updating status. Gemini… not as well.

Since the tasks could sometimes be more complex, adding a supports Markdown to the description was enough to get the agents to use markdown. Now I get formatted tasks with headers, bullet points and even code snippets.

For the flow, I initially started adding instructions to the .local.md files which quickly turned out to be a pain to manage. Eventually, I started leveraging the instructions block of the MCP server. In the UI, there’s a config, top right that enables editing the instructions that are attached to each instance. An example will best illustrate how I use it:

# MCP Protocol: Project Task Lifecycle
## 1. Task State Management
The agent must strictly follow the semantic state machine for the current Project.
* **Pre-Execution**: Before performing any code changes or terminal actions, the agent **MUST** update the task status to `INPROGRESS`.
* **Pre-Validation**: Before requesting user feedback or validation, the agent **MUST** update the task status to `REVIEW`.
* **Closure**: Only the user may move a task to `COMPLETED` or `CLOSED` terminal states. The agent is prohibited from performing these transitions.
## 2. Quality Gates (Non-Negotiable)
Before a task can be transitioned to `REVIEW`, the agent must ensure the code is production-ready across all relevant languages.
* **Linting**: All changed files must pass the project's configured linter (e.g., `golangci-lint` for Go, `eslint` for Preact/TS).
* **Testing**: All relevant unit and integration tests must pass.
* **Protocol**: If linting or tests fail, the agent must remain in `INPROGRESS` and resolve the issues before attempting to move to `REVIEW`.
## 3. Interaction Constraints
* **Permissions**: Always request user approval before refactoring existing code or changing established coding patterns.
* **Project Context**: Ensure all actions are performed within the scope of the active Project Key.

Overall it works well, even Gemini does a better job at tracking of its task. It’s not as strong as a prompt, but it’s also easier to maintain. A decent enough trade off.

I found myself using the UI more and more:

Pretty printing Markdown
Quick toggle groups for Type and Status
A bit of color coding to quickly catch what’s happening

Refreshing was getting more and more tedious, so I wired a quick event log that the UI uses to refresh task statuses, or when tasks are being added, show which projects are getting updates.

That’s my latest workflow improvement in the wild west of agents. Curious how others are pulling through these days.