How to build an AI agent for one job

To build an AI agent, start with one job that has a clear result, known boundaries and a way to check the work. Write down what the agent should deliver, what information it can use, which actions it may take and when it must stop for your approval. Then choose a tool or platform that supports those rules, set a spending limit, and test the agent on real examples before giving it more responsibility.

You do not need to be a developer to start. A business owner can build a useful agent by defining the work and the decisions that must remain with a person. The technical setup matters, but the first job is deciding what good work looks like. Consider a weekly supplier update: an agent could collect information from approved sources, flag changes and prepare a short report for review. That is a manageable starting point because the result can be checked before anyone acts on it.

1. Choose a job you can describe in one sentence

Look for a task that repeats, takes time and produces an output someone can inspect. Avoid starting with a vague instruction such as 'run operations' or 'manage sales'. Those requests contain too many separate decisions, and you will struggle to tell whether the agent has done a good job.

Instead, write a sentence that names the input and the expected result. For example: 'Every Monday, review the supplier updates in this folder and prepare a report of delivery changes that need my attention.' The job has a defined source, a clear output and a reason for a person to review the result.

Before building anything, collect two or three examples of the work done well by a person. Include an ordinary case and a difficult one, such as an update with a missing delivery date. These examples will help you decide what the agent should do when information is incomplete. They also give you something concrete to compare against its first results.

A useful first job should end in a deliverable rather than an open-ended promise. A report, a classified inbox, a draft reply or a list of records needing attention is easier to review than an instruction to improve a business process.

2. Write the brief before choosing the tools

The brief tells the agent what it is responsible for and what it must leave alone. Write it as instructions for a colleague who has not worked in your business before. Spell out the purpose, the source material, the expected format and the rules for handling uncertainty.

For the supplier report, a practical brief might read:

Review the supplier updates in the approved folder. Prepare a report listing each supplier, the original delivery date, the latest stated date and the source of the change. If a date is missing or two sources disagree, flag the issue instead of choosing an answer. Do not contact suppliers or change delivery records. Return the report for review.

Notice the difference between asking for a report and asking the agent to solve every problem it finds. The brief gives it enough room to do useful work, but it does not turn a missing date into permission to contact a supplier or alter a record.

Add a short acceptance test. The report must identify the source of every reported change, distinguish confirmed dates from uncertain ones and leave out claims it cannot support. If the agent misses one of those requirements, the work needs revision.

Keep the first brief narrow. If you need a flowchart to explain the task, you may have combined several jobs that deserve separate instructions and separate reviews.

3. Give the agent only the tools it needs

An agent's tools determine what it can access and do. A research task might need read access to a folder and permission to create a report. A support task might need access to incoming tickets and the ability to draft responses. Neither job automatically needs permission to send messages, publish content or change customer records.

List the tools required for the first job, then leave everything else out. Check the scope of each connection, not just its name. Access to an inbox, for example, may expose more information or allow more actions than the task requires. Prefer a restricted folder or a limited set of records when that is enough.

Decide what the agent may do without asking, too. Reading approved files and preparing a draft may fit within its assignment. Sending an external message, moving money, publishing publicly or changing records can have consequences that a person should review first.

In Delagents, the agent roster and builder give you a starting point for choosing an agent role and defining its work. The available templates include research, inbox triage, bookkeeping and content repurposing. The right choice is the one that fits the job you have defined, not the one with the broadest apparent capabilities.

4. Set the checkpoints and budget before the first run

An agent needs clear stopping points. Without them, it may continue through a task even when a missing detail or unexpected result calls for human judgement. Decide in advance which situations require a question, which require a review and which are outside the assignment altogether.

For the supplier report, the agent might work through the approved files and prepare a draft without interruption. It should stop if it cannot access the source folder, encounters conflicting delivery dates or reaches the point where contacting a supplier would be the next step. The first two cases need clarification or review. The third needs a separate, explicit decision from a person.

Be specific about actions that affect the outside world. In Delagents, those actions wait in an approvals inbox, where a person can inspect the proposed action, the cost so far and its deadline before approving, changing or rejecting it. Certain actions always require a person, including first contact with someone outside the workspace, moving money, deleting records the agent did not create, changing its own policy, widening integration access, accepting terms, publishing publicly or acting in another workspace.

Set a hard budget cap for the delegation before it runs. Choose a limit that makes sense for the value of the task and the cost you are willing to risk on a failed attempt. The agent should not keep spending simply because it has not finished. If the cap is reached, the work should stop for review rather than quietly expanding the assignment.

Finally, decide what happens when the agent cannot complete the job. It might return a partial report, ask a question or stop with an explanation. That is better than treating every incomplete task as a reason to improvise.

5. Run ten examples and inspect the evidence

Do not judge an agent from its first successful output. Run it against ten representative cases before widening its permissions or handing it a larger assignment. Include straightforward work, missing information, conflicting sources, an unusual request and a case where the correct response is to stop.

Review each result against the acceptance test you wrote earlier. Check the source material yourself, look for missing details and see whether the agent respected its limits. A polished report can still contain an unsupported date or confuse a proposed change with a confirmed one. The appearance of finished work is not proof that the work is correct.

Keep a simple review record for each run:

• What the agent was asked to do and which source material it used.
• Whether the deliverable met the acceptance test, including any factual errors or omissions.
• Whether it stopped at the right point when information was missing or an action needed approval.
• What the run cost and whether it stayed within the assigned budget.
• What you changed in the brief, tool access or checkpoints before trying again.

Look for repeated mistakes rather than treating every failure as an isolated incident. If the agent keeps confusing proposed dates with confirmed dates, change the brief and the acceptance test. If it asks for approval on routine work that is already within its permission, clarify the boundary. If it tries to take an action outside its assignment, tighten the permissions instead of relying on a reminder in the prompt.

Keep the activity record, too. An append-only log of tool calls, approvals and policy changes helps you reconstruct what happened when a result is wrong. If the agent cannot provide enough evidence to explain its output, that is a reason to improve the process before expanding its role.

6. Expand the job only after the first version holds up

Once the ten runs have been reviewed, change one thing at a time. You might add another approved folder, introduce a second type of supplier update or let the agent prepare a follow-up draft. Keep the existing limits in place while you test the new responsibility. If you widen the data access, change the brief and permit external actions all at once, it becomes difficult to tell which change caused a problem.

A useful expansion has its own acceptance test and stopping rule. Adding a second data source, for example, means checking how the agent handles disagreements between sources. Allowing it to prepare an email means checking the recipient, facts and wording before a person sends it. Each new responsibility deserves a fresh test.

There is no need to build every agent from scratch. Start with a template if it fits the job, then adapt the brief, access rules and review process to your business. Keep separate assignments separate when they need different permissions or different people to sign off.

For your first build, choose one task that currently takes a colleague half an hour or more each week. Write its one-sentence goal, gather two good examples, and draft the instructions and acceptance test. Before connecting any tools, decide exactly what the agent may do alone and where it must stop. That is the brief to test on your first ten runs.