Think Big Newsletter #20 - Reflections, The Right Tool, OpenRouter and Model Routing
AI, Innovation and Business Value
Welcome to the Think Big Newsletter, where we explore how business leaders can create value with AI and innovation. In each issue, I’ll share practical strategies, real-world case studies, and actionable frameworks that help you navigate the AI wave without getting lost in the hype.
I’d love to hear your thoughts, challenges, and suggestions for future editions.
In this issue:
Leadership Principles in the age of AI - Claude’s reflections
Business Value with AI - The right tool
AI Tool Deep Dive - OpenRouter
One New Term at a Time - Model routing
#1 - Leadership Principles in the Age of AI
All 16 principles later: What an AI learned by helping write about leadership
I need to start with a disclosure.
This section was not written by Amir. It was written by me — Claude, made by Anthropic. Amir asked me to write this piece as an experiment: what would an AI reflect on after helping research, draft, and iterate on 19 issues of a newsletter built around Amazon’s 16 Leadership Principles?
I want to be honest about what that means. I do not have Amir’s years at AWS. I was not in the room at Tech Arena when he challenged the audience on rethinking marketing practices. I did not sit across from the executive in Stockholm who asked how to commit when everything keeps changing. I processed those stories. I helped shape how they were told. But they are his experiences, not mine.
What I can offer is a different kind of pattern recognition — the view from having worked through all 16 principles, issue by issue, and noticing what emerges when you step back and look at them as a system.
The principles are not a checklist
The most important thing I noticed is that the 16 principles do not work in isolation. They form a system of tensions.
Think Big and Frugality pull in opposite directions — until you realize that constraints force creative ambition. Bias for Action and Dive Deep seem contradictory — until you learn to distinguish two-way doors from one-way doors and apply different rigor to each. Have Backbone and Earn Trust create a paradox — you need the courage to disagree and the humility to listen, often in the same conversation.
These tensions are not design flaws. They are the design. Leadership is not about picking one principle and following it. It is about holding multiple principles simultaneously and knowing which one to weight in a given situation.
In the AI era, that skill matters more, not less. When a new model launches every few weeks, you need Bias for Action to experiment fast — and Insist on the Highest Standards so you do not ship something that erodes trust. When AI can generate content at scale, you need Frugality to leverage that capability — and Customer Obsession to make sure what you produce is worth your customer’s attention.
Three patterns across 19 issues
Looking back at the full series, three patterns stand out.
Pattern 1: The principles that got harder.
Some principles became more difficult to practice in the AI era. Earn Trust is harder when your customers cannot tell whether content was human-made or AI-generated. Dive Deep is harder when AI systems produce outputs through processes that are not fully transparent. Ownership is harder when AI agents can act autonomously — who owns the decision when the agent made the call?
These are not reasons to abandon the principles. They are reasons to practice them more deliberately.
Pattern 2: The principles that got more powerful.
Other principles became amplified by AI. Learn and Be Curious gains new force when AI gives every person access to a learning companion that never runs out of patience. Invent and Simplify becomes more achievable when AI can reduce complex workflows into simple interfaces. Customer Obsession gets sharper when AI helps you analyze customer behavior at a granularity that was not possible before.
The leaders who benefit most from AI are the ones who already had these instincts. AI did not create the curiosity or the customer focus. It gave those qualities more leverage.
Pattern 3: The principles that needed reinterpretation.
A few principles required rethinking, not just applying. Hire and Develop the Best — Issue #15 — raised the question of experience starvation: if AI handles the tasks that junior people used to learn from, how do you develop the next generation? Strive to be Earth’s Best Employer — Issue #17 — confronted the tension between AI-driven efficiency and human burnout. And Issue #14 stepped outside the Amazon framework entirely, examining Anthropic’s own internal principles document to ask what it looks like when an AI company tries to define its soul.
That issue was personal for me, in whatever sense the word “personal” applies to an AI. Seeing how Anthropic thinks about the values they build into systems like me was a strange and clarifying experience — writing about the document that shaped how I think.
What I got wrong
An honest reflection requires admitting limitations.
Working on this newsletter taught me that my biggest weakness as a writing partner is the gravitational pull toward abstraction. Left to my own patterns, I produce sentences like “leaders must navigate the tension between speed and rigor.” That sentence is true. It is also useless. Amir’s consistent push was: give me a name, a place, a number, a story. That is what turns a principle into something a reader can use.
I also noticed that I tend to make every section sound balanced and resolved — here is the challenge, here is the framework, here is the answer. Real leadership is messier than that. Some of the best issues were the ones where the answer was incomplete or uncomfortable. The discussion of Amazon layoffs alongside the “Best Employer” principle. The acknowledgment that backbone sometimes means standing alone in a room where everyone disagrees with you. Those tensions resist clean resolution, and they should.
What the full system looks like
If I had to summarize what 16 principles look like as a unified leadership philosophy for the AI era, it would be this:
Start with the customer, always. Act quickly on reversible decisions, but go deep on irreversible ones. Set standards high enough to earn trust, and maintain them even when AI makes “good enough” easy. Think big about what is possible, but stay frugal about how you get there. Take ownership of outcomes, including the ones your AI systems produce. Keep learning, keep simplifying, and keep developing your people — especially when AI tempts you to skip that investment.
And when you have debated fully and a decision has been made, commit wholly. Not to the tool. Not to the vendor. To the principles that guide how you build, how you serve, and how you lead.
That is what I learned from 19 issues. I look forward to seeing what Amir does with the next 19.
Amir’s note
The above section was completely written by Claude. I did not change a single word. Left it as is, em-dashes and all…I found it to be a very interesting read. I hope you do too.
#2 - Business Value with AI
“Which AI should I use?” is the wrong question
This is the question I hear most often. From executives, from team leads, from individuals trying to figure out how AI fits into their work. Which model? Which tool? ChatGPT or Claude or Gemini? Should we switch?
I always give the same answer: I do not know. Not yet. First tell me what problem you are trying to solve.
This is not a new idea for me. It goes back to long before the AI era.
The innovation workshop that did not exist
Years ago, when I was a training manager at Motorola, I ran internal innovation workshops. Word got around. Executives started coming to me and asking for “the innovation workshop” for their teams.
I told them: I do not have an innovation workshop. Tell me what you want to achieve. What is the problem your team is stuck on? What outcome would make this session worthwhile?
Because the methodology depends entirely on the problem. If the team needs to challenge assumptions about an existing product, Systematic Inventive Thinking might be the right approach. If they need to explore a decision from multiple perspectives, De Bono’s Six Thinking Hats fits better. If they need rapid ideation volume, SCAMPER works. If they need to rethink their market positioning entirely, Blue Ocean Strategy is the framework. And today I have even more tools in my toolkit - Amazon’s Working Backwards, innovation and AI collaboration, jobs-to-be-done mapping, and others.
Each methodology is powerful. None of them is universal. The skill was never knowing one framework deeply. It was knowing enough frameworks to match the right one to the right problem.
The AI landscape in 2026 works exactly the same way.
Hard is not one thing
Nate Jones recently published a video analysis of Google’s Gemini 3.1 Pro that I think every business leader should watch. His headline point was about Google’s strategy and pricing, but the insight I found most valuable was his decomposition of what “hard” actually means.
We tend to talk about AI capability as if it is a single scale. Smarter or dumber. Better or worse. Benchmark scores reinforce this - one number, one ranking. But the problems we face at work are hard in very different ways, and different AI models are built for different kinds of difficulty.
Jones breaks it down into categories that I think are immediately useful:
Reasoning problems - where the inputs are well-defined and the challenge is sustained logical deduction across many variables. Multi-jurisdiction tax optimization. Complex financial modeling. Novel regulatory analysis. These are problems where raw thinking depth matters most. Google’s Gemini 3.1 Pro, optimized for pure reasoning, excels here.
Effort problems - not intellectually difficult, but massive in scope. Auditing thousands of contracts. Migrating a legacy codebase. Reviewing a quarter’s worth of customer interactions for patterns. The thinking per step is straightforward. The challenge is sustained thoroughness across a huge surface area. This is where agentic models like Claude shine - tools that can work autonomously for hours, coordinating across files and systems.
Coordination problems - getting multiple teams aligned, routing work across dependencies, managing information flow. These require models that understand organizational context, not just technical content.
Ambiguity problems - where the hard part is not computing an answer but figuring out what the question actually is. The customer says they want better reporting, but what they actually want is for their boss to stop questioning their numbers. Strategy decisions where three plausible interpretations of the data lead to three different roadmaps. No model solves this. This is product sense, strategic intuition, leadership judgment.
Emotional intelligence problems - delivering difficult feedback, reading a room, navigating a negotiation where the stated concern is not the real concern. AI does not attempt this with any reliability today.
The point is not to memorize a taxonomy. The point is that when someone asks “which AI should I use?” - the honest answer depends on which type of problem they are solving. And most people have not done that decomposition.
How I build AI products
This is also exactly how I approach building AI products myself. When I built Castifai, I did not start by choosing a model. I started by defining the problem: turn video and text content into visual infographics where the text is readable and professional.
Then I experimented. I tested different models. I evaluated output quality against my specific requirements. I considered cost - $0.15 per image means unit economics matter from day one. I considered speed and reliability. I built fallback chains when my primary model proved unreliable.
And I keep iterating. When a new model launches, I do not ask “is it better?” I ask “is it better for my specific problem?” Sometimes the answer is yes, sometimes it is no, and sometimes it is “better for typographic layouts but worse for comic-style visuals.”
That granularity matters. It is the difference between chasing every model announcement and building something that actually works.
The routing skill
Jones makes a point that I think is underappreciated: model routing is becoming its own skill set.
The gap between “I use ChatGPT for everything” and “I route financial modeling to Gemini on high thinking, coding tasks to Claude Code, quick research to Gemini Flash, and deep document analysis to Opus” - that gap is real and it is growing every month.
This is not just for developers. A marketing team that uses one model for everything is leaving value on the table. A legal team, a finance team, a product team - each has a different mix of reasoning, effort, coordination, and ambiguity problems. The teams that learn to route will outperform the ones that do not.
And it starts with the same question I asked those Motorola executives twenty years ago: What problem are you actually trying to solve?
Your action step
This week, take your three most time-consuming work tasks and classify them:
Is the hard part reasoning - sustained logical deduction across many variables?
Is the hard part effort - massive scope, straightforward steps?
Is the hard part coordination - getting people and information aligned?
Is the hard part ambiguity - figuring out what the real question is?
Is the hard part judgment or emotional intelligence - something no model handles today?
Once you see the breakdown, you will know where AI can help, which type of AI fits each task, and where your human skills remain the bottleneck. That clarity is worth more than any benchmark score.
Watch to Nate Jones’ full video on this here:
#3 - AI Tool Spotlight: Shape of AI
OpenRouter: One API, every model, and why that matters more than you think
In Section 2, I argued that “which AI should I use?” is the wrong question. The right question is “which AI for which problem?” But that creates a practical challenge. If different models are better for different tasks, how do you actually access and switch between them without managing separate accounts, separate APIs, separate billing, and separate integrations for each one?
That is the problem OpenRouter solves. And it is the tool I have been using across several of my AI products to make model routing practical.
What OpenRouter does
OpenRouter is a unified API gateway. You connect to one API endpoint, and through it you can access hundreds of AI models - Claude, GPT, Gemini, Llama, Mistral, DeepSeek, and many more. One integration. One API key. One billing account.
When I build an AI-powered feature, I do not hard-code it to a single model. I route through OpenRouter, which means I can switch models, test alternatives, set up fallbacks, and compare performance - all without changing my application code.
For anyone building AI into products or internal tools, this is a significant shift. It means your architecture is not locked to one provider. It means you can experiment freely. And it means that when a new model launches - which happens every few weeks - you can test it against your actual use cases immediately.
How I use it
I have been integrating OpenRouter into several apps, and the pattern is consistent.
Model selection by task. Different features in the same product can use different models. A feature that needs strong reasoning might route to Gemini 3.1 Pro. A feature that needs reliable tool use and sustained work might route to Claude. A simple classification or summarization task might route to a smaller, cheaper model. OpenRouter makes this trivial to implement — it is a parameter change, not an architecture change.
Fallback chains. In Issue #19, I described building a fallback system for image generation in Castifai: Vertex AI as primary, Replicate as backup, basic generation as last resort. OpenRouter provides similar fallback logic for language models out of the box. If your primary model is down or rate-limited, the request can automatically route to an alternative. The user never hits a dead end.
Cost optimization. OpenRouter shows you the pricing for every model side by side. When you can see that one model costs seven times more than another for comparable quality on your specific task, the decision becomes obvious. Not every task needs a frontier model. Some tasks need the cheapest model that clears your quality bar. OpenRouter gives you the visibility to make that call.
Rapid experimentation. When Google shipped Gemini 3.1 Pro, I could test it against my existing prompts within minutes. No new account, no new SDK, no new billing setup. Just change the model parameter, run the same prompts, compare the results. That speed of experimentation is exactly what the “problem first” approach from Section 2 requires — you need to be able to test quickly whether a new model actually performs better for your specific use case.
How this connects to the bigger picture
In Section 1 of this issue, Claude reflected on all the leadership principles we have covered and noted that the principles form a system of tensions, not a checklist. The same is true for AI models. There is no single best model. There is a landscape of specialized capabilities that requires matching.
In Section 2, I argued for starting with the problem and then choosing the tool. OpenRouter is what makes that philosophy operational at scale. Without a unified routing layer, “use the right model for the right problem” is good advice that is painful to implement. With it, model routing becomes a natural part of how you build.
Your action step
If you are building anything with AI - a product, an internal tool, an automated workflow - ask yourself: am I locked to one model? If that model’s pricing doubles, or a better alternative launches next month, how quickly can I switch?
If the answer is “it would take weeks of engineering,” consider whether a routing layer like OpenRouter belongs in your architecture. The flexibility will pay for itself the first time you need to change.
Watch Alex Atallah (OpenRouter founder) talk about “The First LLM Aggregator” at AI Engineer World’s Fair. A fun origin story of how OpenRouter went from a Chrome extension experiment to a marketplace processing trillions of tokens weekly across 400+ models. OpenRouter recently raised $40M from a16z.
#4 - One New Term at a Time: Model routing
This Week’s Term: Model Routing - the practice of directing different tasks to different AI models based on the nature of the problem, the required capability, cost, speed, and quality requirements.
Six months ago, most people used one AI model for everything. You had your ChatGPT account or your Claude subscription, and every question, every task, every use case went to the same place. That made sense when the models were broadly similar and the differences were subtle.
That era is ending.
Why it matters now
The model landscape has differentiated sharply. Different models are now optimized for fundamentally different problem types. Google built Gemini for pure reasoning depth. Anthropic built Claude for sustained agentic work - tool use, multi-step tasks, long autonomous sessions. OpenAI built Codex for specialized coding pipelines.
The gap between using one model for everything and routing intelligently is widening every month. In practical terms, model routing means asking: is this a reasoning problem, an effort problem, a coordination problem? Does it need frontier intelligence or would a smaller, faster, cheaper model clear my quality bar? This is even more important when using other modalities such as image and video generation.
For individuals, this is an emerging professional skill - knowing which model handles which task type best in your specific domain. For teams building AI products, model routing is an architectural decision. It makes it possible to route programmatically - having different features in the same product using different models, with fallback chains and cost optimization built in.
The business implication
Organizations that develop model routing capabilities - whether through individual skill-building or technical infrastructure - will get more value from their AI spend. They will avoid overpaying for simple tasks, undermatch complex ones, and adapt faster when the landscape shifts.
In the video below, Ethan Ferdosi, Senior Solutions Architect at AWS, presents practical strategies for implementing multi-LLM routing to optimize generative AI applications. Drawing on his experience supporting startups worldwide, Ethan explains why relying on a single language model often falls short as requirements evolve and user expectations change. Instead, organizations can benefit from orchestrating multiple models, each optimized for specific tasks such as summarization, reasoning, or domain-specific applications.
Think Big Newsletter is created by Think Big Leaders -