The Model Can Be General. The Question Cannot.

As general-purpose agents handle more kinds of work, specialized agents face an obvious question. If the same agent can read files, operate software, and use a wide range of tools, how many agents built for particular tasks will we still need?

The answer matters for how software will be organized. If a specialized agent's value consists mainly of knowing a domain, connecting a few tools, or doing something today's general model struggles with, a better model may take much of that value away.

Specialized software does another job, though. It turns a business goal into a well-defined task, establishing what the model must decide and what software should handle. That work remains useful even when a general-purpose agent can already finish the whole task.

Data import makes the distinction concrete. A user says, "Import this quotation into the system." The goal is clear enough. What, exactly, is the model being asked to decide?

The user wants correct business records. They should not have to specify objects, fields, and execution steps. The software needs to do more work on the task definition, because the request combines several kinds of work: interpreting the file, understanding the destination, reading values, resolving relationships, and writing records.

Take a single price. Column D in the source is labeled "Unit price." The target field, price_unit, has the same business meaning. Cell D17 contains 123.0. Ask the model to return a field and value ready to write, and it has to establish the correspondence and reproduce the number.

That seems almost indivisible: put a value in a field. Yet it contains two responsibilities. Decide where the value comes from. Retrieve that value accurately.

Define the task more precisely, and the model's decision can be expressed as:

price_unit <- D17

The arrow says that D17 supplies the unit price. Software follows the reference to read 123.0, handles the type according to the field definition, checks constraints, and writes under the applicable permissions. The model does not need to generate the number again or arrange the mechanics of reading and copying it.

The answer now does something different. With price_unit = 123.0, we have a value returned by the model. With a source-to-field mapping, software knows where to get the value. We can check the judgment separately from the retrieval, and the data has an explicit source.

One decision can also cover a whole region. From the headings and boundaries, the model may determine that rows 17-80 are line items and column D supplies their unit prices. Software can then process each row. The model interprets the region's structure and purpose; the same reading and execution logic handles every value within it.

A customer field in a quotation form takes this distinction a step further.

Suppose A2 says "Customer" and B2 says "Cedar House Interiors." The product list begins below. The model has to recognize that this label and value describe the customer for the whole quotation. The target system requires the order to reference a customer record, so the name must resolve to a record identifier.

There is now a business choice inside the task. What should happen if the customer does not exist?

Suppose the user has specified the rule: search by name, reuse a unique match, and create a customer only when there is no match. Multiple matches require confirmation. For this task, whether to search or create first has already been settled.

A specialized system can give that rule a defined relationship operation. The model identifies B2 as the source for the order's customer field. Software reads the name, queries the records, and follows the appropriate branch: reuse, create, or request confirmation. Once it has a customer identifier, it sets the relationship.

The execution order follows the user's rule. The model still interprets the form, but it does not have to guess on every run whether the user tolerates duplicate customers, permits automatic creation, or expects a search first.

Another company might allow links only to existing customers and require the task to stop if none is found. That choice must enter the task and the system. A model's experience cannot substitute for the user's decision.

The D17 example separates out mechanical value handling. The customer example separates out a settled business rule. Both reveal responsibilities inside a vaguely defined AI task that can be made explicit and handled deterministically by software.

One important role of specialized software is to define precisely what requires intelligence.

The software environment that organizes tools, context, constraints, execution logic, and feedback around a model is commonly called an agent harness. For an import, it provides form labels, cell locations, target field definitions, and tools for gathering more evidence. It also requires the model to submit mappings through explicit source references. A sentence saying "This is the customer name" still leaves software without enough information to finish the job.

Asking better questions is therefore a software design problem, extending well beyond prompt engineering. A prompt can say "Don't copy the number incorrectly" or "Search before creating." The system must read through source references and branch on query results according to defined rules. Those mechanisms let software act on the model's decisions and take responsibility for enforcing rules that have already been settled.

This leaves room for exploration. The model might inspect the header, find a supplementary note on another sheet, then revise a mapping after checking the target field. It can choose the investigation order. Explicit decisions give it something specific to revise when new evidence arrives.

Those decisions can still be wrong. If the model maps the quantity column to the unit price field, software may read every number correctly while importing the wrong business meaning. An explicit mapping lets a reviewer compare the decision with the source and target definitions. Software tests can check reading and writing independently. Each responsibility has something concrete to inspect and fix.

Type rules, permission checks, write ordering, and agreed retry and idempotency behavior can become properties of the software. We can test whether a customer match skips creation or whether multiple matches lead to confirmation without asking the model to read the quotation again.

Even an apparently minimal task may contain responsibilities that software can execute deterministically. Moving them into software reduces the work the model has to perform on each run. The model may still face difficult structural and semantic questions. It need not also copy hundreds of numbers accurately or reconstruct the execution of rules that are already known.

The task then depends on the model getting fewer things right at runtime. Previously, the model might have had to identify the price source, reproduce every value, and remember the order of search and creation. The last two responsibilities now have deterministic implementations. Fewer conditions depend on the model's answer, and the remaining ones are easier to see.

The causal chain starts with task definition. A more precise question makes the model's responsibility clearer. More of the remaining responsibility can become a software property. Less of the task then depends on the model's decisions and generated output at runtime.

A smaller problem may result. Splitting one task into ten model calls does not achieve this if every call still mixes interpretation, retrieval, and execution. The useful distinction is what the model must decide and what can follow established rules once it has decided.

This definition work carries domain knowledge. ERP imports involve main records, line items, and object relationships. Procurement approvals involve amounts, permissions, and supplier rules. A general model may understand all of them. Each actual task still has its own facts, preferences, and execution requirements.

A general-purpose agent can help define that work or call specialized capabilities with established domain rules and execution mechanisms. A specialized agent can also serve users directly. The number of specialized execution mechanisms a system needs does not tell us how many separate products users will see.

A useful test of a specialized agent is whether it defines the model's problem more accurately: which facts must be obtained, which choices require judgment, and which user requirements can already be enforced by software. Stronger models can take on a wider range of judgments. Software still has reason to take over responsibilities that have been settled.

The model can be general. The question cannot.