Every SaaS App Needs a Governance Agent; here’s our blueprint

AI has changed the SaaS playbook. While most companies are racing to bolt on generative features, the real opportunity lies deeper, in rethinking how software maintains itself. The next wave of SaaS differentiation won’t come from what tools create, but from how they self-govern.

SaaS is struggling and focused on the wrong AI use cases

2025 has been a tough year for pre-AI SaaS companies; limited growth, disruption due to AI upstarts, hesitation from buyers to commit, and contractions as customers look to cut costs. 

In trying to compete, most SaaS companies have focussed their AI strategy on a few things:

1. Creation (tackling the “cold start problem”, including suggestions)

2. Summarization (for data analysis)

3. Support (or sales)

These have often been the edges of where AI-native products are seeking to disrupt traditional tools. 

Which makes sense, because those new tools are starting from scratch - they don’t have a ton of existing data, customers with habitual workflows, and lots of incremental feedback to respond to. 

However, SaaS tools can turn all this existing data and usage into a strong advantage if they can find ways to create “Automation” with AI that builds on the existing moat they have, rather than try to outcompete with Gen AI use cases. 

One of the most obvious and lowest-hanging fruits of “Automation” use cases = Account Maintenance. 

Account management is an annoying chore that teams have to do to prevent issues, bloat, slop, and risk as they use a tool. 

By default, most SaaS tools are some kind of CMS (Content Management Service), and so using the tool over time generates a lot more content, and more “operational debt”. 

This debt shows up everywhere:

• CRM systems: Duplicate contacts, stale opportunities, outdated pipeline stages

• Design tools: Abandoned projects, inconsistent naming, version sprawl

• Marketing platforms: Unused campaigns, off-brand templates, orphaned assets

• Project management: Dead tasks, zombie projects, and permission chaos

Account management today is all manual, tedious, and dependent on owners

Keeping a software tool clean and usable has until now required a ton of oversight and “admin” work, so much so that we now have people/teams/functions (e.g., Product Ops) responsible for it. 

It consists of:

• Some individual(s) taking responsibility for putting in a lot of manual time

• Wiki pages (to write, distribute, read, maintain, etc.)

• CSM suggestions at QBRs (hopefully CSMs are good and suggestions taken!)

• Internal review meetings (until they drop off the priority list)

Account management and associated governance happens everywhere and is a big hidden cost leading to greater inefficiency as the team grows. It also leads to risk and disruption when key “owners” of tools leave. 

Large teams are more risk-averse (they have more to lose) and so tend to move slowly as they invest in (manual) Governance, while startups are more willing to take risks, as they view this work as "bureaucratic" and don’t want to spend time on “management”. 

But what if we could solve this with AI and automation?

Account management work would then not scale with usage, meaning startups could be low risk, and large companies could still move quickly. 

It’s up to SaaS platforms to build their own “Governance Agents” and here’s how: 

Chameleon’s Governance Agent, Ranger

Chameleon enables teams to build in-app UX (banners, cards, tooltips, walkthroughs, checklists, microsurveys, etc.), and so “Governance” has always been a sensitive topic for customers. 

They need trust and controls to: 

• Prevent the wrong thing from showing up

• Avoid too many in-apps for users

• Handle sensitive end-user data

• Avoid duplication/redundancy 

Avoiding user error or missing key information is just as important as avoiding software bugs. But while preventing and managing bugs has a whole system around it, preventing user errors relies mainly on the individual to understand everything and not make a mistake 🫠

Chameleon already had some “governance features” including rate limiting (aka throttling), environment management, roles & permissions, element detection, and display controls, but now we have an Agent that does the following:

The jobs that we currently offer within Ranger include:

• Renaming: finds any objects that were created but not named or not named according to your existing naming patterns, and suggests better names; this makes it easier to find and organize everything your team has created!

• Deletion of redundant items: sometimes people create things, don’t use them, and then don’t get rid of them. Ranger looks for those (e.g. Segments not used by any Experiences) and encourages you to delete them.

• Experience management: In-app “Experiences” are core to Chameleon so we help customers archive ones not being used, unpublish those not being seen, and publish those that were recently edited.

• Removes teammates: we want to ensure your account stays secure, and you’re not overpaying for seats so we suggest you remove teammates that have not been active in the last few months (likely they left your company or changed roles).

• Broken elements: a key part of Experiences includes them being anchored to, or triggered by, in-app elements (being present or clicked, etc.), and when these change, your Experiences may not work.. So we monitor and highlight any discontinuities in our detection of these elements showing up in your app. 

We are in the process of building new jobs and are actively looking for feedback on which aspects would be helpful. Some currently leading contenders include:

• Tag management: applying Tags to Experiences based on what we detect is the way you use Tags (can be pretty varied by company)

• Styling consistency: identifying any Experiences that are off-brand (not using your Account’s “Themes”) and suggesting the closest matching Account Theme to apply

• User data trimming: archiving or deprioritizing user data that isn’t being actively used or sent, to reduce the noise, for example, when selecting an Event or User Property in a dropdown field 

