In the Agent Era, the Scope a Specialist Software Supplier Can Choose

Adding agent features to specialist software looks like a decision to put one more chat window on the screen. You take the user's question, build an answer from the product's data, and show it. But there is more than one way to build that same screen, and the one you pick changes what is left in the supplier's hands a year later. I think this choice shapes the scope a supplier can sell in the future more than the polish of the feature does.

This is part 4 of the series. Part 1 covered the separation between a general-purpose worker (agent) that uses many tools and the specialist tools themselves. Part 2 dealt with placing an agent runtime inside the organization for that worker to operate in, and Part 3 looked at how experience gained in the field flows back into the product. In this series, "worker" refers to this general-purpose agent, not a person; people are called people. Part 4 applies the same view to the business choices of specialist software suppliers.

As I see it, the most important first step is building an interface through which a general-purpose worker can use the product's specialist functions. If the customer has no agent runtime ready, one option is to supply a scaled-down agent along with the product. Even then, I think the product's specialist functions and work assets should be designed so that other compatible workers can use them in exactly the same way. In this post, I call the scaled-down agent supplied with the product an embedded agent, the name used in Part 1.

This choice carries over from product development into business. For a general-purpose worker to use a specialist product, the customer's organization first needs a place for that worker to operate. For customers who already have that environment, you connect the product. For customers who need a runtime to take on broader work, consulting on and building general-purpose agent infrastructure comes along with it. Supplying an embedded agent and building organization-wide infrastructure are different scopes of supply, and which one to take depends on the customer's readiness and needs.

People at customer companies already use workers like Claude Code on external networks. I expect demand to grow for applying that way of working to internal code and operational data as well. But on internal networks the models, runtime, tool connections, and execution permissions are not in place, so that flow breaks. Closing this gap, and getting customers to use the specialist product inside the workflows they already know, is the common starting point for both the product-side task and the infrastructure-side task.

Two internal structures behind a single report

Picture a user typing "Investigate why the service has been slow since this morning." The agent goes through monitoring metrics, logs, and recent change history, then organizes the facts it found and its hypotheses about the cause. What stays on the screen is the user's request and a one-page report written by the agent. But the internal structure that produces this page can take two forms.

The first implements the investigation order, the analysis rules, and the way tools are called, all inside the code of a product-specific agent. The second exposes the product's specialist functions as callable tools, bundles the instructions and investigation procedure into separate work assets, and has the agent read and use them. The report the user receives is the same in both cases.

The difference shows when a second requirement comes in. If the customer wants to call this product from a worker they already use, swap the runtime, or attach the same investigation capability to another task, what has to be rebuilt differs. If specialist functions and work assets are bound inside a particular agent, they have to be pulled out or reimplemented. If the boundary is drawn from the start, the functions and assets stay as they are and only the connection changes.

A dedicated agent can also be built to call external systems. So the question is not whether it can call external tools. It is which implementation those connections and work assets belong to. The fork in the road is whether the ability to use a specialist monitoring product well stays as the internal implementation of one particular agent, or becomes a product asset that many workers can draw on.

The later you draw this boundary, the more it costs. When building the first feature, the effort difference between the two structures is small. But once a second runtime and a third task appear, you first have to separate the work assets out of an already-written execution loop, and then check whether the behavior accumulated so far has been reproduced faithfully. If you set the boundary now, the investment in the first feature carries over unchanged to the next runtime and the next task.

Being able to call something is not the same as being able to use it

The interface is where an agent finds a product's functions, understands them, calls them, and uses the results in its next step. I'll reuse the point from Part 1 as it was stated there: being able to call a function and being able to use it appropriately are different problems, and the interface does its job only when both are in place.

Suppose you expose a function that queries metrics for a given time window as a tool. The agent needs to know how to specify the target and time range, what units and meaning the returned values have, and how to tell a case with no data apart from a failed query. For analysis results, it should also be able to see under what conditions a value was produced and what it is based on. Making sure this meaning holds steady when a different worker calls the same function is the interface's job.

Work assets sit on top of this. They package which function to use for which question, what to look at first in an investigation, and how to read the results, as documents and Skills, plus scripts where needed. Shipping functions and work assets together means agents spend less time fumbling toward the right usage by trial and error.

An interface like this becomes the path by which the product enters workflows the customer already has. An operations engineer's investigation does not end with one monitoring product. If they need to look at the log system, change history, and internal documents together, the organization's worker has to be able to carry that work forward and call the specialist monitoring product's functions at the moment they are needed.

