[Trackingplan](/categories/news) October 27, 2026

# From SaaS to agents: our users' job became the agent's job

Trackingplan's CEO on how a first AI feature taught us our users' job was the agent's job, and why we rebuilt the SaaS around agents.

![](/images/699487c44d72b2ee9745211c_josele-perez.avif)

**[Josele Pérez](/author/josele-perez)** CEO & Co-founder

11 min read · 2355 words

> **TL;DR** Last Christmas we built our first AI feature to debug the alerts Trackingplan already sent. Within weeks users were asking it to debug more than 80% of those alerts. We then built a copilot for digital analysts and used it every day across the company, until we saw it was not a copilot at all: once we scheduled the prompts we kept repeating, it was doing the job our users did in Trackingplan. So we rebuilt Trackingplan as a harness where agents do the marketing analytics work, on top of the data quality layer we had spent years building. What made it possible was computer use: an agent no longer needs an API to use a tool. The hard part was not the model. It was getting the same answer twice.

I have been writing software for 30 years, and I try to stay close to every new wave of tools. By late 2025 I was using agents every day, not only to write code but to automate tasks and analyse data. That habit is behind the biggest decision we have made at Trackingplan since we started: to stop building a product people operate, and to build agents that do the work.

I know how that sounds. For months we have all been reading posts like this one, and many of them were more marketing than anything else. An agent could only act through integrations, and for most of the tools a marketing team uses those integrations were complex or did not exist. A person who could open each tool and click through it still had the advantage.

What changed that is computer use. An agent no longer depends on an API or an MCP server to work with a tool. It opens a browser and uses the same interface the user would have used, to act or to pull data out of tools that an agent could not touch otherwise. That is what makes it possible for an agent to do a user's whole job today, not only the parts that happen to have an API.

This is how we got there.

## The alert was only the start

For years Trackingplan was a SaaS for what we now call marketing observability. It sat where marketing data is born, in the hit, the dataLayer, the pixel, the consent state, the tag manager release, and watched it. It monitored automatically, learned what normal looked like and alerted teams when something broke.

That worked, and it is still the foundation of everything we do. But an alert is the start of the work, not the end of it. Someone still had to open it, understand what broke, find out why, decide how to fix it and explain it to the rest of the team. Monitoring and alerting were automated. Debugging was not.

Last Christmas we built our first AI feature to close that gap. It took the data Trackingplan already collected about each alert and did the debugging: what broke, where, the likely cause and what to do about it. We launched it at the end of January as the [AI Debugger](/changelog/trackingplans-ai-debugger), and within a few weeks it was the feature our users valued most. We could tell because they asked it to debug more than 80% of the alerts we sent, and because customers kept telling us it saved them several hours a week they used to spend debugging and trying to reproduce errors.

One case stayed with me. A customer's sales in GA4 stopped adding up. Someone had changed the currency code of one market in the dataLayer, so that market's revenue no longer matched. Nothing was missing and nothing threw an error; the numbers were just wrong. The agent found the change and the customer fixed it within hours, not days, without an analyst spending hours looking for it.

That told us where the value of the product had been all along: not in showing people a problem, but in getting them to the answer. So we asked the obvious next question: where else could AI do the work?

## A copilot that wasn't

The answer was in front of us. We work with marketing and analytics teams every day, and we see how much of their week goes into tasks that are repetitive and low in value, but necessary for the work that has impact: checking that a release did not break tracking, reconciling numbers between tools, auditing consent and cookies, writing the weekly report, chasing why conversions dropped on Monday. Nobody chooses that work, and everybody depends on it.

