Unifying multiple Business AI agents

In a rush to bring agentic advertising tools to market, Meta had incubated multiple Business AI (BizAI) product lines in parallel—each gated behind separate feature flags, each serving overlapping advertiser audiences, and each independently shipping similar capabilities.

As individual experiments, many had found product market fit within their respective gates. But further audience expansion would expose advertisers to redundant, potentially confusing experiences. And with eight separate products converging on the same customers, the risk to revenue and brand trust was significant.

The question put to me: should we unify these products, double down on one, or start fresh?

I began by conducting stakeholder interviews across all eight product teams—meeting with each product lead and their design org to map goals, roadmap timelines, and appetite for collaboration.

Not everyone was aligned. Several product leaders were resistant, viewing their roadmaps as too early-stage to absorb the disruption of unification. But the design teams largely understood the long-term stakes. I used that opening strategically: I proposed a cross-team design sprint, inviting a designer from each product area to participate. This let us surface the real problem space collaboratively, without triggering the organizational defensiveness that a top-down mandate would have.

The sprint surfaced four structural issues that any solution would need to address:

• Opt-in fragmentation: Each product had its own legal opt-in flow. A unified offering required a single Business AI opt-in within Ads Manager, with feature-level onboarding layered on top. Adoption and revenue risk would determine what came standard versus what was an add-on.
• Redundant onboarding and knowledge: Customers who had already onboarded to one BizAI feature would be asked to repeat the process for each new one. Shared onboarding, tied to a common knowledge layer, was the obvious fix.
• Siloed data: Each product maintained its own underlying data layer. A customer who trained one agent would have to re-enter the same information to train another. This wasn't just a UX problem—it was a structural one that would only compound with scale.
• Multiple management surfaces: Each product had a slightly different management UI, despite sharing the same entry point. The separation was an artifact of internal segmentation tooling, not user need. This was the definition of “shipping our org.”

With a clear view of the problem space in hand, I partnered with the data team to quantify the overlap. We mapped each product's audience against the others and modeled the revenue risk of allowing gate expansion without resolution.

Up to this point, the work had been entirely design-led. Engineering and PM partners had been informed, but hadn't yet meaningfully engaged—partly because the scope was so broad, and partly because the implications for their teams weren't yet tangible.

To change that, I consolidated the sprint output into a set of high-fidelity concept mocks that illustrated the proposed direction concretely. This became the turning point. Partners who had been skeptical began engaging seriously once they could see a clear, credible proposal rather than an abstract framework.

I authored a briefing document for the VP of Product and approximately 50 stakeholders in advance of a product review. This was a politically sensitive document—it needed to be substantive enough to drive real structural change across multiple teams, while being framed carefully enough not to create defensive reactions.

After 15 minutes of discussion, leadership aligned on the proposal with one modification: rather than retrofitting the existing eight products, we would apply these learnings to a new unified surface—one that would absorb the best of all eight and serve as the foundation going forward.

The VP described the outcome as "spot on" and "uncontroversial"—a meaningful signal given how contested the underlying decisions actually were.

We moved quickly into building the new product surface, which we called Weave (it aimed to "weave" together all these products). It adopted the unified opt-in model, shared knowledge layer, and consolidated management experience defined in the proposal—while giving each existing product a clear path to progressively integrate.

This project was fundamentally about prevention: stopping a fragmentation problem before it compounded into customer attrition or revenue loss. We shipped a solution that unified eight competing products into a coherent platform—without disrupting active customers, without risking revenue, and without forcing any single team to abandon their work.

The absence of a headline metric is, in this case, the point. The win was organizational and architectural—and it required navigating a genuinely complex stakeholder landscape to get there.