The era of the basic AI chatbot is ending. For three years the default way to "add AI" to a product was a conversational box: a user typed a question, the model summarised a document or drafted an email, and a human did the rest. That was useful, but passive. Agentic engineering changes the job. The model stops generating text and starts taking action: deciding which tool to call, validating the input, and executing a real workflow on your behalf.
Key takeaways
- A chatbot generates text; an agent takes action through a defined set of tools it is allowed to call.
- The Model Context Protocol (MCP) gives a model validated, audited operations instead of free-form access to your systems.
- Production agents need three things: strict data boundaries, validated schemas, and human approval gates for anything destructive.
- The hard problem has moved from prompt engineering to system orchestration.
- The difference between a demo and a product is discipline, not model sophistication.
How is an agent different from a chatbot?
A chatbot is a model in isolation, fenced off from your systems. An agent is the same model wired into them through a controlled interface. The chatbot answers; the agent acts.
That interface is the whole game. Instead of asking a model to "write an email," an agent is given a send_email tool with a fixed signature, calls it with validated arguments, and the email actually goes out. The model becomes the part that decides. The tools are the part that does.
What does the Model Context Protocol actually do?
MCP gives a model a defined set of tools and a strict contract for using them. Rather than handing the model your database, you expose a narrow server: it can query a Postgres table, update a CRM record, or trigger a deployment, but only through endpoints you have explicitly published, with every input validated before anything runs.
Simon Willison and others tracking this space keep making the same point: the hard problem moved from prompt engineering to system orchestration. Getting a model to produce plausible text is no longer the bottleneck. Getting it to take the right action, safely, every time, is.
What does a production-grade agent require?
Three requirements are non-negotiable. Skip any one and you have a demo, not a system.
- Strict data boundaries. The model never gets unrestricted access to a production database. It talks to an MCP server that exposes a narrow, audited set of operations, with authentication carried through on every call. It can read shipment status. It cannot run arbitrary SQL.
- Validated schemas. Every action the model proposes is checked against a strict schema before it executes. Models are non-deterministic and will occasionally generate a malformed or out-of-bounds call. The schema is the deterministic gate that catches it.
- Human approval gates. Reading and gathering are automated. Decisions that change state, issuing a refund, deleting a record, moving money, require explicit human confirmation. The agent prepares the action; a person approves it.
Why do most "agents" still fail in production?
Because teams ship the happy path and skip the boundaries. A model that works in a demo will, given enough real traffic, eventually call the wrong tool, return confidently wrong data, or try to act beyond its authority. Without a schema to reject the bad call and a human to catch the risky one, that failure reaches a customer.
The fix is not a better prompt. It is an architecture where the unsafe action is impossible by construction, not merely unlikely.
What does an agent actually look like in production?
The shape is consistent across the agents we ship at Systemartis. A model sits behind an orchestrator that owns routing, retries, and the human checkpoints. Tools are exposed through MCP servers that validate and log every call. State lives in a real backend, not in the model's context window.
When something goes wrong, the audit trail shows exactly which tool was called, with what input, and what came back. That is what makes the system trustworthy. "The AI did it" is not an answer anyone can act on. "The agent called update_shipment with this payload at this time, and here is the response" is.
Stop building wrappers
The next generation of software will not be judged on how well it chats, but on how reliably it works without supervision. A thin wrapper around a chat-completion endpoint is not that. An agent with real tools, hard boundaries, validated calls, and a human holding the keys to anything destructive is.
The chatbot was a useful demo. The agent is the product.