Orbis
From Silos to Shared Reasoning — Centralizing Platform Intelligence
Building the shared intelligence layer that reduced duplication and made insights cumulative across teams.
Context
Product Type:
Shared reasoning platform for cross-product decision making
Scale:
Collaborative build across Product, Applied Science, and Platform Engineering
Role:
Product Lead defining vision, architecture, and the shared “common language” for insight
The Bridge:
As individual products gained traction, insights fragmented across silos, making it difficult to form a coherent picture without manual effort. This pattern is common across media analytics, sports platforms, and advertising systems. Orbis addressed this by introducing a unified reasoning layer that reduced cognitive overhead and aligned interpretation across tools.
The Real Problem
What we initially believed:
The path forward was to make individual products smarter; adding more models and richer features to each silo.
What we realized:
The bottleneck wasn’t a lack of intelligence, it was a lack of connection.
Users could see individual signal, but they couldn’t:
Connect insights across tools or workflows
Understand how yesterday’s insight relates to today’s data
Build on conclusions without starting over
The risk wasn’t underpowered products. The risk was overwhelming users with intelligence they couldn’t synthesize.
The Moment:
Intelligence does not scale when embedded locally. Centralizing reasoning as a platform capability reduced duplication, aligned teams around a shared language, and turned fragmented signals into cumulative organizational understanding.
The Strategic Tradeoff
We faced a foundational decision:
Option A: Continue embedding intelligence separately inside each product
Faster short-term wins
Increasing fragmentation over time
Option B: Invest in a shared reasoning layer above all products
Slower initial delivery
Clear path to coherence, reuse, and scale
…
We chose Option B, Invest in a shared reasoning layer above all products
The pushback was not about vision, but readiness.
Product teams worried about losing velocity. Applied science worried about over-constraining exploration. Platform teams worried about owning a system too early.
What changed the decision was recognizing that fragmentation was already costing us. Without a unified reasoning layer, we were losing competitive advantage in deals and constraining our ability to scale insight across products. Waiting for “readiness” would have meant accepting long-term strategic loss.
I established a guiding principle:
Reasoning is a shared capability, not a local feature…
Once this decision was made, local intelligence implementations were deprecated by design
This became a platform rule, not a guideline.
What that meant in practice:
We prioritized:
Common language: A single, enforced representation of signals and context to prevent divergent interpretations across products.
Temporal memory: Platform-level memory that allowed insights to accumulate instead of resetting per product.
Insight foundation: A platform designed to move teams from reactive analysis to cumulative understanding.
We deferred:
Polished user-facing surfaces and premature automation, prioritizing foundational clarity over early UI expansion.
Where intelligence lives once products scale:
Orbis unified memory, context, and reasoning across products instead of duplicating intelligence inside each one.
The goal was not solving insight problems one product at a time and instead designed a foundation that could unify memory, context, and interpretation across the platform. The short-term cost was speed; the long-term gain was coherence.
Outcome
This decision set a precedent for how platform bets are evaluated, and would have been the failure point had coherence not emerged.
Impact:
Internal adoption: Orbis became the long-term intelligence strategy for the organization
Reduced redundancy: Enabled multiple products to ship intelligence features without duplicating reasoning logic
Paradigm shift: Intelligence moved from isolated outputs to continuous understanding
What I’d Do Differently
With the same architectural decision, I would introduce lightweight user-facing touchpoints earlier to test interaction hypotheses before platform assumptions fully hardened.
I owned the risk that centralization would slow teams down before it made them faster.