For most first-MVP features in 2026, the static-prompt path is the right default. The agent path adds roughly 5x complexity for some tasks and zero value for others. A founder’s job is not to learn agent architecture — it is to apply a 4-property decision rule that says, in the next vendor call, whether the agent premium is bought intelligence or markup.
This is a decision framework, not a definition. For the plain-English definition, see What is an LLM agent, actually?. The article you are reading sits downstream — you know what an agent is, a vendor has priced one into your scope, and you need a calibrated rule for whether to pay it. It is part of the eval-first build playbook cluster within the broader idea-to-product manifesto.
Table of Contents
- The static-prompt-first principle
- The architectural ladder MVP-1 actually climbs
- The 4-property decision rule
- Why properties beat use cases
- Worked example: the immigration-intake summarizer, built both ways
- How to use the rule in a vendor call
- Six common features, scored against the rule
- A note on hybrid shapes
- Frequently Asked Questions
- Closing
The static-prompt-first principle
One sentence: start with the simplest architecture that can meet the quality bar, and only escalate when an eval forces you to.
Anthropic stated this in Building effective agents (Dec 2024): “use the simplest solution possible, and only increase complexity when needed.” OpenAI’s A practical guide to building agents (2025) restates it in three criteria — agents earn their place when the task involves complex judgment, brittle deterministic logic, or unstructured navigation. Neither company leads with that line in marketing, because marketing sells agents.
The principle matters at MVP stage because failure modes are asymmetric. Building the simpler shape and finding it does not work costs one week plus one eval run. Building the agent shape and finding it does not work costs six weeks plus an opaque eval that cannot tell you whether the failure is the prompt, the tools, the planning loop, the state, or the model. The simpler shape fails legibly. The agent shape fails ambiguously. Founders pay for legibility.
The architectural ladder MVP-1 actually climbs
| Rung | Shape | Control flow | Cost/latency |
|---|---|---|---|
| 1 | Static prompt (single call) | One prompt, one answer | Cheapest, fastest |
| 2 | Static prompt with tools | One function call in one turn | ~1.5x rung 1 |
| 3 | Workflow (chained prompts) | Engineer-written sequence | 2-4x rung 1 |
| 4 | Agent (LLM-directed loop) | LLM picks next step on the fly | 5-10x rung 1 |
| 5 | Multi-agent | Multiple agents coordinating | 10x+ rung 1 |
Most founders only need rungs 1, 3, and 4. Rung 5 is production-rare in 2026 outside coding-assistant and infrastructure use cases. If a vendor sells rung 5 for MVP-1, walk out. The MoFu decision is almost always rung 1 vs rung 4 — and a vendor pricing rung 4 for what is honestly a rung-1 problem is the single most common scope inflation in the 2026 agency market.
The 4-property decision rule
Score the feature against these four binary properties. Each one fires or it does not.
Property 1 — Multi-step workflow
Does the feature decompose into 3+ steps where the choice of step N depends on the output of step N-1? The keyword is depends on. Same-order steps are a workflow (rung 3). Step 3 changing depending on what step 2 returned — branches open-ended, no whiteboard-ready flowchart — is an agent candidate.
- Fires: research a topic; triage a ticket where the next system depends on customer text; contract review where the clause-comparison depends on clause types found.
- Does not fire: extract line items from an invoice; classify a ticket into seven categories; draft an email from a brief.
Property 2 — External state
Does the feature read from or write to a system not in the prompt — CRM, database, file system, external API? Pure-text features do not fire. Features that look up the customer, fetch the order, write to the CRM — these fire. A single deterministic external call is rung 2, not rung 4. Fires when the set of side effects is open-ended.
Property 3 — Variable input order
Could two reasonable executions, on different inputs, take meaningfully different sequences? If every execution performs the same operations in the same order, you have a workflow. Fires only when input genuinely shapes the path and the paths are not enumerable.
- Fires: legal research (path depends on jurisdiction); debugging (next file depends on stack trace); medical-coding triage (rules depend on diagnosis).
- Does not fire: invoice extraction; standard-form intake; first-pass resume screen.
Property 4 — No deterministic alternative
Could a competent engineer write the decision tree in code in 200 lines without losing the value? Fires only when the answer is no. If you can whiteboard if invoice.country == "US": prompt_template = X and stay under 200 lines, the feature is a workflow with branches. Agents earn their cost when branches are open-ended or the conditions depend on nuanced model judgment a brittle if cannot capture.
The scoring rule
| Fires | Right shape |
|---|---|
| 0 | Static prompt (rung 1 or 2) |
| 1 | Static prompt or workflow — almost never an agent |
| 2 | Workflow first; agent only if the workflow eval misses the bar |
| 3 | Agent earns its cost — proceed to rung 4 |
| 4 | Agent is the right shape, no debate |
The rule does not say “3+ fires therefore you must build an agent.” It says “3+ fires, the agent premium is bought intelligence, not markup.” Below 3, the burden is on the agent. Above 3, on the static-prompt path.
Why properties beat use cases
A property-based rule is harder to game than a use-case rule. The use-case framing — “agents are good for customer service, research, coding” — is permissive: any pitch can be reshaped to look like a research problem. The property framing forces the conversation onto the feature’s mechanics: how many steps, what state, whether a 200-line decision tree can do the job.
Practitioners shipping production LLM features through 2024-2025 have been blunt: most teams who think they have an agent problem have a structured-output problem or a routing problem. They reach for rung 4 when rung 1 or rung 3 would have shipped in a quarter of the time and scored higher. The property rule is the corrective — and gives a non-engineer founder language to push back in a call.
Worked example: the immigration-intake summarizer, built both ways
A tool for a small immigration-law firm that turns a 4-page PDF intake form into a structured summary the attorney reviews on the first call. A vendor would price an agent build at $90K, 10-week timeline.
Run the rule first. P1 — form structured, same sections every time: no. P2 — form uploaded, summary returned, no CRM write at MVP-1: no. P3 — every intake reads the same sections in the same order: no. P4 — a senior engineer could write the section logic in an afternoon: no.
Score 0/4. Static prompt is the right shape.
| Build | Cost/summary | Latency | Eval (30 intakes) | Build time | Build cost |
|---|---|---|---|---|---|
| Static prompt (rung 1) | ~$0.04 | 6s | 92% | 2 weeks | $15K-$25K |
| Agent (rung 4, 5 tools, 15-iter cap) | ~$0.31 | 48s | 94% | 6 weeks | $70K-$95K |
The agent is 2 points higher on success, 8x cost, 8x latency, 4x build cost. It earned nothing. Worse, it introduced a new failure mode (planning loops stuck on ambiguous sections, burning budget without finishing) the static prompt does not have.
What changes when 3 properties fire
Same firm, MVP v2. The tool now pulls case-history from the case-management system, consults the USCIS policy manual to flag which client circumstances trigger which forms (I-130, I-485, I-751), writes the summary back as a structured case note, and queues paralegal follow-ups for missing information.
Re-score: P1 fires (the I-130 section is consulted only if family-status returned married). P2 fires (reads/writes case-management, consults policy). P3 fires (asylum and employment-based applicants traverse different sections in different orders). P4 fires (the deterministic alternative needs 200+ USCIS rules and is brittle to updates).
Score 4/4. Agent is the right shape. The static prompt collapses to 71% task success; the agent stays at 89% at $0.62 per summary and 75-second latency. Quality went up by 18 points on a task the static prompt cannot solve. That is what “bought intelligence” looks like.
The crossover, named
Holding model constant: at 0 properties static wins on every dimension; at 1 static still wins on $/quality; at 2 a workflow (rung 3) usually wins; at 3+ the agent earns its premium. Illustrative numbers from a small body of 2026 MVP work — the shape is what matters.
How to use the rule in a vendor call
The rule is most useful as a script for the next scoping conversation. Three questions, in order:
- “Which of the four properties does this feature satisfy?” A competent vendor will have a position. A vendor who fumbles to use-case categories instead of mechanics is signaling.
- “If we built the static-prompt version first, what would the eval score be?” Any vendor pitching an agent should be able to estimate. If not, the agent recommendation is not grounded in a quality comparison; it is grounded in the price tag.
- “If the static-prompt version hit 85% on our eval, would we still need the agent?” Many features clear the MVP quality bar with a static prompt and never escalate.
A defensible MVP scope, when the rule scores below 3, prices the static-prompt build as v1 and the agent as a contingent v2 — built only if the v1 eval comes in below the agreed threshold. The structure puts the risk on the architecture choice rather than on the founder’s budget.
Six common features, scored against the rule
| Feature | P1 | P2 | P3 | P4 | Score | Right shape |
|---|---|---|---|---|---|---|
| Invoice line-item extraction | no | no | no | no | 0 | Static prompt |
| Support-ticket classifier | no | no | no | no | 0 | Static prompt |
| Outbound email drafter from a brief | no | no | no | no | 0 | Static prompt |
| Onboarding: book meeting, send packet, write CRM | partial | yes | no | partial | 1-2 | Workflow (rung 3) |
| Contract-clause reviewer against a library | yes | yes | yes | partial | 3 | Agent |
| Sales-research agent producing a 1-pager from public sources | yes | yes | yes | yes | 4 | Agent |
The top three are where most 2026 vendors over-build. The middle one is the most expensive scoping mistake — features that look agent-shaped (multi-step, side-effect-bearing) but run the same sequence every time. They are workflows. The scoring lens echoes stop scoping AI projects in features — scope them in evaluations: the question is not “what is this feature called” but “what is the architecture and what is the eval that catches it failing.”
A note on hybrid shapes
The framework is binary at the rung level, but production is hybrid. A common 2026 pattern: rung 4 at the top orchestrating rung 3 and rung 1 underneath — the agent makes routing decisions, underlying calls are predictable. The rule still applies: the agent layer is justified only when the routing decision itself scores 3+. If routing is enumerable, the orchestrator is itself a workflow and the agent layer is dead weight. For MVP-1 the hybrid is usually overkill — ship the static prompt. The case for keeping MVP-1 narrow is covered in the case for boring AI features in MVP-1.
Frequently Asked Questions
Is the 4-property rule a hard threshold or a heuristic?
A heuristic. The score forces a structured conversation. The threshold of 3 is calibrated to where the agent’s complexity premium starts paying for itself — but the eval is the authoritative judge.
How do I push back on a vendor who says every feature needs an agent?
Read out the four properties for the feature and ask which fire. If the vendor cannot name them feature by feature, the recommendation is sales. Second pushback: “What eval score does the static-prompt version hit?” A vendor who has not estimated has not done the scoping work.
What if my feature lives on the border — 2 of 4 properties fire?
Build the workflow (rung 3) first. Workflows assemble in days, score, and either ship or escalate. The cost of building a workflow and discovering an agent is needed is low. The reverse is high.
Does the rule work for non-text features (vision, voice, multimodal)?
Yes. P2 (external state) often fires more easily because voice and vision pipelines touch microphones, cameras, file systems, and downstream services. The rule otherwise scores the same.
How does this rule interact with frameworks like LangGraph or the OpenAI Agents SDK?
The rule decides the rung, not the tool. Rung 1 — write directly against the model’s API. Rung 3 — chained prompts in plain code. Rung 4 is where frameworks earn a look. Framework choice is a phase-2 decision.
Can I retrofit a static prompt into an agent later?
Yes — that is the steel-manned argument for starting at rung 1. The static prompt informs the eval set, the tool list, and the failure modes. Most production agents in 2026 began as single prompts that needed to scale. The reverse rarely happens because complexity hides which simplifications would have worked.
How do I know the static-prompt path will not scale?
You do not, until the eval tells you. Ship it, score against a 30-50 example eval, read the failures. If failures cluster where the static prompt cannot reach by design — needs external systems, needs variable sequences — the escalation is justified.
What is the most common mistake founders make against this rule?
Buying an agent at MVP-1 because the vendor called the feature “agentic.” Roughly two-thirds of MVP-1 features in 2026 score 0 or 1 on the rule. Apply it and make the vendor defend the score property by property.
Closing
The 4-property rule converts a vague architectural choice — agent or no agent? — into a specific, defensible score a non-engineer founder can run in five minutes. The static-prompt-first principle is the default; the properties name when the default fails; the worked example shows where the crossover lives.
In 2026 the over-application of “agent” in vendor proposals is the single largest source of MVP-1 scope inflation. Bring the rule to your next scoping call. Score the feature property by property. Make the vendor defend the score. If the rule lands below 3 and the vendor still pitches an agent, the difference is margin, not bought intelligence — and you now have the language to say so. The companion piece why your MVP should ship with 3 evals, not 30 covers the eval that makes this decision empirically.
Need a 30-minute scoping call to apply this rule to your feature? SFAI Labs runs MVP-1 scoping engagements with this framework as the default. Download the AI MVP Scoping Worksheet to run the rule yourself before your next vendor call.
Dirk Jan van Veen, PhD
