Building your first AI agent for business

Start with one repetitive process you can describe end to end, map every step and exception, build the smallest version that handles it, then run it beside the human doing the same job until the outputs agree. The build is the short part. Choosing the right problem and proving the thing works are where the weeks actually go.

Most of what gets sold as an agent is a workflow. That distinction is not pedantry, and it is the one that decides how much can go wrong.

What is an AI agent?

An AI agent is a system that takes a goal, decides for itself which steps to take, and carries them out using tools it can call, without a person directing each step. The deciding is what makes it an agent. A system that follows a path someone laid out in advance, even one with a language model inside it, is a workflow.

Anthropic drew the same line in its Building Effective AI Agents post in December 2024: workflows orchestrate models through predefined code paths, agents direct their own. The post has since been flagged by its authors as dated on tooling, and the distinction has held up better than the tooling around it.

The practical reading: a workflow is easier to build, easier to debug and safer, and most first projects should be one. Reach for an agent when you genuinely cannot predict the number of steps in advance.

What makes a good first problem to automate?

One that repeats, follows a logic you can write down, and currently eats a chunk of somebody's day. Lead qualification qualifies. Invoice routing qualifies. The first-response layer of a support inbox qualifies.

Two traits matter more than the time saved. The output has to be checkable, so somebody can look at what the system produced and tell quickly whether it is right. And the process has to be one that a person can already describe out loud, in order, without stopping to work it out. A process nobody can explain is a process nobody can specify, and specifying it is the build.

Resist the agent that does everything. It does not ship.

What do you map before you build anything?

Every step, every decision point, every exception, in the most boring granularity you can stand. What starts the process. What information each step needs. Where the edge cases go. Who gets told, and when.

This document does the work people expect the tool to do. When the map is complete, the build turns into translation: a process a human already thought through, handed to a system that can run it. When the map is missing, the system does something slightly wrong at step four, nobody can say why, and it gets quietly shelved three weeks later.

Teams without an engineering function are often better at this part than the engineers, which is its own argument.

What should the agent be allowed to decide on its own?

Less than the demo suggests. Every capability you grant is a capability that fires on the day the model misreads the situation, and the blast radius is whatever you connected it to.

OWASP calls this Excessive Agency and ranks it sixth in its 2025 Top 10 for LLM Applications: systems handed more autonomy, more permissions or more tools than the task needs. The related entry, Improper Output Handling, covers what happens when whatever the model produced gets passed downstream without anyone checking it first.

Write the boundary down as a list of actions the system may take without asking, and a list it must escalate. An agent that can draft a refund and route it for approval is a different risk from one that can issue it. The second one is sometimes correct. It is never correct by accident.

How do you connect it to the tools you already run?

Deliberately, and with more time budgeted than the build itself. A business with a CRM, an email platform, a project tool and a decade of accumulated integrations is not a blank surface, and the workflow already running is what you build against rather than around.

Three things reliably catch teams out. Authentication, where shared credentials and expiring tokens kill deployments about three days after launch. Data formats, where a field pulled from one system and pushed into another is subtly wrong in a way nobody notices for a month. And failure handling, where the honest question is what the system does when a step fails, and whether anyone finds out.

That last one is a process question wearing a technical costume. If the answer is that it fails silently, the integration is not finished, whatever the demo showed.

How do you test an agent before it goes live?

Run it beside the existing process on the same inputs, and compare the two outputs until you trust the comparison. One to two weeks is usually enough to see where it is right, where it cuts corners, and where it produces something confident and untrue.

NIST's AI Risk Management Framework (AI 100-1, January 2023) puts measure alongside govern, map and manage as a core function, and parallel running is the cheapest version of it available to a small team. It also produces the thing most first builds lack: a written definition of a correct output, arrived at by argument rather than assumed.

Then keep watching. Inputs change, upstream tools get updated, and edge cases that never appeared in testing start appearing weekly. A system that was right in January can be quietly wrong by March with nothing in the logs to mark the change. We hold the first two weeks after handover under live monitoring for exactly that reason, which is how we work, and a system already running is the most useful time to audit one.

The build is a fortnight. The map and the parallel run are the project.

MorningLabs AI builds the agents, automations and internal systems a business runs on, and audits AI systems that are already live.