Separating the Worker from the Tool

More and more products ship with AI built in. Document tools summarize documents, monitoring tools explain anomalies, and collaboration tools organize conversations. But the work users actually want to get done spans several products. Even if each AI gives an answer, someone still has to connect those answers and decide what to do next.

General-purpose agents are a new kind of general-purpose worker (agent) that takes on this job. In this series, "worker" refers to this general-purpose agent, not to a person; people are called people. A worker understands a goal, uses multiple tools, keeps track of context, and carries the work forward. Customers may already be using their own worker outside your product. That worker expands what it can do by learning other tools and Skills. Specialized software, too, is shifting toward handing its features and usage knowledge to this worker. In this post I look at that shift through the lens of "separating the worker from the tool." This is the first post in a four-part series on the relationship between specialized software and general-purpose agents; the next post covers how to operate this worker inside an organization.

Work crosses product boundaries

One of the things that drew my attention to this shift was the post "Claude Blue - All of Silicon Valley Is Depressed". What caught my eye was people carrying several tasks forward in the terminal through Claude Code and Codex. A plain command prompt was turning into a workspace where many kinds of software are used together.

Behind that plain terminal screen, the agent reads files, runs code, finds and compares material, queries other systems, and then produces a result. The user explains the goal to the same worker and keeps the work going. A single acting entity can now connect and use many tools.

Consider investigating an operational anomaly. When an alert says response times have spiked, you need to check metrics, search logs from the same time window, and compare them against deployment history and configuration changes. Past incident records or conversations among the people responsible might offer clues. The findings need to be written up as a report that others can review.

Analytical databases like ClickHouse and observability and search tools like SigNoz and Elastic support MCP so agents can query data and use their features. In SRE (Site Reliability Engineering) work, which deals with service reliability, these touchpoints can be tied into a shared workflow. For example, when a P99 latency anomaly is posted to Slack, a workflow built around Claude Code can be designed to investigate metrics and logs, write a report, and ask the person responsible to review it.

Anthropic's Ship your first managed agent workshop includes a demo that investigates metrics, logs, and change history, identifies database connection pool exhaustion as the cause, and recommends a fix. The same flow appears in the design write-up for Managed Agents and the workshop example code. The work gathers evidence from several tools and compares hypotheses under a single investigative goal.

If a product's features can only be used by its built-in agent and there is no touchpoint for an outside worker, this kind of investigation tends to break off at the product boundary. There is one investigative purpose, yet you have to explain it again in every product and carry results from one chat window to the next.

If each product offers its features and results to an outside worker, the worker can carry the whole investigation across products. The product is responsible for the specialized features, and the worker decides which feature to use when and drives the flow of the work.

A worker that uses many tools

An agent has both a head that thinks and hands that act. It can move around the work environment, read files, run commands, and use many tools. It is closer to a worker that has both the ability to judge and the means to handle tools. That is why the worker-and-tool metaphor fits the relationship between specialized software and agents.

Here the tool provides its specialized features, data, and state. A database runs queries, a browser opens and manipulates pages, and a design tool edits documents and objects. The worker decides which tools to use in what order for a given goal and connects the results.

A general-purpose worker is not tied to a specific product; it learns how to use many tools to accomplish goals. A tool provides touchpoints for that worker while staying responsible for its own specialized features and internal decisions. Products can also have AI and specialized agents inside them, and I will look at their role later.

This relationship recalls the separation of frontend and backend: you draw a boundary between parts that have different responsibilities and different reasons to change, and couple them through that boundary. The principle also connects to the thinking that produced hexagonal architecture, which keeps core business logic from being tied to a particular screen or external technology so that people and other programs can use the same features through their own touchpoints. This separation is possible even within a single screen and a single install package. In this post, "external agent" means an acting entity distinct from the product's own features; which server it physically runs on can be decided separately.

The agent runtime as the worker's execution base

Between a model generating an answer and a worker carrying work forward, you need an execution structure. It has to turn model output into actions, take tool results and decide the next action, and maintain the context and state of the task. In this post I will call that base the agent runtime. It includes the harness that forms the execution loop and the features around it, though what each product provides and how it is deployed can differ.

Claude Code and Codex are general-purpose workers that read and write files, write or run code, and connect the results of many tools. These abilities are used not only for development but also for data analysis, document writing, and operational investigation. Other runtimes such as OpenCode, pi, Deep Agents, and Eve also provide a common execution base for many kinds of work.