Our first approach was the obvious one in 2026: a copilot for the digital analyst. We built a prototype on [nao](https://github.com/getnao/nao), an open-source analytics agent, connected it to the data Trackingplan already had, and the whole company started using it every day. Not as a demo, but to answer real questions about real customers' tracking.

A few things surprised us. The first was what the browser changed. An agent driving a real browser can reproduce a broken checkout on a live site, capture every network request and console error, and show you the hit that went missing, without anyone building an integration for that site first. An agent that can read a tag manager can tell you which release changed what. That is investigation work, not autocomplete.

The second was how much of the context could be learned instead of written. The agent did not need someone to document the tracking plan, because Trackingplan already discovers it from real traffic. What the traffic cannot say, a pixel retired on purpose or a test domain to exclude, the team tells it once, and it keeps it for everyone.

The one that mattered most was simpler: we kept typing the same prompts. The same checks, account after account. "Did yesterday's release break anything?" "Do the purchases in GA4 match the backend?" Once we put those prompts on a schedule, or fired them on a trigger like a new release being detected, the copilot stopped being a tool that made someone on the team faster. It was doing a large part of that person's work.

Somewhere in those weeks it clicked. A copilot assumes a person in the driver's seat, operating the product, with AI helping. But look at what that person did in Trackingplan: open an alert, investigate it, decide whether it mattered, fix it or route it, and report on it. The agent was doing that loop on its own. What we had built was not a copilot for the Trackingplan user. It was doing the Trackingplan user's job.

The person does not disappear. They stop operating a tool and start directing work: they say what matters, set the bar, review what the agent found and decide. The hours that went into checking go back to the decisions that need a person.

## What it took

The copilot also showed us its worst failure early. Ask an LLM the same question about the same marketing data twice and you can get two different answers: a different date range, a different definition of a conversion, a sum across accounts that should never be summed. Each answer sounds sure of itself. Developers have the "works on my machine" meme; analytics with AI has its own, "it works on my ChatGPT". A prompt that gave a good answer on Tuesday is not a process anyone can rely on.

What fixed it was not a better model. It was a very precise context layer: what each table means, which metrics exist and how they are computed, what this customer's team already knows, and which rules can never be broken, plus old-fashioned code for everything that should not depend on the model's judgement, and tests that tell us when an answer drifts.

That is what we rebuilt Trackingplan into: [an agent harness for marketing data](/blog/agent-harness-for-marketing-data), the data, the context, the tools, the rules and the tests that let agents do marketing analytics work and get it right. We launched it in September; [why the same model gives different answers with and without that harness](/blog/same-models-different-answers) is its own post. You ask it a question and it answers from your own tracking data, and the prompts we used to repeat by hand, a weekly report, a compliance audit for the DPO, a watch on a dataLayer that keeps regressing, are described once and run on a schedule or a trigger.

The one thing we did not throw away is the monitoring, and it is the reason this works. An agent that acts on marketing data is only as good as that data. A wrong number does not look broken; it looks like an answer, and now it can trigger an action. Most data quality tooling starts downstream, in the warehouse, after the decisions that make a number right or wrong have already happened. We had spent years building the layer that checks it at the source, before it becomes the number everyone relies on. That is why I wrote in our [manifesto](/landings/manifesto) that an agent cannot reliably operate a system it cannot observe.

## To other SaaS founders: someone will replace your customers with agents

If you run a SaaS company, this is not a possibility to keep an eye on. It is already happening.

Right now, in twenty places around the world, a 17-year-old is vibe-coding an agent that does, on its own, what your customers do today with your SaaS and its integrations. In less time, and for less than what a single seat of your SaaS costs. They don't need your API: with computer use, the agent uses your interface the way your users do. They don't need funding, a sales team or a roadmap. They need a weekend, and if it doesn't work, they will try again the next one.

Look at what your users do inside your product every day: the screens they open, the checks they repeat, the reports they export and rewrite. That loop is exactly what those kids are automating. The first one who gets it right will sell your customers the work done instead of the software to do it, and customers pay for outcomes, not for seats in front of screens. If you don't lead that change, you won't lose a feature or a few accounts. You will lose the whole pie.

You still start ahead. A new entrant has the same models you have and nothing else. You have the know-how: years of knowing what your users get wrong, what good looks like in your domain and which edge cases break everything, which is the context an agent needs and the hardest part to build. You have the data your product already collects, which a startup has to ask for. And you have the customers, who already trust you with their work and will tell you, faster than anyone, which tasks they want off their plate.

That lead is shrinking every week. Every month one of those agents spends with your customers' data, it learns some of your know-how; every customer it signs is one you lose. What it costs you to move is the willingness to question the product you have: some of your screens and features will matter less once an agent does the work behind them. That is uncomfortable. Losing your company to a teenager with a laptop is a lot more uncomfortable.

If I had to boil down what worked for us, it would be four things:

-   Use the agents yourself, every day. We only understood what we had once the whole company depended on it, and our own [engineering team](/blog/trackingplan-x-ai-an-engineering-note) had already gone from autocomplete to agent-written code.
-   Watch which feature people value most, not which one is newest. Ours was the one that did work for them.
-   Look for the prompts you repeat. If you run the same prompt for every customer, it should be running on a schedule or a trigger, and you are not building a copilot.
-   Spend on the context, not the model. The model is the same for everyone. Your data, your context and your checks are not, and they are what makes two runs give the same answer.

We started by automating the alert. We ended up automating the work behind it. Every product built for people to operate will face the same question we did, and sooner than most expect. Better to answer it yourself.

## Frequently asked questions

### What is the difference between an AI copilot and an AI agent?

A copilot helps a person do a task: it suggests, drafts and answers while the person drives. An agent does the task: it decides what to look at, uses tools, checks its own work and comes back with a result. In a copilot the person is the operator; with an agent the person sets the goal and reviews the outcome.

### What are AI agents for marketing?

Software that carries out marketing work on its own, such as monitoring tracking, investigating a drop in conversions, auditing consent or writing the weekly report, using the same data and tools a marketing analyst would. They are only as reliable as the data they work on, which is why they need to be able to check it.

### Why did Trackingplan become an AI agent?

Because our first AI feature, which debugged tracking alerts, became the most valued part of the product within weeks: users asked it to debug more than 80% of the alerts we sent, and customers told us it saved them several hours a week. The copilot we built next turned out to do the work our users used to do in Trackingplan themselves. Rebuilding the product around agents was the way to give customers that work done, not more screens to operate.

### Will AI agents replace SaaS?

They will replace the part of SaaS where people operate screens to get work done. The know-how, the data and the customers stay valuable, and the SaaS companies that build the agent version of their own product start with all three. The ones that don't will meet a competitor that did.

On this page

1.  [*01*The alert was only the start](#the-alert-was-only-the-start)
2.  [*02*A copilot that wasn't](#a-copilot-that-wasn-t)
3.  [*03*What it took](#what-it-took)
4.  [*04*To other SaaS founders: someone will replace your customers with agents](#to-other-saas-founders-someone-will-replace-your-customers-with-agents)
5.  [*05*Frequently asked questions](#frequently-asked-questions)

**Stop babysitting tags**

Trackingplan audits your real user data around the clock and flags issues before they cost you.

[Start free trial →](https://app.trackingplan.com/signup)

![](/images/699487c44d72b2ee9745211c_josele-perez.avif)

**Josele Pérez** CEO & Co-founder

Co-founder and CEO of Trackingplan, a product-driven founder and lifelong tech enthusiast who has been writing software for 30 years.

Share Copy link [LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.trackingplan.com%2Fblog%2Ffrom-saas-to-agents) [X](https://twitter.com/intent/tweet?url=https%3A%2F%2Fwww.trackingplan.com%2Fblog%2Ffrom-saas-to-agents&text=From%20SaaS%20to%20agents%3A%20our%20users%27%20job%20became%20the%20agent%27s%20job)

Read next

[All Blog →](/blog)

-   [
    
    12 minTrackingplanOctober 25, 2026
    
    ### Agent harness for marketing data: how we built ours
    
    An agent harness is everything around the model. How we built one for marketing data: the semantic layer, the tools, the evals, and what we threw away.
    
    by **Alexandros Andre Chaaraoui**](/blog/agent-harness-for-marketing-data)
-   [
    
    13 minTrackingplanSeptember 28, 2026
    
    ### Same models, different answers.
    
    Inside the new agentic Trackingplan: how it works, and why it isn’t comparable to an LLM with an MCP.
    
    by **Alexandros Andre Chaaraoui**](/blog/same-models-different-answers)
-   [
    
    10 minTrackingplanOctober 27, 2026
    
    ### Context layer for AI agents: how we built ours
    
    What a context layer for AI agents is, how it differs from a semantic layer, and five lessons from building the one behind Trackingplan's analytics agent.
    
    by **Alexandros Andre Chaaraoui**](/blog/context-layer-for-ai-agents)

Trackingplan

## See everything. Miss nothing.

Your implementations audited around the clock with real-time, real-user data. Real-time alerts about errors or changes in your data, campaigns, pixels, privacy and consent. Let AI flag issues before they cost you.

[Start free trial →](https://app.trackingplan.com/signup) [Book a demo](/demo)