• Integrations monitoring: detecting any issues with syncs or cases where you may need to re-authorize Chameleon or reconnect a synced tool

• Key and token management: decommissioning any keys or tokens that have not recently been used and identifying any that might stop working because the creator leaves

• Accessibility auditing: identifying any Themes or Styles that may not meet the latest accessibility guidelines and encouraging adjustments or changes

• Looking for more, so welcome feedback if you have ideas -- email us! 📧

Note that outside of this, we are also improving Governance in other ways, including by automatically generating intelligent descriptions of items you create (Segments, Events, Properties, Themes, Automations, etc.) to help everyone on your team stay informed and on the same page. 

How to build your own Governance Agent

Here’s a quick rundown of the steps we took, which you can adapt for your own use case: 

1. Inventory of objects and AI tagging

To begin, you should have a good understanding and table of all the key objects that are available in your product. For us, this included: Experiences (each type), Segments, Audiences, Themes, Tags, Events, Attributes, User Profiles, Teammates, etc. 

To enable us to leverage AI and Agents, we wanted an easy-to-understand and machine-readable understanding of these objects, without needing to send all the metadata associated with each object. 

Accordingly, we built generated AI “descriptions” (text-based summaries) for each object; intelligently providing context (e.g., research on the customer’s product to help generate more accurate inference of what an Event could mean) and instructions (e.g., to prioritize certain aspects of a Theme over others in generating a description)

We then generated all these and made them available for any tools/skills/routers/agents to be able to use, and this provided the basis for AI processing when needed. 

2. Jobs brainstorm and feedback

We then started a Google Sheet of ideas for “jobs” that our Agent could do, using obvious workflows including keeping names and descriptions accurate, removing stuff that wasn’t being used, identifying stuff that may get overlooked or is risky, etc. 

We described the basic algorithms for each of these jobs, e.g. “Delete X if Y and Z” and reviewed these with the other members of this product pod to ensure they made sense. 

Some of the jobs ended up being powered by AI; some were informed by AI; and some were without AI -- simple binary checks based on static but smart rules. We only leveraged AI if it wouldn’t have been possible to provide similar value without. 

Separately, we asked our CSM team to provide common items they either know customers find hard/annoying/time-consuming to deal with, or things they wish customers did to keep their accounts in better check. These then led to more jobs being added. 

We prioritized the jobs list into priority levels based on a simple RICE score (Reach = how widely applicable this job is; Impact = how helpful it is if we offered this job; Confidence = how likely it was the job would provide a suggestion that would be accepted; Effort = how much effort to build this job). 

3. UX design, branding, packaging etc. 

We then got into the detail of the UX; we tried to follow a standard format for all individual jobs (a table with rows of suggestions with some simple configuration / adjustment and key actions). Other aspects we reviewed included:

• What the default action should be (should it be accept, or skip) based on how strong an “opt-in” we wanted

• Which jobs should have a unique “customization” to tailor suggestions 

• How to avoid overwhelming someone who ends up getting a TON of suggestions

• How to make the act of accepting suggestions and clearing out the review list delightful

• How to track the overall work done and showcase impact

As this is an aspect without a ton of precedent we decided against investing too many cycles on perfecting the UX and expect to learn a lot during real testing with customers, and so budgeted some time and capacity to refine after customer testing. 

We also decided not to charge for this at this stage so we can drive adoption, get feedback, and hone the agent. In future we’d anticipate charging based on either suggestions or “accepted” suggestions to more closely tie value being received (and the cost of the work) to the price we’re charging. 

4. Testing with sample data and going live

The majority of the “aha!” for this Agent/feature is in how well it treats the data (e.g. how well the renaming suggestions actually reflect a customer’s preferences) and so we needed to test extensively on our existing staging data. We then extracted some additional, well-scoped data from existing customer accounts to verify against real and varied use cases.

Early results are promising but we’re looking forward to getting some specific feedback, and we’ve implemented an in-app Chameleon microsurvey to help us collect feedback from those customers that end up discovering and using the tool. 

We also added some tracking so we can easily monitor the % of successful suggestions and dive into the cases where Ranger isn’t working as well as we’d like.

Outlooks and examples

We don’t expect Chameleon to be the only SaaS product with a Governance Agent and would love to hear from you if your product/team has built one or is considering it. 

However, today there are not many examples of similar features/Agents elsewhere… One we came across was Syskit from Microsoft 365, which applies your existing policies to all your workplaces, as Microsoft is generally leading the Governance race across the largest software players. 

This makes it a fantastic opportunity to get ahead of the competition and win mindshare in being a cutting-edge SaaS application!

Looking further ahead we think this is the start of a movement around “autonomous” software; tools that do the job with limited (ongoing) human management and operate 24/7 to learn and improve. 

There are also significant implications for your users; treating them as orchestrators and managers and not builders or creators, and adapting the UX to orient around “reviewing” instead of “doing”. 

If you’re a founder, product leader or operator and interested in learning more about Ranger and our process, join me on this live event where we’ll share more on our background and roadmap.