Building agents that hold up

Current-generation AI agents work best on a specific kind of work: low cognitive load, high repetition. Teams starting with agents tend to pick use cases that aren't serious. This page covers both halves of that problem: how to evaluate whether a task is a good candidate for agent automation, and seven principles for building agents that don't break.

The sweet spot: low cognitive load, high repetition

Current-generation agentic AI achieves the highest likelihood of success with work requiring low cognitive load and high repetition from humans. These tasks prove too dynamic for traditional automation — simple scripts won't suffice — but remain predictable enough for AI to handle reliably. They appear across businesses in data entry, research, qualification, and triage, where automation saves time and maintains quality consistency.

Vercel's implicit "build it now" filter

Vercel's methodology yields a clear decision framework:

The work must be verifiable. Checking whether the agent performed correctly requires no heroics.
The workflow must be step-wise and bounded. Think "five clicks and completion," not "develop a product strategy."
The task must be recurring and painful. People describe it as toil or suffering, not as valued work.
Inputs and outputs must be known. You understand exactly what enters the system and what constitutes good output.
A human must remain in the loop. The agent prepares work. A person approves, edits, or rejects it.

This filter produces a specific answer to "where to build agents right now": back-office flows, operational support, the tedious work nobody chose to do.

Vercel has not implemented Google's full orchestration platform. Almost nobody has. Their work demonstrates that building agents today means solving problems that reduce toil, solving problems that are verifiable, solving problems where inputs and outputs are known — and pursuing them relentlessly. The value is accessible.

Three questions to validate any use case

Three questions clarify any new agent use case.

Is this work verifiable and bounded? If checking the result proves difficult, it's probably not a first-wave agent application.
Is this work recurring toil? If people don't actively dislike it, or if it occurs infrequently, an agent is probably the wrong solution.
Do I know what orchestration guardrails belong around it? If you cannot answer "What tools? What data? What budget? What escalation path?", you're not ready to deploy this as an agent.

Three "yes" answers place it in the Vercel category: build it now, maintain human oversight, develop organizational capability. Any "no" answer places it in the Google category: potentially valuable later as part of a comprehensive agent architecture, but not something to pretend can be safely automated today.

Seven principles for agents that don't break

Principle 1: Pick a problem that actually matters

This sounds obvious, but it's where most people fail. When teams start with agents, they tend to pick use cases that aren't serious. The thinking goes something like: "This is new and experimental, I don't want to wreck anything important, so let me try something low-stakes first."

That approach is a trap. If you pick a problem that doesn't matter, you won't take it seriously. The rest of your organization won't take it seriously. You won't prioritize debugging it when things go wrong, and you won't care enough about whether the output is correct to build in the necessary quality checks.

You need to pick a problem where getting it right actually matters. Not recklessly high-stakes for your first build, but meaningful enough that you'll invest the time to make it work properly. This requires some courage. It also creates the right incentives. When the outcome matters, you design better systems.

Principle 2: Start with the outcome, not the input

Most people design agents from the beginning of the workflow. They start by thinking about what triggers the agent, what the input looks like, how to parse it. Those are important questions, but starting there leads to weak designs.

Successful agent builds start with the outcome. What do you want this agent to produce? What does "done" look like in concrete terms? And critically: how will you know it's correct?

The answer to that last question changes dramatically depending on your context. For marketing copy, correctness might mean checking reading level and doing a quick fact-check with another LLM. For healthcare operations where you're categorizing medical information, correctness means detailed audit trails, secure storage, and zero tolerance for errors.

Think obsessively about what correctness looks like before you build anything. Then work backwards from there. This discipline forces you to confront the hard questions early: What are the stakes here? What does verification look like? How do I prove this worked?

When you adopt this outcome-first mindset, something interesting happens. You get stubborn about keeping things simple.

Principle 3: Use the dumbest agent that can do the job

This is the most counterintuitive principle, and the one that makes the biggest difference in production.

Your instinct will be to use the most powerful model available. You'll want to juice up the reasoning power and have one smart agent handle the entire task. Resist this instinct completely.

In practice, dumb agents work better when they're fed the right context. What you're trying to achieve in a business setting is deterministic intelligence. You need predictability. And until we have true reasoning systems with zero hallucination risk, predictability comes from simplicity and clarity, not from raw cognitive power.

Hallucinations in a business context are more subtle than making things up. Yes, OpenAI is adding guardrails for egregious hallucinations, which helps. But those guardrails won't catch the cases where your agent follows the process correctly but makes a different choice because the prompt was ambiguous. That's not technically a hallucination. It's a business logic error caused by poor design.

You avoid these errors by dumbing everything down. Your prompt needs zero ambiguity. Your data sources need to be extremely structured and organized. And the model itself should be simple and rule-following. Turn down the reasoning power. Let the agent be predictable rather than clever.

Why? Because you'd rather have multiple simple agents doing individual tasks in sequence than one superintelligent agent trying to do everything at once. The simple agents give you audit trails. You can see exactly what each step did. You can troubleshoot when something breaks. You can verify that step three made the right choice because you designed the context specifically for that decision.

