AI agent vs API integration: which do I actually need?

The wrong choice costs months

The technical decision feels minor — call an LLM API once vs. build an autonomous agent. The product implications are huge: one ships in two weeks, the other in 28 days; one costs cents per use, the other dollars; one fails predictably, the other fails creatively.

This post is the decision framework we use during discovery to pick the right path before architecture starts.

What "AI integration" actually means

An AI integration is a one-shot LLM call: input goes in, output comes out, the system returns. Think:

• Summarize this support ticket
• Generate a product description from these fields
• Classify this email as urgent / not urgent
• Draft a response, human reviews and sends

The LLM is a function in your existing system. It doesn't take actions. It doesn't access tools. It returns text (or JSON), and your code does the rest.

What an "AI agent" actually means

An AI agent is an autonomous system: it has goals, it has tools (database, APIs, functions), and it iterates. Think:

• Customer support agent that reads the ticket, queries the order database, checks the policy, drafts a refund, and emails the customer
• KYC agent that reads the application, validates against sanctions lists, requests missing documents, and drafts an approval/rejection memo
• Code review agent that reads the PR, checks the conventions, runs the tests, and posts comments

The LLM is the brain of a system that has hands. It takes actions. It can call tools multiple times. It can change its mind based on what tools return.

Five questions to choose between them

1. Does the user need a single response or a sequence of actions?

• "Generate a draft email" → integration
• "Handle this support case" → agent

2. Does the system need to read or write to other systems mid-task?

• "Just transform this text" → integration
• "Look up the customer's order, check return eligibility, issue refund" → agent

3. Is the path predictable or does it vary by input?

• "Always summarize, always 3 bullet points" → integration
• "Sometimes refund, sometimes ask follow-up question, sometimes escalate" → agent

4. Does it need to recover from errors mid-task?

• "If it fails, return error, user retries" → integration
• "If the API call fails, try a different approach, ask the user, or escalate" → agent

5. Will a human review every output?

• "Always reviewed before sending" → integration is enough, often
• "Operates autonomously most of the time" → agent

If you answered "agent" to two or more, you need an agent. If you answered "integration" to all five, you don't.

The cost difference

A single integration call: 1 LLM request. Cost: $0.001–$0.05 per use.

An agent: 5–20 LLM requests per task (planning, tool calls, evaluation). Cost: $0.05–$1.00 per use.

This matters if you're running 10,000 of these per day. At 100/day it doesn't matter at all.

The build complexity difference

An integration takes 1–2 weeks to ship to production. The architecture is: API call → response handling → store result.

An agent takes 4 weeks because the architecture is: tool definitions, planner, executor, retry logic, observability, guardrails, escalation paths, memory store, audit logs.

This is why "we'll just add AI" projects often blow up — the team estimated for an integration but built an agent.

When founders pick wrong

Most commonly: building an agent when an integration would do.

Real example: a fintech founder wanted "an AI that helps customers with billing questions." Sounds like an agent. But 90% of billing questions can be answered from the FAQ + the customer's last invoice. We built an integration: pulls last invoice, retrieves relevant FAQ, drafts a response. Total cost to build: 12 days. Cost to operate: $0.02 per question. The agent version we sketched would have been 28 days and $0.40 per question — and not measurably better in CSAT.

The other direction (building an integration when an agent is needed) is rarer because it's usually obvious — the user explicitly says "and then it should also do X, and then Y."

The hybrid pattern

Many real systems are: integration in the front, agent in the back. The customer-facing surface is a fast, cheap, predictable integration. When the integration can't handle a case, it escalates to a slower, smarter agent. This pattern is almost always cheaper than running every interaction through the agent.

How we decide during discovery

During Phase 1 (Inference, Days 1–3) of the 28-Day MVP, we run through the 5 questions above with you. The answer goes into the architecture artifact as an explicit decision: "This is an integration because…" or "This is an agent because…". That decision becomes binding for the engagement.

If you're unsure, default to integration. You can always wrap an agent around it later. Going the other direction (replacing an agent with a simpler integration) is much harder.

Get the architecture artifact template and the full discovery question list in the 28-Day AI MVP Playbook.