This is also why coding ability becomes a general-purpose pair of hands. Code is a common means of calling existing APIs and libraries, transforming data, and composing multiple steps. Where you once had to build a new dedicated execution engine for each kind of work, you can instead give tools and knowledge to a worker that already exists.

This kind of execution base is also offered as services and developer tools. Claude Managed Agents and OpenAI's agent development tools connect model responses into multi-step tasks. You can assemble work by attaching Skills, hooks and plugins, tools, and execution and verification environments such as CI to an agent.

In explaining the design of Managed Agents, Anthropic separates the "brain" that drives the agent's reasoning and execution from the "hands," the environment where tools run. That distinction concerns the architecture for implementing and operating the runtime. The worker/tool distinction I am drawing concerns the design boundary between the entity doing the work and specialized software. The two distinctions hold together at different layers.

OpenClaw and Hermes emphasize an assistant role, and Cowork emphasizes a workspace for work. Their user experience and mode of operation differ, but because each has an execution structure that keeps goals and context, uses tools, and carries work forward, they can be understood as agent runtimes.

The interview with Cursor's Lauren Tan shows how, inside Cursor, bots work with their own execution environments and recurring tasks while people review the results. A worker that takes on ongoing work needs a place to run, tools, and a structure for continuing the work.

Just as the JVM runs Java programs, the Python interpreter runs Python scripts, and Node.js or the browser runs JavaScript, the agent runtime becomes a common base on which features are provided. It differs from traditional language runtimes, though. An agent interprets goals and instructions and composes part of the execution path itself, and the code it writes or calls along the way can in turn run on existing language runtimes.

Natural-language instructions also make up applications

When the execution base changes, so does the way features are deployed on top of it. The agent runtime already provides the common abilities needed for reasoning, tool use, and making progress on tasks. A package can carry the goals, procedures, constraints, and judgment criteria for applying those abilities to a specific kind of work.

A talk on the relationship between agents and Skills, along with a related short video, also describes combining work knowledge and tools with a general-purpose agent. The common execution ability is reused across many kinds of work, and the differences between them are delivered through Skills, tools, and rules.

I see Skills and plugins as a new way of packaging applications. They do not have to include large amounts of code or binaries. If a combination of natural-language instructions alone expands what users and agents can do together, that package is providing a new capability.

For example, a report-review package can instruct the agent to distinguish facts from hypotheses, check the sources of figures, find missing evidence, and write review comments in a set format. Even if the package contains only natural-language instructions, it delivers a feature by using the agent's abilities to read files, search, and write documents. Verification scripts and reference material can be added too.

Natural language takes on part of the role of code that defines actual behavior. Because how instructions are interpreted and executed depends on the capabilities of the model and runtime, you also need a process for checking and improving the results. Bundling instructions, distributing them, and applying them repeatedly has become part of how software is put together.

A package looks thin because the runtime provides the common execution ability. That does not mean the work knowledge or judgment criteria inside it are light. MedSci Skills provides, for use in existing agents, the specialized knowledge needed for literature search, checking citation and reporting guidelines, and producing statistics and publication-ready outputs. Packages like this support specialized work on the premise that the researcher reviews the output and remains responsible for it.

Hugging Face Skills likewise gives existing workers such as Claude Code, Codex, Gemini CLI, and Cursor the instructions and tool usage needed for model training and evaluation and dataset processing. Users can add a package to an agent they already know and hand it new specialized work. Here the unit for distributing specialized features has widened from a separate executable program to a bundle of knowledge and procedures that a common runtime interprets and carries out.

From this perspective, a feature is made by combining a package, a runtime, and the tools available. So the same package can do more or less depending on the execution environment and the tools connected to it. The claim that the agent runtime is the execution base for a new kind of software includes this relationship.

Individual runtimes are also bringing this kind of extension into their own platforms. Claude Code's Mods let JavaScript or TypeScript modules packaged in plugins hook into session events and tool calls and add new features and views. DeepSeek Harness puts forward the principle "Everything is a Plugin" and builds the harness as a combination of plugins. From Skills that convey work procedures in natural language to code that extends execution behavior itself, the range of what can be layered onto a common runtime is widening.

Environments for handling work outside the runtime are also appearing. Herdr, Orca, and Paseo are different options for operating existing agents. Traycer and Raven also connect acting entities and coordinate work in their own ways. Behind them is a shared need to handle the placement, progress, and results of work beyond a particular runtime's chat window.

