Shipped the AI Control Tower MVP in ten weeks, and defined how conversation, agentic actions, deterministic workflows and human review work together.
ServiceNow · 2026 · Platform design for conversation, agent orchestration and human review, from approval day to center stage at Knowledge 2026
The problem nobody owned
The day after approval, the vision for an AI Native Platform experience became a deadline. We had 10 weeks to be code complete and present AI Control Tower on the center stage at Knowledge 2026, on a framework still being defined while we built on it.
We were two big teams coming together. Mine spent months proving that intelligence should be a foundation to the overall experience. The other product team wanted traditional SaaS: navigation first, intelligence as an add on. Eight business units contributed to it, each set up to move unblocked. The trade-off was that no one had the bandwidth to collaborate across every workstream, so the pieces grew apart. There was no agreed way to decide between us. And the feature that made the product AI-native, conversation, had no owner.
What I saw
Waiting for the "AI to be ready" meant we were never going to ship. The technology only improves through committed use. So the real question wasn't how much AI to ship, it was how to make it trustworthy at an MVP scope, and use customer trial sentiment to determine whether it's ready to be shipped. My answer: scoped, visible, correctable. Let's put intelligence in front of a person who decides.
Trustworthy also meant being honest about where AI didn't belong. An agent is the wrong answer when inference costs more than the work is worth, when the risk of a hallucination is too high, or when a deterministic action is simpler and just as good. Part of shipping an AI-native product was deciding where not to use AI.
Who I pulled in
I brought in the platform experience team and engineering, and wrote an alignment document that gave design, product, and engineering one shared model for behavior and interaction. When decisions started routing around design and product to hit the timeline, I re-established the triad: decisions through it, not around it.
Capturing interaction models and addressing them head on.
I had created another artifact -- the "ownership lens" -- to make it clear which teams own which part of the product.
I partnered with the team that owns the platform's deterministic workflows, playbooks, to work out where agents and playbooks should meet. I also coached design leaders who were new to the platform, and to AI-native patterns that were still taking shape.
Experimenting with ways to validate and code at the same time
What changed
Conversation became core
I took ownership of conversation. Teammates I respected felt it shouldn't be core, but I bet the other way. The industry was trending towards customers connecting their systems through protocols like MCP, and conversation would be how they worked across them. I defined how what a user asks activates the right agents and surfaces insight they can act on.
Evaluations became interface decisions
AI Control Tower moved me from AI strategy into the operational details of agent behavior. I reviewed the complete evaluation set, learned how each evaluation was implemented, and wrote scripted scenarios for how agent behavior should appear in the interface. The evaluations told us whether an agent got it right. The scenarios decided what a person would see when it did, when it wasn't sure, and when it failed.
We shipped with a limited evaluation set on purpose. Customer trials would give us real utterances, and those would shape the final criteria better than anything we could script in ten weeks.
Agents outside the chat pane
Most of my work sat outside the conversation pane, in the action layer. When a button hands work to an agent, the button has to say what the system will do and what the person still controls. Every affordance and state carried that contract: loading, permission, uncertainty, failure, rejection and reversal.
The action layer forced an explicit boundary between AI and deterministic behavior:
| Use an agent when… | Use a deterministic or manual action when… |
|---|---|
| Interpreting intent creates meaningful value | Inference would cost more than the value it produces |
| Orchestrating across steps or systems saves real effort | The risk of a hallucination is too high |
| Automation adds value a person can see | Automation adds little over doing it directly |
| The result is visible and correctable | A simple action is more reliable and cost-effective |
Human in the loop, with priorities the customer defines
On the home page, I shipped our first human-in-the-loop system: agent insights surfaced as prioritized actions for a person to review, take or reject. The system could interpret and propose. The person still decided.
However, priority couldn't be universal. Business units define urgency differently, and so do their customers. A single ranking model would have imposed one organization's assumptions on everyone else, so the criteria became configurable by business units and by customer admins.
Record pages shared that architecture but not a team, so I extended the patterns there too.
Agents and playbooks, side by side
Agents didn't replace deterministic workflows. With the respective team that owns deterministic workflows, we worked out how the two operate together: agents where interpretation or orchestration creates value, playbooks where consistency, cost or reliability matter more. The same question shaped my MCP work.
We shipped on center stage at Knowledge 2026. Customers joined early trials to shape what came next. The way we'd experimented became teaching material, other teams began adopting the patterns, and I joined the intake council that steered them, including the moments when a product team's choices diverged from platform guidance.
A protocol isn't an interface standard
A platform team and several business units proposed MCP Apps as the shared answer for interfaces. I recommended against treating them that way, yet. MCP was the right bet for connectivity; it's part of why conversation mattered. But inference interfaces didn't share consistent interaction or compatibility conventions. Standardizing on them early risked repeating the browser-compatibility mess of the 2000s: many producers building against inconsistent assumptions, and the platform inheriting the integration and quality debt. We had just spent years removing that kind of fragmentation.
Shipped, and what spread
We shipped on center stage at Knowledge 2026. Customers joined early trials to shape what came next. The way we'd experimented became teaching material, other teams began adopting the patterns, and I joined the intake council that steered them as one of four subject-matter experts, including the moments when a product team's choices diverged from platform guidance. A pattern that shipped here and held up across three council engagements became a candidate for native framework support.
Shipped: AI Control Tower MVP, conversation, the home-page human-in-the-loop system, record-page patterns. In trial: early customer trials, harvesting real utterances for evaluation criteria.
What I'd tell a leader
- No one can wait for the AI technology to work before shipping -- the AI is the product, and users must stress test it.
- If the MVP is something embarrassing, it might be the right thing to ship into customer trials as long as customers can contribute feedback.
- Ownership gaps don't close themselves. Someone has to step into them, and patterns only scale when someone owns the escalation path.
- We can confidently ship with limited initial evaluations by leveraging customer trials to harvest actual user utterances, which will dynamically shape our final evaluation criteria.
- Not every action needs an agent. When inference costs more than the work, or a wrong answer is expensive, ship the deterministic path and design it just as carefully.
- A protocol isn't an interface standard. Connectivity can be ready long before the experiences built on it are consistent.
The MVP proved the interaction direction. It also made the next problem unavoidable: patterns only scale when teams share definitions, quality criteria, decision records and an escalation path. That's Part 3.