Every Organization Needs an Agent Runtime

"Every organization should have Claude Code."

By Claude Code I mean a general-purpose agent runtime: something that takes a goal and keeps working on it with many tools. Whether an organization uses internet services freely or runs an air-gapped network, I think it will end up treating this kind of runtime as a basic part of the work environment. People hand work to an agent, and the agent uses tools inside that person's working environment.

This is part 2 of a series. In part 1 I looked at agents as general-purpose workers that use many tools. Software provides the interfaces through which this worker can use its functions and data, and Skills and plugins extend what the worker can do. I expect this shift to reach air-gapped networks too. Enterprise software should also be designed on the assumption that customers run general-purpose agents.

I think automating and organizing work with general-purpose agents will become the normal way of working. My guess is that people in customer organizations are already getting a sense of what is possible by using tools like Claude Code on the outside network. What they will expect for internal work is the ability to apply that familiar way of working to their real code, data, and internal systems.

At the center of that way of working, I expect, will be an agent running on the user's local PC. There the agent can work alongside a person, close to the folders, development environment, documents, and tools that person already uses. For day-to-day work, that convenience and the short distance to the working environment are a major advantage.

The basic structure is the same on an air-gapped network. A general-purpose agent runtime sits on the internal work PC, and that worker does its job using the organization's models and tools. Differences in network, authentication, model supply, and execution permissions are questions about how to implement this structure. Adoption starts with making the way of working people already know from outside possible inside as well.

A shared foundation for work that spans many tools

An organization's work is not made up only of predefined procedures. Problems appear that did not exist yesterday, new material has to be checked against existing material, and results from different systems have to be connected. Repetitive parts can be automated, but interpreting a changed situation and deciding what to do next remain.

Say an operations lead asks, "Find out why processing times got longer this week." That means querying metrics from the database, reviewing the deployment history, and comparing logs and configuration. If needed, you write a short script to process the data, test a hypothesis, and write a report with supporting evidence. You use the functions of existing systems, but the order in which you combine them changes as the investigation goes on.

The foundation for this kind of work is a general-purpose agent runtime like Claude Code. It takes a goal and keeps context, reads and writes files, writes or runs code, and connects the results of different tools. Coding ability is then not limited to building new programs; it becomes a general-purpose hand for working with software that already exists.

An internal chat window where you can ask a model questions is useful too. Handing it real work, though, takes more execution structure: a place to work, tools to use, somewhere to keep intermediate results, and a way to retry on failure or hand off to a person. The point where an answer ends and the point where the work ends are different.

Work that existing programs and explicit workflows handle well, such as calculation, classification, and fixed approval procedures, can stay with them. The general-purpose runtime takes on work that requires combining functions depending on the situation, and uses those programs and workflows as tools when needed.

With this foundation in place, you rarely have to rebuild an execution engine every time a new kind of work comes up. You can give the same worker new tools and domain knowledge, and define its scope and completion criteria. The argument that organizations need general-purpose agents rests mainly on this reusability.

The agent's main home is the user's PC

I expect the main place where agents do everyday work to be the user's local PC. That is where the files being worked on, code repositories, installed programs, and development environments already are. People start work in that environment, check intermediate results, and make edits themselves. If the agent can handle files and tools within an allowed scope in the same environment, passing work back and forth with a person takes less effort.

The benefit goes beyond execution speed. There is less moving material into a separate workspace, syncing the state of two environments, and bringing results back. Users can hand off work on the code and documents they are looking at right now, and check the files or changes the agent produced with their usual tools. The more small tasks get handed off day to day, the bigger this difference becomes.

The advantage holds in air-gapped organizations. If code and documents live on the internal work PC and internal systems are used from that PC, it is natural to put the agent close to that working environment too. The files, commands, and system access available to the agent should be set according to the organization's policies and the user's job permissions.

Running an agent on a local PC does not mean model inference also runs on that PC. The runtime manages context and runs tools on the user's PC, while model calls can go to an internal inference server provided by the organization or to an approved service. This structure combines local working convenience with model supply at the organization level.