Individual runtimes are evolving into platforms that accept features, while external Agent OSes and orchestrators treat multiple runtimes as common units of work. Since runtimes differ in tools, permissions, and state management, you also have to check the execution conditions and compatibility of the same package on each. Handling these differences at a higher level resembles how Kubernetes manages the resources and workloads of many nodes in a common way. The agent has become a unit to deploy and manage separately from individual specialized tools.

The ways software takes in agents

General-purpose workers develop outside products too, and learn how to use other tools. Specialized software needs to be able to pass its features and usage knowledge to that worker. The same design problem arises not only for instruction packages but also for applications with their own screens, data, and distinctive features: providing a path for the customer's agent to discover and use the product.

I will call products designed with agent use in mind "agent-friendly software." They share the philosophy of making room for the worker, but they come in three directions depending on where the product starts and where it is headed.

The first is tools that assume from the start that agents are the main workers. pen.dev and ego-lite can be seen this way. pen.dev's documentation describes both using the integrated agent inside the app and connecting external MCP clients. It connects workers while keeping its own design documents and editing features, and its public integration example shows how that touchpoint is implemented.

ego-lite's public implementation is designed so that people and agents each use the browser in their own workspace. The agent reads a Skill and uses JavaScript tools provided by the browser to inspect and manipulate pages. The app, the Skill, and the execution interface together form one user experience. It offers an independent app as an agent's tool while letting people keep working in the same environment.

The second is extending existing specialized tools so agents can use them well too. ClickHouse provides knowledge about schema design, query optimization, and data ingestion as official Agent Skills. Arize also provides Skills and MCP touchpoints so external coding agents can use features such as tracing and evaluation. These make the features accessible while also delivering the knowledge for using them well. Efforts like QGIS MCP fit here too, as ways of connecting existing specialized software to agents as tools.

The third is bringing agents into the spaces where people already work. Collaboration products such as Slack, Notion, and Jira are where documents, conversations, and work status accumulate. When agents join these spaces, people and agents can draw on the same work context and exchange results. Slack's MCP and Skills Plugin is a concrete example of such a touchpoint. However, which features can be connected may vary with the path used to install the package and with the runtime.

This classification describes where a product starts and where it is headed. Tools built around agents still have screens that people operate directly, and existing collaboration platforms may provide agent execution features. A single product can take several directions at once.

The ways these products deliver features to the worker also vary. A Skill might be a single markdown instruction file, or it might include a small script or call an npm package. It can also be the entry point that conveys how to use and access an independent application. Skills, plugins, and integrated applications connect within a single usage flow, depending on how the feature is implemented and delivered.

HKUDS's CLI-Anything is another attempt to connect existing software to agents through a command-line touchpoint. It points in the same direction: connecting specialized tools to the execution abilities agents already have.

WebMCP is a touchpoint that exposes a web page's features as tools with descriptions and input schemas. An agent connected to the browser can call them to use the web service. As of October 2026, it is being discussed as a W3C Community Group draft and is in trial in Chrome and Edge.

Developers can register existing JavaScript functions as tools, or expose HTML forms by giving them names and descriptions. The site's code performs the actual behavior, and the results are reflected in the screen and application state the person is looking at. Compared with a regular MCP integration, WebMCP focuses on people and agents collaborating while sharing context on an open web page.

JupyterLite WebMCP, a winner of the OpenAI WebMCP Challenge, adds this touchpoint to an existing specialized tool. It exposes reading, editing, and running Jupyter notebooks in the browser as tools for agents. The agent uses the same execution kernel that holds the notebook and data the person is editing. The submitter says it was built as a Jupyter frontend extension, with no built-in LLM or separate chat window.

The research tool's features and state stay in Jupyter, and the user's agent makes use of them. The existing screens and business logic stay in place, and a new worker gets a path to use them. Through this path, specialized software can take part in larger workflows.

Tools that are good to use from the agent's side

Beyond building touchpoints, you need to design them so agents can use them well. An agent needs to be able to discover features, construct appropriate inputs, understand results, and decide what to do next when something fails.

In JupyterLite WebMCP, the agent can read text the user has selected and check its changes in the relevant cell. If a person edited the content first, a check prevents the agent from overwriting it based on stale state. In the suggestion mode for cell edits, you can review the before and after and accept or reject the change. Touchpoint usability includes reading the current state accurately, respecting other participants' work, and making results verifiable.

