Spandana Kintali

The problem

AI Control Tower keeps an inventory of an enterprise's AI agents, use cases, and models, each with metadata across many fields, such as description, provider, and model card. Rule-based detection flagged records with missing fields, but a flag doesn't tell a steward what belongs in the field. Governance is only as good as the inventory behind it, so every gap in a record was a gap in oversight.

My role

I owned the product experience: which fields to enrich, how each one gets filled, how recommendations appear, and how they're approved. Engineering built the agent on ServiceNow's existing agent framework.

Outcome

Shipped to General Availability.

What I'd do next

Had I continued on the product, my next step would be handling conflicting results across sources. Rather than having the agent pick a winner, I'd show the conflicts side by side with their sources and let the steward decide the best course.

The problem

ServiceNow's out-of-the-box skills, agents, and agentic workflows were opening up to four model providers (ServiceNow, Claude, Google, and Microsoft Azure), so customers could choose a model per AI system. Choice creates compliance risk. Rules on where data can be processed and which providers are permitted differ by country and keep changing. Without controls, a developer could deploy an AI system on a provider the organization's compliance team never approved.

Who it's for

AI stewards and AI centers of excellence set the policy. Developers and admins who build and deploy AI systems have to stay within it.

The challenge

One policy, six teams. A control only works if it holds everywhere an AI system can be activated. Six teams each owned part of that path: the control surface, the service that manages available providers, the infrastructure that routes model calls, and the three build and admin surfaces where AI systems get activated. A steward shouldn't have to set the same policy in several places, because gaps between them would be compliance gaps.

My role

I coordinated the six teams around a single set of cross-product requirements, so the policy a steward set would mean the same thing on every surface. I also worked with design on the UX patterns. Engineering teams owned the architecture and the build.

Outcome

Built across April–June 2025 and made available to all Pro Plus customers in July 2025. It covers skills, agents, and agentic workflows, for both regulated and non-regulated markets, and kept improving in later releases.

The problem

Managers are expected to develop their teams, but most have no reliable view of what skills their team actually has. In my customer interviews, one manager of eight described keeping it all in a spreadsheet, and others asked for a dashboard that showed skills, proficiency levels, and gaps in one place.

Who it's for

Managers, who need to understand their team's strengths and gaps and support their people's development. Employees and HR benefit indirectly, because the skills data feeds their learning and growth plans.

The challenge

Trustworthy skills data across several teams. A skills dashboard is only as good as the data behind it. Skills were partly self-reported, so scores built on them would mislead. The feature also depended on several teams: skill profiles and job architecture on the platform side, and learning and growth plans on the development side. If those pieces didn't connect, managers would see numbers with no way to act on them.

My role

I led a team of 8 engineers, 1 UX designer, and 1 visual designer from discovery through General Availability. I ran manager interviews with our research team, benchmarked competitors, wrote the use cases, and defined the dependencies with the platform and Employee Growth & Development teams.

Outcome

Shipped to General Availability in early 2024 as part of Manager Hub, which is deployed across ~1,200 global customers.