AI Agent Development

In AI agent development, quality depends less on the model than on the rules written before it runs: which task the agent owns, which tools it may touch, when it stops and asks a person, and how its actions are recorded. This guide covers those decisions in the order a business owner makes them.

Technical terms are explained briefly where they first appear, so you can speak the same language as any vendor and judge a pilot with your own data.

01Test the idea with a one page task card

A single page task card tells you whether a job suits an agent at all. It names the event that starts the job, the goal, the condition that proves the job is done, the systems involved and the person who would notice if something went wrong. If you cannot fill in those five lines, the problem is the process definition, not the technology, and AI agent development should wait until that definition is clear.

Once the card exists, make the call with four questions:

• Path variety: List your last twenty requests; if most follow the same order, a rule based workflow automation is enough.
• Checkability: Someone on your team must be able to verify the agent's output in a few minutes; if only a specialist can check it after long effort, the pilot cannot be measured.
• Cost of a mistake: Can a wrong step be reversed? Actions that cannot be undone may only sit behind an approval gate.
• Volume: A job done a few times a week rarely repays the build and upkeep.

If more than two answers are negative, postpone the agent. The card later becomes the first draft of the test set, so the work is never wasted.

02First agent tasks by type of company

A first agent task should be narrow, frequent and easy to check. The examples below are not client results; they are typical starting points that meet those criteria in different kinds of companies.

• Online store: An agent that reads a return request, compares the order date, the shipping history and the return policy, and leaves a ready decision note for the support rep, who still approves the refund.
• Manufacturer or distributor: An agent that reads the technical specification attached to a quote request and lists matching catalog items plus the details still missing.
• Accounting or consulting firm: An agent that finds, at month end, which client still owes which document and drafts the reminders.
• Appointment based service business: An agent that matches a canceled slot with suitable people on the waiting list and proposes who to contact.
• B2B sales team: An agent that pulls next steps out of meeting notes for the CRM record; fixing the record rules first through CRM automation makes this much easier.

Answering internal questions usually calls for a search assistant that cites its sources rather than an agent. If nothing gets written to any system, a company knowledge assistant is simpler and cheaper. Start with the job that is easiest to measure, not the most ambitious one, and bring the employee who owns that job into the project from day one; they are the right person to write the correct answers in the test set.

03Plain language architecture: loop, state and orchestrator

Technically, an agent is a loop: the model reads the current state, decides to call a tool, sees the result and repeats until it reaches the goal or hits a stop rule. The part that runs this loop is ordinary code called the orchestrator. It takes the model's proposal, checks the permission list and decides whether the tool actually runs.

Pin down three concepts when you discuss architecture:

• State: Which step the task is on, what each tool returned and which limits remain. This lives in a database, not in the model's memory, so an interrupted task resumes where it stopped.
• Context: The amount of text a model can see at once is limited. Long threads and large spreadsheets are not passed in whole; only the relevant slice is.
• Memory: Notes made during a task are discarded when it ends. Facts the agent must remember long term, such as a customer's delivery preference, sit in a separate record that is reviewed.

Several agents handing work to each other look attractive but are hard to debug, so we start with one and add a second only when a subtask needs separate permissions or another model. Fixed steps run outside the loop as plain code, so the model is involved only where judgment is required. Ask vendors for a sketch of this loop showing which decisions sit in the model and which in code.

04Tool design: small parts that each do one job

Most of the effort in AI agent development goes into tool design, because the agent's quality often depends more on its tools than on the model. Each tool has a name, a short description of what it does, the parameters it accepts and the format of what it returns. The model picks tools by reading those descriptions, so write them as carefully as instructions for a new hire.

• One job each: Instead of a broad "manage the CRM" tool, define separate ones such as "find a customer by email address" and "add a note to a record", and grant access per tool.
• Safe retries: Write tools carry an idempotency key, meaning a repeated request does not create a second record; a retry after a network error never produces a duplicate invoice.
• Readable errors: A failing tool returns a message the model can act on, such as "no permission" or "record not found", so it can change course.
• Narrow output: Results are paged and limited to the fields the task needs, not thousands of raw rows.
• Dry run mode: Write tools first run in a version that only reports what they would have done; the real version runs after approval.

Keep the tool list short. Many similar tools raise the odds of a wrong pick; as the task grows, split it rather than adding tools.

05Data sources, credentials and connection paths

For each system the agent connects to, settle the access path first, then the credentials, then data quality. The access path is usually the system's API, a webhook that fires when something happens, or an MCP server that exposes tools in a standard form. MCP, the Model Context Protocol, is an open protocol that lets a model call tools across different systems in the same way.