For log queries, too, the format and scope of the returned information matter. If you return hundreds of thousands of lines as-is, the worker burns a lot of context and compute finding what it needs. Searching by time range and conditions and returning relevant logs along with surrounding context makes investigation easier. When input is wrong, an explanation of how to fix it lets the next attempt proceed.

Anthropic's post on tool design deals with this difference. It argues that you should define functional units that fit the work the agent will do, return highly relevant information, and refine descriptions and error messages for actual use. Whether a tool call succeeds and whether the agent completes the work with that tool need to be checked together.

Glean CLI shows this concretely. You can look up a command's schema, check the content before sending a request, and pass structured results to other processing steps. The Skill distributed alongside it teaches agents how to use the CLI. Search, Glean Assistant, and running internal agents are all available from the same command-line touchpoint.

This is design that takes the worker's characteristics into account. An agent can write code to compose many calls, but its working context is limited, and it can misread ambiguous descriptions. To make effective use of the worker's abilities, you have to provide, alongside the specialized features, the knowledge and touchpoints for using those features correctly. Part of the effort people once spent learning how to operate a product now ships with the product in a form the worker can read and use.

AI inside the tool and specialist workers

A product's specialized features and work knowledge should be usable by the worker the customer has chosen. AI inside the product can also be designed to fit its responsibilities while preserving this boundary. I will describe it in three parts: components that perform defined functions, a default worker that uses the product, and workers that handle delegated specialized work.

The first is calling a model within a workflow whose execution order and branching are explicitly defined. For narrowly scoped functions like classification, extraction, and transformation, code can control execution and use a model at the steps where it is needed. In this structure, accuracy, latency, and cost are tuned and verified for that function. The quality of model output still needs to be checked separately, but there is less need to autonomously plan the entire task every time.

Services like Jina Reader, which return content in a form that other workers can easily read and use, can be understood the same way. What matters to a user or agent is what useful result they get from a given input. Which AI is used internally is an implementation choice made for the accuracy and efficiency of that feature.

The second is shipping a default worker that uses the product. A built-in agent can be set up as a lightweight concierge that integrates conveniently into the UI and helps with first tasks. If you separate common execution abilities, such as keeping goals and context and using tools, from the product's own features and work knowledge, the external agent the customer has chosen can use the same tools. Like pen.dev, seen earlier, this approach provides both an integrated user experience and an access path for external workers.

The third is a specialized agent inside the product taking work delegated by an external worker. The external worker passes goals and conditions through an API, CLI, MCP, or similar, and the internal worker decides how to carry them out within a limited set of tools and permissions and returns the result. The internal agent's autonomy and execution structure can then be designed to match the scope of its specialized work.

The connection method is chosen to fit what is being exchanged. A2A handles interaction and task collaboration between agents, and ACP, the Agent Client Protocol, connects clients such as editors with coding agents. You can also provide tools for direct manipulation while delegating some specialized work to an internal worker.

Notion Custom Agents can be seen as an example of an in-house-employee-style worker with assigned duties and an access scope. Whether such a worker operates inside the product and whether an external worker can call or replace it are separate questions to verify.

In Glean, you can see both tools for external workers and workers inside the product. Users ask questions in Glean Assistant, and external agents can use MCP and the CLI described earlier to access enterprise knowledge or look up and run Glean agents. Waldo, an internal search component, gathers evidence with defined search tools and then hands control and context to a frontier model. It runs first to reduce latency, and it differs from a sub-agent structure that an external model calls every time. Glean agents' external execution path does not mean Waldo itself is called directly.

A general-purpose worker values the ability to handle diverse goals and tools, autonomy, and persistence of context. Specialized components inside a tool can be designed for the accuracy, latency, cost, and resource efficiency of a limited function. The names "worker" and "tool" are not fixed to a particular company or product. In a relationship where something receives a goal and performs the work, it is a worker; in a relationship where another worker uses its features or delegates work to it, it is a tool or a delegate. Responsibilities and interfaces need to be made clear according to this relationship.

Where the value of specialized software remains

The more general-purpose workers become, the clearer it becomes what specialized software provides. Data and state, specialized computation, domain rules, and verification methods accumulate in the tool. The worker uses those assets to achieve goals. Once a tool's usage can be delivered as a package, the paths through which specialized knowledge is used also widen.