Execution environments on servers or in the cloud can handle overnight jobs, scheduled recurring work, long-running tasks, and shared team automation. Even with those in place, I expect the agent on a person's own PC to stay central for everyday work, where people hand off tasks and step in at any moment. The shared operations layer should help that worker make good use of the organization's resources.

Individual experience turns into the organization's way of working

Signs of this shift are already showing up in several organizations. Internal research published by Anthropic surveyed 132 engineers and researchers in August 2025, conducted in-depth interviews with 53, and analyzed internal Claude Code usage data. It shows the same execution foundation assisting different kinds of specialist work: the security team analyzing unfamiliar code, researchers building screens for data visualization, and so on.

This study covers usage inside a company that builds AI, and its productivity figures include self-reports. What I focus on is that people, while still checking and correcting results, came to take on a wider range of work beyond their own area of expertise.

Shared context also matters in Elena Verna's account of how Lovable works. Through the company's knowledge base you can look up not only what happened but why a decision was made, and multiple agents that handle marketing, analytics, and the codebase take part in daily work. What I take from this is that for an organization to share an individual's capabilities, it has to provide work context along with execution tools.

The bot usage inside Cursor and Anthropic's operations-investigation demo from part 1 also show an agent taking a person's request and carrying the work forward with many tools. The organizations and scope differ, but I think this way of working will spread beyond early AI adopters into ordinary work environments.

The pace and approach of adoption will vary by organization. Some may start with individual work, others with recurring tasks a team shares. As usage grows, the useful settings, Skills, and tool usage patterns that accumulate on individual PCs will need to be managed and distributed as shared organizational assets. The direction is to run close to each person's working environment while also using the organization's knowledge and operating standards.

Implementing the same way of working on the internal network

Air-gapped organizations can also put a general-purpose agent runtime on internal work PCs and connect it to the code and documents on that PC and to the internal systems it is allowed to reach. The user describes a goal in their usual working environment, and the agent reads material, uses tools, and produces results. The challenge of building this on an internal network is carrying that familiar flow all the way through.

When implementing it, you need to separate where the user-facing interface, the agent runtime, and model inference live. In the basic setup, the interface and runtime are on the user's PC, and the model runs on an internal inference server or a service the organization has approved. Some tools run on the PC; others are called through internal system APIs. Only by checking what data moves along each of these paths can you configure the setup to fit the actual network boundary.

For shared team automation or long-running jobs, you can add execution environments on internal servers and private clouds. The user's PC handles conversation and ad hoc tasks, and work that needs continuous execution runs in a shared workspace. Even as the number of things to manage centrally grows, the center of everyday work can stay close to the user.

Depending on its constraints, an organization may be able to use an approved external inference service, or it may have to place model weights and the serving system inside as well. In the latter case, installing a runtime is not the end of it. The models, runtime packages, and tool dependencies have to be obtained internally, and updates and operations have to continue within that boundary. A claim that something "can be self-hosted" only means something once you check how much of it is self-hosted.

Anthropic's announcement about its Korea business says that Samsung Electronics employees are using Claude Code, Cowork, and other tools. Companies with strict security requirements are also starting to use general-purpose agents for work.

At KCD x Ceph x OpenInfra Day Korea 2026, held on September 1, 2026, kt cloud presented its experience operating MCP with ToolHive. The talk description covers what they learned and the trial and error along the way, and names identity, permissions, credentials, and operations as the main challenges for an organization sharing MCP.

These cases show that enterprises are using general-purpose agents and building the operational foundation for sharing tools. I expect air-gapped organizations to move in the same direction. That said, none of these cases validates a particular air-gapped configuration, so an actual build has to check where model inference and tool execution happen and which paths data travels.

Even with the same working structure, capability can differ depending on the models and compute available. If internal resources are limited, you have to actually check what range of work can be handed off and how good the results are. You can set the scope of use by providing the right tools and context and verifying the results. With a shared execution foundation in place, later improvements to models and infrastructure carry over to the work and tools you have already connected.

Design products on the assumption that the organization's agents will use them

