Agent, chatbot or workflow? Where an AI agent pays off for an SMB, where it fails, which guardrails you need, and a 6-week pilot with a cost estimate.
6-week agent pilot
One closed-ended process reachable via API. A 30-50 example eval set with a numeric success criterion.
The same task as a deterministic workflow (n8n). This is the benchmark, not the manual process.
Tool use, step and cost limits, human approval for irreversible actions.
Task success rate, cost per task, intervention rate. Go: ≥85% success and cheaper than the workflow.
In 2026, "AI agent" is the most misunderstood term in SMB requests for proposals. Three different things go by the name: the chatbot that answers, the workflow that happens to include an LLM step, and the actual agent that decides for itself which tool to call and when to stop. The gap between the three is an order of magnitude in cost, in risk, and in what you can actually achieve.
This article is about the third category, but it does so by drawing a precise line against the other two. The question is not "do we need an agent," but which process is worth the added cost and risk of open-ended decision-making, and which is better served by a deterministic workflow with a single LLM call.
What we describe here comes from our own projects and from the experience of our partner network: customer-support, back-office and data-collection agents running in production, and others we shut down after the pilot because a workflow turned out to be cheaper and more reliable. The numbers are orders of magnitude, not benchmark results; the value measured on your own eval set is the only one that matters.
At the end of the article you'll find a 6-week pilot plan and a cost estimate you can run against your own process to reach a go/no-go decision. If you're interested in the general questions of AI adoption (maturity, use cases, ROI), we covered those in AI implementation for Hungarian SMBs in 2026; this article picks up where that one left off.
The three concepts are not levels of one another but distinct architectures. The choice isn't about "how modern" something is, but "how many decisions we hand to the model."
| Aspect | Chatbot | Workflow + LLM step | Agent |
|---|---|---|---|
| Who decides the next step? | There is no next step | The developer, in advance | The model, at runtime |
| Tool use | None, or 1 fixed | In a fixed order | Model chooses, repeatedly |
| Number of steps | 1 | Fixed (e.g. 4) | Variable (2–30) |
| Deterministic? | Partly | Yes, the structure | No |
| Typical cost per task | 1–5 HUF | 5–30 HUF | 30–500 HUF |
| Error handling | Re-prompts | Retry / fallback branch | Self-correction, but errors accumulate |
One input, one output. A RAG chatbot belongs here too: it searches, then answers, but it doesn't set anything in motion out in the world. Its risk is low because it doesn't act.
The developer draws the graph of the process: a form arrives → the LLM categorises it → a record is written to the CRM → an email draft is produced. The LLM is one or two nodes in the graph; the rest is deterministic. n8n, Zapier and Make all support this model, and in 2026 roughly 70–80% of SMB AI projects look like this. The lead-assistant case study is also a workflow, not an agent.
The model is given a goal and a set of tools, then decides in a loop: which tool to call, what to do with the result, whether the task is complete. The loop runs until the model signals "done" or hits the step limit. The value lies in not having to map out every branch in advance; the risk lies in the model choosing the wrong branch.
Note: If the steps of the process can be listed in advance, build a workflow. An agent is justified when the order or number of steps depends on the input and it isn't worth coding that out beforehand.
The technical core of an agent is tool use (function calling): the model doesn't write text, it returns a structured call that your code executes, then feeds the result back to the model. That's the loop.
# Simplified agent loop (Anthropic Messages API, Python)
tools = [
{
"name": "get_order",
"description": "Fetch an order from the ERP by order number.",
"input_schema": {
"type": "object",
"properties": {"order_id": {"type": "string"}},
"required": ["order_id"],
},
},
{
"name": "create_credit_note",
"description": "Create a credit note. IRREVERSIBLE — only after approval.",
"input_schema": {
"type": "object",
"properties": {
"order_id": {"type": "string"},
"amount_huf": {"type": "integer"},
"reason": {"type": "string"},
},
"required": ["order_id", "amount_huf", "reason"],
},
},
]
messages = [{"role": "user", "content": ticket_text}]
for step in range(MAX_STEPS): # step limit: guardrail #1
response = client.messages.create(
model=MODEL, max_tokens=1024, system=SYSTEM_PROMPT,
tools=tools, messages=messages,
)
if response.stop_reason != "tool_use":
break # the model is done
for block in response.content:
if block.type == "tool_use":
result = dispatch(block.name, block.input) # your code, with your own validation
messages.append({"role": "assistant", "content": response.content})
messages.append({"role": "user", "content": [
{"type": "tool_result", "tool_use_id": block.id, "content": result}
]})
The dispatch function is yours. Everything is decided here: this is where you validate, where you request human approval, where you log. The model only proposes a call; whether you execute it is your decision.
The Model Context Protocol (MCP) solves the problem of having to write the CRM, ERP or file-system connection separately for every agent. An MCP server describes the tools once (name, description, schema), and any MCP-capable client can use them. In 2026, the clients of the major model providers and the widely used agent frameworks all support it.
The practical benefit of MCP for an SMB: if you already have an internal MCP server for orders, the next agent (or a developer's own assistant) uses the same one — no re-integration. The downside: an MCP server is as much an attack surface as any REST API, and access control is on you to handle.
Three areas where agents running in production in 2026 deliver measurable savings. All three share the same conditions: the tools are reachable via API, the end of the task is clearly recognisable, and a faulty step is either reversible or gated behind approval.
The classic chatbot answers; the agent resolves the ticket. "Where's my order?" → it fetches the order, pulls the status from the carrier's API, writes the reply, and if the parcel has been stuck for 3 days, it puts a compensation proposal up for approval.
Typical result: 35–50% of tickets close without human involvement, and for the rest the agent hands the operator a finished summary and a suggested reply. Our e-commerce AI chatbot case study is the first phase of this; the agent layer is the second.
Precondition: order, shipping and billing data are reachable via API. If they live in Excel, integration comes first, the agent after.
Example: a supplier invoice arrives, the agent finds the matching purchase order, compares the line items, drafts an email to the supplier if there's a discrepancy, and forwards it to accounting if it matches. The number of steps depends on the complexity of the invoice, which is why an agent model works better here than a fixed workflow.
Typical result: 1–3 hours saved per day per back-office employee, and a 60–80% drop in mismatched pairings. We're writing a separate article on the document-processing layer; the foundations are described under our AI automation service.
Gathering competitor prices, tender notices and supplier data sheets into a structured form. The agent browses, extracts, checks, writes to a table. The value isn't the individual query but the fact that 4–6 hours of manual collection per week becomes 20 minutes of review.
Precondition: a human reviews the result before it's used. A data-collection agent can make mistakes, but the mistake is cheap as long as it doesn't feed directly into a decision.
The failures in our pilots trace back to four causes. These aren't the model's faults but a poor match between the task and the agent model.
"Decide whether we should give this customer a discount." There's no eval set for this, no clearly correct answer, and the model will confidently decide wrong. An agent is good at execution, not at business judgement. The human makes the decision; the agent does the 8 steps that follow it.
If the tool is a website that has to be "clicked," or an Excel file sent by email, the agent will be slow, expensive and brittle. A 2026 browser agent takes 20–40 steps to fill in a form that an API call handles in one. Integration first, agent second.
If a single step is correct 95% of the time, a 10-step agent run will be fully correct only 60% of the time (0.95¹⁰ ≈ 0.60). That's why every step must be verifiable, and a faulty step must not corrupt the next. The eval methods described in defending against LLM hallucinations apply here on a per-step basis.
An agent that can't find an answer tends to try again and again. Without a step limit, a ticket that should cost 200–400 HUF can run to 5,000 HUF, and if that happens across 300 tickets a day, the monthly bill grows by an order of magnitude. The limit isn't optional — it's a baseline requirement.
Warning: If a vendor offers an "autonomous agent" for irreversible actions (payment, deletion, signing contracts) without human approval, ask for the eval set and the intervention rate. If they don't have one, the system isn't ready for production use.
A guardrail isn't a line in a prompt ("be careful") but the code and process around the dispatch layer. Five layers we implement in every production agent of ours:
| Layer | What it protects | How |
|---|---|---|
| Step and token limit | Cost, infinite loops | MAX_STEPS 10–25, a task-level token budget |
| Tool permissions | Unauthorised actions | The agent gets only the tools the task needs; read and write are separate |
| Human-in-the-loop | Irreversible actions | Approval queue: payment, deletion, external communication |
| Input filtering | Prompt injection from the ticket or email | We treat tool results as data, not instructions; we filter injected instruction patterns |
| Logging and replay | Audit, debugging | Every step (prompt, tool call, result, cost) in a trace; any run can be replayed |
// Human-in-the-loop guardrail in the dispatch layer (TypeScript)
const IRREVERSIBLE = new Set(['create_credit_note', 'send_email', 'delete_record']);
async function dispatch(name: string, input: unknown, ctx: RunContext) {
ctx.steps += 1;
if (ctx.steps > ctx.maxSteps) throw new AgentHalt('step-limit');
if (ctx.costHuf > ctx.budgetHuf) throw new AgentHalt('budget');
const tool = registry.get(name);
const args = tool.schema.parse(input); // schema validation, we don't trust the model
if (IRREVERSIBLE.has(name)) {
const approval = await approvals.request({ runId: ctx.runId, tool: name, args });
if (approval.status !== 'approved') return { status: 'pending-approval' };
}
const result = await tool.execute(args, ctx);
await trace.record({ runId: ctx.runId, step: ctx.steps, name, args, result });
return result;
}
In practice the approval queue is a Slack message or an internal admin screen with an "Approve / Reject" button. The goal isn't for a human to review every step, but to make sure the 3–5% of irreversible steps never run without a check.
The goal of the pilot isn't "does it work" but "is it worth it compared to a workflow." That's why the benchmark isn't manual work but a deterministic workflow for the same task.
| Week | Task | Output |
|---|---|---|
| 1 | Task selection, eval set | 30–50 real cases with expected output; success criterion as a number |
| 2 | Workflow baseline | An n8n or code-based workflow run against the eval set; success rate + cost per task |
| 3 | Agent v1 | Tools, system prompt, step limit; first run against the eval set |
| 4 | Guardrails + HITL | Approval queue, permissions, trace; per-step error analysis |
| 5 | Shadow mode | Runs on live input but doesn't act; a human compares the proposal against reality |
| 6 | Decision | Success rate, cost per task, intervention rate; go / no-go / back to the workflow |
If the workflow delivers 90% and the agent 88% at triple the cost, the answer is the workflow. That's not a failure but the most valuable result of the pilot: it became clear in 6 weeks, not in 6 months.
There are two costs: building and running. For both, the order of magnitude is what matters, not the exact figure; your own process data overrides these.
| Item | Order of magnitude (net HUF) | Note |
|---|---|---|
| 6-week pilot (the plan above) | 1.2–2.5M | Includes the workflow baseline |
| Production rollout after the pilot | 1.5–4M | The number of integrations decides |
| Integration for a missing API | 0.3–1M / system | If the ERP/CRM offers no API |
| Approval interface | 0.3–0.8M | Slack-based is cheaper, an admin UI more expensive |
Example: customer-support agent, 200 tickets a day
LLM cost per ticket (2026 Q3 order of magnitude, mid-tier model):
average 6 steps × ~4,000 tokens = ~24,000 tokens → 40–120 HUF per ticket
200 tickets × 22 days × 80 HUF = ~350,000 HUF / month
Infra (trace, queue, hosting): 30–60,000 HUF / month
Oversight, prompt and eval maintenance: 100–200,000 HUF / month
Total: ~500–600,000 HUF / month
Savings:
200 tickets × 40% auto-close × 6 min = 480 min = 8 hours / day
8 hours × 22 days × 6,000 HUF (loaded hourly rate) = ~1,050,000 HUF / month
Net: ~450–550,000 HUF / month; the 3M HUF rollout pays back in 6–7 months.
The calculation is sensitive to two factors: the auto-close rate and the number of steps. If auto-close is 25%, payback stretches to a year; if the step count grows to 15 without a limit, LLM cost doubles. That's why the pilot measures both before anyone decides on a rollout.
Tip: Always measure agent cost at the task level (HUF per closed ticket), not at the token level. The token price falls every year, but the step count depends on your prompt and guardrails; the latter is what you can influence.
When the number or order of steps in the process depends on the input, the tools are reachable via API, and a faulty step is reversible or can be gated behind approval. If the steps can be listed in advance, a deterministic workflow is cheaper and more reliable.
A well-structured pilot gives a numeric answer in 6 weeks: success rate on the eval set, cost per task, and intervention rate during the shadow week. Those three numbers are what you need for the decision — not the demo.
Yes, provided the agent gets only the tools the task requires, read and write are separate permissions, irreversible actions are gated behind human approval, and every step is logged. Without permission scoping and an approval queue, we don't recommend it.
A customer-support agent handling 200 tickets a day runs at a 2026 order of magnitude of 500–600 thousand HUF per month (LLM cost, infra and oversight combined), and pays back in 6–7 months if 40% of tickets close without human involvement. Your own figure depends on the auto-close rate and step count measured in the pilot.
In 2026 the AI agent is neither hype nor a silver bullet: it's an architecture that, for certain processes, is cheaper and more flexible than a fixed workflow, and for others is more expensive and more brittle. The difference isn't decided by the technology but by the nature of the task: tools reachable via API, a closed-ended goal, reversible or approvable steps.
Failures almost always come from the same place: an open-ended business decision is handed to the model, a missing API is bridged with an agent, or there's no step and cost limit. All of these surface in the first two weeks of the pilot, provided the eval set and the workflow baseline are in place.
The practical order: pick a process, build it as a workflow, measure it, then try it as an agent on the same eval set. If the agent is better or cheaper, there's something to roll out. If not, you've saved yourself a six-month project in 6 weeks.
Related articles: AI implementation for Hungarian SMBs in 2026, defending against LLM hallucinations, n8n vs Zapier vs Make.
If you have a process you'd like to decide between workflow and agent, book a 30-minute call: we'll go through the tools, the data and the risks, and tell you which direction is worth taking. If it's an agent, the 6-week pilot above is the starting point.
About the author
Corevanix Kft.
Technology partner
Budapest-based technology partner — SAP/ERP integration, web development, AI automation and mobile app development. We work inside the client’s own environment, and the delivered code belongs entirely to the client.
Legal basis, a DPA with the AI provider, EU data residency, pseudonymisation, retention and training opt-out, the balancing test, the AI Act and a checklist.
Prompts are code: repo, versioning, review, template structure, few-shot examples, eval sets, regression tests, injection defence, cost and observability.
OCR + LLM pipeline, JSON-schema extraction, validation with human-in-the-loop, SAP/ERP integration, error-rate tracking and ROI for invoices and contracts.