Claude Science combines general-purpose execution ability with domain-specific assets. The public description includes a general-purpose coordinating agent, science-domain Skills and connectors, and research tools and computing environments. Outputs link code, environment, and work history to aid review and reproduction. This internal separation of roles and openness to freely connecting external agent runtimes are separate design conditions.

Lane 3 as described by Synopsys divides labor between an intelligent execution base and specialized tools. OpenAI takes on the model, compute, and service layers, combined with Synopsys's tools and specialized assets. The official partnership announcement also describes plans to develop a model specialized for using EDA tools and to design it to interoperate with customers' agent harnesses.

The core assets of specialized software should accumulate in tools, data, and work procedures. Improving models and agents tailored to a specific field is also possible within this structure. What matters is drawing a boundary so that models that use tools well and specialized tools can each develop and still be combined.

ML Intern was an agent that used Hugging Face's papers, datasets, and compute resources to do ML research and write and run code. It delivered specialized business logic coupled to its own agent's execution loop and context management. I think this tight coupling was a clear design mistake.

It tied expertise, which could have been offered as tools and work procedures for existing workers, to the adoption of a separate worker. Users had to accept a separate agent environment to use the specialized features, and the provider had to maintain not only the specialized features but also the role of a general-purpose runtime. What users already working with Claude Code or Codex need is for their own worker to be skilled at using research tools and execution environments. ML Intern provided that ability but also required them to choose a worker all over again.

ML Intern's repository was archived on September 29, 2026, and the shutdown notice announces the end of the existing web app and CLI and points to HuggingChat as the path forward. I think this shutdown also exposed the fragility of a design that ties the delivery of specialized features to the survival of a particular execution product.

By contrast, Hugging Face Skills, which delivers expertise from the same ecosystem to existing workers, is still available. As of October 4, 2026, the official repository had about 11,000 GitHub stars, and distribution of Skills for agents is integrated into the recommended install path for the official CLI. Demand for expertise that helps with ML research is not the same as demand for a separate research-agent runtime. Specialized software should reflect this difference in product design.

Feynman's skills-only distribution likewise provides a path for connecting research skills to existing agents without its own terminal app or runtime. Even a product that bills itself as a specialized agent can deliver its specialized features independently. What matters is turning domain knowledge and business logic into assets and offering them so that the worker the customer has chosen can use them.

For providers, deciding which workers can use their specialized features, and what to provide so those workers can work skillfully, becomes part of product design. Standalone apps, Skills, plugins, MCP, CLIs, and WebMCP are different forms for implementing this choice.

So that workers and tools can each evolve

Designing a product so general-purpose agents can use it offers three expected benefits.

First, it can reduce the burden on users of learning how to operate each product. If you provide the product's features, constraints, and ways to handle errors in a form the agent can read and use, users can focus on describing what they want and reviewing the results.

Second, work that cuts across many tools can be handed to the same worker. A worker that uses a specialized monitoring product, Elastic, a shell, and Slack investigates by connecting metrics, logs, change history, and conversations. If you have to copy results between separate chat windows for each product, the user becomes a mail carrier between agents. Common touchpoints let the worker keep context and carry the whole investigation through. Real integrations still require aligning data formats, permissions, and business meaning, but each product no longer bears as much of the burden of implementing investigation procedures with every other product one by one.

Third, you can make use of what workers and tools each achieve as they develop. If the deployment and operation of agents are separated from the product's specialized features, customers can choose the workers and resources that suit their work and keep using the product's features. Providers can focus on specialized features and usage knowledge while benefiting from improvements in general-purpose runtimes.

Providers can build tools for general-purpose agents to use and help customers set up environments to operate those workers. For customers without such an environment, they can also ship a built-in agent that uses the same product touchpoints. The design aim is that specialized features and work knowledge remain usable even when the customer's execution environment changes.

Just as we have given people screens and instructions, we need to give agents features, usage knowledge, and execution results. Natural-language instructions, executable packages, and standalone applications are different forms for delivering that combination. A product's expertise should keep reaching the worker the customer has chosen and be able to take part in larger workflows.

The next question then turns to the organization: where, within the organization's context and permissions, do you place this worker that uses many tools, and how do you operate it? In the next post, I will argue that every organization, including those on air-gapped networks, needs an execution base for general-purpose agents.