AI Agents for Business – AI Agent Development & Deployment

What an AI agent for business is made of – the anatomy of a production deployment

A production AI agent is a model-and-tools loop wrapped in control layers: a permission gate, human approval points, limits and an action log. The model does the reasoning, but whether the agent is safe and predictable depends mostly on what surrounds it.

This table doubles as a list of questions for any vendor. If a proposal has no permission gate, no limits and no log, you're getting a prototype, not an agent ready to work on company data. How the agent loop itself works is explained in plain language in the post AI agents – what they are and how they work.

Example: a proposal-drafting agent, step by step

A proposal agent is a good example because it combines everything hard: an unstructured customer email, several systems, pricing decisions and external communication. Below is the typical flow I design, marking where the agent only reads, where it writes and where a human decides.

1. Read the enquiry (read only). The agent reads the email and attachments and extracts products, quantities, deadline and company details into a structured format. It treats the email as data, not as instructions.
2. Identify the customer (CRM read). It checks whether the company is in the CRM, its order history, payment terms and assigned sales rep.
3. Availability and pricing (ERP and price list read). It checks stock, delivery dates and the price including customer-specific discounts.
4. Clarifying questions (draft). If data is missing, such as a dimension or quantity, it drafts a question to the customer instead of guessing.
5. Draft proposal (draft write). It creates the proposal in the CRM as a draft, with a rationale for each line and the source of each price.
6. Approval (human). The sales rep gets a notification with a summary, differences from the standard price list and risk flags such as a discount above the threshold or an unusual deadline.
7. Sending (after approval). Only an approved proposal is sent, and the agent logs the activity and a follow-up date in the CRM.

The agent has no right to email the customer on its own or change a price in the price list. Those limits aren't about distrusting the model; they're simple arithmetic: one wrong proposal sent to a customer costs more than one click from a sales rep. Integrations with the systems involved are covered in the posts on AI in CRM and AI in customer service.

Designing an agent's tools – tool calling and MCP in practice

An agent's quality depends heavily on its tools: how many there are, their names, their descriptions and what they return. In its post on writing tools for agents (September 2025), Anthropic advises against wrapping every API endpoint as a tool and recommends fewer tools built around real tasks, because more tools don't always lead to better outcomes.

Rules I apply to every tool

• Separate read and write tools. "Get customer" and "create proposal draft" are two tools with different permissions, not one generic "operate on CRM".
• Write as a draft, not a final result. Where the system allows it, the agent creates a draft and publishing or sending is done by a human or by a separate, controlled step.
• Schema-validated arguments. Every call goes through JSON Schema and business rules: allowed values, amount ranges, tax ID format, an existing customer ID.
• Idempotency. Write actions carry an idempotency key, so a retry after a network error doesn't create two invoices.
• Readable errors. Instead of a 500, the tool returns a message saying what went wrong and what the agent can do. Anthropic recommends this because models recover better from it.
• Lean results. A tool returns the fields needed for the decision, with pagination and filters, not the whole API response eating up context.
• Unambiguous names and descriptions. `customer_id` rather than `user`, and a tool description written as if explaining it to a new hire.

Technical details, including error handling and retries, are in the post on tool calling in production.

MCP – when I use it and when I don't

MCP (Model Context Protocol) is an open standard for connecting models to tools and data. In December 2025 Anthropic donated it to the Agentic AI Foundation under the Linux Foundation and reported more than 10,000 active public MCP servers. For a business it means one MCP server built for your CRM can serve both an agent and the assistants your staff use.

The MCP specification's security best practices forbid token passthrough (forwarding tokens that weren't issued to that server) and recommend a minimal initial permission scope that is only widened when needed. They also describe the risk of local servers running with the user's privileges. In practice I implement this with a dedicated technical account for the agent, scopes limited to the operations it needs, and servers run in an isolated environment. More on the protocol itself is in the post on MCP.

An AI agent threat model – the lethal trifecta and the Rule of Two

An agent is most exposed when it reads untrusted content, has access to sensitive data and can take actions or communicate externally, all at once. Before building any agent I check which of these three properties it has, and design it so that a single session never has all three without human oversight.

The approach has two well-known sources. In June 2025 Simon Willison called the combination of access to private data, exposure to untrusted content and the ability to communicate externally the "lethal trifecta". In October 2025 Meta described the "Agents Rule of Two": within one session an agent should have no more than two of three properties: processing untrustworthy inputs, access to sensitive systems or private data, and the ability to change state or communicate externally. If all three are needed, a human has to supervise.

In December 2025 OWASP published a separate threat list for agentic applications (Top 10 for Agentic Applications for 2026), alongside the familiar list for LLM applications that I cover in the AI automation guide. The agentic list includes agent goal hijack, tool misuse, identity and privilege abuse, and memory and context poisoning. I test for each of them before launch. Practical isolation and permission techniques are in the post on AI agent security.

