How to Think About AI Architecture
The framework debates are loud. The question underneath them is quieter: what should guide the choice in the first place?
You're evaluating how to build with AI. Or evaluating what someone is proposing to build for you.
You're hearing terms. Agentic workflows. Multi-agent orchestration. Autonomous reasoning. Retrieval-augmented generation. The vocabulary is dense and it shifts constantly.
Underneath the vocabulary is a simpler question: what kind of architecture does my problem actually need?
That question has an answer. And you probably already have the mental model to find it.
The Mental Model That Keeps Failing
A particular vision of AI architecture has captured attention: AI as orchestrator.
In this model, you give an LLM a goal and let it figure out how to get there. It reasons about the next step. It decides which tool to call. It delegates to sub-agents. It loops until it's satisfied with the result.
This is the "agentic" vision. Manager agents that coordinate worker agents. Role-playing personas that debate and delegate. Reasoning loops that re-evaluate "should I continue?" at each step.
Frameworks like LangChain's original agent abstraction, AutoGen, and CrewAI were built around this model. They're impressive in demos. For open-ended research tasks or creative exploration, they can genuinely work.
But most business problems aren't open-ended. Customer support has known steps. Invoice processing has known steps. Lead qualification has known steps. The workflow exists before the AI arrives.
When you apply the orchestrator model to defined workflows, something wasteful happens. The AI spends tokens reasoning about what to do next when you already know. It's discovering a workflow you could have specified.
The Mental Model That Works
Here's a different starting point: AI as transformation step.
You know the data engineering pattern. Extract, transform, load. Data comes in, gets processed, goes out. Each step has clear inputs and outputs.
When you add AI to a business workflow, it fits the same pattern. The AI receives input. It classifies, generates, extracts, or decides. It returns output. Then the workflow continues.
The AI is a step in a pipeline you control. You define the control flow. You specify what happens when. The AI executes within that structure.
This isn't limiting. Transformation steps can be very sophisticated. Complex prompts. Multi-turn interactions. Retrieval augmentation. Fine-tuned models. The sophistication lives inside the step, where it belongs.
What changes: you maintain visibility. You can trace what happened. You can test each step. You can debug when something breaks. You can explain the system to someone else.
A Learning Story
This isn't theoretical. Teams learn this through experience.
LangChain was the dominant framework for a reason. It promised to handle chains, agents, memory, and tools in one package. Early adopters used it because it was there and it worked for prototypes.
Then production happened. Nested chains became hard to debug. Agent loops did unexpected things. Teams found themselves reading framework internals to understand their own systems. The abstraction that helped early became the thing they fought later.
LangGraph emerged from the same ecosystem with a different philosophy. Instead of magical orchestration, it offers graph primitives with explicit state. You define nodes and edges. You see the graph. State is a typed object you control. Cycles are intentional design choices, visible in the structure.
Teams that moved from LangChain agents to LangGraph often describe relief. They can see what's happening again. The sophistication is still there. The opacity is gone.
The lesson: this wasn't about abandoning frameworks. It was about finding tools that aligned with principles that mattered. Transparency. Explicit control. Typed state. The framework changed. The principles didn't.
The Anti-Patterns
Certain architectural patterns cause repeated problems. Worth naming them.
An LLM decides which sub-agent to call next. Unpredictable flow, hard to debug, unnecessary for defined workflows. If you know the workflow, just define it.
Multiple "agents" with personas that debate or delegate. Adds latency and cost. Obscures what could be simple sequential logic.
The framework manages state you can't see or override. When something goes wrong, you can't inspect the state that caused it.
A library that tries to solve every possible AI problem. Bloat you don't need. Hidden complexity you don't understand.
The LLM re-evaluates "should I continue?" on every iteration when the answer is always "yes, do the next step." Wastes tokens. Adds non-determinism.
These patterns aren't always wrong. Open-ended research tasks may need them. But when they appear in defined business workflows, they usually signal a mismatch between tool and problem.
The Evaluation Criteria
When assessing any framework, current or future, these questions cut through the noise.
Can you trace exactly what happens from input to output without reading framework source code?
Are input and output contracts enforced, or just documented? Does the system catch unexpected returns explicitly?
Do you define the workflow, or does the framework decide? Can you look at the code and see what will happen?
When the abstraction doesn't fit, can you drop to plain code? Or are you locked in?
Could you rebuild the core logic in a weekend if the framework disappeared?
These criteria work for LangGraph. They work for PydanticAI. They'll work for whatever emerges next year. They're framework-agnostic because they're about properties you need, not implementations that provide them.
What Actually Varies
Different workflows have different requirements. The architecture should match.
Tier 1: Linear and Ephemeral. A request comes in. You process it through known steps. You return a response. No state persists between requests. Plain Python with a web framework handles this. No AI-specific framework needed.
Tier 2: Background Processing with Durability. Jobs that run asynchronously. Work that survives a restart. Higher volume that needs queuing. Celery with Redis handles this. The framework is about jobs and queues, not AI.
Tier 3: Stateful with Cycles and Human Checkpoints. Workflows that pause and resume. Human approval at multiple points. Loops where output determines whether to continue. State that persists across days. LangGraph handles this. The graph primitives match the problem.
The point: match architecture to what the workflow actually requires. Tier 1 problems don't need Tier 3 tools. Tier 3 problems genuinely need the sophistication. The mistake is reaching for complexity before you've confirmed you need it.
Why PydanticAI Points Somewhere
PydanticAI and Atomic Agents have gotten attention recently. Worth understanding why.
PydanticAI comes from the Pydantic team. Everything revolves around typed data models. You define exactly what input and output you expect. The library includes self-correction: if the LLM returns something that doesn't fit the schema, it can re-prompt automatically. The concept of "agent" exists but stays lean. Just enough structure to unify the prompt, dependencies, and tools.
Atomic Agents takes a similar philosophy. Input-process-output as explicit pattern. Each piece does one job. You copy the tools you need rather than installing a kitchen-sink library.
Neither framework tries to solve every problem. Neither hides what's happening. Both enforce typed contracts. Both let you own the code.
This matters because it shows what developers are gravitating toward after experiencing the alternatives. Less magic. More visibility. Typed I/O as foundation. The principles are winning.
The Principles That Endure
LangGraph is the current best choice for stateful workflows. That will probably change. Something better will emerge. Or LangGraph will evolve into something different. Or the whole landscape will shift.
What shouldn't change: how you evaluate.
Transparency over magic. Typed interfaces over loose contracts. Explicit control over hidden orchestration. Minimal abstraction over comprehensive frameworks. Right tool for actual complexity over impressive architecture for its own sake.
These principles let you assess the next framework that appears. They let you recognize better fit when it emerges. They keep you from coupling to something that won't age well.
We've been calling this "principled practitioner" thinking. You use frameworks. You're not loyal to them. When better options appear, you can evaluate them against criteria you already have. The framework is a tool. The principles are yours.
The Questions to Ask
Before frameworks, ask about your workflow.
Understanding the workflow comes first. Architecture follows.
The Clarity Underneath
The debates about frameworks will continue. New tools will emerge. Old favorites will fade. The vocabulary will shift.
What won't shift: most business workflows have defined steps. AI fits as a transformation within those steps. You should be able to see what's happening. Typed contracts prevent surprises. Match your tools to the actual complexity of your problem.
These aren't opinions about which framework is best. They're observations about what makes AI systems work in production, maintained over time, by teams who need to understand what they've built.
Start with your workflow. Understand what it actually requires. Then choose tools that match, using criteria that will still make sense when today's frameworks are yesterday's legacy.
The frameworks are temporary. The thinking endures.