Why does an agent need a working layer around the model?

If a model can explain a configuration error, why not let it fix the file as well? An IT colleague investigating a failing service might welcome the help. Yet the moment the model edits a repository, the organization has questions that answer quality alone cannot settle. Which directory was in reach? Which identity started the work? Could the agent run a command that changes something outside the file? And if the tool call should stop, who takes over?

A working layer around the model makes those questions operational. People often call it a harness. It includes the client that runs the session, the tools exposed to it, the place where code executes, and the points where organizational context and decisions enter the process. It is not a promise that the model will become infallible. Its purpose is to make an agent’s work a recognizable part of a company’s workflow rather than a chat window with accidental access to a terminal.

Use an existing client, own the organizational boundary

ADR-0001 in agentic-organization chooses opencode as the developer workstation client. This is a decision about the developer’s local work, not a declaration that every employee must use a terminal. The client already has an agent loop, a terminal interface, file operations, and tool integration. Building all of that anew would consume effort before the company had addressed the part distinctive to its own environment: how a persona gets the right model route, applicable rules, and access to organizational tools.

The ADR describes three integration surfaces. Managed configuration points the client at the organization’s model gateway. A plugin asks the policy service about proposed tool calls and reports tool events. The backend’s MCP interface presents organizational capabilities to the client. Together they connect an individual’s workstation to company decisions without pretending that the model itself can enforce them. An earlier article on policy documents considers why reading a rule and applying it before an action are separate jobs.

Other designs were considered. A custom terminal client and executor would give closer control, but require maintaining the agent loop. A backend broker could offer stronger central enforcement at the cost of a new protocol and latency for local files. ADR-0001 takes the existing client route and retains the risk that a plugin running under a developer’s privileges is a soft control. Selecting a harness does not create hard enforcement.

The launcher has more to do than open a window

ADR-0009 turns that choice into a workstation workflow through the 3pa command line tool. In the current run implementation, it checks gateway availability and the persona session before launch. It fetches and verifies a signed organizational configuration, then mounts the verified configuration into the sandbox on the normal container route. The project directory is mounted into that container. Its network is connected to a filtered outbound proxy rather than handed unrestricted direct access on the normal compose path. The doctor command checks prerequisites such as the container runtime, session, gateway access, and signed configuration before someone tries to begin work.

The model does not verify the configuration signature or create the sandbox. Nor does a container undo mistakes in the mounted project; teams still need version control and review. Alternate launch options skip signature verification or use a path without the filtered proxy. A control on the normal path is not a property of every launch.

The plugin adds another decision point. Its tool.execute.before handler asks the policy service for a decision. An enforced denial or request for approval aborts the call; a request does not create a complete approval interface on its own. When the service cannot be reached, the plugin defaults to continuing unless it is configured to stop on failure. The policy engine’s normal dry_run mode observes ordinary decisions without enforcing them. This matters because an installed plugin and an enforced policy are not synonyms. Our discussion of guardrail boundaries examines that distinction in the context of untrusted content.

A developer workstation is not everyone’s desk

A production team may work from maintenance records; procurement compares supplier offers; finance handles spreadsheets and reporting periods; HR deals with documents that should not be exposed across roles. These are possible workflows, not a claim that the product automates all of them today. Each team has a different answer to where files live, what tools are appropriate, and who reviews a consequential change. Requiring everyone to use the developer’s laptop sandbox would move support work onto machines that may not need a development toolchain.

ADR-0014 keeps the laptop sandbox route for developers while choosing server-side workspaces for departments. But it is especially important to read that ADR’s status notes, not just its first decision table. Its plan for a custom departmental terminal and a reduced web application was superseded by ADR-0022. That newer decision favors an existing terminal ecosystem for power users and a simpler web view for other staff. The repository’s known-limits page still lists missing workspace lifecycle pieces, including attachment and idle suspension. A design direction is not the same as a finished experience available to every department.

The clients share an organizational idea: people need tools and context appropriate to their work, while the company knows where decisions belong. A finance agent checking a document and a developer editing code need not share a screen. Both need clarity on what was attempted, which policy mode was active, and who takes over when an action stops. A harness locates that conversation; it cannot make local policy choices for the company.

A practical start is to choose one real task and draw its path. Who initiates it? Where do its files reside? Which tools can alter a record or send information out? What happens when a decision blocks the call or the policy service is unavailable? Test the normal route and a failure route. That exercise often shows whether the problem is a missing client capability, a missing organizational rule, or a misplaced assumption about enforcement.

Why does the model need a working layer? Because organizational work has a location, an owner, tools, and consequences beyond the text of an answer. ADR-0001, ADR-0008, and ADR-0009 in agentic-organization show one way of connecting a developer workstation to those concerns, while ADR-0022 explains why the same interface need not serve everyone. The relevant question for another team is which of those connections its current agent workflow is missing.

Verification note: The design and implementation distinctions here were checked against ADR-0001, ADR-0008, ADR-0009, ADR-0014, ADR-0022, the 3pa launcher and doctor code, the workstation plugin, and the sandbox configuration. The limits of departmental workspaces and policy enforcement were checked separately.