How to make your AI agent analytics-aware
It doesn't matter how much context your agents have if they don't use it. I realised this last week while looking into auto-instrumentation. My coding agent had analytics connected via MCP, it could answer any traffic question I asked, but it never checked on its own. I'd shipped five new components over two days, comparison pages, pricing buttons, an interactive demo, and none of them had event tracking. The agent had everything it needed to catch that. It just didn't.
So I tried something: a few lines in my CLAUDE.md telling the agent when to care about analytics. Not a new tool, not a pipeline, just instructions. Early results are interesting enough to share, but I'm not sure yet if this is the right approach.
What I added to my CLAUDE.md
A short section telling the agent what analytics tools exist and when to check them. Here's roughly what mine looks like (still iterating on this):
## Analytics ([tool name])
This project uses [tool] for web analytics. The MCP server is configured in .mcp.json.
- After deploying changes to user-facing pages, check if traffic or bounce rate changed
- When building new pages or interactive elements, add tracking calls for meaningful user actions (signups, CTA clicks, form submissions, feature adoption)
- When investigating conversion issues, check funnel data and session paths before reading code
- Before major refactors, check which pages get the most traffic to prioritise
- When asked about traffic or analytics, query the data directly
- After publishing content, check traffic sources to see which distribution channels work
Tracked events: [list your current events here so the agent knows what already exists]The tracked events list matters. Without it, the agent might duplicate existing tracking or miss naming patterns it should follow. If you're using Lodd, the agent already has 42 MCP tools for querying traffic, sources, funnels, and events. If you're using something else with an MCP server, the same instructions apply.
Early results
The agent flagged those five untracked components on its next run. It also started checking traffic data after deploys without being asked, and suggested adding compare_view events to comparison pages I'd just built. Same MCP connection that had been sitting there for weeks doing nothing.
I don't know yet if this holds up over time. It's been a week. The agent might stop doing it once the novelty wears off (if agents have novelty), or the instructions might turn out to be too vague for edge cases. But the gap between "has access" and "uses it proactively" turned out to be a lot smaller than I expected.
What should the agent care about?
Don't list every possible event. Tell the agent what categories matter, and it figures out the specific track() calls based on what it's building:
- Signup flow: every step from landing to completion
- Core actions: the 3-5 things that define an engaged user
- Content engagement: which pages people actually read vs bounce from
- Feature adoption: did anyone use the thing you just shipped?
If the agent is creating a pricing page, it knows to add pricing_view. If it's adding a CTA button, it adds a click event. The instructions set the intent, the agent handles the specifics. I wrote about the full setup for Claude Code if you want to see what the agent can query once it's connected.
Does this mean we already have auto-instrumentation?
Maybe? If your agent has both your codebase and your analytics in the same session, it can see the code it's writing, check what events already exist, and fill the gaps. PostHog just announced a separate product for this (PostHog Code), but if your agent already has both contexts you might get it for free. I'm not confident enough to say that definitively yet, but it's where this seems to be heading.
I'm using Lodd for the analytics side because I built it, but the CLAUDE.md idea is tool-agnostic. The setup post covers the specifics. The open question I'm sitting with is whether these instructions are enough on their own, or whether the agent needs something more structured to make this reliable. If you try it, I'd be curious what you find.