• Dedicated service account: The agent connects with its own account and only the scopes it needs, never with an employee's login, so the logs show clearly who did what.
• No secrets in prompts: API keys stay in a secrets vault and are injected when a tool runs; the model never sees them.
• Rate limits: Provider limits are read in advance, and the agent knows how to wait instead of hammering the system.

Unstructured documents such as invoices, contracts and scanned forms should not reach the agent raw. Splitting them into fields first through AI document processing makes the results far easier to audit.

An older program without an API needs an export, an intermediate database or a thin layer of custom software. Screen clicking bots break with every interface change, so keep them as a last resort. Data quality matters as much as the connection: if one customer appears under two names in two systems, the agent will multiply that confusion rather than fix it.

06Model choice, hosting and version pinning

Choose the model by how often it gets the hardest step of your task right on your own test set, not by public leaderboards. For agent work the deciding factors are how reliably it calls tools with correct parameters, how well it follows instructions over long context, and response time.

• Split roles: A more capable model for planning and decisions, and a faster, lighter one for simple steps such as field extraction or classification, keeps costs balanced.
• Hosting: Weigh the provider's own API, cloud platforms that let you choose a region, and open weight models on your own servers against data location, operating effort and quality.
• Version pinning: Behavior can shift when providers update a model, so production uses a fixed version and a new one goes live only after passing the test set.
• Outage plan: When the provider does not respond, the agent either waits or hands the unfinished task to a person; nobody assumes the same prompt works unchanged on another model.

Self hosting keeps data in house, but hardware, updates and security become your job; let the volume of personal data and your capacity to run servers decide.

07Designing the approval queue and the step log

An approval gate that a reviewer cannot understand in a few seconds is either ignored or rubber stamped. The screen should show, at a glance, the action the agent wants to take, the records it relied on, the before and after values of every field that will change, and its reasoning.

• Three choices: Approve, edit and approve, or reject. A rejection asks for a short reason code, and those codes feed the next round of improvements.
• Named owner: Every action type has an approver and a backup for when that person is away.
• Timeout: If approval does not arrive within the set time, the action never runs by default; a reminder goes out or the task closes.

The step log answers, months later, why the agent did something. Each entry holds the task ID, timestamp, tool called, inputs, result, model version and the approver.

Retention periods for entries with personal data are set up front, access is limited by role, and the log records who viewed which entry.

08Agent security: outside content, secrets and outbound limits

An agent is most dangerous when it can reach private data, reads untrusted outside content and can send data out. When those three abilities meet in one task, a single email carrying hidden commands can steer the agent into leaking data; the design must break at least one leg of that triangle.

• Outbound allowlist: The agent may write only to listed domains and listed recipients; any message to an unlisted address lands in the approval queue.
• Separated context: Information extracted from outside content goes into a marked data field, never into the same place as the agent's instructions.
• Sending channel: If the agent sends email from your domain, SPF, DKIM and DMARC records must be correct; our SPF, DKIM and DMARC checker shows the status in a couple of minutes.
• Isolated runtime: Agents that run code or process files work in a separate environment with restricted network access.

Security probes belong in the test set. A document with planted instructions, a fake request from a manager, or a customer message asking for an action outside the agent's permissions is tried on purpose.

They run again after every prompt or tool change, and when one succeeds, the fix goes into the permission layer first, because lasting protection comes from limits in code.

09GDPR, transfers and the EU AI Act

Because an agent acts, write down separately what data it reads, where it sends it and what it produces about people. The points below are not legal advice; they are a checklist to work through with your legal adviser before the build.

• Processor contracts: Under Article 28 of the GDPR, any provider processing personal data on your behalf, including the model and automation platforms, needs a data processing agreement; read their terms on data use, retention and training.
• Transfers: If a provider sits outside the EU or EEA, Chapter V of the GDPR applies and the legal basis for the transfer must be documented.
• Decisions about people: Article 22 restricts decisions based solely on automated processing with legal or similarly significant effects, so the final say on applicants, credit or contracts stays with a person.
• Transparency: Article 50 of the EU AI Act requires that people know they are interacting with an AI system; we apply that to every recipient, inside the EU or not.
• Other markets: The UK has its own version of the GDPR, and US state privacy laws differ; confirm which rules apply to the people your agent contacts.

A practical rule: mask fields the agent does not need at the tool level. If a task does not require a national ID number, the agent never sees it and so can never write it anywhere by mistake.

10Rollout steps from pilot to full use

Widening permissions in measured steps, instead of switching the agent on all at once, lowers both the risk and the team's resistance. This is the sequence we follow:

