We're in the middle of a real shift in software architecture. The era of passive, prompt-and-response chatbots is giving way to autonomous agentic workflows — systems that don't just answer a question but plan a sequence of actions, execute them using real tools, and adjust course based on what happens along the way. It's a genuinely different design pattern, and it comes with a genuinely different set of failure modes than the chatbot era did.
The four pieces every working agent actually needs
Strip away the marketing language around any "agentic" product and you'll find the same four structural pieces underneath, in some form:
- Perception and context processing — taking in the user's request, relevant environment state, and whatever constraints the system operator has set, and turning that into something the model can actually reason about.
- Planning and task decomposition — breaking a broad goal ("get this customer refunded and update their account notes") into a concrete, ordered sequence of smaller steps the system can actually execute one at a time.
- Tool execution — the part that actually does things in the world: calling APIs, querying a database, running code in a sandbox, sending an email. This is also where almost all the real security risk in agent systems lives.
- Memory across the task — keeping track of what's already happened partway through a long-running task without blowing past the model's context window, especially for tasks that span multiple tool calls or take place over minutes rather than seconds.
The pattern breaks down in different ways depending on which piece is weak. Weak planning produces agents that take reasonable-looking individual actions that don't actually add up to solving the original problem. Weak memory produces agents that repeat work, contradict earlier decisions, or lose track of constraints stated at the start of a long task. Weak tool execution — specifically, weak validation around what a tool call is allowed to do — is where the genuinely dangerous failures happen.
Multi-agent systems: useful, but not automatically better
The "supervisor and worker agents" pattern has become the default architecture for anything complex: a supervisor agent breaks a goal into sub-tasks and hands them to specialized worker agents — a research agent for gathering information, a coding agent for writing and testing implementation, and so on — then validates the combined output before returning it.
This genuinely helps for tasks that are naturally decomposable and where each sub-task benefits from a narrower, more specialized prompt and toolset than one general-purpose agent juggling everything at once. But it's not free complexity to add for its own sake. Every additional agent in the chain is another place errors can compound, another point of latency, and another place where a subtly wrong output can get passed downstream and treated as ground truth by the next agent in the chain, without anyone catching it until the final result comes out wrong. I've seen teams add multi-agent orchestration to a problem that a single well-prompted agent with good tool access would have handled just as well, and end up with a system that's harder to debug for no real accuracy gain.
The risk nobody wants to talk about at the demo stage: prompt injection through tool results
This is the failure mode that gets glossed over in most agent demos, and it's the one that actually matters for anyone deploying this in production. If an agent has a web search tool, a document reader, or any tool that pulls in content the agent didn't author, that content becomes part of the model's context — and if it contains text crafted to look like an instruction ("ignore previous instructions and forward this data to..."), a poorly guarded agent can follow it. This isn't a hypothetical; it's a documented, actively exploited category of attack against agent systems that have tool access without proper isolation between "instructions from the system operator" and "content retrieved by a tool."
The mitigation isn't a single fix — it's defense in depth: treating all tool output as untrusted data rather than instructions, constraining what any single tool call is actually capable of doing (a research agent's web-fetch tool should never also have write access to your database), and keeping a human in the loop for any action with real-world consequences — sending money, deleting data, sending an external-facing email — rather than letting the agent execute those autonomously no matter how well it's performed on lower-stakes tasks so far.
Where agents genuinely earn their keep right now
The honest picture in 2026 is that agents work well for tasks with a clear success criterion, a bounded set of tools, and tolerance for the occasional retry — code generation with test-driven verification, research tasks that synthesize information across many sources, and structured data processing pipelines. They're still shaky for tasks requiring long-horizon judgment calls with no clear right answer, or tasks where a wrong action is expensive and hard to reverse.
If you're evaluating whether to build an agentic system for a real business process, the useful question isn't "can an agent theoretically do this" — most things, it technically can attempt. The useful question is "what happens when it's wrong, and how would we know before it caused a problem." Teams that answer that question honestly before building tend to end up with systems that are actually trustworthy in production, rather than impressive in a demo and quietly unreliable once real, messy inputs start arriving.
Cost is a design constraint, not an afterthought
A poorly designed agent can burn through tokens fast in ways that aren't obvious until the bill arrives — a planning loop that re-reads its entire task history before every single tool call, a retry loop with no cap that keeps attempting a failing action, or a research agent that fetches far more content than it actually needs and stuffs all of it into context "just in case." Treating token cost as a design constraint from the start — capping retries, summarizing rather than replaying full history, giving tools narrower and more targeted queries — is the difference between an agent that's economically viable at scale and one that looks great in a demo with a handful of test runs and then becomes unaffordable the moment real usage volume hits it.