AI agents at work in 2026: what actually works and what comes next

AI agents earn their keep in 2026, but only inside clear boundaries. Give an agent a well-defined workflow, the right tools, and a human sign-off on anything with side effects, and it will do useful work every day; ask it to run unsupervised for hours and it will still disappoint. The honest position this year sits between the hype and the dismissal: agents are dependable junior colleagues, not autonomous employees.

How did we get from chatbots to agents?

The chatbots of the mid-2010s were decision trees wearing a conversational costume. They matched a visitor's message to a scripted intent, "track my order" or "reset my password", and broke the moment anyone phrased a question sideways. They could not read a document, call a system, or admit uncertainty gracefully. Most organisations that deployed one quietly retired it.

Large language models changed the texture of the interaction, and the early 2020s belonged to copilots: autocomplete in the code editor, a drafting assistant in the document, a chat panel beside the spreadsheet. The copilot pattern kept the human firmly in the driver's seat. The model suggested; the person accepted, edited, or ignored. That division of labour was the point, and it is why copilots spread so quickly with so little damage.

The agent era, which took hold through 2024 and 2025, added the missing capability: tool use. A modern agent does not just generate text. It plans, calls a tool such as a search, a database query, a ticketing API or a code interpreter, reads what came back, and decides what to do next. That loop of act, observe, adjust is what separates an agent from a very fluent form-letter machine, and it is why agents can finish tasks rather than merely start them.

What do agents genuinely do well in 2026, and where do they still fail?

Where they deliver

Four categories of work have crossed from demo to dependable. Drafting: give an agent your source material, briefs, transcripts and past examples, and it produces first drafts of proposals, summaries and correspondence that need editing, not rewriting. Research and synthesis: an agent that can search, read and compare across dozens of documents will assemble a briefing faster than a person, provided a person checks the citations. Coding assistance: writing functions against a spec, generating tests, reviewing a change for obvious defects. This is now routine practice in serious engineering teams, including ours. Structured workflows with approvals: triaging inbound requests, extracting data from documents into systems, assembling recurring reports. This works anywhere the steps can be written down and a human signs off before anything irreversible happens.

Where they still fall short

Long-horizon autonomy remains the honest weakness. Small errors compound over many steps, and an agent that is impressively right for twenty minutes can be confidently wrong by the end of the hour, without flagging the difference. Unsupervised actions with side effects, such as sending the email, changing the record or issuing the refund, are where agent projects go wrong in ways that reach customers. Ambiguous goals produce plausible busywork rather than a request for clarification. And anything that depends on unwritten organisational context, such as who actually decides or which client is sensitive right now, is still a human's job, because that context lives in people, not in any system an agent can query.

What is MCP, and why does it matter to your integration plans?

The Model Context Protocol is an open standard, introduced by Anthropic in late 2024 and since adopted broadly across the industry, for connecting AI applications to tools and data. Before it, every agent-to-system connection was a bespoke build: one connector for this model and that CRM, another for that model and this database, each with its own authentication quirks and failure modes. MCP replaces that with a common shape: a server exposes tools and resources, an agent application consumes them, and a connector is written once and works across compliant clients.

For a mid-sized organisation the practical consequences are threefold. First, integration effort stops multiplying: expose your systems through MCP servers and any capable agent can use them. Second, you are far less locked in: the model behind the agent becomes swappable without rebuilding every connection. Third, and most usefully, MCP gives you a single control point: the tools you expose define what an agent can ever do, which makes permissioning and auditing a design decision rather than an afterthought. When we build agent systems within our AI development practice, the MCP tool surface is one of the first things we design, because it is effectively the agent's job description.

What does an agent actually cost?

Not the model. API usage is real money, but for most workflows it is the smallest line in the budget. The expensive part, the part that separates a working agent from an impressive demo, is everything around the model.

Evaluation sets come first. An evaluation set is a collection of real, representative cases with known good outcomes: the awkward supplier email, the malformed invoice, the request that should be escalated rather than answered. Every change to the prompt, the tools or the underlying model gets run against that set before it ships, the same way a test suite protects software. Building one takes genuine effort from the people who know the work, and it is the single best predictor we see of whether an agent project survives contact with reality.

An agent without an evaluation set is an opinion with an API bill.

Guardrails come second: scoped permissions on every tool, approval gates on side effects, logs of every action an agent took and why, rate limits, and sandboxes for anything experimental. None of this is exotic: it is the same discipline covered in our security and compliance approach, applied to a new kind of software component. Budget for evaluation and guardrails as the majority of the build, because that is what they are.

How should a mid-sized organisation adopt agents this year?

Slowly, deliberately, and one workflow at a time. The pattern that works in practice:

1. Pick one workflow. Frequent enough to matter, describable as written steps, measurable before you start. Invoice intake, inbound enquiry triage and first-draft reporting are common, sensible first choices.
2. Keep a human approval on every side effect. The agent drafts, gathers, and proposes; a person clicks send. This one rule converts most catastrophic failure modes into minor editing work.
3. Build the evaluation set before launch, not after. Twenty to fifty real cases with agreed correct outcomes is a workable start, grown from production as edge cases appear.
4. Measure honestly. Time from request to completion, correction rate, and how often the human overrides the agent. If the override rate is not falling after the first month of tuning, the workflow was the wrong pick: choose again without shame.
5. Expand only after it holds. A second workflow inherits the plumbing, the guardrail patterns and the habits from the first. That is where the economics turn favourable.

What to avoid is equally clear: the organisation-wide "AI transformation" that starts everywhere and finishes nowhere, and the unsupervised agent granted production access on day one because the demo looked convincing.

What should you expect next?

Two directions are worth planning around, stated as direction rather than promise. Computer-use agents, which operate software through the screen the way a person does, clicking and typing rather than calling an API, improved markedly through 2025 and 2026. They matter because so much business software has no API worth the name. Today they are best treated as promising for internal, supervised tasks and not yet dependable enough for anything customer-facing.

Multi-agent systems, where an orchestrating agent delegates to specialists and the results are checked and combined, are moving from research pattern to engineering practice, particularly in code review and large research tasks. They add real coordination overhead and are not a default choice; a single well-scoped agent beats an elaborate committee for most workflows. We track both areas, along with the wider tooling landscape, in our technology radar.

How OlDevs builds agents that hold up

OlDevs has built software from Vancouver since 2014, and we treat agent projects as software projects: scoped, tested, measured, owned. Our AI Automation & Agents work starts with the workflow and the evaluation set, not the model; we design the MCP tool surface deliberately, keep human approval on side effects from day one, and instrument everything so you can see what the agent did and why. You get one accountable team, a working demo every week, the same rhythm described in how we work, and, when the project ends, you own all of it: code, prompts, evaluation sets, accounts and IP.

If there is a workflow in your organisation that fits the shape described here, frequent, describable and measurable, we can tell you within a conversation whether an agent is the right tool for it, and what the build would involve. Request a quote and we will reply within one business day.