Task-specific agent

What is a task-specific agent?

A task-specific agent is an AI agent that does one job, with the edges of that job decided before it ever runs. The task is fixed, the tools it may call are fixed, the data it may read is fixed, and there is a written condition that says when a run is finished. Anything outside that description is not its problem.

It usually lives inside an application rather than in a chat window: in the shared mailbox, in the ticket queue, in the ERP screen where the work already happens. The general assistant sitting next to it takes any question you can type. This one takes one kind of request and produces one kind of result.

The narrow scope is the whole design. Each of those four boundaries is a decision somebody made on purpose, and each one takes a class of failure off the table before the first run. An agent that may only read the current customer's orders cannot quote another customer's prices back to them.

Vendors build this shape into their tooling. Microsoft describes a declarative agent for Microsoft 365 Copilot as running on the same orchestrator and the same models as Copilot itself, scoped to a specific business need through three configured parts: instructions, actions, and knowledge sources.

The four things you fix, and what each one removes

Each of these four stands on its own, and skipping one is how a project ends up with an agent nobody wants to switch on.

One task
Write the job as a single sentence with no "and" in it. "Reply to customers who ask when their order ships." If your sentence needs an "and", you have two agents, and you should build the first one. What this removes is the guessing: the model never has to work out which of your five processes it is currently in, because it is only ever in one.

One tool set
The agent gets the tools the task needs and nothing else. This removes two failures at once. The model cannot pick the wrong tool from a list that does not contain it, and a mistake cannot spread further than the tools reach. Anthropic's engineering write-up on building effective agents makes the point that tool definitions deserve as much design attention as a user interface, with clear documentation and example usage for each one. The rule that saves the most trouble in practice: never ship two tools that do almost the same thing, because those are the two the model will confuse.

One data scope
You decide which sources the agent may read and under whose rights it reads them. In Copilot Studio you attach knowledge sources to the agent, and for SharePoint and Dataverse the agent reads them with the signed-in person's own Entra ID, so it only surfaces content that person could already open. There is also a setting called Allow ungrounded responses. Turn it off and the agent blocks any reply produced in a turn where it consulted neither a knowledge source nor a tool, and hands the conversation to the fallback topic instead of improvising. Microsoft's own documentation adds the honest caveat: that switch does not guarantee the model never uses its general knowledge, it only blocks the turns where nothing was consulted at all.

A done condition
Write down what has to be true for a run to count as finished, in a form another person can check without reading the transcript. A draft exists in the mailbox and contains an order number. A ticket has a category and an owner. Anthropic recommends stopping conditions such as a cap on iterations to keep an agent under control, and that is worth having, but a step cap and a done condition are different objects. The cap stops the run. The done condition tells you whether the run worked. Designing that condition well is the subject of loop engineering, and it is the part teams skip.

Task-specific agent versus general assistant

The dimension that separates them is whether you can say, before the run, what a correct outcome looks like.

• What you ask it
  The task agent takes one kind of request in a predictable shape. The assistant takes anything you can type, including things nobody anticipated.

• What correct means
  For the task agent it is defined per case before the run. For the assistant it is judged per answer afterwards, by whoever happens to be reading.

• How you test it
  The task agent has a set of past cases with expected outcomes that you replay after every change. The assistant has spot checks and complaints.

• Who owns it
  The task agent belongs to the process owner it was built for. The assistant helps everybody, so it usually belongs to nobody, and nobody notices when its answers get worse.

The two complement each other. The assistant handles the long tail: the awkward one-off question, the document nobody has a process for, the thing that happens twice a year. The task agent handles the volume: the same request 200 times a week, where the value is in never having to think about it again. A company that runs both is normal. A company that asks the assistant to carry the volume work ends up with output nobody can check, and a company that tries to build a task agent for every long-tail question never finishes the first one.

Why the bounded ones reach production

Pilots stall for reasons that have little to do with model quality. Four of them go away when the scope is small enough to write down.

You can say what correct means. For one task you can state the pass criteria in a sentence, and that makes automated grading possible. Microsoft Foundry ships built-in agent evaluators, several of them still in preview, that it describes as working like unit tests for agentic systems, returning a pass or a fail per case. Task adherence asks whether the agent followed the rules and constraints in its instructions, and tool selection asks whether it picked the right tools without picking unnecessary ones. Neither question has an answer for an assistant that will be asked anything at all tomorrow.

