Choosing the build stack for enterprise AI
Your team already has the patterns down. You know what an agent is, why prompt chaining beats one mega-prompt, when to add tools, and how multiple agents divide labor. The practical question is what you actually build it with.
In 2026 the answer is no longer "pick LangChain." The build stack now comes in layers, and picking the wrong layer is how a six-week prototype turns into a nine-month rewrite. Frameworks define how your agent thinks. Platforms decide where it runs. A newer class of CLI agents lives in your terminal and writes the code itself. Below is a map of those layers, with what each tool does and when it pays to reach for it.
The three layers of the agentic stack
Agent tools are not one shelf. They sit at three altitudes, each handling a different job.
- Orchestration frameworks govern how your agent reasons and coordinates. This is the control-flow layer, where the model can be a graph, a crew, a conversation, or a protocol. LangGraph, CrewAI, AutoGen, and Google's ADK all live here.
- Agent platforms and environments govern where your agent runs and who controls it, covering deployment and identity alongside data connections and observability. Google AgentSpace and Vertex AI Agent Builder live here.
- CLI and coding agents build the agent in the first place. These are terminal-native agents, like Claude Code and its peers, that read your repo and write the orchestration code itself.
Most teams touch all three. Conflating them is the mistake, because a framework is not a platform and a coding agent is not a production runtime. Once you have the layer right, the tool choice inside it gets much easier.
Orchestration frameworks
Frameworks set the shape of your agent's reasoning. The four that matter each encode a different mental model, and that model, not the feature list, is what you are picking.
LangChain and LangGraph: graph-based control
What it is: LangChain is the broad toolkit of components, from model wrappers and prompt templates to retrievers and tool integrations. LangGraph is its stateful younger sibling, a low-level framework that models an agent as a graph of nodes (steps) and edges (transitions), with shared state passed between them. Cycles, branches, and human-in-the-loop checkpoints are all first-class.
When to reach for it: when control flow is the hard part, meaning long-running workflows that loop, retry, pause for approval, and resume. If your agent has to revisit a step or wait on a human before continuing, the graph model pays off. The cost is verbosity, since you wire the state explicitly, which is more code than a one-liner crew.
CrewAI: role and crew-based orchestration
What it is: CrewAI frames a system as a crew of role-playing agents (a researcher, a writer, a reviewer), each with a goal and a set of tools, working tasks toward a shared objective. It is a lean, standalone framework that, in recent versions, carries no LangChain dependency, so it is quick to stand up and easy to reason about.
When to reach for it: when the work maps cleanly onto human-style roles and you want a multi-agent system running quickly. CrewAI gets you from idea to a collaborating team of agents faster than the alternatives, trading some of LangGraph's fine-grained control for that speed. It fits content pipelines, research crews, and well-defined business workflows, and fits poorly when you need surgical control over every transition.
Microsoft AutoGen: conversation-based orchestration
What it is: AutoGen models multi-agent work as a conversation. Agents, including a human proxy, exchange messages in a group chat, and coordination comes out of the dialogue rather than a predefined graph. It introduced the conversational multi-agent pattern and remains the clearest version of it.
When to reach for it: when the problem is open-ended and you want agents to negotiate a solution through back-and-forth, such as research exploration, code-and-critique loops, or brainstorming with a human in the room. The flexibility is the point, and the same flexibility makes the behavior less deterministic than an explicit graph, so weigh it against how predictable you need the output to be.
Google ADK: protocol-first orchestration
What it is: the Agent Development Kit, or ADK, is Google's code-first, open-source framework for building and deploying agents. It bets on interoperability and is built around open protocols, with native support for the Model Context Protocol (MCP) to connect tools and agent-to-agent communication (A2A) to let separate agents message each other. It also ships clean workflow primitives (sequential, parallel, and loop agents), so common control flow comes built in.
When to reach for it: when you are building for a heterogeneous, multi-vendor world and don't want your agents locked to one stack. If you expect to expose your agent to others, or to consume third-party agents and tools, ADK's protocol-first posture fits best. It also puts you closest to Google's managed runtime when you are ready to deploy.
Agent platforms and environments
A framework gives you an agent. A platform gives you somewhere to run it, with identity and governance plus data access and monitoring, the parts that decide whether a pilot survives a security review.
Google AgentSpace
What it is: AgentSpace is Google's enterprise environment for rolling out and governing agents across an organization. Google rebranded the surrounding products in 2026, so AgentSpace and Vertex AI Agent Builder now sit under its Gemini Enterprise Agent Platform. The capability stays put even as the brand name moves: a managed home where employees use agents grounded in company data, with the access controls and audit trails a security team requires.
When to reach for it: when the bottleneck is not building one agent but rolling agents out safely to a workforce, with governance, permissions, and enterprise search across internal systems. This is an adoption-and-control layer, not a coding framework.
Vertex AI Agent Builder
What it is: Vertex AI Agent Builder is the build-and-deploy side of Google Cloud's agent platform. It pairs a managed runtime (Agent Engine) that handles deployment, scaling, session state, and memory with tooling that fits ADK naturally. It is where an ADK agent goes to live in production without you operating the infrastructure.
When to reach for it: when you've built an agent and need it deployed and scaled in production, observable the whole time, without standing up your own serving stack. Reach for the platform once the prototype works and "make it production-grade" becomes the job.
CLI and coding agents
The newest layer writes the other two. CLI agents are autonomous agents that live in your terminal, read your codebase, run commands, and edit files, the Level 1 and Level 2 agents pointed squarely at software development.
What it is: tools like Claude Code, and the broader class of terminal-native coding agents, work inside your repository. They plan a change, run tests, read errors, and iterate, running the full agentic loop against your code. More and more, this is how teams build the agents above. You describe the orchestration you want, and the CLI agent scaffolds the LangGraph nodes or CrewAI crew for you.
When to reach for it: for the building itself, such as scaffolding a new framework, refactoring an agent pipeline, writing tool integrations, or wiring up MCP servers. They speed up the developer rather than serve as a production runtime for end users. The orchestration frameworks define the agent you ship; the CLI agent helps you ship it faster.
Enterprise reality: the team that picks LangGraph for control, deploys on Vertex AI Agent Builder for governance, and uses a CLI agent like Claude Code to write the glue is usually one engineer moving across three layers in an afternoon, not three teams. The layers are converging because each one assumes the others exist.
Comparing the four frameworks
Past the marketing, the four orchestration frameworks differ on one axis: how they model coordination. Match the model to your problem and the rest follows.
| Framework | Coordination model | Reach for it when | |---|---|---| | LangGraph | Graph-based (nodes, edges, shared state) | Control flow is the hard part: loops, retries, approvals | | CrewAI | Role/crew-based (agents as collaborating roles) | The work maps to human-style roles and you want speed | | AutoGen | Conversation-based (agents chat to a solution) | The task is open-ended and benefits from negotiation | | Google ADK | Protocol-first (MCP and A2A built in) | You're building for a multi-vendor, interoperable world |
Three caveats come with that table.
- They are not mutually exclusive. An ADK agent can call a tool that a LangGraph agent exposes over A2A. Protocols exist so frameworks work together rather than compete.
- The platform layer is separate. You can govern any of these frameworks, and picking a deployment runtime is a different decision from picking a reasoning model.
- The names will shift. CLI agents move fastest, so treat any specific tool as a snapshot in time. The layers hold steady even when the products get renamed.
A minimal crew (abbreviated)
Here is the role-based model made concrete: a two-agent CrewAI crew where a researcher hands findings to a writer. It takes very little code to get a collaborating team running.
# Abbreviated: illustrative role-based crew, not production code
from crewai import Agent, Task, Crewresearcher = Agent(
role="Senior Researcher",
goal="Find the key facts on the assigned topic",
backstory="A meticulous analyst who cites sources.",
)
writer = Agent(
role="Technical Writer",
goal="Turn research notes into a clear brief",
backstory="An editor who values plain language.",
)
research = Task(description="Research {topic}", agent=researcher)
write = Task(description="Write a 1-page brief", agent=writer)
crew = Crew(agents=[researcher, writer], tasks=[research, write])
result = crew.kickoff(inputs={"topic": "agentic frameworks"})
The same job in LangGraph would be two nodes and an edge; in AutoGen, two agents in a group chat. The framework changes the shape of the code, while the underlying pattern of specialists working toward a shared goal stays the one the multi-agent systems pattern describes.
How to choose, quickly
You don't have to evaluate every tool. Three questions, answered in order, settle the stack.
- Where is the hard part of the reasoning? Looping control flow points to LangGraph, while human-style roles map to CrewAI, open-ended negotiation suits AutoGen, and cross-vendor interoperability is ADK's territory. Pick the framework whose model matches your problem.
- Where does it need to run, and who governs it? A weekend tool can run anywhere, whereas an agent that touches customer data and faces a security review wants a managed platform: Vertex AI Agent Builder to deploy it, AgentSpace to roll it out safely.
- What is writing the code? Whatever framework you pick, a CLI coding agent will help you scaffold and iterate faster than writing it by hand, which is a productivity choice separate from the first two.
Answer those three and you have your stack (reasoning model, runtime, and build tooling) without a multi-week bake-off.
Key takeaways
- The agentic stack has three layers: orchestration frameworks (how it reasons), platforms (where it runs and who governs it), and CLI agents (what builds it). Picking the wrong layer is the expensive mistake.
- The four orchestration frameworks differ mainly on coordination model: LangGraph is graph-based, CrewAI is role/crew-based, AutoGen is conversation-based, and Google ADK is protocol-first.
- Match the model to your problem: control flow points to LangGraph, human-style roles to CrewAI, open-ended negotiation to AutoGen, and multi-vendor interoperability to ADK.
- Platforms like AgentSpace and Vertex AI Agent Builder are a separate decision. They handle deployment and governance and keep the agent observable, not how the agent thinks.
- CLI agents like Claude Code are the build layer, not a production runtime. Use all three layers deliberately rather than asking one tool to do every job.