I Built an AI App. Eight Months Later, It Became a Skill

When I first wrote about NutriAgent in November 2025, it was a full application. It had a Python backend, a web interface, a Telegram bot, user accounts, Google OAuth, Supabase, and a Google Sheets integration.

Recently, I reproduced its core workflow as a skill for my personal AI agent. It took around 15 minutes and two prompts. I didn't build another backend, deploy a service, or implement OAuth again. I explained how I wanted the workflow to behave, tested it, and watched a new row appear in my nutrition spreadsheet.

The original application wasn't a mistake. It was how I could deliver that experience with the tools available at the time.

Eight months later, the starting point had changed.

Eight Months Ago, This Was an App

I built NutriAgent because I wanted to track calories and protein without trapping my data inside a nutrition app. I wanted the raw records in a spreadsheet I controlled, where I could create my own reports and eventually connect nutrition with my training data.

The first version was a personal n8n workflow. It worked for me, but when a friend wanted to try it, I realized that everything was tied to my accounts. To make it reusable, I rebuilt it in Python and added the parts a real multi-user product needed: authentication, storage, a web interface, Telegram, Google OAuth, conversation history, and account linking.

I've already told that story in I Ditched MyFitnessPal and Built an AI Agent to Track My Food, and later wrote about what broke after I used it every day for a month.

This article starts after that version.

My Gaming PC Became an Agent Box

I had a modest gaming PC at home with 16 GB of RAM and a 1 TB drive. Using it through Windows, WSL, and remote desktop from my Mac felt awkward, so I installed Linux and turned it into a remote box for running agents. I'll write about that setup separately.

I moved Hermes there from a VPS. Hermes is the personal agent I now run on that machine. It can load reusable skills and use tools connected to my Google Workspace. The PC runs the agent environment, not the frontier model itself.

Once Hermes was running, I wanted to test a workflow I already understood well. NutriAgent was the obvious candidate.

Two Prompts, Fifteen Minutes

Instead of opening the old repositories, I described the outcome I wanted. Hermes should understand a meal, estimate its nutritional values, follow the structure of my existing log, and append the result to Google Sheets.

The first prompt created the initial skill. I used a second prompt to clarify the remaining details and adjust how it should write the data.

Then I tried it with an actual meal.

The result landed in the same kind of spreadsheet I originally built NutriAgent to produce. There wasn't a new service running behind it. Hermes already knew how to interpret natural language and use tools. Google Sheets already held the data. The skill supplied the part that was specific to me: the procedure.

That's the part that surprised me. I didn't find a cleverer way to rebuild NutriAgent. I didn't rebuild it at all.

What I No Longer Had to Build

The skill isn't equivalent to the full NutriAgent product. I can't give someone a signup link. It doesn't have a generic Telegram bot, its own Google OAuth flow, or a dedicated interface. It only needs to work with my agent, my Google account, and my spreadsheet.

For personal use, that was enough to preserve the behavior I cared about:

Understand what I ate.
Estimate calories and macros.
Follow the schema of my nutrition log.
Save the result somewhere I control.

Previously, I had to own both that behavior and the application around it. Now Hermes provides much of the environment, and the skill only describes what is different about this workflow.

This also changed the marginal cost. I moved Hermes off the VPS and configured this experiment to use model access I already had through my Codex subscription instead of maintaining a separate per-call API bill for NutriAgent. The subscription and the electricity aren't free, so this isn't a zero-cost workflow. But it removed a separate bill for each NutriAgent interaction.

The skill also changed how I add features. I had wanted predefined meals for food I had already analyzed on previous days. In NutriAgent, that would've meant changing the application, updating the prompt, testing the new behavior, and deploying another version.
With Hermes, I just said, “Remember this meal data for next time under this name.” That was enough to make it part of the workflow. A feature I had postponed in the application became a one-request change.
For a personal workflow, I wasn't only skipping the initial development. I was also skipping much of the release cycle for every small improvement after it.

I Started Seeing the Same Question Elsewhere

I recently watched Theo Browne's talk Everything We Knew About Software Has Changed. His broader point was that capable models with tools such as code execution can reduce some ideas that once required custom software to a set of structured instructions. At one point, he joked that many startups in the room could be Markdown files.

That sounded less abstract after the NutriAgent experiment.

I also read @javz Start Building for Agents, Not Just Humans. In my comment, I connected his argument to personal agents that increasingly handle the interaction for us. If I already start from Hermes, a smaller application may not need to own the entire experience. It may only need to give my agent the missing behavior.

I don't think this means every AI product will become a Markdown file. NutriAgent is a personal workflow that writes to a destination I control. Products serving many people still have responsibilities around reliability, permissions, privacy, onboarding, support, and shared state. Some products are valuable precisely because they coordinate people or centralize something that an agent can't create on demand.

I don't have a clean answer for where that line is. But I know my first step has changed. A few months ago, I would've started a workflow like this by creating a repository. Today, I'd try it as a skill first and build the standalone product only when the workflow proves it needs one.

Now I Have to Ask This About Synapse

NutriAgent isn't the only AI product I've built.

Synapse, the personal AI companion I built for my wife, has a much more complex memory system. It ingests conversations, extracts entities and relationships, stores them in a temporal knowledge graph, and retrieves relevant context for future conversations. I've spent months improving its ingestion, GraphRAG retrieval, context budgets, and memory interfaces, It now serves more people, so multi-tenant is a thing.

Now I'm wondering how much of that system I would build if I started again today.

Could the ingestion workflow become a skill? Could a general-purpose agent use a graph tool and follow instructions for consolidating conversations? Is the graph architecture the product, or is it one implementation of the outcome I want?

I don't know.

Synapse may still need a dedicated product because reliable long-term memory, privacy, evaluation, and the experience around personal conversations could be the actual value. Or I may find that some of the system can be compressed just as NutriAgent was.

Most of my articles are about building more software to solve a problem. This one is about removing software while keeping the core workflow alive.

NutriAgent made sense as an application when I built it. What interests me now isn't whether that decision was correct. It's what kinds of products will still need to exist when personal agents can assemble workflows like this on demand.

Before I build my next AI product, I want to know how much of it can be a skill first.

If you are building AI products and want to follow along, I write about the problems and trade-offs that appear when someone actually uses them.

Follow me: