What product designers can learn from how they design intelligence flows.
Everyone thinks Perplexity and NotebookLM succeed because they use “better AI.”
They don’t. They use the same models as everyone else.
I spent three months deconstructing both — not just as a user, but as an architect. I mapped where intelligence lives, traced where humans direct and where AI executes.
Here’s what they actually did differently.
The answer isn’t in the AI models. It’s in how they architect the flow of work between human and AI.
This is what I call Intelligence Flow Architecture — the design of HOW cognitive work flows between human and artificial intelligence. Not what the AI can do, but how the collaboration is structured. Where does intelligence live? Who does what work? How do they hand off tasks?
This is a design discipline most product teams don’t know exists.
What I mean by “architecture”: I’m not talking about software architecture (microservices, backend systems) or information architecture (navigation, content structure). I’m talking about architecting the “how” — the flow of cognitive work between human and AI. Who does what? Where does intelligence live? How do they collaborate? This is the discipline of designing intelligent systems, not just intelligent features.
Let me show you exactly how Perplexity and NotebookLM do it — and what you can apply to your own products.
The architecture difference
Here’s what people miss:
Both products run on the same foundation — large language models, vector embeddings, search APIs, retrieval-augmented generation.
Same ingredients. Completely different results.
Why? Because they architected different intelligence flows — different answers to these critical questions:
- WHERE does AI work autonomously?
- WHERE does human provide direction?
- HOW do they hand off work between them?
- WHAT intelligence lives in which layer?
In his June 2025 keynote at Y Combinator, Andrej Karpathy — former director of AI at Tesla and OpenAI co-founder — described this exact shift: “LLMs aren’t just tools anymore. They’re becoming operating systems. The LLM is the CPU, the context window is the memory, and the real design work is architecting how this new computer orchestrates problem-solving.”
That’s exactly what Perplexity and NotebookLM understood.
Watch what happens:
When you ask Perplexity a question, AI doesn’t give you search results to click. It searches, synthesizes, answers, and cites sources — all autonomously.
Flow: You direct → AI discovers → You evaluate
When you upload documents to NotebookLM, AI doesn’t just “chat about your docs.” It analyzes, maps relationships, and generates insights — without waiting for instructions.
Flow: You curate sources → AI orchestrates knowledge → You explore
These are different architectures of collaboration.
Let me deconstruct both — layer by layer.
Perplexity’s intelligence flow architecture: Real-time discovery
What makes Perplexity feel different from Google isn’t better search. It’s a different distribution of cognitive work.
THE DESIGN DECISIONS:
Someone architected this. Someone decided:
- AI executes search autonomously (you don’t click 10 tabs)
- AI synthesizes while streaming (you don’t wait for batch results)
- AI handles citations in real-time (you don’t copy-paste sources)
- Human directs through conversation (you don’t fill search forms)
Cognitive split: ~20% Human (direction + evaluation) / 80% AI (discovery + synthesis)
What this feels like to you as a user:
You ask a question. Seconds later, you’re reading a synthesized answer with sources — without opening ten browser tabs. It feels like the system “just knows” what you meant and found the answer for you.
That feeling isn’t magic. It’s architecture.
The intelligence lives in the synthesis layer, orchestrating search and combining sources in real-time.
NotebookLM’s intelligence flow architecture: Document orchestration
NotebookLM made a completely different architectural choice.
Not web discovery. Document understanding.
THE DESIGN DECISIONS:
Someone architected this. Someone decided:
- AI works only with YOUR documents (not the entire web)
- AI builds knowledge graph invisibly (you experience results, not structure)
- AI generates multiple formats from same knowledge base
- Human curates sources and exploration direction
Cognitive split: ~30% Human (curation + direction) / 70% AI (analysis + orchestration)
What this feels like to you as a user:
You upload research papers. Within seconds, the system “understands” them — not just text search, but conceptual understanding. It finds connections you hadn’t seen. It can explain your own documents back to you in different formats.
That feeling isn’t magic. It’s architecture.
The intelligence lives in the knowledge processing layer, building invisible structure that enables multiple interaction modes.
The pattern they both reveal
Both succeed because they architected intelligence flows with clear principles.
(If you look back at the hero infographic at the top, you’ll see the contrast: Traditional AI = features bolted onto existing UIs. Intelligence Flow Architecture = intelligence embedded in the system’s core.)
The four principles
Principle 1: Design backward from autonomous execution
Don’t start with: “What interface should we show?”
Start with: “What will the system DO autonomously?”
- Perplexity: Search + synthesize + cite
- NotebookLM: Analyze + map + generate formats
Then design everything else to enable that autonomy.
This inverts traditional software design. Traditional products started with the interface — buttons, menus, workflows — then built backend systems to support them. Intelligence-first architecture starts with autonomous execution and works backward.
The shift is profound: from “How will users accomplish this task?” to “What can the system accomplish autonomously?” As Satya Nadella noted, we’re moving business logic from the application tier to the intelligence tier. The execution layer defines your system’s value — everything else exists to enable it.
Without this inversion, you end up with “AI features” bolted onto traditional interfaces. The intelligence feels like an add-on because it IS an add-on. True intelligence-first architecture means intelligence is embedded as fundamental structure, not added as features.
Principle 2: Embed intelligence in specific layers
Don’t bolt AI on as features.
Architect where intelligence lives:
- Perplexity: Intelligence in synthesis layer
- NotebookLM: Intelligence in knowledge processing layer
The intelligence isn’t visible as “AI feature” — it’s structural.
The test for embedded intelligence: Can you remove the AI and still have a functional product? If yes, intelligence is bolted on. If no, it’s embedded.
Perplexity without its synthesis intelligence doesn’t exist — it’s not “Google with AI added,” it’s a fundamentally different architecture where intelligence IS the product. NotebookLM’s knowledge processing layer isn’t a feature you can toggle off; it’s the system’s foundation.
This architectural embedding happens in specific layers of your five-layer stack. Intelligence doesn’t float everywhere — it concentrates where transformation occurs. In Perplexity, that’s Layer 2 (synthesis orchestration). In NotebookLM, it’s Layer 2 (knowledge graph construction). Identify where YOUR system’s intelligence must live, then build everything to support that layer.
Principle 3: Design clear human/AI boundaries
Define precisely where AI works autonomously and where human provides direction:
- Perplexity: Human directs → AI discovers → Human evaluates
- NotebookLM: Human curates → AI orchestrates → Human explores
Think of this as creating control maps — the new journey maps for AI experiences. Instead of mapping what users do, you map who is in control (user, AI, or both) and when that control shifts. As Rob Chappell notes, “The question is no longer ‘What is the user trying to do?’ The more relevant question is: ‘Who is in control at this moment, and how does that shift?’”
This is the evolution from traditional user journeys to human-AI collaboration flows.
This pattern is becoming so clear that in June 2025, Karpathy dedicated his Y Combinator keynote to it. He calls it “partial autonomy” — systems where AI generates and humans verify in a continuous loop.
The architectural insight: The fastest generation-verification loop wins. Not the most autonomous AI.
That’s why Cursor (coding), Perplexity (search), and NotebookLM (research) are succeeding — they optimized the loop, not the autonomy.
Principle 4: Optimize for cognitive distribution
Not: “Can AI do this task?”
But: “SHOULD AI do this, or SHOULD human?”
- Human strengths: Goal definition, judgment, creative direction, evaluation
- AI strengths: Discovery, synthesis, pattern recognition, execution
Both products make this mapping explicit in their architecture.
This requires mapping cognitive strengths systematically. From your Hybrid Cognition Map: Humans excel at goal definition, context understanding, judgment calls, ambiguity resolution, ethical decisions, creative direction, and stakeholder intuition. AI excels at information retrieval, pattern recognition, rapid iteration, consistency, tedious execution, multi-source synthesis, and 24/7 availability.
The magic happens at the intersection — not human OR AI, but human AND AI working in complementary strengths. Perplexity distributes: human defines information need (judgment), AI discovers and synthesizes (execution). NotebookLM distributes: human curates sources (context), AI processes and orchestrates (synthesis).
Poor cognitive distribution creates friction. If you ask humans to do what AI does better (tedious data processing), or ask AI to do what humans do better (strategic judgment), the collaboration fails. Design explicitly for strengths, not just capabilities.
A few days ago, my daughter had an English exam. She’d finished her practice exercises and wanted more. I took photos of the worksheet, showed them to an AI, and asked it to generate similar exercises. Seconds later: a new practice set, perfectly matched to her level.
She finished it. Asked for another. I already had everything loaded — another set appeared in seconds.
This wasn’t impressive because the AI was smart. It was impressive because I’d designed the how: Photo → Parse → Generate → Verify → Iterate. A five-second intelligence flow that would have taken me 30 minutes manually.
That’s Intelligence Flow Architecture in daily life.
Now let’s make it actionable for your team.
From analysis to application
You’ve seen how Perplexity and NotebookLM architect intelligence flows.
Now let’s make this actionable for your team.
The method works for any product workflow — from email to CRM to document editing.
Here’s the four-step process:
How to apply intelligence flow architecture to your product
STEP 1: Map your current workflow
Pick one core workflow. List every step users do manually.
STEP 2: Identify cognitive work
For each step, ask:
- Is this discovery work? (AI strength)
- Is this synthesis? (AI strength)
- Is this judgment? (Human strength)
- Is this goal-setting? (Human strength)
STEP 3: Design the intelligence flow
Redistribute work:
- What should AI do autonomously?
- Where does human direct?
- What are the handoff points?
STEP 4: Design backward from execution
- What will AI execute? (execution layer)
- What intelligence enables that? (intelligence layer)
- How do systems coordinate? (orchestration layer)
- How does human express intention? (input layer)
Example: Redesigning email with Intelligence Flow Architecture
Let’s make this concrete. Here’s how Intelligence Flow Architecture transforms a common workflow — email composition.
Traditional Gmail requires you to manually type, edit, format, and send — roughly 5 minutes of writing every word. Intelligence Flow Architecture redesigns this as a 6-layer collaboration where AI handles autonomous execution while you provide direction and judgment.
The result: 30 seconds instead of 5 minutes. Directing instead of writing.
The transformation:
- Before: You spend time writing, formatting, editing
- After: You spend time on judgment and direction
The architecture enables this:
- Intelligence Layer: Understands context, style, user’s past patterns
- Execution Layer: Drafts email autonomously
- Input Layer: Natural language intention (“decline politely”)
That’s Intelligence Flow Architecture applied.
Why not full autonomy? The Tesla lesson
Before we dive into what this means for product teams, let’s address the obvious question: Why design for partial autonomy instead of full autonomous agents?
In his June 2025 keynote, Karpathy shared a telling story from his five years building autonomous systems at Tesla:
In 2013, he took a perfect self-driving ride in a Waymo — zero interventions, flawless. He thought: “Self-driving is imminent.”
That was 12 years ago. Even now, Waymo vehicles that appear driverless still require significant human teleoperation and oversight.
His warning applies directly to product design: When AI generates massive outputs — 10,000 lines of code, complete research reports, fully redesigned interfaces — you haven’t saved time if verification takes hours. “When I see things like ‘oh 2025 is the year of agents,’ I get very concerned. This is the decade of agents.”
“We have to keep the AI on the leash,” Karpathy emphasized. Not because AI isn’t capable, but because verification speed determines actual productivity.
This is why Intelligence Flow Architecture prioritizes the generation-verification loop over full autonomy. The goal isn’t to remove humans from the loop. The goal is to make the loop spin as fast as possible.
A note for designers: You might be thinking “I’m not a system architect. Can I actually apply this?” Yes. Intelligence Flow Architecture isn’t about backend engineering — it’s about design thinking applied to human-AI collaboration. Start small: Pick one workflow. Map where human directs vs where AI executes. That’s architecting intelligence flows. You’re already doing this thinking — now you have language for it.
What this means for product teams
Here’s what changes when you adopt Intelligence Flow Architecture:
BEFORE (AI Features):
- PM says: “Let’s add AI to this workflow”
- Designer asks: “What should the AI button look like?”
- Engineer builds: API call to GPT → show response
- Result: Feature that feels bolted on
AFTER (Intelligence Flow Architecture):
- PM asks: “What cognitive work should AI handle autonomously?”
- Designer maps: Human direction → AI execution → Human evaluation
- Engineer architects: Intelligence layer + orchestration layer + execution layer
- Result: System that feels intelligent
The pattern
Perplexity and NotebookLM didn’t ask “How do we add AI?”
They asked: “How do we architect collaboration between human and artificial intelligence?”
That’s the difference between an AI feature and an intelligent system.
That’s Intelligence Flow Architecture.
And that framework — deciding where intelligence lives, how work distributes, when systems execute autonomously — that’s intelligence-first architecture.
Same AI models.
Different architecture.
Completely different experience.
Now you know why.
Perplexity and NotebookLM don’t use better AI—they use better intelligence flow architecture was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.