The expectation that customers will eventually use general-purpose agents affects what you deliver now. Even if an air-gapped customer has no such environment yet, the product should be designed as a specialist tool for the customer's worker. The current adoption gap should not make it the default for each product to build its own separate worker and work context. Where needed, a general-purpose execution foundation can be provided along with the product.

In an organization that already has a runtime, users should be able to connect the product to the agent they use on their PC. The product provides the functions to use, input formats, required permissions, and the meaning of its results, and delivers the procedures for using it well as Skills or plugins. Everything from the agent discovering a function to checking the result is part of the product's user experience.

In an organization without a runtime, the first product deployment can include rolling out a compatible runtime to work PCs along with the needed model and tool connections. The agent provided this way should be able to use other tools, and the product should be able to work with other agents later. The first deployment then becomes the starting point for connecting the next product.

AI and specialist agents inside the product stay within this structure. Specialist components that optimize a search plan or perform a particular analysis can run inside the product. The organization's worker calls those functions or delegates work to them. This applies the worker/tool distinction from part 1 to the deployment and operating conditions of the customer organization.

Lane 2, as Synopsys presented it at its Investor Day, is a supply model in which customers use Synopsys tools with their own models and agents, and use Synopsys's agents alongside them when needed. I read this as a choice to bring the customer's own working foundation into the product's design and business model. The supplier provides specialist tools and the execution assets they need, and the specific integration scope and compatibility can be checked against the customer's environment.

The unit of delivery therefore comes to include specialist functions together with how to use them, how to connect them, and how to verify them. Even when a runtime and a product are supplied together, their responsibilities should stay separate and the boundary between them should stay replaceable.

Connecting local runtimes to the organization's operating environment

When one person runs an agent on their own computer, they can adjust conditions directly: which folder it works in, which account it is logged into, what it is allowed to change. Once many people run workers on their own PCs, these conditions need to follow organizational standards. You need to deliver shared tools, policies, and work assets to runtimes running locally, and be able to see what they execute.

The organization's operating environment should help turn a user's request into a task with a clear purpose and completion criteria, and run it within the organization's context and permissions. Scope and conditions should be recorded in a ticket or task spec, and the work should finish by collecting the results from various tools along with the evidence that they were verified. These shared standards can apply both to the agents on individual PCs and to workers running on servers.

Individual tools check permissions on their own data and functions and validate requests. The shared operating environment manages the scope and progress of work that spans several products. Each layer should hold its own boundary while passing along the requester's identity and allowed scope consistently.

In this post, Agent OS or meta-harness refers to a higher operating layer that lets an organization hand off and check work by the same standards even across different runtimes. Where an individual runtime carries on judgment and tool calls, the organization's operating environment also tracks whose request started the work and under what conditions it should end. Workers placed on individual PCs and shared servers can be connected and operated from this layer.

This need becomes concrete as more work runs through agents. You have to decide which worker gets a request, how to split several tasks and merge their results, and where to resume work that is waiting or was interrupted. Even if you start with a particular runtime, you end up needing to manage the work's purpose, state, and completion evidence separately from that implementation. Abstracting runtimes and orchestrating work become problems an organization has to solve to keep its work running.

The appearance of the external work environments covered in part 1 is one side of this demand. Even as individual runtimes add plugins and extensions, the organization has to apply shared standards across multiple runtimes and use tools and work assets together. The organization's operating environment uses the runtime's capabilities while drawing a boundary so that not all work depends on a particular product's support scope and release schedule.

Even while agents run on users' PCs, authentication, approved models and tools, Skill distribution, execution logs, and cost management can be provided as a shared foundation. Access permissions also have to be enforced in each tool and system. In this setup the organization defines the standards and services it shares, and splits where things run between individuals' ad hoc work and teams' ongoing work.

Some recent projects are worth looking at when setting up shared team automation and isolated long-running execution. Google's AX, whose core concepts and specification are still in development, points toward declaring tasks, workspaces, and models and deploying isolated execution. OpenHands separates the server that handles agent execution and workspaces, the browser client, automation, sandboxes, and so on. These execution environments can come under the organization's operating scope alongside the work done on individual PCs.