There is a gain on the supplier side too. The product's specialist functions get paths to be used both in the embedded agent's screen and in the customer's other working environments. When moving to a better model or runtime, the analysis functions and work assets come along unchanged. Of course, which environments to actually support has to be decided by checking connection methods, permissions, and model and runtime capabilities one by one.

So the first development task is to pick, from representative work, the functions to hand to the agent and to expose those functions and work assets in a consistent form. The choice of connection method, such as an API or MCP, is the means of implementing this. What to check from the product's perspective is how well real work gets done through that interface.

If the embedded agent and external workers use the same door

Many customers do not yet have a general-purpose agent environment. To let them use the product's agent features anyway, one option is to supply an embedded agent. The embedded agent narrows general-purpose execution capability down to what the first task needs, but it uses the product's specialist functions and work assets through exactly the same interface as external workers.

What goes into the embedded agent by default is common execution capability. It keeps track of the user's goal and context, reads the instructions provided, calls tools, and takes results into the next step. Deployment and operational configuration are also trimmed to what the first task needs. On the product screen, it can be attached as a dedicated assistant that explains usage and helps with the first investigation.

Specialist knowledge sits with the product functions and work assets. The product handles metric computation, data processing, and specialist analysis, and the instructions for using those functions and the investigation procedure ship as documents, Skills, and scripts. No product business logic is planted separately in the embedded agent's execution engine. The embedded agent and the customer's general-purpose worker see the same functions and the same assets.

Work functions that run in a fixed order under fixed conditions are implemented inside the product, and the product can also call a model directly during analysis. The agent uses these functions as tools while holding the goal and context of the overall task. This is how responsibility divides between the product's internal implementation and the execution agent that uses the product.

If this boundary holds, a customer can start with the embedded agent and, once the organization's runtime is ready, connect the same product functions and work assets as they are. The supplier also has less reason to maintain separate analysis logic for the embedded agent and for external workers. When the runtime changes, connections and quality still need rechecking, but rebuilding the entire set of specialist functions is avoided.

Conversely, if the investigation procedure and interpretation rules go into the embedded agent, that agent becomes the product's only entrance. The moment the customer wants to do the same work with their own worker, the supplier ends up implementing the same knowledge a second time, and from then on also has to make sure the two implementations do not produce diverging results.

The change as seen by whoever picks up the investigation

A person investigating an operational anomaly moves between several screens, lines up the same service and time window, gathers material, and decides what to look at next. When handing the investigation to another team, they re-explain everything they have seen so far from the beginning. What an agent can take off their plate is this repeated preparation and execution.

Here is an investigation flow a supplier could set up after looking at the customer's systems. The worker gathers metrics, logs, and change history within the permitted scope, runs the specialist monitoring product's functions, and organizes the results together with information from other tools. The output separates observed facts, cause hypotheses, and things that need further checking, and attaches evidence. This flow has to be designed and verified on the basis of the material and tools the customer can actually access.

When the flow works, the time people spend moving material around and aligning conditions goes down. The person in charge spends their time on the important claims and the remaining uncertainty, and the next person reads the execution record and picks up where things left off. Part of the burden of learning each tool separately is lifted as well.

A customer already running an organizational worker uses the product within that flow. A customer that is not ready starts with the embedded agent. Whichever side they start from, keeping the product's specialist functions and work assets in continued use is what continuity means from the customer's side.

The tool connections and per-service information prepared for anomaly investigation also get used for periodic reports and post-deployment checks. They do not carry over as is, though. You have to check the target work and permissions and adjust the procedure. Even so, valid connections and knowledge become the starting point for the next task. What remains with the customer is a runtime and tool connections that actually run, work procedures they can revise, and work records they can trace back through later.

You need to decide how far to delegate each of querying, analysis, drafting remediation plans, and actual operational changes. If you start with investigation and report writing, the completion criteria are set to match that scope. The standard is what the person receiving the report was able to judge, and on what evidence. Expanding to drafting changes or applying them to operations comes after that standard is met.

The customer's readiness determines the scope of supply

Once the boundary of the worker that will use the product is set, the next question is where and how to operate that worker. This is where product design connects to the infrastructure business.

Depending on what working environment the customer has and how far they want to extend the work, the scope of supply splits three ways. In all three cases the product's specialist functions and work assets are the same; what changes is the runtime and the scope of connections.

These three are not fixed tiers. A customer that started with the embedded agent may later set up an organizational runtime, and a customer that already has an environment may only fill in integration and operational features. If specialist functions and work assets are kept common, the same assets follow the customer into whichever row they move to.

