Minimum Viable Agent
Last reviewed
Sources
18 citations
Review status
Source-backed
Revision
v3 ยท 6,836 words
Improve this article
Add missing citations, update stale details, or suggest a clearer explanation.
Suggest edit
CtrlK
Last reviewed
Sources
18 citations
Review status
Source-backed
Revision
v3 ยท 6,836 words
Add missing citations, update stale details, or suggest a clearer explanation.
See also: Artificial intelligence terms
A Minimum Viable Agent (MVA) is the simplest valid implementation of an AI agent: a program in which a large language model calls tools in a loop, observes the results, and decides on its own when to stop. In structural terms it is an LLM call inside a while loop, a small set of tool definitions, an environment those tools can act on, and a termination condition. Everything beyond those four elements (frameworks, planners, multi-agent orchestration, vector memory, evaluators) is an addition justified only by a concrete need the minimum cannot meet.
The phrase has two intersecting meanings in agent-engineering practice. The first, drawn from product methodology, treats the MVA as the agent equivalent of a Minimum Viable Product: a narrow first version shipped to real users to validate utility before adding features. The second, popularized by Anthropic's December 2024 essay Building effective agents, treats the MVA as a structural minimum: the smallest set of primitives that still constitutes a true agent rather than a deterministic workflow.[1] The two readings overlap in spirit (start small, escalate complexity only when needed) but they answer different questions. The product reading asks "What is the smallest valuable thing to ship?" The structural reading asks "What is the smallest thing that is still an agent?"
This article focuses primarily on the structural reading, which has become the dominant usage among practitioners after Anthropic's essay and the wave of "build an agent in fifty lines of Python" tutorials that followed. Under that reading, an MVA is an LLM call inside a while loop, a small set of tool definitions, an environment those tools can act on, and a termination condition. Anything beyond those four elements (frameworks, planners, multi-agent orchestration, vector memory, evaluators) is an addition on top of the minimum, justified only by a concrete need that the minimum cannot meet.
The term "minimum viable agent" emerged informally on developer forums and social media through 2023 and 2024 as builders reacted against what they perceived as the over-abstraction of early agent frameworks. By late 2024, two influences crystallized the modern usage. The first was Anthropic's engineering essay Building effective agents, published on 19 December 2024 by Erik Schluntz and Barry Zhang, which drew a sharp line between two categories of "agentic systems."[1] The essay defines the two categories directly: "Workflows are systems where LLMs and tools are orchestrated through predefined code paths," while "Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage."[1] The MVA is the smallest implementation that still meets the second definition. The second influence was Hugging Face's release of smolagents on 31 December 2024, a deliberately barebones library whose core agent logic fit in roughly one thousand lines of Python and whose marketing centered on the message that agentic capabilities do not require heavy frameworks.[2]
The Anthropic essay is the most frequent citation when authors define the MVA. Its central recommendation is that "the most successful implementations weren't using complex frameworks or specialized libraries. Instead, they were building with simple, composable patterns."[1] The essay advises that "developers start by using LLM APIs directly: many patterns can be implemented in a few lines of code."[1] That stance, repeated across the OpenAI practical guide to building agents (April 2025)[3] and the documentation of frameworks such as the OpenAI Agents SDK and the Claude Agent SDK, is now the consensus position in agent engineering: complexity is something a project earns, not something a project starts with.
The structural definition of an MVA, distilled from these sources, has four required components and one optional one.
finish tool is invoked, a maximum iteration count is reached, a token or cost budget is exhausted, or a human approves a final answer.The optional fifth component is short-term memory, usually implemented as the running list of messages and tool results that the agent re-sends to the model on each iteration. Some authors treat this as part of the LLM call rather than a separate component, since most modern model APIs require the caller to pass full conversation history. The OpenAI Agents SDK, the LangGraph create_react_agent helper, and the Claude Agent SDK all manage this transcript automatically.
What is deliberately absent from the structural minimum is also informative. There is no planner, no critic, no separate retrieval system, no long-term memory store, no observability layer, no guardrails, no evaluator. Each of those can be added (and in production usually is) but none is required for the system to be a working agent.
The older product-flavored reading of the MVA, common in startup and consulting writing through 2023 and 2024, frames the agent as a deliverable rather than an architecture. Under this reading, an MVA is a single-purpose agent shipped to real users as quickly as possible, building on the Minimum Viable Product tradition associated with Eric Ries and the Lean Startup movement. A customer-support agent that answers FAQs and escalates anything else, a recruiting agent that ranks resumes against a single job description, or a finance agent that extracts five fields from earnings releases would all qualify. The structural definition does not contradict this reading; an agent can be both a product MVP and a structurally minimal implementation. The two views simply emphasize different axes of "minimum": product surface area versus engineering surface area.
The defining pattern of an agent, and therefore of any minimum viable agent, is the agent loop. Different sources describe it with slightly different vocabulary, but the steps converge.
Anthropic's Claude Agent SDK reduces this to a four-word slogan: "gather context, take action, verify work, repeat."[4] The Claude Code SDK was renamed the Claude Agent SDK on 29 September 2025 because Anthropic observed that the same loop powering its coding tool was being used internally for research, video creation, note-taking, and other agentic work.[4] The loop is the thing; the domain is interchangeable.
The blog post The Unreasonable Effectiveness of an LLM Agent Loop with Tool Use argues the same point even more sharply. The loop, the author writes, is a "shockingly simple" construct in Python:[5]
def loop(llm):
msg = user_input()
while True:
output, tool_calls = llm(msg)
print("Agent:", output)
if tool_calls:
msg = [handle_tool_call(tc) for tc in tool_calls]
else:
msg = user_input()
The argument is that with even one general-purpose tool (the post uses bash) and a strong model, this loop is enough to handle a surprising fraction of real engineering work.[5] The MVA is the loop; everything else is plumbing.
A more precise way to describe the loop, popularized by the ReAct literature, breaks step three into two phases.
Thought before acting, making the decision step visible.This four-step cycle (parse, decide, execute, observe) is what most practitioners mean when they say "agent loop." It is the operational core of an MVA.
The word minimum carries two implicit critiques. The first is aimed at the early generation of agent frameworks (LangChain before LangGraph, BabyAGI, AutoGPT, and similar) that wrapped the agent loop in many layers of abstraction. Builders who tried to debug or extend those systems often found that the framework's ontology (chains, agents, tools, callbacks, parsers) obscured rather than clarified the simple while loop underneath. Anthropic's essay makes the case explicitly: frameworks "often create extra layers of abstraction that can obscure the underlying prompts and responses, making them harder to debug."[1] The MVA is the response: write the loop yourself, see every prompt and every tool call, and add a framework only when you have a problem the loop alone cannot solve.
The second critique is aimed at the temptation to add multi-agent orchestration, planners, critics, and elaborate memory schemes before validating that a single tool-calling loop fails. The OpenAI practical guide to building agents recommends starting with a single agent and a small tool set, then expanding only when the agent's failure modes call for it.[3] The smolagents launch post puts it as "don't build agents for everything," and Anthropic's essay opens with the same advice: optimizing a single LLM call with retrieval and in-context examples is usually enough for many use cases.[1][2]
The minimum, in other words, is a discipline. It says: justify each addition. If your agent works without a planner, do not add one. If it works without a vector store, do not add one. If it works without a sub-agent, do not add one. The MVA is the baseline against which all such additions must demonstrate their value.
The canonical demonstration of an MVA is a short Python script that solves a real task using only the OpenAI or Anthropic SDK and standard library. The example below is representative of the shape that appears in dozens of tutorials, including the Anthropic cookbook, the OpenAI documentation, and the smolagents introduction. It is paraphrased to illustrate the structure rather than copied from any single source.
import json
import anthropic
client = anthropic.Anthropic()
def get_weather(location: str) -> str:
# Stand-in for a real API call.
return json.dumps({"location": location, "temp_c": 14, "sky": "overcast"})
def calculator(expression: str) -> str:
return str(eval(expression, {"__builtins__": {}}, {}))
TOOLS = [
{
"name": "get_weather",
"description": "Look up the current weather for a city.",
"input_schema": {
"type": "object",
"properties": {"location": {"type": "string"}},
"required": ["location"],
},
},
{
"name": "calculator",
"description": "Evaluate an arithmetic expression.",
"input_schema": {
"type": "object",
"properties": {"expression": {"type": "string"}},
"required": ["expression"],
},
},
]
DISPATCH = {"get_weather": get_weather, "calculator": calculator}
def run_agent(user_message: str, max_turns: int = 10) -> str:
messages = [{"role": "user", "content": user_message}]
for _ in range(max_turns):
response = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=1024,
tools=TOOLS,
messages=messages,
)
if response.stop_reason == "end_turn":
return "".join(
block.text for block in response.content if block.type == "text"
)
if response.stop_reason == "tool_use":
messages.append({"role": "assistant", "content": response.content})
tool_results = []
for block in response.content:
if block.type == "tool_use":
fn = DISPATCH[block.name]
result = fn(**block.input)
tool_results.append(
{
"type": "tool_result",
"tool_use_id": block.id,
"content": result,
}
)
messages.append({"role": "user", "content": tool_results})
raise RuntimeError("Agent exceeded max_turns without finishing.")
The full program is approximately fifty lines including imports and tool definitions. It contains every required component of an MVA. The model is the Claude API call. The tools are get_weather and calculator. The environment is the local Python interpreter plus whatever the tools reach (the weather function would normally hit an external API). The termination conditions are two: the model returns end_turn, or the loop hits max_turns. The message history serves as short-term memory.
Nothing in this script depends on a framework. It runs on pip install anthropic alone. The same shape ports cleanly to OpenAI's tool-calling API by swapping the client and adjusting the response parsing. It is, in the literal structural sense, a minimum viable agent.
Once a builder has the basic loop, several well-known variations refine it without abandoning the minimal posture. Each is a recognizable pattern in the agent literature, named in research papers or framework documentation.
The ReAct pattern, introduced by Shunyu Yao and colleagues in the 2022 paper ReAct: Synergizing Reasoning and Acting in Language Models (presented at ICLR 2023), is the historical ancestor of most modern tool-calling agents.[6] ReAct interleaves natural-language Thought traces with Action calls and Observation outputs, producing transcripts shaped like:
Thought: I need to find the population of France first.
Action: search["population of France 2024"]
Observation: 68 million.
Thought: Now compare it to Germany.
Action: search["population of Germany 2024"]
Observation: 84 million.
Thought: I have enough to answer.
The ReAct paper showed that interleaving reasoning and acting reduces hallucination on question-answering benchmarks like HotpotQA and Fever, and that on the ALFWorld and WebShop interactive benchmarks ReAct "outperforms imitation and reinforcement learning methods by an absolute success rate of 34% and 10% respectively, while being prompted with only one or two in-context examples."[6] Most modern tool-calling APIs (OpenAI function calling, Anthropic tool use, Google Gemini tools) effectively implement a structured ReAct loop; the model's assistant message is the Thought, the tool call is the Action, and the tool result is the Observation. The MVA above is, in this sense, a ReAct agent in all but name.
Reflection variants, exemplified by the 2023 paper Reflexion: Language Agents with Verbal Reinforcement Learning by Noah Shinn, Federico Cassano, Edward Berman, Ashwin Gopinath, Karthik Narasimhan, and Shunyu Yao (NeurIPS 2023), insert a self-critique step into the loop.[7] After each attempt, the agent generates a verbal reflection on what went wrong and stores it in an episodic memory buffer that conditions future attempts. Reflexion reported a 91% pass-at-1 score on the HumanEval coding benchmark, surpassing the 80% baseline of GPT-4 at the time.[7] In MVA terms, Reflection adds an extra step to the loop (after observation, generate a reflection) but does not require a second agent or a separate planner.
Plan-and-execute agents, popularized by BabyAGI in early 2023 and formalized in the LangChain blog and LangGraph tutorials, split the work into two phases.[8] A planner LLM generates a list of steps once, and an executor LLM (often a smaller model) carries out each step. Replanning happens only when the executor fails or new information arrives. The pattern reduces calls to the expensive planner model, cutting cost and latency relative to step-by-step ReAct. The trade-off is rigidity: a static plan cannot react to surprising tool results as cleanly as a fully dynamic loop. An MVA can grow into plan-and-execute by adding a single up-front planning call, with the rest of the loop unchanged.
Multi-agent variants, represented by frameworks such as AutoGen, CrewAI, and the OpenAI Agents SDK's handoff feature, run several specialized agents that exchange messages. Microsoft Research's AutoGen paper, AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation, frames this as conversation among customizable, conversable agents.[9] Multi-agent setups can outperform single agents on tasks that decompose cleanly along role lines (researcher and writer, planner and coder), but they cost more tokens and add coordination failure modes. Anthropic reports that multi-agent systems use about fifteen times more tokens than chat interactions, so they are economically viable only when the value of the task justifies the expense.[10] Anthropic's essay treats multi-agent as a late addition, used only when a single agent demonstrably cannot handle the task.[1] The MVA's multi-agent extension is to instantiate two MVAs and let one call the other as a tool.
Code agents, the design at the heart of Hugging Face's smolagents, replace JSON tool calls with executable code blocks. Instead of emitting a tool name and arguments, the model writes Python that uses the tools as functions. The smolagents launch post (31 December 2024, Aymeric Roucher, Merve Noyan, and Thomas Wolf) reports that this approach reduces LLM calls by roughly 30% on complex benchmarks because a single code block can chain several tool calls and intermediate computations.[2] The MVA shape is preserved; only the tool-call serialization changes. Smolagents executes the model-generated code in a sandbox (E2B, Modal, Docker, or WebAssembly) to contain the obvious risk.[2]
A recurring question for new builders is when to graduate from a hand-rolled MVA to a framework. The honest answer in 2026 is that the major frameworks have largely converged on "give us the minimum loop, then add the things you need." Each framework defines the minimum slightly differently.
| Framework | Vendor | Minimum unit | Distinctive value over a hand-rolled MVA |
|---|---|---|---|
| smolagents | Hugging Face | ~1,000-line core, code agents | Smallest commercial framework; teaching tool; model-agnostic via LiteLLM[2] |
| OpenAI Agents SDK | OpenAI | Agent + Runner.run_sync | Built-in tracing and handoffs; production successor to Swarm[11] |
| Claude Agent SDK | Anthropic | Managed loop + default tools | "Gather context, take action, verify work"; gives the agent a terminal[4] |
| LangGraph | LangChain | create_react_agent / StateGraph | Durable execution, checkpointers, human-in-the-loop interrupts[12] |
| AutoGen | Microsoft | ConversableAgent + UserProxyAgent | Multi-agent conversation; now in maintenance mode[9] |
StateGraph: a typed state, nodes that read it and return deltas, and edges (some conditional) that wire them together. The create_react_agent helper produces a one-line MVA equivalent. LangGraph's value over a hand-rolled MVA is durable execution: a checkpointer (in-memory, SQLite, or Postgres) writes state at every super-step so a graph can be paused, resumed, replayed, or branched.[12] Builders typically choose LangGraph when they need human-in-the-loop interrupts or long-running tasks that survive process crashes.ConversableAgent paired with a UserProxyAgent. AutoGen v0.4 made the runtime event-driven, and Microsoft has since put AutoGen into maintenance mode, recommending the new Microsoft Agent Framework for greenfield work.[13] AutoGen's appeal was always multi-agent debate and group chat patterns; its baseline is heavier than an MVA but lighter than orchestration platforms.Agent (an LLM with instructions, tools, and handoffs), Runner (the loop), guardrails, and tracing.[11] The smallest possible program is two lines after import: agent = Agent(name="Assistant", instructions="You are helpful.") and Runner.run_sync(agent, "Write a haiku."). The SDK's signature feature beyond the loop is built-in tracing and the handoff primitive that converts a multi-agent system into a graph of single-purpose Agent objects.Bash, code generation, file search, and MCP integration. Subagents run in isolated context windows. The Claude Agent SDK's design principle is to give the agent a computer: rather than enumerate tools, it gives the agent a terminal and lets it improvise.[4]The practical heuristic adopted by most teams writing about this in 2025 and 2026 is: start with a hand-rolled MVA in fewer than one hundred lines of Python; move to smolagents or the OpenAI/Claude Agent SDKs when you want managed tracing and prebuilt tools; move to LangGraph or the Microsoft Agent Framework when you need durable state, human-in-the-loop interrupts, or graph orchestration with multiple agents.
A central message of Anthropic's essay (and one repeated in OpenAI's, Google's, and Hugging Face's guides) is that many problems do not need an agent. The essay phrases it directly: "Agents can be used for open-ended problems where it's difficult or impossible to predict the required number of steps, and where you can't hardcode a fixed path."[1] If the workflow is predictable, a workflow is better. If a single LLM call with retrieval suffices, that is better still. The first question to ask before building an MVA is whether the problem actually requires dynamic decision-making at runtime.
Anthropic's essay names five workflow patterns that should be tried first: prompt chaining, routing, parallelization, orchestrator-workers, and evaluator-optimizer.[1] Only after these prove insufficient does the autonomous agent become the right tool. The reason is the cost-error tradeoff. The essay notes that "Agentic systems often trade latency and cost for better task performance," and that "the autonomous nature of agents means higher costs, and the potential for compounding errors."[1] An agent that takes ten model calls to do what a workflow could do in two is an agent that costs more and has more chances to fail.
The practical signs that an agent is appropriate are: the task has a long tail of edge cases that resist enumeration, the path through the task depends on information that arrives during execution, the task is open-ended in length (a research project, a debugging session, a multi-step support case), or the human alternative is a person with expertise rather than a person following a script. If the task fails any of those tests, a workflow or a single augmented LLM call is the better starting point.
The simplicity of the MVA is also its largest source of failure modes. A short loop with no guardrails is a short path to a runaway bill or a stuck agent. The pitfalls below recur in every postmortem written about agents shipped to production.
The most common failure is the agent that does not stop. Without a hard cap, an agent can call a broken tool hundreds of times, debate itself, or re-plan endlessly. Industry guidance settles on three layered termination conditions: a maximum-iteration cap (typical production values are fifteen to twenty-five steps), a token or cost budget per run, and a no-progress detector that exits the loop when several consecutive iterations produce no new information. Termination conditions are not optional polish.
Agents consume roughly four times the tokens of a comparable chat interaction, and multi-agent setups about fifteen times, because every loop iteration re-sends the growing message history to the model.[10] The fix is a combination of per-run budgets (hard caps on tokens and dollars), prompt caching of the system prompt and stable parts of the history, summarization of older turns once the history grows past a threshold, and a routing layer that sends easy tasks to a cheaper model. Some teams place a proxy in front of all LLM calls that enforces these limits centrally rather than relying on each agent to police itself.
The MVA template above runs tools with no try/except wrapper. In production, every tool needs error handling because tool failures are how environments communicate negative information. A 404 from an HTTP tool is data, not a crash. The harness should catch tool exceptions, format them as messages back to the model, and let the agent decide whether to retry, switch tools, or give up. Repeated identical errors in a row should trip a circuit breaker.
A loop that nobody can read is a loop that nobody can debug. Production agents need structured tracing of every model call, tool invocation, and tool result, with token counts and latencies. The de facto standard in 2026 is OpenTelemetry: frameworks including Pydantic AI, smolagents, the Claude Agent SDK, and Strands Agents emit OTel spans, which platforms such as Langfuse, LangSmith, Arize Phoenix, and Helicone can ingest.[14] Adding tracing to an MVA usually means wrapping the LLM call and the tool dispatcher with an instrumentation library; it does not require restructuring the loop.
Anthropic's essay calls out the agent-computer interface as deserving as much attention as the prompts themselves, advising builders to "think about how much effort goes into human-computer interfaces (HCI), and plan to invest just as much effort in creating good agent-computer interfaces (ACI)."[1] Tool descriptions should read like documentation written for a junior engineer who will use the tool blind. Common mistakes include: ambiguous parameter names that the model fills with the wrong values, tool sets that overlap so the model picks the wrong one, side-effecting tools that should be idempotent but are not, and tools that return walls of text the model cannot summarize. The fix is to write tool docs first, test them with a few prompts, and shrink the tool set until each tool has one clear purpose.
An agent that reads untrusted text and then acts on tools is an attack surface. A web-browsing agent that reads a malicious page can be coaxed into calling tools the user did not ask for. The literature on prompt injection recommends three defenses: separate the system prompt from user content with structural markers, run the agent in a sandbox where its tools cannot reach sensitive systems, and confirm any irreversible action (sending email, executing trades, deleting files) with a human. Smolagents enforces sandboxing for code agents by routing execution through E2B, Modal, Docker, or WebAssembly.[2] The Claude Agent SDK and OpenAI Agents SDK both ship sandboxed execution modes.
Anthropic's essay warns that "the autonomous nature of agents means higher costs, and the potential for compounding errors": small mistakes in early steps that cascade into worse outcomes later.[1] An agent that misreads a user's date format on step one will compound that mistake on every subsequent step. The defenses are evaluation, redundant verification (have the agent check its own work or have a second model verify), and intermediate human checkpoints for high-stakes flows.
Moving an MVA from a notebook to production requires several additions, none of which violate the minimal posture but all of which extend it.
Short-term memory is the message history that the loop already carries. Long-term memory is what the agent remembers across runs: prior conversations, learned preferences, accumulated facts. Implementations range from a key-value store keyed on user ID to a vector database for semantic recall. The OpenAI Agents SDK and LangGraph both expose session abstractions that persist message history; for richer memory, teams add a vector store such as Pinecone, Weaviate, or pgvector. Anthropic's Claude Agent SDK recommends starting with agentic search (the agent uses a search tool against a file or document store) and adding semantic search only if the agentic version is too slow.[4]
Production agents need evals: scripted test cases that exercise representative tasks and grade outputs. Anthropic, OpenAI, Google, and Hugging Face all publish evaluation guides in their agent docs because the failure modes of agents are emergent rather than catchable in unit tests. Common eval shapes include ground-truth tasks (a known-answer QA set), trajectory grading (does the agent's tool sequence look right?), and LLM-as-judge scoring on open-ended outputs. Evals run in CI prevent regressions when a prompt or model is changed.
Guardrails are checks layered on agent inputs and outputs. Input guardrails block prompt injection, jailbreaks, or out-of-scope queries before the agent runs. Output guardrails check the final response for PII, policy violations, or factual contradictions before it reaches the user. The OpenAI Agents SDK exposes guardrails as a first-class primitive; LangGraph users typically add guard nodes; hand-rolled MVAs add explicit validate_input and validate_output calls.[11] Guardrails are not part of the structural minimum but they are part of any responsible production deployment.
Once an agent runs against real users, the operator needs to see what is happening. Tracing platforms record full transcripts, token counts, costs, latencies, and tool-result samples. They support replay, A/B comparison of prompts, and aggregate analytics on which tools are used, which fail, and which produce the longest latencies. The integration is shallow (a wrapper around the model client and tool dispatcher) but the operational value is large.
For any agent whose actions have non-trivial cost (sending a customer email, posting code, moving money), production deployments include human-in-the-loop checkpoints. Anthropic's essay frames this as the agent "pausing for human feedback at checkpoints or when it encounters blockers."[1] LangGraph's interrupt primitive and the Claude Agent SDK's permission system are designed for exactly this. The MVA template above adds human-in-the-loop with a single change: insert a confirmation step before tools whose requires_approval flag is true.
Agents that run for minutes or hours need different deployment shapes than chat applications that respond in seconds. Long-running agents typically run as background jobs (Celery, Temporal, AWS Step Functions) with a checkpointer that lets them resume after a crash. LangGraph's persistence layer is built for this; the Microsoft Agent Framework adds enterprise-grade durability on top of AutoGen's lessons.[13] The MVA does not require any of this until run times exceed the request timeout of the host platform.
A practical illustration brings the concepts together. Suppose a startup wants a customer-support agent that answers product questions, looks up order status, and escalates anything else to a human. The product MVA is one of the canonical examples cited above (a narrow scope, a clear value to users). The structural MVA is the implementation.
The agent has three tools: search_docs(query) that returns the top three FAQ snippets from a vector store, get_order_status(order_id) that hits the order database, and escalate_to_human(reason) that posts to a Slack channel and ends the loop. The system prompt instructs the agent to answer from docs when possible, to verify identity before disclosing order details, and to escalate anything outside its scope. The loop has a max_turns of eight and a per-run cost cap of two cents. The harness runs in a sandboxed function with no other network access. Every turn is traced to Langfuse. A nightly eval set of fifty tickets, each with a graded ideal response, runs in CI.
This is still an MVA in the structural sense. The loop is a few dozen lines. The tool set is three. The environment is a vector store and an order database. The termination conditions are: model returns a final answer, escalation tool is called, max turns hit, cost cap hit. What has been added is not framework abstraction but operational scaffolding: tracing, evals, sandboxing, cost limits. Each addition was justified by a real failure mode that the bare loop did not handle. The MVA discipline is preserved.
The naming clearly echoes Eric Ries's Minimum Viable Product. The lineage is more than rhetorical. Both ideas reject premature optimization: the MVP rejects building features without validating user need, and the MVA rejects building agent abstractions without validating that the loop alone fails. Both treat shipping and observation as superior to planning and theorizing. Both recognize that the cost of complexity is paid up front and the value of features is paid back only if the underlying assumptions survive contact with reality.
Where they differ is in the role of users. The product MVP is fundamentally a hypothesis test about what users want. The structural MVA is a hypothesis test about what an architecture can do. A team can ship a product MVP that is a deeply complex agent, or a product non-MVP that is a structural MVA. The two minimums are independent axes; the rigorous practitioner attends to both.
Several misconceptions about MVAs have hardened in informal usage and are worth correcting.
The core idea predates the term. The 2022 ReAct paper described what is recognizably an MVA loop in research form, and the 2023 Toolformer paper by Timo Schick and colleagues at Meta AI showed that language models could be trained to decide when to call APIs.[6][15] By mid-2023, BabyAGI and AutoGPT had popularized the idea of LLM agents that pursue goals over many steps; both were criticized for opacity and unreliability, which fueled the appetite for simpler implementations.
Through 2023 and into 2024, LangChain became the dominant framework for building agents, and a backlash against its abstractions developed in parallel. Anthropic's Building effective agents essay in December 2024 crystallized that backlash into actionable guidance and gave the MVA mindset its definitive citation.[1] Hugging Face's smolagents release one week later (31 December 2024) provided a concrete framework that exemplified the philosophy.[2] OpenAI's practical guide to building agents (April 2025) and the OpenAI Agents SDK (March 2025) brought a major commercial backer behind the same design language.[3][11] Anthropic's renaming of the Claude Code SDK to the Claude Agent SDK in September 2025 generalized the pattern beyond coding, and the Microsoft Agent Framework carried AutoGen's multi-agent ideas into a more disciplined runtime.[4][13]
By 2026 the MVA is the default starting point in agent engineering. New projects begin with a hand-rolled loop or a thin SDK; complexity is added in defended increments; and frameworks compete on how cleanly they preserve the underlying loop while adding production scaffolding. The discourse has moved from "which framework should I pick?" to "what is the simplest agent that could possibly work for this task, and how do I instrument it?"
The ecosystem of tools that pair well with MVA-style development has grown rapidly. The list below is representative rather than exhaustive.
The MVA mindset is not a universal solvent. Several classes of problem strain the simple loop and benefit from more structure from the start.
Knowing these limits is part of the discipline. The MVA is the default, not the destination.
A minimum viable agent is the smallest implementation that still qualifies as an agent: an LLM in a loop, a few tools, an environment, and a termination condition. The concept has both a product reading (ship the narrowest useful version first) and a structural reading (do not exceed the architectural minimum without justification). The structural reading dominates in 2026, anchored by Anthropic's Building effective agents,[1] the OpenAI practical guide,[3] and the design choices of frameworks such as smolagents, the OpenAI Agents SDK, the Claude Agent SDK, and LangGraph. Builders who internalize the MVA discipline write fewer lines of code, debug more easily, ship more reliable systems, and add complexity only when the bare loop demonstrably fails. The principle is older than the term: start small, observe carefully, escalate only when justified.