What you'll take away
The term 'AI agent' has become so broadly applied that it now describes both a customer service chatbot with a slightly longer system prompt and a fully autonomous system that books flights, manages calendars, and executes code. The confusion is not merely semantic — it has real engineering consequences. Teams that treat agent development as chatbot development with more tools end up with systems that behave unpredictably, fail in production, and erode user trust in ways that are hard to diagnose.
This post is about the architectural differences between a conversational AI system and a genuinely agentic one, the failure modes that are unique to agents, and the engineering discipline required to build agents that behave reliably in the real world.
The Defining Property of an Agent: Consequential Action
A chatbot's world is words. It takes text in, produces text out, and has no persistent effect on the world beyond the conversation. The worst thing a chatbot can do is produce a bad response. An agent's world includes the real world — APIs, databases, file systems, external services. It can send emails, execute trades, modify records, trigger workflows. The worst thing an agent can do is take an irreversible action based on a misunderstanding.
That distinction — between generating words and taking actions with real consequences — is what makes agent development a qualitatively different engineering discipline from chatbot development. The architecture must be designed around the constraint that mistakes can have downstream effects that are expensive or impossible to undo.
The Four Components of an Agentic Architecture
1. The Planner
The planner is the LLM making decisions about what to do next. In a simple ReAct agent, this is the same model for every step: observe, reason, act. In more sophisticated architectures, the planner is a separate orchestrator model that decomposes tasks, assigns sub-tasks to specialised sub-agents, and synthesises their outputs. The planner is where most of the interesting engineering decisions live: how much autonomy does it have? How does it handle ambiguity? When does it ask for human confirmation versus proceeding independently?
2. Tools
Tools are the functions the agent can call to affect the world. A well-designed tool interface is one of the most important architectural decisions in an agentic system. Each tool needs a clear, unambiguous description that the LLM can understand — not a description of what the function does in code, but a description of what calling it achieves in the world. 'Sends an email to the specified recipient with the specified subject and body' is a good tool description. 'Calls the sendEmail endpoint of the mail service API' is not.
3. Memory
Agents that need to operate across multiple sessions, or that need to reference information from earlier in a long task, require memory. The options are: in-context memory (expensive, limited by context window), episodic memory stored externally and retrieved via RAG (scalable but requires retrieval accuracy), and structured memory in a database or key-value store (fast but requires the agent to know what to store and retrieve). Most production agents need a combination.
4. The Execution Environment
The environment the agent operates in — the APIs it can call, the sandboxes it can execute code in, the data stores it can read and write — must be engineered with the assumption that the agent will sometimes do unexpected things. Every tool call should be logged, every state change should be auditable, every action that modifies external state should be reversible where possible, and irreversible actions should require explicit confirmation.
Is your AI ready for production?
48-hour turnaround. No obligation.
The Production Failure Modes Unique to Agents
- Cascading errors: An agent takes an action based on incorrect information from a previous step, and subsequent steps compound the error in ways that are hard to trace
- Tool misuse: The agent calls a tool correctly by API contract but incorrectly by intent — deleting a record that should have been archived, or sending a draft that should have been reviewed
- Infinite loops: The agent's planner gets stuck in a reasoning loop, taking the same actions repeatedly without making progress
- Prompt injection: A malicious document or external data source contains instructions that hijack the agent's behaviour when it processes the content
- Scope creep: Given broad permissions and an underspecified task, the agent takes reasonable but unintended actions that the user did not authorise
Engineering for Reliability: The Key Principles
Reliable agents are designed with the assumption that the LLM will sometimes make mistakes, and the architecture absorbs those mistakes before they propagate into irreversible actions. The principles that define reliable agent architecture:
- Minimal footprint: Request only the permissions the agent needs for the current task. Don't give an agent write access to a database if it only needs to read from it
- Confirmation gates: For high-consequence actions, require explicit human confirmation before execution, even if it interrupts autonomy
- Reversibility preference: Design tools to prefer reversible operations — archive over delete, draft over send, stage over deploy
- Step-by-step logging: Every reasoning step and tool call should be logged with enough context to reconstruct what the agent was trying to do when something went wrong
- Bounded autonomy: Define the scope of what the agent can do autonomously and enforce it in the execution environment, not just in the prompt
Where Most Enterprise Agentic Projects Go Wrong
The most common failure mode we see in enterprise agent projects is treating the planner prompt as the primary safety mechanism. Teams build a capable agent, add a system prompt that says 'always ask before deleting anything,' and consider the safety problem solved. It isn't. LLMs do not reliably follow instructions under all conditions — especially when the instruction conflicts with completing a task the model has been rewarded for completing.
Safety in agentic systems is an engineering property, not a prompting property. Confirmation gates are enforced at the tool level, not in the prompt. Permissions are scoped at the environment level, not in the instructions. Reversibility is built into the API design, not mentioned in the system prompt. Teams that conflate 'I told it not to' with 'it won't' are building agents that will eventually cause expensive incidents.
GYSP's AI & ML Development practice has designed and deployed production agentic systems for enterprise clients in finance, legal, and operations. The architecture patterns we've developed are grounded in operational experience with the failure modes that matter most — and with the trust deficit that forms when an agent does something unexpected once and the business refuses to grant it autonomy again.
“The question that determines whether an agent project succeeds is not 'can we make it capable?' — modern LLMs provide that. It's 'can we make it trustworthy?' That's an engineering question, not a model question.”
— Rahul, AI/ML Delivery Head — GYSP.tech
Frequently Asked Questions
What is the architectural difference between a chatbot and an AI agent?+
A chatbot generates text responses based on conversation context. An AI agent additionally has tools (web search, code execution, database queries, API calls), planning capabilities (breaking goals into steps), and memory (persisting information across interactions). The key difference is agency: an agent takes actions with real-world effects, not just produces text.
What are the most common failure modes in production agentic AI systems?+
The most common failures are: tool call failures without proper error handling causing cascading task failures; context window overflow in long-running tasks; prompt injection through retrieved external content; infinite loops when agents retry failed actions without exit conditions; and cost overruns when agents make more LLM calls than expected. Observability is essential for diagnosing these failures.
How do you implement reliable memory for AI agents?+
Agent memory should be implemented in tiers: working memory (current task context in the prompt), episodic memory (recent conversation or session history in a short-term store), and semantic memory (distilled knowledge in a vector store or knowledge graph). Long-term memory requires explicit summarisation or consolidation strategies to prevent context pollution and storage growth.
What is the right architecture for a multi-step agentic workflow?+
Multi-step agentic workflows should use an orchestrator-worker pattern: a planning agent decomposes the goal into sub-tasks, specialist worker agents execute each sub-task using scoped tool access, and the orchestrator validates results before proceeding. Each agent should have minimum tool access, explicit error handling, and structured output validation to prevent cascading failures.