To turn the runtime setup covered in Part 2 into a business, you first have to decide what to leave with the customer. The starting point is writing down, together, the work to delegate, its completion criteria, the systems to be accessed, and the permitted scope of execution. Runtime selection criteria were also covered in Part 2. What a supplier additionally has to decide is the scope to develop in-house. It is better to focus on parts needed only in the customer's environment, such as connecting the organization's workspace and authentication, or features that hand off work and manage its state. A custom runtime or a fork is something to choose after weighing the long-term maintenance burden. If the product's specialist logic stays in the product and the instructions and procedures stay in work assets, the same investment applies whichever runtime is chosen.

What the supplier needs to anchor in this business is understanding the customer's work, designing the overall setup, and connecting the specialist product with other tools to verify actual results. For the common operations layer, components like ToolHive, LiteLLM, and Arize Phoenix, examined in Part 2, can be candidates, and for inference infrastructure, vLLM, llm-d, and others. What matters more than which tools went in is whether you can explain and demonstrate that the work the customer wants to delegate actually gets done in the environment that ties them together.

Handover includes operations manuals and training, verified work procedures, and evaluation cases. It also records which configuration and versions passed, who receives incidents and which layer they get classified to, and who rechecks what when models, runtimes, or tools change. Even after the build is done, the connected systems and work procedures keep changing. Fixing connections, updating work assets, checking quality after changes, and investigating causes of failure make up the scope of the operations and improvement service. How much to actually take on, and under what contract to provide it, is decided by looking at the customer's needs and the support burden.

Sometimes the need for a runtime surfaces while applying the product, and sometimes work that uses specialist tools takes shape while building the runtime. That is why the two businesses connect. But if you lump together customers who only need a product connection and customers who also need infrastructure, you overestimate both the scope of supply and the business opportunity.

Who writes the completion criteria for the first task

Whether this structure actually works shows up in a single first task. When choosing the first task, what matters is not difficulty but whether its completion criteria can be written down. For an operational anomaly investigation, that would be a scope like setting a target and time window, looking at the material, and producing a report that includes evidence and things to check further. Within this scope you divide what the specialist monitoring product will handle, the role of other systems, and the points where people make the call.

Completion criteria written by the supplier alone are useless. The customer has to be able to read the same sentences and reach the same verdict. For a first investigation, such items include whether the query target and time range are correct, whether the report's factual judgments can be traced back to the source material, and whether parts with no data or failed calls are surfaced rather than hidden. Whether to also delegate pinning down the actual cause of an incident is decided separately.

Anthropic's guidance on AI-driven code modernization explains that you should first define the target state, verification conditions and tests, and the actual rollout procedure, run the whole process end to end at a small scope, and then expand. The approach puts the process of people reviewing results and accepting them into their work inside the execution design. Applied to supply, what you leave with the customer includes not only a running environment, work Skills, and procedures, but also the agreed completion criteria and evidence that those criteria were met.

Writing the criteria down makes comparison possible later. When you revise the investigation procedure or change the model and runtime, you can measure what changed with the same ruler. Whether a supplier can build this kind of verification and acceptance system to fit a customer's real work is what its consulting and build capability amounts to.

When running the first task, if the customer has a runtime ready, have them use it there first. If not, start with the embedded agent. Once one side is running, trying the same assets in another compatible worker reveals whether the meaning of the work is trapped inside a particular runtime's internal implementation. It settles the scope of reuse by running it rather than by claiming it.

The gain on the customer side becomes visible only when total time to reach the same completion conditions, time people spent directly, and quality of results are looked at together. Even if the report came out quickly, if the person in charge re-investigates all the source material, the burden has not gone down. The math on whether the actual work improved adds up only when review and rework, handling of connection failures, and model, infrastructure, and maintenance costs are included.

The supplier side has to be measured with a different ruler: whether specialist functions get reimplemented when attaching to another runtime, how much of the existing connections and work assets can be carried unchanged to a new customer, and in which direction per-site modifications and support burden move. Whether there is real demand for infrastructure building and operations support, and whether that scope can be sustained, also shows up in the same period.

What comes back from the field and what does not

Part 3 described the relationship between field application and accumulation as seed and germination. It also laid out the criteria for what to leave as site-specific configuration and what to reflect into the common product. What Part 4 adds is how those criteria are used at the point where business assets are divided.

The configuration, work procedures, and execution records provided to the customer have to be kept distinct from the implementation and verification cases the supplier will generalize. A customer's source data or internal knowledge does not automatically become the supplier's reusable asset. Technology and execution experience can be organized and moved into the common product only within the scope where sharing and use are permitted, and drawing that line is itself a matter of contracts and the relationship on site.

