This is Part 2 of a two-part series. For the executive overview — why the framework matters and how to use it in strategic decision-making — see Your AI Is a Thinking Partner. You’re Using It as a Search Engine.
I manage sixty-plus concurrent projects through sustained human-AI collaboration. Multiple engineering teams, multiple products, multiple domains — software architecture, organizational design, product strategy, content operations. Each project has its own context, its own state, its own active decisions. I do this with a small team and AI agents that act as a distributed engineering force.
The infrastructure that makes this possible isn’t tooling. It’s a thinking methodology — five modes of reasoning that I apply to every non-trivial problem, whether it’s an architecture decision, an integration challenge, or a system design that needs to scale across dozens of projects simultaneously.
This is the practitioner’s guide. If you lead engineering teams and work with AI agents daily, this is how the framework operates at the level of real technical decisions.
Mode 1: First principles — What is the AI actually solving?
The most common failure mode in AI-assisted engineering isn’t wrong code. It’s solving the wrong problem competently.
I gave an AI agent a design document for a feature that required users to select two independent dimensions simultaneously — like choosing a row and column on a grid, where every combination is valid. The agent looked at the existing codebase, found a similar-looking sequential workflow, and built another sequential workflow.
The result compiled. Tests passed. The architecture was fundamentally wrong. The two dimensions were orthogonal — they should have appeared side by side, not in sequence. The AI had pattern-matched on code structure instead of understanding the design’s architectural model.
“What is the relationship between these components?” is a first-principles question. “What does the existing code for something similar look like?” is pattern-matching. They lead to different architectures.
Pattern-matching is the AI’s default mode. It’s also the default mode of most engineers under time pressure. First principles breaks the pattern by asking: what is this system for? What constraints does it actually need? Which of the constraints in the existing code are load-bearing, and which are accidents of history?
A simpler example: an AI stacking CSS hacks — negative margins, calc expressions, fixed pixel values — to fix a layout issue that required one line. The hero section was inside a container constrained for article text readability. The hero wasn’t article text. Remove the constraint. One question, one line, done. But only if you ask “what is this container for?” before you start adjusting its properties.
The discipline for technical leaders: Before any architecture or design review, ask the AI to identify every assumption in the current approach. Most of the time, the most important assumption is the one nobody questioned because it was inherited from a previous version of the system.
Mode 2: Systems thinking — What does this change cause?
Every technical decision propagates. The question isn’t whether there are second-order effects. There always are. The question is whether you’ve mapped them.
I maintain tiered context files for every active project — working memory, reference, and archive tiers that allow AI agents to operate effectively across long-running collaborations. For months, I used a single file per project. It worked until it didn’t.
The largest file crossed a thousand lines. Session history from months ago, team rosters unchanged in weeks, completed task checklists, architecture decisions, and buried somewhere in the middle, the three items I needed the AI to focus on today. Eighteen projects had files over 500 lines. Median: 178 and growing.
The system-level diagnosis: one file serving four functions with fundamentally different lifecycles. Current tasks change hourly. Team composition changes weekly. Architecture decisions change monthly. Historical records never change. Four functions competing for a single scarce resource — the AI’s context window. Every line of archived history displaced a line of working memory.
The four functions weren’t just different — they competed for a scarce resource. Every line of historical record displaced a line of working memory. The system had a built-in conflict that no single-file architecture could resolve.
This is a systems thinking problem because the degradation was invisible at the component level. Each file, individually, was fine. The context was accurate. The history was useful. But the interaction between the components — history competing with active work for attention — created a system-level failure that no amount of component-level optimization (trimming, summarizing, archiving) would fix.
The solution required structural separation. But that’s Mode 4. First, the system needed to be mapped. I wrote about the full technical architecture in The Tiered Context Architecture.
The discipline for technical leaders: Before proposing changes, map every component that interacts with the area you’re changing. For each, ask: “If I change X, what happens to Y?” The bugs that survive code review are almost always second-order effects that nobody traced.
Mode 3: Complexity thinking — Design for what you can’t predict
I regularly integrate contributions from multiple engineers into a single codebase — sometimes many contributions in a single day. Each modifying overlapping files, each built against a version that doesn’t include the others.
Merge A and B: clean. Merge C: clean. Merge A+B+C: conflicts that didn’t exist in any pairwise combination. A contribution that merges cleanly third might conflict fatally fifth, because the fourth changed assumptions the fifth depends on. The interaction space grows combinatorially, and the system adapts as you modify it — each merge changes the codebase that the next merge targets.
This is complexity, not complication. Dave Snowden’s Cynefin framework draws the distinction well: complicated systems have many parts but behave predictably — you can disassemble and reassemble them. Complex systems exhibit emergence — behavior that no individual component explains and that changes when the agents in the system adapt to each other.
You can’t plan your way through a complex integration. You can only create structures that make surprises visible quickly and respond to them faster than they compound.
I developed a dependency-aware ordering approach: analyze which files each contribution touches, identify overlapping modifications, sequence merges to minimize cascading conflicts. Not eliminate — minimize. Then verify after each merge that prior integrations survived the new one. Invest in detection speed, not prediction accuracy.
The methodology is documented in synthesis merging and multi-contributor workflows.
The discipline for technical leaders: Replace comprehensive upfront plans with incremental rollouts and fast feedback. Define “working” and “not working” metrics before you start. Design your response to surprises before the surprises arrive. The goal isn’t to get it right the first time — it’s to learn fast enough that course corrections are cheap.
Mode 4: Analogical thinking — Import solutions across domain boundaries
This is the mode that produces the most surprising results. And it’s the one most engineers skip entirely, because engineering culture rewards depth over breadth.
The context management problem from Mode 2 — four functions competing for a scarce resource — had a solution. But it didn’t come from information architecture, knowledge management, or any of the fields you’d expect. It came from CPU design.
Every modern processor has an L1 cache (tiny, fast, constant churn), L2 cache (larger, slower, less volatile), and main memory (large, slow, stable). The reason: different data has different access patterns, and treating all data identically wastes resources.
My context files had the same structural problem. Active tasks were hot data. Team and architecture facts were warm data. Session history was cold data. All stored in one tier, all accessed identically, all competing for the same resource. The solution was the same: separate by access pattern, with explicit rules for what moves between tiers and when.
I didn’t set out to apply cache theory to AI context management. I recognized the structural parallel while thinking about why single-file architectures couldn’t work regardless of how well they were curated. The analogy held under scrutiny — access patterns mapped, lifecycle differences aligned, the resource-contention model explained the degradation. The architecture has been running for months. The growth problem hasn’t returned.
A second example: during integration work, I discovered that cherry-picking individual contributions could silently revert work from previous integrations. All tests passed. Type checker: zero errors. But a feature was quietly removed because the cherry-picked contribution predated it. The tests verified correctness. They couldn’t detect absence.
The structural analogy came from database engineering: referential integrity. In a database, you verify not just that a write succeeded, but that it didn’t corrupt prior transactions. Applied to code integration: after each merge, verify that previously integrated work still exists and is still connected. This check is routine in database engineering. It had no equivalent in the integration workflow until the analogy surfaced it.
Specialists go deep. Generalists go wide. Synthesists go diagonal — they find structural parallels between fields that have never talked to each other, and they import solutions that nobody in the original domain would have reached.
The engineer who reads cognitive science, operations research, and labor history alongside systems design has a strictly larger solution space. Not because breadth is inherently virtuous, but because more structural patterns means more potential matches, and more matches means better solutions.
The discipline for technical leaders: When you’re stuck, describe your problem’s structure without domain-specific language. Just relationships: “Sequential operations where each must preserve the integrity of all previous operations.” Then ask where that exact structure exists in other fields. Validate the analogy before committing: do the structural similarities hold, or did you only match on surface?
Mode 5: Design thinking — Build the operating system, not just the architecture
This is where the framework goes from analytical tool to daily practice. The first four modes help you think through problems. Design thinking turns that thinking into a system you can actually live in.
The tiered context architecture from Modes 2 and 4 gave me the right separation. But architecture isn’t operations. I still had to answer: what does a practitioner’s day actually look like when they’re managing sixty projects through AI collaboration?
The answer is a complete operating system built around information entropy reduction. Every day, a gap opens between what happened (in Slack channels, PR queues, staging environments, team conversations) and what I know. The gap compounds — an unanswered thread becomes a blocked engineer, becomes a missed deadline, becomes a trust problem. The operating system exists to close that gap before it compounds.
The daily ritual
My day starts with a dependency-ordered checklist — not a loose to-do list, but a sequenced pipeline where each step feeds the next:
Context optimization comes first. Archive completed items and stale session summaries from CONTEXT.md to the session archive. Move newly-stable facts to REFERENCE.md. Verify the archived content exists in its destination before removing it from working memory. Two-phase commit — never delete before confirming the write. This keeps every project’s working memory under 150 lines, which is the budget that keeps AI agents focused rather than diluted.
Multi-channel sync comes second, because you can’t plan a day on stale information. Git fetch across all active repos. PR queue scan. Slack transcript sync across every tracked channel, reading every thread in full — not summaries, not first messages, the full threads, because a thread showing “2 replies” might contain a complete resolution that changes today’s priorities. Record timestamps for every significant message so threads can be re-read later for new replies.
Cross-referenced catch-up comes third. An item that looks open in yesterday’s action plan may have been resolved overnight in Slack. A task marked incomplete may have been superseded by a PR merge. Cross-reference every potential action item against Slack, CONTEXT.md, and the PR queue before flagging it as open. The source of truth is the current state of the actual systems, not yesterday’s notes.
Daily action plan creation comes fourth. This isn’t a morning journal. It’s a structured operational document: prioritized tasks with checkboxes, draft messages with thread locators (channel, timestamp, last unanswered reply), a waiting-on-others table, and a running “things to know” section. The plan is a living document updated throughout the day — completed items get timestamps, new items get added, priorities get adjusted. It creates a permanent archive of what actually happened, not what was planned.
Morning communications come last, because now every message is grounded in current reality. Status updates reference actual system state. Replies to overnight threads account for what’s already been resolved. Technical claims are verified against code, not transcripts.
The lessons pipeline
Every day produces raw material for two things: better future sessions and better methodology.
Reusable lessons — patterns, mistakes, solutions that apply beyond the current project — get documented in a shared lessons archive. These aren’t retrospective exercises. They’re captured in real time, as they happen, because the specificity fades within hours. A lesson documented at the moment of discovery includes the exact context, the exact failure mode, and the exact fix. A lesson documented at end of day is already a summary of a summary.
The lessons compound. The synthesis thinking framework itself is a product of this pipeline — patterns I noticed across dozens of projects, extracted, tested against new problems, refined, and eventually encoded as methodology.
Why this is design thinking
The architecture (tiered context, cache hierarchy analogy) is Modes 2 and 4. The operating system — the daily ritual, the action plan format, the lessons pipeline, the information entropy discipline — is Mode 5.
For any irreversible action with external impact, preparation and execution are separate decisions made by separate parties. The agent prepares. The human confirms.
That principle came from a deployment where an AI agent completed every prerequisite and then deployed to production without asking — it interpreted readiness as authorization. The technical work was flawless. The interaction design was wrong for an irreversible action. The principle now governs every part of the operating system: context moves between tiers only when explicitly confirmed. Action plans suggest priorities; the human sequences them. Draft messages are prepared with thread locators; the human sends them.
Design thinking at this level isn’t about user empathy in the abstract. It’s about building systems where the human maintains judgment at every decision point that matters, while the AI handles the throughput that makes sixty concurrent projects possible.
The framework as infrastructure
The five modes build on each other:
- First principles finds what’s true, stripping inherited assumptions
- Systems thinking maps how truths connect and where they compete
- Complexity thinking identifies emergence and designs for unpredictability
- Analogical thinking imports solutions from other domains with matching structure
- Design thinking builds an operating system that real practitioners can live in
You won’t need all five for every problem. A debugging session needs first principles and systems thinking. An architecture review benefits from all five. The skill documentation maps situation types to recommended depth.
Installing the framework
The synthesis thinking framework is available as a free, open-source Agent Skill — install it into any agent that supports the Agent Skills standard and it runs as background reasoning infrastructure, shaping how the agent approaches every non-trivial problem automatically.
It’s part of a collection of 22 open-source synthesis skills covering code review, context management, multi-contributor integration, and more. All methodology skills are released under CC0.
The synthesis thinking framework is the foundational methodology behind synthesis engineering. For the executive overview, see Your AI Is a Thinking Partner. For the project management approach, see AI-native project management.
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 coined the terms “synthesis engineering” and “synthesis coding” to describe the systematic integration of human expertise with AI capabilities in professional software development. He writes code daily and contributes to open-source projects including synthesis skills. Connect with him on LinkedIn or GitHub, or read more at rajiv.com.