Gemini vs Claude vs OpenAI: Choosing an Agent Stack and Talking About It in Interviews
A vocabulary map across the three ecosystems — SDKs, agent frameworks, coding harnesses, skill and context conventions — plus a decision framework and the questions interviewers ask about provider choice.
After this lesson you can
- ✓Map any concept (skills, sub-agents, caching, MCP) to its name in each ecosystem
- ✓Argue for a provider choice on engineering grounds rather than benchmark headlines
- ✓Design for portability so a provider switch is a week, not a rewrite
The Rosetta stone
Most of the confusion in this space is naming. The concepts are shared; each ecosystem gives them different labels and packages them at different layers. Keep this table in your head and you can read any provider’s docs in an afternoon.
| Concept | Gemini / Google | Claude / Anthropic | OpenAI |
|---|---|---|---|
| Model API + SDK | Gemini API · google-genai (Python/JS/Go); Vertex AI for enterprise | Messages API · anthropic SDK (Python/TS/Java/Go…) | Responses API · openai SDK (Python/TS/Java/Go…) |
| Agent framework | Agent Development Kit (ADK) — LlmAgent, Sequential/Parallel/Loop agents | Claude Agent SDK — the Claude Code runtime as a library | Agents SDK — Agent, Runner, handoffs, guardrails |
| Coding harness | Gemini CLI · Jules | Claude Code | Codex (CLI, IDE, cloud) |
| Project instructions file | GEMINI.md | CLAUDE.md | AGENTS.md |
| Skills / extensions | Gemini CLI extensions; custom commands | Agent Skills (SKILL.md) — open format | Codex skills; custom prompts |
| Sub-agents | sub_agents / AgentTool in ADK; A2A between services | agents in Agent SDK, Task tool in Claude Code | agents-as-tools or handoffs in Agents SDK |
| Caching | Context caching (explicit objects + implicit) | Prompt caching (cache_control breakpoints) | Automatic prompt caching (prefix match) |
| MCP support | SDK (session as tool), ADK, Gemini CLI | API connector, Claude Code, Agent SDK, apps | Responses API mcp tool, Agents SDK, Codex |
| Managed hosting | Vertex AI Agent Engine | Managed Agents (server-hosted, sandboxed) | Assistants → Responses + hosted tools |
| Agent-to-agent protocol | A2A (originated at Google, now Linux Foundation) | MCP; A2A interop | MCP; A2A interop |
| Observability | Cloud Trace via ADK; OpenTelemetry | OpenTelemetry hooks in Agent SDK | Built-in tracing dashboard in Agents SDK |
How to actually choose
Benchmarks move monthly; the engineering factors move slowly. Decide on these instead.
- •Where your data already lives. Vertex AI if you are a GCP shop, Azure OpenAI if you are Microsoft-centric, Bedrock for Claude on AWS. Data residency and procurement often decide before engineering does.
- •The task profile. Long agentic coding sessions, very large documents, heavy tool use, low-latency chat and multimodal input each favour different models at any given moment — run your own eval set, not the vendor’s.
- •Ecosystem depth for your shape of agent. Coding agents and skills → Claude Code / Agent SDK is the most mature. Workflow agents on GCP with managed deployment → ADK + Agent Engine. Handoff-style customer agents with built-in tracing → OpenAI Agents SDK.
- •Cost structure. Compare cached-input pricing and batch discounts, not list price. An agent’s bill is dominated by re-sent context, so the provider whose caching fits your traffic pattern wins.
- •Portability. Whatever you pick, keep the agent loop, tool definitions and skills in your own code or in open formats (MCP, SKILL.md, OpenTelemetry). Then a switch is an adapter, not a rewrite.
Designing for portability
A portable agent codebase has four seams. Model adapter: one function that takes a provider-neutral message list and tools and returns a neutral response — thirty lines per provider. Tools as MCP servers or plain functions with JSON schemas, never as provider-specific decorators. Skills as SKILL.md folders read by your own loader (lesson 2). Observability as OpenTelemetry spans, not a vendor dashboard.
With those seams, evaluating a new model is a config change plus an eval run. Without them, it is a quarter. This is also a strong interview answer to "how would you avoid vendor lock-in" — concrete seams beat abstract warnings.
The interview map for this whole track
AI-engineer interviews in 2026 test four things: can you pick the right architecture (workflow vs agent, single vs multi), can you control cost and context (caching, compaction, tool result hygiene), can you make it reliable (evals, error contracts, permission boundaries), and can you talk across providers without confusing their vocabularies. Each lesson in this track maps to one of those. Practice by taking one product you know and designing it three ways — that exercise, done out loud, is most of the interview.
- •Architecture → lesson 1 (patterns) and lesson 3 (multi-agent)
- •Cost & context → lesson 4 (caching, compaction) and lesson 5 (tool result design)
- •Reliability → lesson 3 (failure modes), lesson 5 (error contracts), plus the evals posts in the blog series
- •Cross-provider fluency → this lesson, and re-implementing any example above on a provider you use less
Interview questions this lesson prepares you for
- You are asked to pick between Gemini, Claude and OpenAI for a customer-support agent. What do you evaluate, in what order?
- How would you structure an agent codebase so switching model providers is cheap?
- What is the equivalent of Claude Code’s sub-agents in ADK and in the OpenAI Agents SDK?
- A2A vs MCP — which layer does each own, and can one system use both?