OpenAI's Symphony, an engineering preview meant for testing in trusted environments, lays out a flow that takes issues as tasks, starts isolated runs, and collects evidence such as CI status and review results for a person to review. The official description of Salix distinguishes an agent's continuous execution from work that needs a computer, and also covers using external runtimes. The projects differ in scope and maturity, but each tries to operate a worker as a unit broader than a single terminal session.

The Kubernetes analogy helps because it expresses a job's conditions separately from a specific place of execution. Just as you deploy an application by declaring the resources and runtime conditions it needs, an agent's task can be handled at a higher level by specifying the runtime, permissions, and completion criteria it uses. Actual execution is then placed on the user's PC or a shared environment depending on the nature of the work. Switching models or runtimes does not keep task capability, permission handling, and state persistence the same, so you have to check both the shared contract and real compatibility.

Organizational context and completion evidence create execution capability

Connecting models and tools to the operating environment does not mean the agent will immediately do your organization's work well. It needs to know which material takes priority, what the same term means in which line of work, and what the requester means by "done." People get this context by talking with colleagues and remembering past decisions. Agents need a path for receiving it too.

The feature map described by Lauren Tan of Cursor shows this gap well. Even if an agent can run an app and operate its screens, it wastes time if it does not know where the feature the user is talking about lives and how to reach it. Material that maps features to screens and access paths makes it easier to turn vague user reports into actual verification work.

Rather than leaving that knowledge in one person's conversation, you can manage it as a reusable work asset: data lookup procedures, incident investigation steps, report review criteria, and per-product usage guides bundled into Skills, documents, and scripts. It should also be clear who maintains them and which version has been verified.

Agent Registry treats MCP servers, agents, Skills, and prompts as a catalog that an organization can discover and deploy from. Skillport serves Skills to multiple agents through a CLI and MCP. Tessl and TrueFoundry's Skills Registry are other examples of managing reusable instructions and packages. Knowledge is not just written once; delivering it to the workers that need it and managing changes becomes part of the operating environment.

The state of the work itself also has to be kept separately from the conversation. Whether someone requested a review and has not heard back yet, whether new material has arrived so work can restart, whether something is actually done: these are hard to judge just from whether a chat message was generated.

WorldLoops tracks unresolved work based on signals read in by other agents, and handles proposals, approvals, state transitions, and records. The implementation in its public repository distinguishes actions that write directly to external systems from local state transitions. Ouroboros refines requests into specs, records execution and evaluation, and connects a common workflow across multiple agent runtimes. In both, work state and execution conditions are managed persistently, so work can continue even when the conversation session changes.

Tools that produce completion evidence matter too. In the verification case from Toss frontend developers, an API for testing, a device farm for operating real devices, and replay for checking logs and failure scenes all appear together. The surrounding environment has to be prepared so the agent can verify things. Writing good verification instructions and actually having an environment where verification is possible have to go together.

The same principle applies to permissions. A natural-language instruction like "Read only the data you're allowed to" and actually restricting that scope in the system serve different roles. The organization's worker should use tools within the requester's permissions and the scope allowed for the work, and when it leaves results behind, the set of people allowed to see those results should carry over too.

Someone also has to manage this foundation. What Lovable calls an "agent parent" is the person responsible for the quality of agent output, who updates knowledge and corrects wrong answers. Saying an organization operates agents also means someone takes on this responsibility. As the number of runs grows, the role of judging which work assets and environments need fixing becomes more important.

Providing an internal execution foundation is a specialty in its own right

Depending on its capabilities, an organization can build the runtime environment itself or bring it in and manage it with outside help. The starting point is making the way of working customers have experienced on the outside network usable on internal work PCs too. Adding model supply, tool connections, and shared operations to carry this through to real work can become a specialist business.

The necessary components are the runtime on user PCs, the organization's shared operations layer, the model inference foundation, and the resources that support them. Everyday work happens close to the PC, and models, tools, policies, and records can be provided through the shared foundation. Execution environments for long-running jobs or shared team automation are added to the extent needed.