You can test it before and after every change. Copilot Studio lets you build a test set of real cases and pick how each one is graded: compare meaning against an expected answer, a pass or fail on whether the agent used the tools you expected, or a custom test where you write the criteria yourself and label each result. The set gives you a pass rate, and that number is what turns "the agent seems better now" into something you can put in a change ticket. The evals entry covers the same discipline one level down, at the model call.

You can price it. A known task with a known volume gives you cost per run times runs per month, which is a number a finance manager can approve. Usage of a general assistant depends on how curious people feel this week. A bounded agent is also the shape an agent spend cap actually fits, because you know what a normal run costs and can flag the ones that do not look normal.

You can name an owner. The job belongs to a process that already has someone responsible for it: the warehouse manager, the head of customer service, the bookkeeper. That person can judge the output, because they used to produce it themselves. The agent registry entry covers how you keep that ownership written down.

A worked example: the delivery date agent

Four questions decide whether one of these works. What is the one sentence that describes the job? What is the smallest tool set that finishes it? What does it do when it is not sure? And how does a person see what it did? If your company has not put an agent into daily use yet, this is the shape to start with, and those four answers belong on paper before anybody builds anything.

A building materials wholesaler gets a steady stream of emails asking one question: when is my order coming? Here is the scope, written out first.

• Task
  Draft a reply to inbound emails that ask about the delivery date of an existing order.

• Tools
  Read the shared sales mailbox. Look up an order by number, or by the sender's email address. Read the planned dispatch date from the ERP. Write a draft into the mailbox. No send. No changes to any order.

• Data
  Orders from the last twelve months belonging to the customer who sent the mail. Nothing about other customers, no pricing tables, no supplier contracts.

• Done condition
  A draft reply sits in the mailbox, it names an order number, and it either gives a dispatch date or says in one line that the date is not confirmed yet.

• When unsure
  No matching order, more than one plausible order, or a question that is not about a delivery date: the mail moves to the sales inbox with a one-line reason and no draft.

• What a person sees
  Per run: the incoming mail, the order it matched, the tools it called and the draft it wrote, in a list the sales lead can open. Not a log file that only an administrator can read.

Now the request it has to refuse. A customer replies: "Fine, but cancel line 3 and add twenty more bags of cement while you are at it." The agent has no tool that changes an order, so it cannot act. That gap is deliberate. Even if the ERP connector could technically do it, the written task says draft a reply about a delivery date, so the correct behaviour is to move the mail to sales with the reason "order change requested". It is a perfectly reasonable business request. It is not this agent's job.

The arithmetic is what makes it worth building. Say sixty of these mails arrive in a week and each takes about four minutes to answer by hand: find the order, check the dispatch date, type a polite reply. That is four hours a week. If checking and sending a prepared draft takes a minute, the same sixty mails take one hour. The three hours that come back sit with one team on one task, so you can actually measure whether they came back at all.

What a vendor means when the page says agent

Most of what is sold as an agent inside a SaaS product today is a task-specific agent: a scoped helper for scheduling, for expense coding, for first-line support inside that product's own data. That is fine, and often exactly what you want. The point is that the word on the pricing page tells you nothing about capability, so do not accept it as a capability claim.

Salesforce publishes six levels of agentic control for its own platform, from an agent that picks its own actions with no instructions at all down to a hard-coded script with deterministic logic. One vendor, one word, six different amounts of autonomy behind it. Ask the specific questions instead: what is the one job, which systems does it touch and with whose permissions, what happens when it cannot handle a case, and what does a run cost. If the answers come back as adjectives, you are reading marketing. The AI washing and agent washing entry has the longer version of that conversation.

What to watch out for with a task-specific agent

Scope creep is the failure mode of this shape. The agent handles one mail type well, so somebody asks it to handle returns too, then complaints, then quote requests. Each addition is small and each one is approved by a different person in a different week. Nobody re-runs the test set, because no moment ever felt like a release. Six months later the scope sentence in the configuration still describes the original job, the agent answers four kinds of mail, and nobody can say what correct means any more. The rule that prevents it: changing the scope sentence is a change, and a change means the test set runs again before it goes live.

A person quietly fixing every third output means the done condition is wrong. If the process owner edits most drafts before sending, the agent is producing a first attempt rather than finishing the job. That can still be worth having, but say so out loud and track the edit rate, otherwise the saving you reported at the pilot is not the saving you are getting.

Bounded is not the same as safe. A narrow agent that reads customer emails still reads text written by strangers, and instructions hidden in that text are the classic prompt injection route. The small tool set limits what an attacker gets, which is the whole reason to have one, but it does not stop the attempt.