One agent or a multi-agent system – how I choose

By default I build a single agent with well-chosen tools, and a multi-agent system only when the task splits into independent, parallel parts. More agents mean more tokens, more places for errors and harder debugging.

Anthropic's June 2025 write-up of its research system shows this well. The multi-agent setup (a lead model plus subagents) outperformed a single agent by 90.2% on an internal research eval, but agents used about 4 times more tokens than a chat interaction and multi-agent systems about 15 times more. The authors note the architecture pays off for tasks valuable enough to justify the cost and that can be parallelised.

When splitting work across several agents makes sense, and how to design it, is covered in the post on multi-agent systems, with a research agent example in AI deep research.

How I test an agent before launch – outcome, trajectory and consistency

I test an agent on a set of real cases and assess three things: whether the outcome is correct, whether the path to it was right (tools, arguments, order) and whether the agent behaves the same way on repeated runs. A correct outcome alone isn't enough, because the agent may have reached it through an action it shouldn't have taken.

Why consistency is a separate metric

The authors of the τ-bench benchmark (Sierra, 2024) proposed the pass^k metric: the share of tasks an agent solves correctly in all k attempts. In their tests, agents built on the leading models of the time solved under 50% of tasks, and pass^8 in the retail domain was below 25%. Models have improved since, but the lesson stands: an agent that solves a task "sometimes" isn't fit to work unsupervised. So I run every case in the test set several times.

What the test set contains

• Typical cases from the company's history, with the correct outcome described by the person who handles them today.
• Edge cases – missing data, conflicting information, unusual requests, cases at the edge of the agent's permissions.
• Cases where the agent should refuse or escalate – to check that it knows when to stop.
• Attack attempts – instructions hidden in emails, attachments and documents, attempts to extract another customer's data.

These results decide which autonomy level the agent starts at and when it can move up. Autonomy levels and approval rules are described in the AI automation guide, and the evaluation method in the post on LLM evaluation.

n8n, LangGraph or a model provider's SDK – what I build agents on

I choose the technology based on how complex a case's state is and how important it is to resume after a pause. A simple agent with a few tools works well in n8n, while an agent running multi-step cases with human approval mid-process fits LangGraph or custom code better.

Whatever the choice, I keep business logic (permissions, validation, limits) out of the prompt, in ordinary code or configuration. That way switching the model or framework doesn't change the security rules. If a system has no API, interface automation (computer use) sometimes helps, but I treat it as a last resort, as explained in the post on computer use. Building an agent in LangGraph is covered in a separate tutorial.

Action log, tracing and cost per task – what runs after launch

I record every agent step so that a week later you can reconstruct what it saw, what it decided, which tool it used and what it cost. Without that you can neither explain a complaint nor safely increase autonomy.

What a log entry contains

• The case ID and the agent version (prompt, model, tools).
• Input: what the agent received and through which channel.
• Every tool call with arguments, result and the permission gate's decision.
• Human decisions: who approved, corrected or rejected, and why.
• Tokens, cost, step count and time.
• Personal data masked wherever it isn't needed for analysis.

For tracing I follow the OpenTelemetry semantic conventions for generative AI, which define standard attributes for model and tool calls. That way agent data lands in the same monitoring tools your IT team already uses, rather than in a separate closed dashboard.

How I keep cost under control

I calculate the agent's cost per case, not per month: average steps times tokens per step times the model price. I set a hard step limit and a token budget per case; once exceeded, the agent stops and hands the case to a human. That protects against loops where the agent calls the same tool over and over. Further levers such as prompt caching and a cheaper model for simple steps are in the post on AI API cost optimization, and monitoring in monitoring AI in production.

What to prepare before an agent rollout and what you get at the end

On the company side you need three things: someone who knows the process and can judge the agent's output, access to the systems through an API or another secure channel, and a few dozen historical cases for the test set. An agent for one process starts from €3,000.

Pre-launch checklist

• A process owner with time for the workshop and a weekly review of results in the first month.
• Written process rules, including the informal ones: discount thresholds, exceptions, customers handled differently.
• Test access to the systems (CRM, ERP, email) and the ability to create a dedicated technical account for the agent.
• Historical cases with correct outcomes, including the hard ones.
• A decision on where data is processed: a cloud model under a data processing agreement or a locally hosted model. The post on AI data security helps with that.

What I hand over after launch

Agents often draw on company knowledge, so in many projects I pair them with a RAG implementation. If the process can be described by rules, n8n process automation will be cheaper, and for customer service it's worth starting with an AI chatbot. An example of an agentic system in production is the GiftFinder case study.