One possible business is taking an open-source runtime that offers a way of working similar to Claude Code, connecting it to the customer's work PCs, internal models, and internal tools, validating it, and supplying deployment packages and operating manuals with it.

The basic approach is to choose a mature open-source runtime and add the supplier's own harness and integration layer where needed. Building the runtime itself is also an option, but you have to weigh the burden of continuous feature work, bug fixes, and keeping up model and tool compatibility. Using an existing project's extension points and interfaces lets you take in upstream improvements while filling in the features the site needs. If you have to maintain a fork, the cost of continuously managing its divergence from upstream has to be part of the decision.

Selection criteria have to be checked in real users' working environments. You need to look at whether it can handle the work PCs' operating systems, development environments, files, and tools; whether tool calling is stable with internal models; and how it handles long-running jobs and failures. Whether workspaces and execution permissions can be separated, and whether the needed packages can be distributed and updated without an external connection, also matter. The project's maintenance status, extension model, license, and operational support terms should be considered as well.

There are many projects to look at for implementation. Gajae-Code is an example of a coding agent harness, and Open Cowork and OpenDots show ways of building the work environment where users meet agents. In OpenHarness you can look at a harness implementation that connects models, tools, and Skills. Applying any of these to an air-gapped network requires validating model connections, dependencies on external services and authentication, deployment and update conditions, and the needed operational features in the real environment.

Execution capability has to be checked for a model and runtime together. FineEnvs' multi-harness RL experiment connects several real agent harnesses to a common environment to evaluate model behavior and train weights. The same model can produce different results depending on the harness. What I note is that a structure able to handle multiple runtimes in a common experimental environment matters for training and evaluation as well.

Applied to internal-network adoption, this experiment suggests that a candidate model's scores alone cannot tell you its task capability. You need to run the customer's representative tasks with the intended runtime and tools connected, and compare completion quality, failure modes, and cost. The first step is making it possible to check different execution environments against the same tasks and criteria; whether to further train a model can be decided based on needs that show up in that evaluation.

In an environment where many people use many tools on their own PCs, a shared operations layer is needed. Who can use which models and tools, where approved Skills come from, and where to check task progress and failures all have to be tied into the organization's authentication and permission systems. A model gateway, tool management, and execution observability each deal with different things, so their responsibilities should be designed separately.

For example, ToolHive can be used to deploy and manage MCP servers and control tool access. LiteLLM can be a starting point for setting up access and routing across multiple models, along with usage and cost management. The registries discussed earlier handle discovering and distributing the tools and Skills the organization will use. Where functions overlap, combine them with your existing systems and operational burden in mind.

Uber's MCP Gateway shows why this kind of shared foundation is needed at organizational scale. As teams built their own integrations, discovering, operating, and reusing tools became hard, so Uber built a gateway that handles both existing service APIs and MCP servers. A registry manages tool definitions, owners, and enabled status, and a proxy forwards calls to the actual services. Even discovered tools go through review and enablement by the owning team.

Applying the ToolHive and Uber cases to an internal-network build shows that, beyond an interface for calling tools, the organization has to handle by its own standards who provides a tool, who can use it, and how changes are managed. A specialist monitoring product can clearly provide its functions, usage, permissions, and the meaning of its results, while the shared operating environment can take on discovering and connecting the interfaces of many products.

Observability and evaluation tools like Arize Phoenix can be used to inspect traces of model calls and tool use, and to compare before-and-after results on the same cases. Linking this to the completion records of the work gives you evidence to investigate whether a problem came from the model's judgment, a tool's response, permissions, or the work procedure. Collecting logs is not enough; you need a system that checks the quality of real work.

If many agents working locally share a common inference server, you have to decide how much work that server must handle. You need to be able to judge how many GPUs are required when workers at a given scale perform given tasks concurrently, and which model to quantize to what degree and run on which serving engine. Resources for shared task execution also have to be estimated separately. Separating real loads this way is what gives hardware or cloud quotes a basis.