The smart agent doing everything at once? You can't audit it effectively. You can't see how it did the work. And there will be ambiguity that comes from trying to handle the whole task in one pass.

Is this more work to set up? Yes. But it's far less work to maintain, debug, and trust.

Principle 4: Design for clean context, not large context

One of the biggest mistakes is stuffing the context window with everything that might be relevant and hoping the agent figures it out. This fails in multiple ways.

First, it confuses the model. When you give an agent ambiguous instructions and a bloated context window with no clear signal about what matters, you get unpredictable results. The agent is trying to parse your ambiguous human language, and you're making its job harder by giving it too much to work with.

Second, it burns tokens unnecessarily. Agentic systems run at volume. If you're doing 100 blog posts a week or 1,000 health records a day, fat contexts add up fast. Every extra token costs money, and every piece of ambiguity requires more tokens to parse.

The solution is to be fanatical about context design for each step. What does this specific agent node need to know to make this specific decision? Give it exactly that information, structured clearly, and nothing more.

This connects directly to using simpler agents. When you break a workflow into discrete steps, you can design the perfect context for each step. The retrieval context for step one might look completely different from the context for step five, and that's good. Each agent gets exactly what it needs, formatted exactly how it needs it.

Principle 5: Be ruthlessly clear about tool choice

OpenAI's Agent Builder is launching with MCP (Model Context Protocol) as the connection layer for external tools. This is probably the widest release of MCP we've seen. The drag-and-drop simplicity means more people will be connecting more tools than ever before.

This creates a new failure mode: tool choice ambiguity.

Your agent needs a clean dictionary of available tools and crystal-clear guidance about when to use each one. Don't leave the LLM to figure out which tool to use based on vague instructions. It can choose between tools, but only with explicit guidance from you.

Think about it this way: during each run, the agent reads the retrieval context, reads your prompt, selects a tool, executes it, and returns a response. Tool selection happens in the middle of that chain. If your prompt is ambiguous about when to use Tool A versus Tool B, you'll get unpredictable behavior.

The practical advice here is to start with the smallest possible tool collection. When you see someone's impressive setup with 20 different MCP servers, resist the temptation to copy it. That's like giving a seven-year-old access to a full woodshop and trusting them to pick the right tool. They shouldn't have that choice yet.

Instead, give each agent the specific tools appropriate to its task. Make sure those tools are clearly differentiated and that your prompt explains unambiguously when to use each one. Then verify that when the agent picks a particular tool, you can see in the logs that it ran successfully.

This is another place where having multiple focused agents in a chain helps. You can see exactly which agent made which tool call, and you can debug tool selection problems at the specific step where they occur.

Principle 6: One meaningful goal beats 800 mediocre ones

There's a tension in what's being recommended. Pick a problem that matters, but don't bite off too much. These aren't contradictory.

Pick one goal that has real stakes and do it well. Don't try to solve 800 tasks across the business in your first agent build. Don't even try to solve eight.

Focus on one meaningful workflow. Build it properly using these principles. Make sure it works reliably. Then expand methodically.

The reason for this discipline is organizational, not technical. Agent building is about to become democratized in a way that custom GPTs never achieved. Custom GPTs are already somewhat chaotic in organizations — different teams with different conventions, no clear ownership, no way to manage them centrally.

Now imagine that same chaos, but for production workflows. Marketing has their own agent conventions that nobody else knows about. Product has a different approach. When Betty goes on vacation, nobody knows how to maintain her workflow because she's the only one who understands it. And you have no visibility into which MCP servers are being accessed by which agents across your environment.

This isn't sustainable.

The answer is to start with organizational standards before the chaos sets in. As a team, decide what your standards are for agent builds. Agree on principles. Establish what matters: using the simplest possible workflow, the cleanest possible context, the smallest necessary tool collection, prompts that have been vetted for ambiguity.

Build one high-quality example that demonstrates these principles. Then socialize it. Use it as the template for the next build. Create a culture where people care about building maintainable agents, not just agents that work once.

Principle 7: Ambiguous prompts create organizational vulnerabilities

This is the principle that ties everything together.

People load their prompts with adjectives and multiple meanings and then wonder why the agent doesn't behave predictably. They use words that have contextual interpretations. They give instructions that could be read in different ways depending on what the agent prioritizes.

The agents aren't magic. They're trying to parse human language that evolved for flexible social communication, not for deterministic task execution. When you give ambiguous instructions, you get ambiguous results.

This might seem like a minor technical issue, but it becomes an organizational vulnerability at scale. An insecure agent generating production workloads that nobody monitors, that nobody can maintain when the builder is out, creates real risk.

OpenAI's safety guardrails help. Prompt injection protection and content moderation are valuable. But they're not sufficient. It's the organization's job to design policies that actually scale. It's the team's job to establish conventions that work for everyone, not just individuals. And it's your job as a builder to create the most maintainable, auditable agent you can.

That means structured instructions with minimal ambiguity. It means clear definitions of what constitutes success at each step. It means thinking about the person who will need to debug this six months from now when you've moved to a different project.

choosing-an-ai-assistant — How to select the right AI platform for your work
prompting-frontier-models — How to write prompts that get reliable results from AI models