Agentic AI for business: how I build AI agents that actually ship
Agents are not a digital workforce. They are software that takes one real task off someone's desk — with narrow tools, tight permissions, full logs and a human where it matters. Here is how I build them.
Most talk about agentic AI for business is either a demo that books a flight or a slide promising a “digital workforce.” Neither is what clients actually need. What they need is a system that takes a real task off someone’s desk — reliably, with an audit trail, and without doing anything it was not allowed to do. That is a narrower thing, and a much more useful one.
This is how I scope, build and ship AI agents for clients, and where I tell them not to use one at all.
What “agentic” actually means in a business system
A chatbot answers. An agent acts. The difference is tools: an agent can call your API, query your database, create a ticket, send a message or update a record — and it decides which of those to do, in what order, based on the goal it was given.
That loop is simple to describe: read the goal, pick a tool, look at the result, decide the next step, stop when done. The engineering is in everything around the loop — which tools exist, what each one is allowed to touch, how the agent knows it is finished, and what happens when it is wrong.
Where agentic AI for business pays off
The best candidates share three traits: the task is repetitive, it needs judgement a rule engine cannot capture, and a mistake is cheap to catch before it is expensive. In practice that looks like:
- Support triage and first response — read the message, pull the order or shipment, answer the routine cases, route the rest with context already attached.
- Back-office operations — reconcile records between two systems, chase missing data, prepare the draft a human approves.
- Internal knowledge work — answer questions against company documents with sources, then take the follow-up action (open the ticket, update the CRM entry).
- Content and data operations — create, translate and audit structured content through an API instead of a person clicking through an admin panel.
Where it does not pay off: anything where the rules are fully known (write the code), anything irreversible with no human checkpoint, and anything where nobody can say what a correct result looks like.
Tools are the product, not the prompt
The quality of an agent is mostly the quality of its tools. A vague tool called update_record with a free-form payload invites mistakes. A tool called mark_shipment_delivered that takes one id, validates it and returns a clear result is hard to misuse.
I design agent tools the way I would design a public API for a junior developer I have never met: narrow, well-named, validated on the server, with error messages that explain what to do next. The model reads those descriptions and error messages — they are part of the prompt whether you plan it or not.
Why I build on MCP
The Model Context Protocol is a standard way to expose tools and data to an AI model. Instead of wiring each capability into one specific agent framework, you build an MCP server once and any compatible client — a chat assistant, an IDE, your own agent runtime — can use it.
For clients that means the integration outlives whichever model or vendor is fashionable this quarter. The Albania Magic MCP connector is a working example: places, blog posts, translations and SEO audits on a multi-tenant platform, all exposed as tools an assistant can use directly. If you want the same for your own system, that is what my agentic systems and MCP server development work covers.
Permissions come before intelligence
An agent should never have more access than the person it is working for. That sounds obvious and is routinely ignored — the agent gets a service account with admin rights because it was faster to set up.
- Scope every tool call to the user or tenant that triggered it, using the same authorisation rules as the rest of the app.
- Split tools into read and write, and put anything destructive or customer-facing behind an approval step.
- Rate-limit and cap the number of steps per run, so a confused agent stops instead of looping.
This is the same principle I use for RAG inside a Laravel app: keep the AI next to the data and let the existing permission layer do its job.
Log every step, or you cannot improve anything
For each run I store the goal, every tool call with its arguments and result, the model’s final answer, token usage and latency. That log is what turns “the agent did something weird” into a specific, fixable bug — usually a tool description that was ambiguous or a result that did not say clearly enough what went wrong.
It is also what you show a client when they ask why the agent did what it did. For a business system, “we do not know” is not an acceptable answer.
Keep a human in the loop where it matters
Full autonomy is rarely the goal. The pattern that works is: the agent does the gathering, checking and drafting, and a person approves the step that commits money, contacts a customer or changes something that cannot be undone. As trust builds on real data from the logs, more steps move to automatic. That order matters — trust is earned from evidence, not granted on launch day.
Keep the model swappable
Behind a thin provider interface, moving between Claude, GPT or a local model is a configuration change. Some clients need the strongest reasoning available; others, in healthcare or legal work, need data to never leave their servers. Designing for that from the start costs almost nothing. Retrofitting it later is a rewrite.
How a project usually runs
- Pick one workflow. Not “automate support” — one specific, measurable task.
- Define done. What does a correct result look like, and how will we check it?
- Build the tools first, usually as an MCP server or an API integration on top of the systems you already run.
- Run it in shadow mode against real cases, with humans approving every action.
- Widen autonomy step by step, based on what the logs show.
Is agentic AI right for your business?
If you have a task your team does every day, that needs a bit of judgement, and that touches systems with an API — probably yes, and the first version is smaller than you think. If you want the AI to answer questions from your documents first, start with AI agents and RAG systems and add actions later.
Either way, send me the workflow you would hand off first. I will tell you honestly whether an agent is the right tool, or whether a few hundred lines of ordinary code would do it better.
I take on a small number of projects at a time. Tell me what you are building and I will tell you honestly whether I am the right person for it.
Get in touch →