Concurrent user count alone is not enough for capacity planning either. A single agent task can consist of several rounds of inference, tool execution, and time spent waiting for a person to respond. Reading long documents, repeating short judgments, and running code use resources in different ways. You first need to know which tasks start how often, how long they last, and what they wait on.

Inference engineering starts with choosing which models to use and continues into tuning the execution setup to the bottlenecks of real work. When evaluating models like Qwen, Gemma, and Solar, you have to check response latency, memory use, and concurrent throughput along with whether they meet the target quality.

Optimization candidates include MTP, DSpark, and KV cache offloading. You can also consider splitting large and small models by task, or using embedding models and judgment models such as Jev and Laya. Deciding at which stage to apply each candidate and measuring its effect on quality and resource use becomes the supplier's expertise.

The effect of these optimizations depends on the model, serving engine, hardware, and actual work. Even if quantization lets you handle more tasks concurrently, if quality drops on tool use or long-context processing and retries increase, the gain across the whole workload can shrink. You have to look not only at model size and response speed but also at task success, the effort needed for corrections, wait times, and total cost.

vLLM is an example of an engine that handles model inference and serving. llm-d covers running multiple model servers and placing requests with load, KV cache, and similar factors in mind. The engine that runs a model and the layer that operates multiple running instances have different roles, and should be configured to match the scale and bottlenecks you need.

Deciding which of several models to use and deciding which of the servers running the chosen model a request should go to are also different decisions. Which agent gets which work is yet another question above those. Agent operation, model selection, and placement of inference requests need to be kept distinct but connected so you can find the causes of performance and cost.

These validation results then have to be translated into hardware and cloud specifications. Beyond GPU memory and count, you need to look at inter-server communication, storage for reading models and data, and the required availability and headroom for scaling. You should be able to compare using the customer's existing resources, adding hardware, or using an approved cloud, and present quotes that include both upfront and ongoing operating costs. A supply configuration that pairs the runtime and harness deployed to user PCs with a GPU cluster appliance for internal model serving can also take shape in this process.

The Agentic AI Platform engineering playbook is a reference that separates design and architecture, model serving, and operations and governance. When choosing a specific configuration, each layer has to be reconnected to fit the customer's network and authentication setup, available resources, and actual working conditions.

The value a supplier can provide lies in validating these choices against the work the customer will actually do and packaging them into an operable configuration. It should be able to explain what work can be handed off, under what conditions work goes to a person, and what needs to be rechecked when the model or runtime changes. Only when this extends to manuals, training, observability, and incident response can you say the execution environment is in place.

Start from the work PC and expand into an organizational foundation

The starting point is placing a general-purpose runtime on one team's work PCs and connecting the models and tools needed for the work you will actually hand off. Users should be able to hand off work on the files and systems they normally use and check the results. Even at that small scale, the task's purpose and permissions, deliverables, and how to check them should be clear. After that, the Skills, tool connections, model access, and execution logs that many people use repeatedly can be managed as a shared foundation.

At first, a single runtime can do real work. As usage grows, the demand to operate runtimes on many PCs together with shared team workers will grow too. Boundaries have to be drawn so that the work knowledge, tool connections, task records, and verification criteria built up along the way can be used in other execution environments. The direction is to keep the convenience of working close to the user's environment while adding operating capability across the whole organization.

I think air-gapped organizations will end up working with the same basic structure as the outside world. There is a general-purpose agent runtime on the user's PC, and the organization provides the models, tools, knowledge, and operating foundation that worker uses. Implementation varies with the network and resources, but the direction of handing work to a worker that uses many tools is the same. Enterprise software should be designed on the premise that it will be used in that environment, and for customers without an execution foundation, it should be possible to provide one along with it.

Once this premise is in place, new questions arise about how products are developed and applied at customer sites. When powerful outside agents and agents inside the site work under different conditions, what should the supplier build in advance, and what room for adjustment should be left to the site? In the next post, I will look at this through the lens of "seed and germination," distinguishing the change in how this business is carried out from the field adaptation of the product itself.