1. Collect cases: Gather task examples from past weeks along with how the team resolved them, masking personal data for testing.
2. Build the test set: Label the cases easy, hard and misleading, and have the team write the correct outcome for each.
3. Shadow run: The agent processes real requests but writes to no system; its suggestions are compared with the team's decisions.
4. Draft mode: The agent prepares write actions, and each one lands in the approval queue.
5. Limited writes: Low risk, reversible action types run without approval; everything else stays in the queue.
6. Regular review: Rejection reasons, cost and error logs are reviewed monthly, and permissions widen or narrow based on them.

Each step has a pass criterion written in advance, such as the rejection rate staying below an agreed threshold for two weeks. Falling back a step is not a failure; it shows the controls work.

AI agent development does not end at launch. As connected systems, models and business rules change, the agent needs upkeep: monitoring, test set updates and small fixes run as part of our AI automation services.

11The metrics that show whether the agent pays off

An agent's value is measured by what a task costs end to end and how much human intervention it needs; the number of completed tasks on its own is misleading. Before measuring, you need to know how long the same job takes by hand; our working hours calculator helps you estimate that from the team's weekly records.

• Intervention rate: The share of tasks where a person had to correct, redirect or take over.
• Steps per task: If the step count rises for the same task type, the agent is wandering; review tool descriptions or context layout.
• Approval wait time: If the agent is fast but approvals sit for hours, the bottleneck is human, and approval ownership needs rework.
• Total cost: Model usage, platform fees and approval time, counted together.
• Escaped errors: Mistakes that passed approval and surfaced later are counted separately; they show whether the approval screen is clear enough.

Track these side by side in a monthly table. If value does not show, narrowing the task or moving that part to a fixed workflow is usually wiser than expanding the agent. Read the numbers with the person who owns the job; the table alone cannot tell you why interventions rose.

12Limits, risks and criteria for stopping

Agents are probabilistic: the same input may not produce the same output, and a model can invent a wrong tool parameter with full confidence. In long chains, small errors compound, so checkpoints should increase as the number of steps grows.

• Silent drift: When field names change in a connected system, the agent may read the wrong field without raising an error; a regularly run test set catches this.
• Cost swings: Hard requests mean more steps and more model calls, so a monthly budget cap and alerts are set from the start.
• Latency: Multi step tasks can take minutes rather than seconds; if a customer expects an instant reply, the agent belongs in the background.
• Provider lock in: Without documented prompts and tool definitions, changing models means rewriting the project.

Write stop criteria at the outset too. If the intervention rate does not fall by the end of the pilot, if total cost exceeds the manual process, or if the team cannot keep up with the approval queue, the agent is switched off and the task returns to a fixed workflow or to people.

13Common mistakes in AI agent development

These recurring patterns explain why agent projects lose trust; each comes with a healthier alternative.

• Deciding from a demo: Instead of launching an agent that shines on a few hand picked cases, decide with a test set built from past work that includes misleading examples.
• Starting with full access: Instead of connecting the agent with an admin account, start read only and open write access one action type at a time.
• Handing everything to the model: Instead of letting the agent run fixed steps too, move every step whose rule can be written into plain code and use the agent only where judgment is needed.
• Editing prompts off the record: Instead of changing prompts without version control, log every change and run it through the test set before release.
• Leaving approval unowned: Instead of a queue nobody is responsible for, assign an owner and a backup to every action type.
• Watching cost after the fact: Instead of discovering the usage bill at month end, set per task caps, a daily budget and alerts from day one.

All of them treat the agent like a feature you toggle; managed as a process with rules, owners and limits, most never appear.

14Choosing a partner and the next step

Choose your AI agent development partner less by what their agent can do in a demo and more by how clearly they explain what it is prevented from doing. Ask for direct answers to these questions:

• Which of our jobs would you solve with a fixed workflow instead of an agent, and why?
• Will the tool list and each tool's permissions be handed over to us in writing?
• In whose name are the model, automation and cloud accounts opened, and what can we take with us if we part ways?
• How is the test set built, and how are prompt changes tested before release?
• By which criterion will we call the pilot a success or a failure?
• When the agent stops or fails, who is notified, through which channel and with what information?

Vague answers signal a vague scope. A written task card and test plan let you compare proposals on the same scale.

To start with us, briefly describe the job you want to hand over, the systems involved and how the work is done today; you can reach us through the contact page. We fill in the task card together and send, in writing, which part becomes an agent, which part a fixed workflow, and the scope.

Starter options are listed under AI automation pricing; model and platform usage fees are paid separately, from your own account, to the providers. If we conclude you do not need an agent, we will say so and suggest the simpler route.