What is an AI agent?

Take one request: a customer emails asking to move their Thursday appointment to next week.

• A chatbot replies with your rescheduling policy and a link.
• A fixed workflow can only handle it if the email matches a rule, for example a form with a "reschedule" button. A free-text email breaks it.
• An agent reads the email, finds the customer, checks their booking, looks at next week's availability, offers two slots, books the one they pick and updates the record. If the customer asks something it is not allowed to handle, such as a refund, it hands over to a person with the thread attached.

The defining feature is the loop: decide, act, observe, decide again. The agent is judged on whether the appointment moved, not on whether the reply sounded good.

Five things, and failed agent projects usually skip at least one.

1. A model to reason about the goal and choose the next step.
2. Tools the agent can call: read a calendar, write to a CRM, send an email. Each tool should do one narrow thing.
3. Context and memory: what has happened in this task so far, and what the agent knows about this customer or account from before.
4. Instructions and rules: what it is for, what it must never do, the tone, the pricing it may quote, when to stop.
5. Guardrails and handoff: limits on what it can change without approval, checks on its outputs, and a clean route to a human.

A model with no tools can only describe what it would do. Tools with no memory produce an agent that repeats itself. Both without rules and guardrails produce an agent that keeps going when it should have stopped.

Use a plain workflow when the steps are always the same: send the invoice, sync the record, post the report. It is cheaper, faster and easier to audit.

Use an agent when:

• The input varies a lot (free-text emails, mixed documents, conversations).
• The right next step depends on what the agent finds.
• A person currently holds context across several systems to get the job done.

Most good systems are a mix. A workflow handles the trigger, the data checks and the logging. The agent sits at the one point where judgement is needed, inside a fence the workflow defines. Gartner has predicted that over 40% of agentic AI projects will be cancelled by the end of 2027, citing costs, unclear business value and weak risk controls. Starting with the narrowest useful agent, inside a workflow, is the simplest way to avoid joining that number.

Trigger: an email arrives at any of 63 sales inboxes.

Steps: a lightweight listener per inbox passes the email to one central agent → the agent loads the identity, pricing and rules for the site the email arrived at → it reads the full thread history from the data layer → it decides the conversation stage (first contact, objection, fulfilment, payment, upsell) → it replies within fixed commercial terms → separate workflows chase unpaid invoices on a schedule and catch payment confirmations.

Output: standard deals handled end to end with no human in the loop.

That is the shape of a real AI email sales agent running for a digital publishing business: 63 properties, 4,300+ client records, around $105 a month to run, replacing $9,000 to $9,500 a month in staff cost. Note the guardrail that makes it safe: pricing is fixed by tier, so the agent cannot give away margin. Objections are met with added value, not discounts.

• It does something it should not. Prevention: give it the fewest tools possible, make destructive actions (delete, refund, cancel) require human approval, and block dangerous commands at a level the agent cannot override.
• It makes things up. Prevention: ground every answer in data it has fetched, require structured outputs, and check them before they go anywhere.
• It loops or stalls. Prevention: a step limit, a timeout and a fallback route to a person.
• It drifts. A prompt that worked in March produces odd replies in June after a model update. Prevention: a fixed set of test cases you rerun after any change.

The self-diagnosing operations system built for the same kind of business shows these guardrails in practice: specialists diagnose in read-only mode first, every destructive action is posted for approval in chat, and guard hooks block dangerous commands regardless of what any agent decides.

Say you run three dental clinics in Abu Dhabi with one shared front desk. Patients message on WhatsApp to book, reschedule, ask about prices and send insurance cards.

An agent could own the scheduling conversation: read the message, identify the patient, check the right clinic's diary, offer slots, confirm the booking and send a reminder. It would quote only from a fixed price list, never discuss clinical questions, and hand any complaint, medical question or insurance dispute to the front desk with the full thread. A workflow around it logs every action, and a daily summary shows the front desk what the agent handled and what it passed on.

The front desk stops typing the same replies and spends its time on patients in the building.

We start by finding the decision point: the step where a person currently reads something messy and decides what to do. That is where an agent belongs. Everything around it stays as plain workflow.

Then we write the agent's rules as if briefing a new hire: what it is for, what it may quote, what it must never do, when it hands over. We give it the narrowest set of tools that does the job, gate anything destructive behind approval, and build a set of test conversations from your real data that it must pass before go-live and after every change. We build agents in n8n or with Claude Code depending on complexity, and choose the model per task: faster, cheaper models for high-volume replies, stronger ones where judgement matters.