The zero-memory-usage case discussed in the first person in Part 3 reads differently from this angle. If you pick the wrong field, the mapping succeeds and result rows are produced, but the value stays at 0. What is worth keeping is not the fixed code but the conditions that reproduce that failure and what needs checking in the next implementation.

Recurring tool connections and data transformations are bundled into common adapters, investigation procedures that worked are organized into work assets, and real failures are kept as reproduction cases. Then you can assess whether the burden of investigating and implementing the same problem from scratch at the next site has actually gone down.

Field application and common product development are not a relationship where one ends and the other begins. The period of solving the customer's problem also includes the work of organizing the solution so it does not stay locked in one particular project. There has to be a process of picking out, together with the product team, what among the people's experience, connection code, work assets, and verification cases can be used in the next engagement.

What remains on each side is different

The choices so far leave results on both the customer and the supplier side, but what remains differs in character. The customer is left with an environment they can use, and the supplier with assets to carry to the next customer. Both come from the same design, but the conditions under which each holds have to be looked at separately.

On the product side, the paths through which a specialist product takes part in the customer's work widen. If specialist functions can be called not only from the product's own screens and embedded agent but also from the working environment the customer chose, the places where the product is used increase. Because analysis functions and work assets are kept as a single set, existing investment carries over unchanged when runtimes are added.

In exchange, the set of things you are compared against grows. Once the interface is open, the same worker can also call other specialist tools. The competitiveness a supplier needs comes from how useful the specialist monitoring product's functions are in real investigations, how well the results can be read and scrutinized, and how reliably it attaches to the customer's environment. The interface only opens the opportunity; whether that leads to actual use and purchase is decided by this usefulness.

On the business side, the supplier ends up also supplying the environment needed to attach the product to the customer's work. Depending on the customer, the scope varies across product connection, embedded agent provision, organizational infrastructure building, and operations support. Business value can be judged only by weighing together the scope of design, connection, and verification the supplier takes on directly, the customer demand for each scope, the execution cost, and the ongoing support burden.

On the accumulation side, a solution found at one site changes the next product and the next engagement. But this accumulation does not happen on its own. Maintaining a common interface and checking behavior across several runtimes costs development and operations effort, and feeding field experience back into the product takes its own time. How much that investment reduced repeated implementation and support burden, and how much it widened where the product is used, shows up separately in three results: product competitiveness, the scope of new contracts won, and execution cost. If only one of the three improved, the conditions for the other two do not hold yet.

Where this choice wavers

Separating the boundary is not always the better deal. If certain conditions break, binding things together is cheaper. I think these three should be examined before accepting the argument of this post.

First, the case where the interface is open but the customer's organization has no worker to use it. If the embedded agent is effectively the only user, the cost of maintaining a common interface does not tie to near-term revenue. In this case all the gains of separating the boundary lie in the future, and how near you think that future is decides the judgment. The real variable here is how long it takes for people who use workers on external networks to demand the same way of working on internal networks.

Second, the case where specialist functions and the investigation procedure are hard to separate. Some functions carry their analytical meaning in the order of calls, so splitting them into individual tools changes the result. For such functions it is better to bundle them into a single tool so the product enforces the order, and have the agent call that bundle. Separating the boundary does not mean slicing functions into small pieces. The line should be drawn not by the size of a function but by "who has to fix this when this knowledge changes."

Third, the case where the product's differentiation is meant to lie in the agent experience itself. Once the interface is open, the same worker also calls competing products. If the conversational experience, rather than data and specialist computation, is the whole of the differentiation, opening the interface erases that differentiation by your own hand. That said, the shutdown of ML Intern, covered in Part 1, points at the same spot from the opposite direction. If expertise is supplied bound to a dedicated runtime, the expertise stops when the runtime stops. Differentiation defended by conversational experience stands only on the premise that the runtime stays competitive.

Even with all three conditions on the table, I think the default is to separate the boundary. What specialist software holds is data and specialist computation, domain rules and verification methods, and these do not lose value when the worker changes. Execution loops and context management, on the other hand, are an area where general-purpose runtimes improve much faster. Holding on to something that is not your own asset blocks the channel through which you could take in those improvements.

The customer gets an environment in which to tie together their tools and work and hand tasks off, and the supplier gets a specialist product that is called upon in that environment, build and operations capability, and execution experience to carry to the next site. Neither is completed by a single first feature. But how the first feature is structured sets the ceiling on what can be built on top of it later. If the value of specialist software remains in tools, data, and work procedures, the agent features being built now should remain there too.