Back to Blog
toolingshellautomationopentelemetrydeveloper-experience

Automatic Project Tagging Telemetry With a Shell Wrapper (Simply Explained)

A plain-language guide to automatic project tagging telemetry. No jargon, no tech speak, just what it means for your business.

By Mike Hodgen

Want the full technical deep dive? Read the detailed version

I Built a Dashboard That Could Only Tell Me One Number

I run more than 40 software projects. Each one has little AI helpers working inside it, writing code, doing research, creating content. To keep an eye on all of them, I built a single dashboard that shows me what every helper is doing across every project.

Think of it like a control room with one big screen showing all the activity in one place.

Good idea. But it had a flaw.

Every helper was reporting back to the dashboard with the same generic label. Months earlier I'd set a default name in the settings and forgotten about it. So when I opened the control room, every project blurred together into one giant lump.

I could see total activity. I could see total spending. What I couldn't see was the one thing that mattered: which project was eating all my time and money.

That's the worst kind of broken. Not broken enough to notice right away. Just broken enough to make the data useless the moment you ask a real question. If one project was burning 80% of my budget and another was sitting idle, I had no way to know. Same lump.

Why I Didn't Just Fix It by Hand

The obvious fix was to go into each of the 40 projects and type in the correct name. Open project, add label, save, repeat. Forty times.

I said no. Not because I'm lazy. Because that approach rots.

Picture giving 40 employees a sticky note with their job title and trusting them to keep it accurate forever. Six months later, half the notes are wrong because someone changed roles and forgot to update. A few have typos nobody caught. New hires never got a note at all.

That's exactly what happens with manual labels. I rename a project, update the dashboard, and forget the sticky note. New projects fall back to that generic default, recreating the exact lump problem I was trying to fix.

Anything I have to remember to do correctly, forever, with no warning when I get it wrong, isn't discipline. It's a debt that grows quietly until the whole thing is useless.

The Fix Was Embarrassingly Simple

Here's the thing. I already store the project name somewhere reliable. The folder it lives in.

Every project I work on sits in its own folder under one master folder. The folder name is the project name. I keep those folder names perfect, because I have to use them every single day to find my work. They can't drift, because if a folder name is wrong, nothing works and I fix it instantly.

So instead of asking each project to announce its own name, I made the system figure out the name from where the work is happening.

Imagine a delivery driver who doesn't need to ask which neighborhood they're in. They just look at the street sign. The folder is the street sign. The system reads it automatically.

I built a small wrapper that does this. A wrapper is like a thin layer that wraps around the AI helper before it starts working. It glances at the folder, figures out the project name, hands that name to the dashboard, and then steps aside completely. By the time the AI helper starts its job, the correct project name is already attached.

No labels to type. No files to commit. Nothing to remember. I set this wrapper up once, and from then on every helper in every project reports the right name on its own.

I Made Sure It Handles the Messy Cases

Honest tools handle the ugly situations, so I covered them.

Run a helper outside the normal master folder? Instead of lying, it labels itself "unscoped," which is just an honest way of saying "this one doesn't belong to a known project." That's already better than the old default, which lied by slapping the same wrong name on everything.

Got a project tucked inside another project? It picks the top-level name, consistently. Folder names with spaces in them? Handled, so they don't break.

None of these are exotic. They're just the cases that separate "works in a demo" from "actually works in real life." A few extra lines, written once.

What Changed on the Dashboard

Before: one big lump. Total everything, no way to break it down.

After: every project lands in its own room.

I can now see activity, spending, and time broken down by project, automatically, with zero upkeep. When I want to know which project burned through my budget last week, I pick it from a list and the answer is right there. The project that was quietly eating 40% of my resources stopped hiding in the crowd.

The best part is the part I never think about. New projects label themselves the first time I run a helper inside them. I create a folder, start working, and it shows up correctly named, instantly. No setup step. The folder structure carried the information.

That's the difference between data and useful data. Data you can't break apart is barely better than no data, because you can't act on a lump.

Why This Is the Difference Between a Demo and a Real System

Anyone can build something that works in a clean demo. One project, type in the name, ship it, take the applause. It looks finished.

The hard part is the last mile. Making that same system run itself across 40 projects, with nothing to maintain by hand, is a completely different job. It's not glamorous. There's no flashy chart to show off. But it's the entire difference between a tool you actually use and a tool you abandon in month three.

Most builders stop at the interesting 80% and hand you something half-usable. Then they wonder why nobody trusts the data six months later.

I build the boring part that makes the thing survive contact with reality. The honest fallback for the case nobody planned for. The self-setup so your team never has to remember a step. The simple rule that says: don't make people declare what the system can figure out on its own.

When I build AI systems for a company, I'm not handing over a pretty demo that falls apart the moment it meets your real projects, your real edge cases, and your real team that will absolutely not maintain a settings file by hand. I've watched that movie. The tool gets praised at the kickoff and quietly dies a few months later.

If you've got something that's 80% there, technically working but nobody actually uses it because the last 20% was never finished, that's the work I do. The unglamorous, decisive part that turns a working demo into a system people rely on without thinking about it.

Ready to bring AI leadership into your company?

I work with a small number of companies at a time. If you're serious about AI, apply to work together and I'll review your application personally.

Apply to Work Together

Get AI insights for business leaders

Practical AI strategy from someone who built the systems — not just studied them. No spam, no fluff.

Ready to automate your growth?

Book a free 30-minute strategy call with Hodgen.AI.

Book a Strategy Call