Flag

We stand with Ukraine and our team members from Ukraine. Here are ways you can help

Get exclusive access to thought-provoking articles, bonus podcast content, and cutting-edge whitepapers. Become a member of the UX Magazine community today!

Home ›› Scaled AI Requires Canonical Truth

Scaled AI Requires Canonical Truth

by Josh Tyson
2 min read
Share this post on
Tweet
Share
Post
Share
Email
Print

Save

Before enterprises can deploy AI agents that actually work, they need something most organizations don’t have: a single, authoritative source of truth. Joe DosSantos, VP of Enterprise Data and Analytics at Workday, joins Robb and Josh for a wide-ranging conversation about canonical knowledge, the semantic layer, and why data governance, a concept from the 1990s, has suddenly become essential for AI deployment.

The core challenge? Large language models are predictive engines that “anticipate what you probably would mean,” as DosSantos explains. They’re “pretty good at words, but they suck at math.” For B2C applications where multiple interpretations are acceptable, this works fine. But in enterprise contexts, where revenue was exactly $1.625651 billion last year, organizations need deterministic truth, not probabilistic guesses.

The solution requires three layers: establishing canonical knowledge (the laborious human work of defining what data means in your organization), building a semantic layer (the translation mechanism between human definitions and machine-readable formats like YAML), and using the LLM as an interface to deterministic back-end systems rather than treating AI as the system itself.

DosSantos offers a compelling metaphor: trying to deploy AI agents without this foundation is like wanting granite countertops without building the foundation of the house first. You can’t skip it, it’s non-negotiable infrastructure. 

The conversation also tackles AI anxiety, with DosSantos referencing Kate Darling’s framework of thinking about AI as animals rather than human replacements, and Robb Wilson proposing we view AI as simply “smarter machines” — skill saws that know the difference between wood and fingers, stoves that prevent fires, and washing machines that don’t shrink clothes.

For leaders evaluating AI investments, this episode clarifies what actually needs to be built before agents can deliver value: not flashy use cases, but the unglamorous, essential work of data governance and semantic translation.

post authorJosh Tyson

Josh Tyson
Josh Tyson is the co-author of the first bestselling book about conversational AI, Age of Invisible Machines. He is also the Director of Creative Content at OneReach.ai and co-host of both the Invisible Machines and N9K podcasts. His writing has appeared in numerous publications over the years, including Chicago Reader, Fast Company, FLAUNT, The New York Times, Observer, SLAP, Stop Smiling, Thrasher, and Westword. 

Tweet
Share
Post
Share
Email
Print

Related Articles

Learn why the real design challenge of agile is not speed but learning to design smaller, one valuable slice at a time.

Article by Paivi Salminen
Designing Small Is Harder than Designing Big
  • The article suggests that agile design is not about quick development but rather the more difficult discipline of designing smaller, resisting the temptation to map out complete systems, avoiding the snare of horizontal slicing, and inquiring into what the smallest iteration of an idea is that still provides real value to users.
Share:Designing Small Is Harder than Designing Big
5 min read

Find out how clicking “Accept All” is not really consent and how ethical UX design can return user choice to users.

Article by Tushar Deshmukh
Consent Fatigue: Are We Designing People into Compliance?
  • The article shows that consent fatigue is not a user problem but a design problem in which endless permission popups, visual manipulation, and legal-shield thinking have quietly replaced real user autonomy with engineered compliance.
Share:Consent Fatigue: Are We Designing People into Compliance?
10 min read

Learn why teams burn out, innovation stalls, and leaders miss impact without realizing the root cause.

Article by Pavel Bukengolts
The Real Reason Your Design Team Burns Out (And How to Fix It)
  • The piece shows that design teams don’t get burned out from working too much; they get burned out from things like lost files, changing briefs, and decisions that aren’t written down. DesignOps is the answer: treating repetition as a sign, adding mentorship to workflows, and using capability data instead of gut-feeling leadership.
Share:The Real Reason Your Design Team Burns Out (And How to Fix It)
6 min read

Join the UX Magazine community!

Stay informed with exclusive content on the intersection of UX, AI agents, and agentic automation—essential reading for future-focused professionals.

Hello!

You're officially a member of the UX Magazine Community.
We're excited to have you with us!

Thank you!

To begin viewing member content, please verify your email.

Get Paid to Test AI Products

Earn an average of $100 per test by reviewing AI-first product experiences and sharing your feedback.

    Tell us about you. Enroll in the course.

      This website uses cookies to ensure you get the best experience on our website. Check our privacy policy and