You have access to a thinking partner that has read more than any person alive, never gets tired, and can apply rigorous reasoning to any problem you hand it. Most people use it to draft emails and summarize documents.
That’s like buying an Iron Man suit and using it to carry groceries.
I’ve spent the past year directing AI agents through sixty-plus projects spanning product strategy, executive communication, organizational design, software architecture, and investment analysis. The difference between mediocre AI output and genuinely powerful collaboration comes down to one thing: most people never tell the AI which kind of thinking a problem requires. They describe the situation and accept the first reasonable answer.
The highest-leverage skill in AI collaboration isn’t better prompting. It’s knowing which mode of reasoning to apply before you prompt at all.
Here is the framework I use. Five thinking modes, applied in sequence. I’ve encoded it as an open-source tool that loads directly into AI agents — but the framework works just as well on a whiteboard, in a meeting, or in your head. The tool is optional. The thinking is not.
Mode 1: First principles — What is actually true here?
Every bad decision I’ve seen at the executive level starts with an assumption nobody questioned.
Consider a common scenario: a company is losing market share, so the leadership team commissions a competitive analysis. The analysis compares features, pricing, distribution channels. Recommendations follow: match competitor pricing, add three features, expand into two new channels. The team executes.
Six months later, market share is still declining. The analysis was thorough. The execution was competent. The assumption was wrong.
The assumption was that customers chose competitors because of features and price. First principles asks: what do we actually know about why customers are leaving? Not what does the industry report say. Not what does conventional wisdom suggest. What do exit interviews, cancellation data, and customer behavior actually tell us?
Sometimes the answer is: customers aren’t choosing competitors at all. They’re choosing not to buy the category. The whole competitive analysis was answering the wrong question.
First principles strips away borrowed assumptions and rebuilds from verified facts. It’s the discipline of asking “what is actually true?” before asking “what should we do?” In my experience, it’s the single most valuable thinking mode — and the one that AI agents, left to their defaults, almost never apply. They pattern-match on your question and produce the conventional answer. First principles forces them to verify the foundation before building on it.
Try this in your next strategy session: Before discussing solutions, spend fifteen minutes identifying every assumption embedded in the problem statement. Write them on a board. Star the ones nobody has actually verified. You’ll find the most important ones are usually the ones nobody thought to question.
Mode 2: Systems thinking — What does this cause?
Once you know what’s actually true, map how the parts connect. Every decision propagates. The question isn’t “what does this do?” but “what does this cause?”
In 1956, John McCarthy chose the name “artificial intelligence” for a new research proposal. Other framings were available — “automata studies,” “complex information processing,” “machine learning.” McCarthy went with the most provocative one. His choice shaped seventy years of public reaction: fear of sentient machines, science fiction narratives, existential risk policy debates, boom-and-bust investor expectations. A more technical name would have activated none of those feedback loops. Same research. Entirely different trajectory.
Names are architecture decisions. Every stakeholder hears something different. When a company announces it’s “implementing AI to optimize operations,” executives hear efficiency. Workers hear layoffs. Investors hear growth. Regulators hear risk. Customers hear “will my data be safe?” One announcement, five interpretations, five feedback loops — all running simultaneously.
Systems thinking maps every stakeholder affected by a decision, including the ones nobody mentioned in the meeting.
Tesla calls its driver-assistance system “Full Self-Driving.” Waymo calls its autonomous system “Waymo Driver.” Tesla’s requires a human behind the wheel; Waymo’s operates without one. Yet Tesla’s name implies more autonomy than it delivers, while Waymo’s implies less. The names produce measurably different driver behaviors, regulatory scrutiny, and public trust — independent of what the systems actually do.
Try this before your next major announcement: Map every stakeholder group that will hear it. For each group, write down what they’ll hear — not what you intend to communicate, but what they’ll actually interpret. If any group’s interpretation works against your goal, change the message before you send it.
Mode 3: Complexity thinking — What can’t we predict?
Some problems resist planning. The hallmark of a complex system is emergence — behavior that no individual component explains and that changes when the agents in the system adapt to each other.
Mergers fail at a stunning rate. Not because the financial models are wrong — the spreadsheets are usually impeccable. They fail because two organizational cultures are complex adaptive systems. Each has its own norms, incentive structures, and informal power networks. Combining them doesn’t produce a blend. It produces emergence: new behaviors, new alliances, new resistance patterns that neither culture exhibited before the merger.
The executive who treats a merger as a complicated logistics problem (predictable if you plan thoroughly enough) will be blindsided. The one who treats it as a complex adaptive system (inherently unpredictable, requiring fast feedback loops and adaptive strategy) will navigate it.
The distinction matters: Complicated systems have many parts but behave predictably. Disassemble a supply chain and you can reassemble it. Complex systems exhibit emergence. You cannot disassemble and reassemble a culture.
Complexity thinking says: stop trying to design the perfect plan. Instead, build structures that make surprises visible quickly. Run pilots before rollouts. Create rapid feedback loops. Accept that your first plan will need revision — and design the revision process before you need it.
Try this with your next organizational change: Instead of a comprehensive rollout plan, design a 30-day pilot with specific metrics. Define in advance what “working” and “not working” look like. Plan three possible adjustments before you start. The goal isn’t to get it right the first time. It’s to learn fast and adjust faster.
Mode 4: Analogical thinking — Where has this been solved before?
This is the mode that produces the most surprising results. And it’s the one most leaders skip entirely.
After you understand what’s true, how the parts connect, and what will emerge unpredictably, ask: what solved problems in other fields share the same structure as this one?
Consider a hospital struggling with emergency room wait times. The typical approach: study other hospitals, benchmark against healthcare standards, hire healthcare operations consultants. Improvements are marginal because everyone is looking in the same places.
The structural parallel that opens new ground is airport security checkpoints. Both are flow-management problems with variable arrival rates, sequential processing stages, and high cost of failure. The TSA PreCheck insight — segment the queue by preparation level — translates directly into triage redesign that healthcare benchmarking alone wouldn’t surface. (This isn’t hypothetical — queuing theory from operations research has been applied to both domains with measurable results.)
Specialists go deep. Generalists go wide. The leaders who create real breakthroughs go diagonal — they find structural parallels between fields that have never talked to each other.
I’ve watched this pattern repeatedly in my own work. A problem in AI context management — solved by importing CPU cache architecture. A code integration challenge — solved by applying database transaction theory. In each case, the solution wasn’t in the problem’s home domain. It was hiding in a field nobody thought to look in.
The principle: two problems share structure when they have the same relationships between components, even if the components look nothing alike. An emergency room and an airport checkpoint share structure. A CPU cache and an information management system share structure. A labor negotiation and a product design decision share structure.
The engineer who reads labor history, the hospital administrator who studies logistics, the CEO who watches how standup comedians structure a set — they have an unfair advantage. Not because they’re smarter. Because they have more shapes to match against.
Try this with your current toughest problem: Describe its structure without any domain-specific language. Just the relationships: “Variable inputs arrive unpredictably. They require sequential processing. Errors compound. Throughput matters.” Then ask: where else does that exact structure exist? Start there.
Mode 5: Design thinking — Who is this actually for?
Four modes of analysis mean nothing if the solution doesn’t work for the humans who have to live with it.
I learned this through a system migration that was technically flawless. Every API mapped. Data integrity verified. Performance benchmarks exceeded. On paper, perfect. In practice, the team using the old system had years of muscle memory around its quirks. The new system was objectively better and required them to relearn workflows they performed dozens of times a day. Adoption was slow. Workarounds proliferated. The team quietly rebuilt the old system’s quirks inside the new one.
The architecture was right. The design was wrong. It optimized for the system instead of the people.
The best solution for the wrong moment is the wrong solution. Design thinking asks not “what’s correct?” but “what does the person living through this actually need?”
Design thinking asks a different question than the other four modes: not “what’s the right answer?” but “what does the person affected by this decision actually need?” A restructuring that’s optimal on the org chart but devastating to the people living through it will fail. A strategy that’s brilliant in the boardroom but incomprehensible to the team executing it will fail. A technology that’s superior in every measurable way but requires people to abandon their existing mental models will be resisted.
Try this before your next big decision: After the analysis is complete but before you execute, ask one question: “If I were the person most affected by this decision — not the person making it — what would I need right now?” The answer is usually not what the analysis produced.
The framework in practice
The five modes build on each other:
- First principles strips assumptions to find what’s actually true
- Systems thinking maps how those truths connect and propagate
- Complexity thinking identifies what will emerge unpredictably
- Analogical thinking finds solutions from other fields with the same structure
- Design thinking ensures the solution works for real humans
You don’t always need all five. A straightforward operational decision might need only first principles and systems thinking. A genuinely novel strategic challenge benefits from all five. The skill is matching the depth of thinking to the stakes of the decision.
Using it with AI
Here’s where this becomes practical.
When you sit down with an AI agent — Claude, ChatGPT, Gemini, whatever you use — and hand it a problem, you’re getting one mode of thinking. Usually it’s pattern-matching: “problems like this are usually solved like that.” That’s useful for routine questions. It’s insufficient for anything that matters.
Direct the AI through the modes explicitly:
- “Before suggesting solutions, what assumptions are embedded in how I described this problem?”
- “Map every stakeholder affected by this decision, including ones I haven’t mentioned.”
- “What about this situation is genuinely unpredictable? Where should I expect emergence?”
- “What problems in completely different fields have the same structure as this one?”
- “If you were the person most affected by this decision, what would you need?”
Each prompt shifts the AI into a different reasoning mode. The output is qualitatively different from “here’s my problem, what should I do?”
I’ve encoded the full framework as a free, open-source Agent Skill that loads directly into AI agents supporting the Agent Skills standard — including Claude Code, Cursor, GitHub Copilot, and 40+ others. When installed, it runs as background reasoning infrastructure, shaping how the agent approaches every non-trivial problem automatically. No explicit prompting required.
It’s part of a collection of 22 open-source synthesis skills I’ve published. But the software is optional. The five questions above work in any AI conversation, any meeting, any strategic discussion. Print them on a card if that’s more your style.
The framework is the thinking. The tool just makes it automatic.
This is Part 1 of a two-part series. For the technical practitioner’s guide — with detailed methodology, real implementation examples, and installation instructions — see The Synthesis Thinking Framework: A Practitioner’s Guide.
The synthesis thinking framework is the foundational methodology behind synthesis engineering, a professional discipline for human-AI collaboration. For related practices, see AI-native project management and synthesis coding.
Rajiv Pant is President of Flatiron Software and Snapshot AI, where he leads organizational growth and AI innovation. He is former Chief Product & Technology Officer at The Wall Street Journal, The New York Times, and Hearst Magazines. Earlier in his career, he headed technology for Condé Nast’s brands including Reddit. Rajiv was recognized by the World Economic Forum as a Young Global Leader in 2014. He coined the terms “synthesis engineering” and “synthesis coding” to describe the systematic integration of human expertise with AI capabilities in professional work. Connect with him on LinkedIn or read more at rajiv.com.