Agent Stack Configurations: A Complete Analysis of Eight Options

Open client code does not make the model local. A self-hosted model does not make tools safe. An internal MCP server does not restrict permissions by itself. Conversely, an external model API does not necessarily receive production secrets when planning is separated from execution, context is filtered, and authority remains in an internal gateway.

This article extends the formula Agent = Model + Harness and the model/tool gateway ideas from the agent-first approach to internal developer platforms. For a practical choice, the formula needs one more step:

agent stack = harness + model + tools + identity + technically enforced execution boundaries

The article uses three kinds of statements to keep fact and opinion separate:

• —documentation links describe product properties stated and verified on the review date;
• —architecture conclusions interpret the consequences of those properties;
• —recommendations select for a specific implementation class rather than rank every solution universally.

The word “ours” is overloaded. It may refer to:

1. 1Source-code ownership: the team can inspect and modify the harness.
2. 2Operational control: the team deploys, upgrades, and observes the component.
3. 3Data control: the team sets the region, retention period, and permitted transfer destinations.
4. 4Policy control: permissions, routes, approvals, and denials are enforced by infrastructure rather than only by a system prompt.

These properties do not imply one another. Forking an open client gives control over code, not the external model. Self-hosted inference gives control over weights and compute location, not over a local shell running with a developer’s permissions. A managed service may be proprietary yet provide stronger isolation and audit than a home-grown service without a dedicated operations team.

Every axis has its own failure point. A configuration should therefore be recorded as a complete tuple rather than a product name, for example:

ready-made local client
× external model through an enterprise model gateway
× internal tools through a gateway with OBO identity
× local OS sandbox

Axis 1. Agent harness

In-house development or a fork provides maximum freedom in the planning loop, context format, tool policy, and internal-platform integration. The price is permanent engineering work: model compatibility, context compaction, error recovery, approval UX, sandboxing across operating systems, tracing, and dependency updates. A fork also creates a separate supply-chain branch; upstream vulnerabilities are no longer fixed automatically.

A configurable off-the-shelf client lets a team change model endpoints, MCP servers, commands, and rules without building the complete agent loop. It is a practical way to test a hypothesis quickly. A configuration file is not technical control, however: verify where commands actually run, whether egress can be denied, who stores tokens, and what happens when the sandbox is unavailable.

A managed vendor client or cloud agent receives new models and features faster, while the provider assumes part of the isolation and operations burden. In exchange, the organization accepts the provider’s contract for data retention, updates, telemetry, availability, and audit export. Even with a local client, inference and auxiliary checks may remain networked.

Axis 2. Model

“Our model” splits into at least four classes.

• —Open weights in the organization’s own environment. The organization controls inference, versions, and telemetry, but pays for GPUs, spare capacity, serving, upgrades, and quality validation. Open weights guarantee neither a small model nor good tool use.
• —A managed model in a selected cloud or region. Data and compute can remain in an agreed jurisdiction without operating inference directly. Weights, roadmap, and often the control plane still belong to the provider.
• —An external proprietary API. This offers fast access to new capabilities and elastic capacity. The cost is dependency on the API, pricing, limits, data policy, and model behavior.
• —A hybrid router or cascade. It selects a model by task type, cost, and data class. This is not free portability but a separate platform with classification, evals, and safe-fallback rules.

API compatibility means matching request formats, not matching behavior. Two models behind OpenAI-compatible endpoints may interpret system prompts differently, call tools differently, recover differently after errors, and react differently to context compaction. Real portability is proven against the organization’s own task and failure suite.

Axis 3. Tools

Every tool needs two coordinates at once: its origin and its actual execution location.

The label “internal tool” says nothing about execution location. A local MCP server from npm may run on a corporate laptop with the user’s permissions, while an external SaaS tool may accept only a narrow one-time operation through a proxy. The required artifact is a map of actual data and authority flows, not a catalog label.

Every property below was checked against official documentation on July 16, 2026. This is not a model-quality comparison and does not declare one product a replacement for another. It separates what follows from the documentation from what does not.

OpenCode

Verified: the repository is published under MIT; the client supports many providers and a configurable baseURL, plus built-in, custom, and MCP tools. In the current tool documentation, tools are enabled by default, while permissions support allow, ask, and deny.

What does not follow: an open and portable client does not make the model local; rules do not prove the presence of an OS-enforced sandbox; without an enterprise profile, safe defaults remain the responsibility of the user or platform team.

Codex CLI

Verified: the client is open under Apache-2.0; configuration supports custom model providers, including an internal proxy, Ollama, and LM Studio; in CLI/IDE, sandbox and approvals are separate, and the sandbox relies on operating-system mechanisms.

What does not follow: an open client does not make OpenAI models open or local; connecting a different endpoint does not guarantee equal agent-loop quality or tool use.

Claude Code

Verified: official documentation covers the Claude API and Claude delivery through Amazon Bedrock, Google Vertex AI, Microsoft Foundry, and Claude Platform on AWS; the product provides centrally managed permissions and an OS-level sandbox.

What does not follow: these are several delivery paths for Claude, not stated support for an arbitrary self-hosted model. A local client does not imply local inference; data path and retention depend on account type and provider.

GLM-5

Verified: the model card publishes weights under MIT and serving recipes—the card lists 754 billion parameters—while Z.AI offers a managed API.

What does not follow: open weights do not mean “runs on any laptop” and do not remove serving cost. Self-hosted GLM and GLM through an API are different configurations in data path, operations, and failure modes.

GigaChat

Verified: this is a managed API with partial OpenAI API compatibility and custom functions. On the product page, Sber states that data is stored on servers in Russia and that prompts and responses are not used for training by default.

What does not follow: a regional API is not a model under the customer’s operational control. A marketing statement about data must be backed by contract, plan settings, and the organization’s own flow map. API compatibility is not behavioral portability.

Practical conclusion: OpenCode and Codex show that an open harness can work with different endpoints. GLM-5 shows that one model can exist both as open weights and as a service. GigaChat demonstrates the separate class of a regionally managed model. Claude Code shows how one vendor client can offer several infrastructure paths to one model family. None of these examples collapses openness, model ownership, locality, and policy control into one property.

Model and tool gateways are logical roles, not necessarily separate microservices. They may be services, client libraries, or parts of a managed platform. The important capability is independent enforcement of routing, identity, audit, and emergency shutdown. The first gateway controls which data goes where; the second controls who may change what, and on whose behalf.

These are not product rankings but eight repeatable configurations. Each is described by its data flow, ownership, strengths and constraints, economics, lock-in, suitable scenarios, characteristic failures, and mandatory controls.

1 · Fully autonomous or isolated stack

user → own/forked harness → self-hosted model → local or internal tool gateway → internal systems; no egress during normal operation

Ownership. The organization owns the entire stack: model artifacts, inference, harness, sandbox, tool registry, upgrades, observability, and user support.

Strengths. Maximum control over data location and versions; air-gap operation; independence from external availability and sudden API changes; reproducible behavior on a pinned artifact set.

Constraints. Quality and speed depend on available models and compute. New capabilities arrive only after internal upgrade and validation. Every difficult harness function becomes a product responsibility, while isolation slows the delivery of fixes.

Economics and lock-in. High fixed cost for GPUs, platform engineering, spare capacity, evals, and a safe upgrade process. At consistently high utilization, unit cost can become predictable, but “no API bill” does not mean “no inference cost.” External-API dependency is lower, while lock-in remains in the serving stack, weight format, client fork, prompt templates, and behavior of the chosen model.

Best fit. Restricted development, defense and industrial environments, data that cannot leave the perimeter, and sites with unreliable connectivity.

Characteristic failures. An outdated model or vulnerable dependency remains inside for a long time; the local agent gets broad permissions because “the perimeter is already safe”; an external fallback appears unnoticed; insufficient GPU capacity becomes total unavailability.

Mandatory controls. Signed and pinned model, container, client, and MCP versions; a private artifact registry; deny-by-default egress; a dedicated agent identity; read/write tool separation; OS-enforced sandbox; offline fix delivery; centralized logs; and a kill switch. Verify the air gap with regular network tests rather than treating it as a property of the diagram.

2 · Own harness with an external frontier model

user → own harness → enterprise model gateway → external API → own tool gateway → systems

Ownership. The provider owns the model and contractual availability. The organization owns context, the agent loop, routing, tools, permissions, result validation, and user experience.

Strengths. Access to rapidly improving strong models without operating GPUs; full control over domain logic, task state, and the tool layer; the model can be changed behind an isolated adapter.

Constraints. A production-quality harness still has to be built, including context compaction, retries, and loop prevention. Some data leaves the perimeter. A model-behavior change can break the process without any API schema change.

Economics and lock-in. Medium or high development cost plus variable API spend. At small scale this is cheaper than an internal inference platform; at high agent traffic, cache behavior, step limits, and retry cost become critical. Protocol-level lock-in is moderate, but behavior, prompts, and evals tuned to one model create high semantic lock-in. Provider-specific API features increase it.

Best fit. Domain agents whose advantage lies in process and tools rather than a proprietary model; rapid platform evolution where classified context may be sent outside.

Characteristic failures. A secret enters a prompt or tool result; a rate limit causes a retry storm; context is sent to the wrong region; a provider changes a model alias; the model-gateway log becomes a sensitive-data store.

Mandatory controls. One model gateway; pre-call context classification and filtering; provider and region allowlists; pinned versions where available; contractual retention terms; per-request and per-task budgets; egress limits; log redaction; model/version tracing; regression and adversarial evals.

3 · Off-the-shelf client with a local or self-hosted model

user → OpenCode/Codex or another configurable client → Ollama / LM Studio / vLLM / internal endpoint → local and internal tools

Ownership. The client developer maintains the base agent loop. The organization owns the model endpoint, compatibility, secure client configuration, sandbox, and enterprise tools.

Strengths. Fast path to a local experiment; ready-made UX, context management, and tool loop without building a client from scratch; code and prompts can remain in a controlled environment.

Constraints. A compatible endpoint does not guarantee correct tool use. The harness may be optimized for another model family. Context compaction and error recovery are difficult to assess on a happy path. A client upgrade can change prompts and model expectations.

Economics and lock-in. Medium cost: the client license may be free, but GPUs, serving, adapters, evals, and workstation support remain. At small scale, underutilized hardware is often more expensive than an API. API lock-in is lower, but the hidden contract between client and model creates behavioral lock-in. A fork reduces surprise-upgrade risk while increasing maintenance cost.

Best fit. Open-weight model research, sensitive code, local developer assistance, temporary offline work, and platform-team learning.

Characteristic failures. The model emits a syntactically valid but semantically wrong tool call; a local endpoint listens externally without authentication; the client silently fails over outside; a command runs outside the sandbox; laptops produce inconsistent results.

Mandatory controls. Pin the client, model, templates, and serving parameters; maintain a matrix of capabilities proven to work; test tool calling, cancellation, compaction, and error recovery; prohibit unapproved fallback; bind local endpoints to loopback or require authentication; use a separate OS profile and sandbox; distribute a centralized secure configuration.

4 · Vendor coding agent with an internal tool gateway

developer → Claude Code / Codex or another vendor agent → provider model → internal MCP/API gateway → IDP, repositories, CI/CD, and production

Ownership. The provider develops the client and model. The organization owns the tool catalog, action policy, agent identity, audit, and system integrations.

Strengths. Rapid access to strong developer UX and model updates; internal authority can be centralized independently of the client; several clients can share one secure tool contract.

Constraints. Code and context may go to an external provider. Critical client changes arrive on the provider’s schedule. The gateway must be designed as a product, not as a mechanical MCP adapter over low-level APIs.

Economics and lock-in. Seat or API cost plus a shared tool platform—usually more expensive than a pure SaaS pilot, but reusable IAM, policy, and audit reduce the cost of onboarding subsequent agents. Lock-in is meaningful at the client and model layers and lower for enterprise actions when their contract, identity, and logs belong to the organization.

Best fit. Enterprise software delivery where external models are approved but Jira, GitHub/GitLab, CI, cloud, and production access must stay centralized.

Characteristic failures. Every call uses one shared service account; tool output from an issue or repository carries prompt injection; the MCP server exposes low-level commands; client approval does not match the gateway’s actual action.

Mandatory controls. On-behalf-of identity instead of shared tokens; short-lived, audience-bound tokens; high-level tools with narrow schemas; separate read/write capabilities; policy as code and reauthorization at the gateway; independent dry run/diff for dangerous actions; end-to-end trace; kill switches by user, client, and tool.

5 · Fully managed SaaS stack

user → cloud harness → provider model → cloud sandbox/connectors → repositories and SaaS

Ownership. The provider owns most execution, upgrades, and baseline isolation. The customer owns tenant configuration, connected repositories, OAuth scopes, retention settings, review process, and acceptance of results.

Strengths. Minimum time to pilot; almost no internal model or client operations; fast upgrades; cloud jobs can be isolated from a developer workstation.

Constraints. A large trust commitment to the provider; limits around regions, network, custom policy, and telemetry export; availability and roadmap remain outside the organization; old behavior is difficult to reproduce after an upgrade.

Economics and lock-in. Low initial and platform cost, while variable spend grows with seats, tasks, and connectors. Enterprise review, contract work, and shadow-usage controls add cost. Lock-in is high because client, model, execution environment, task state, and connectors often belong to one control plane.

Best fit. A constrained pilot, greenfield work, a small team, noncritical repositories, and asynchronous tasks with mandatory review.

Characteristic failures. A repository or secret believed to be local reaches the cloud; an OAuth connector has permissions broader than the task; default retention violates policy; an upgrade changes effectiveness; audit cannot be exported to the internal SIEM.

Mandatory controls. Enterprise tenant and contractual data modes; allowlists for repositories and task types; minimum connector scopes; secrets only in the intended phase and never in model context; branch protection and independent review; export of available logs; regular retention and region checks; a shutdown and data-export plan.

6 · Multi-model platform with routing and fallback

client/agent → model gateway → policy classifier → local, regional, or external model → tool gateway; fallback depends on data and task class

Ownership. Providers own their models. The platform team owns routing, adapters, evals, budgets, tracing, and safe behavior under failure.

Strengths. Quality, cost, latency, region, and availability can be combined. The organization gains real negotiation and migration leverage. A small model can handle a simple step and a strong model a difficult one.

Constraints. This is one of the most behaviorally complex configurations. A universal API hides differences only until the first nontrivial tool call. The router adds latency, failure points, and a permanent need for evals.

Economics and lock-in. High platform cost justified by scale, resilience requirements, or substantial route-cost differences. Token savings are easily consumed by retries and maintenance. Lock-in to one provider falls, but dependency moves to the organization’s gateway, routing policy, eval suite, and common tool semantics.

Best fit. A large enterprise platform, several data and latency classes, a need to survive provider outages, and cost optimization for already measured tasks.

Characteristic failures. During an outage, a sensitive request automatically goes to an external API; a cheap model misclassifies an action; a cascade multiplies cost; models leave incompatible state; an alias changes without regression testing.

Mandatory controls. Classify data before choosing a route; fail closed for restricted classes; explicitly approve every data class × region × model combination; prohibit asymmetric fallback; record model, version, policy, and routing reason in the trace; run evals for each route and transition; set limits for steps, retries, cost, and time; provide centralized route shutdown.

7 · External planner with an internal deterministic executor

user → internal controller → sanitized context to external model → typed plan → internal policy engine/executor → systems; the external model receives no working credentials and calls no system directly

Ownership. The provider supplies reasoning. The organization defines the intent language, validates the plan, executes operations, controls transactions, and decides which results return to the model.

Strengths. A strong external model can be used while authority and sensitive data stay inside. Blast radius is limited to deterministic commands. Every action can be validated before execution.

Constraints. A useful but sufficiently narrow command language is difficult to design. Sanitization loses context. Long interactive loops are slower. A model can still propose a dangerous but formally valid plan.

Economics and lock-in. Medium or high integration cost with modest internal inference cost and controlled API spend. It pays off where an incorrect action is expensive. The model is relatively easy to replace when the typed contract and evals belong to the organization. Most lock-in moves intentionally into the internal executor.

Best fit. Infrastructure changes, financial and HR processes, production operations, and regulated environments that permit external planning over de-identified data.

Characteristic failures. A malicious instruction hides in a plan string; a validator checks JSON Schema but not business invariants; dry run differs from commit; an overly detailed error leaks a secret; a retry executes an operation twice.

Mandatory controls. A closed typed intent language with no arbitrary shell/SQL; semantic policy validation; OBO identity and workflow-bound tokens; idempotency; dry run and independent diff; transaction limits; human approval for high-risk changes; filtered results and errors; credential-free model context; a log connecting intent, policy decision, and actual action.

8 · User agent with external MCP/SaaS tools

personal or local client → selected model → user-installed MCP/plugin → external SaaS, often with user-delegated OAuth

Ownership. The user chooses client, servers, and scopes. Client, model, MCP, and SaaS vendors divide technical ownership. The organization often discovers the stack only after data and tokens are already present.

Strengths. A personal workflow can be assembled very quickly; integrations are plentiful; users retain a familiar interface and combine services without waiting for the platform team.

Constraints. Fragmented identity, an opaque vendor chain, and weak common audit. A local MCP inherits the user environment. Approvals quickly become ritual. A package update may change tools and behavior.

Economics and lock-in. Low entry cost but poorly visible total TCO: several subscriptions, lost time, duplicate integrations, incident investigation, and later centralization. Lock-in is distributed across the client, OAuth connections, SaaS data, user prompts, and specific MCP servers. Replacing one component is easy; reproducing the complete process is difficult.

Best fit. Personal productivity with low-risk data and exploration of future enterprise integrations in a separate test tenant.

Characteristic failures. A malicious or compromised MCP package receives files and tokens; OAuth requests excessive scopes; a localhost server is vulnerable to DNS rebinding; a token is forwarded without audience validation; prompt injection from an email makes the agent send data; the user automatically approves a sequence of similar requests.

Mandatory controls. Enterprise registry of approved MCP servers and versions; provenance, signature, and lockfile validation; sandboxed local server; loopback binding, Origin validation, and authentication; OAuth with PKCE, audience validation, and short-lived tokens; keyring secret storage; separate personal and work tenants; narrow scopes; no high-risk write tools; centralized access revocation.

NIST defines agent hijacking as a form of indirect prompt injection: an attacker places an instruction in data—an email, website, file, or repository—that an agent reads while performing a legitimate task. In NIST experiments, repeated attempts materially changed measured risk, and scenarios included remote code execution, bulk exfiltration, and phishing. A sentence in the system prompt cannot fix this. Controls must sit at data, identity, and execution boundaries.

Prompt injection and agent hijacking. The agent mixes developer instructions and external data in one context. A model may know that a site is untrusted and still follow a hidden instruction; more tools and repeated attempts increase the attack surface. The denial therefore belongs in policy and IAM. A model may propose an action but must not decide whether it has permission to perform it.

Code and secret leakage. Leakage is not limited to the prompt sent to a model. Tool arguments and results, traces, crash reports, telemetry, caches, shell history, and external fetches all become channels. A secret removed from the original request may return to context after a tool reads .env. The same controls must cover input, the tool loop, and logs.

Excessive permissions and confused deputy. An internal gateway using one service account is more dangerous than an external API with a narrow user scope. The agent becomes a confused deputy when it acts with gateway authority rather than the initiator’s. The MCP security guidance explicitly treats token passthrough as an antipattern: the server must accept only tokens issued for it, validate audience, and obtain a separate downstream token. The MCP authorization specification requires resource-bound tokens and recommends minimum scopes.

SSRF and DNS rebinding. OAuth discovery, dynamic callback URLs, and arbitrary-URL tools expose SSRF paths to metadata endpoints and internal addresses. A local HTTP MCP without Origin validation, authentication, and correct binding can be reached through browser DNS rebinding. The MCP transport specification requires Origin validation and recommends that local servers bind only to loopback.

Supply chain of binaries and MCP servers. A signed binary proves the publisher, not safe behavior. An open repository permits audit but does not prove that the installed package was built from it. An MCP server or skill is executable code and a source of model instructions at once. Version it, review it like an application dependency, and run it with minimum permissions. NIST materials for ISPAB list signed manifests, pinned versions, and sandboxing for third-party MCP servers among the mitigations.

Unsafe fallback routes. “If the local model is unavailable, send it outside” is a policy change, not an availability feature. A fallback must be at least as permissible for the current data class. In a restricted environment, the safe outage response is to stop the task rather than disclose context.

Approval fatigue. Confirming every command does not create informed consent. Users learn to press Allow, and an agent may split one dangerous action into apparently harmless steps. Approval must show the final effect: which data leaves, on whose behalf, which resource changes, and whether it is reversible. The gateway must independently revalidate a dangerous action.

A sandbox that exists only in a prompt or container. Asking a model not to use the network is not network policy, and a proxy environment variable does not block direct connections. The OS, hypervisor, or isolated environment must physically restrict filesystem, processes, and egress. OpenAI describes sandbox and approvals in Codex as complementary controls, not substitutes. A container is useful, but privileged mode, a mounted Docker socket, or broad credentials make its boundary fictitious.

Audit without event provenance. A log entry saying “agent invoked deploy” is insufficient. An investigation needs the user and agent identity, original intent, model and version, route, configuration hash, tool name and version, policy decision, issued scopes, arguments with controlled redaction, actual effect, and approval result. The log itself must be protected as sensitive data.

1. 01OS-enforced sandbox: filesystem, processes, and network are restricted independently of model behavior.
2. 02Deny-by-default egress: specific domains, methods, and destinations are approved; DNS and direct IPs are handled separately.
3. 03Least privilege and OBO: the agent acts for the initiator within the task rather than with a permanent shared token.
4. 04Short-lived credentials: tokens are restricted by audience, scope, time, and preferably workflow/task ID.
5. 05Tool allowlist: capabilities are granted by task and data class; MCP discovery does not imply trust.
6. 06Read/write separation: reading, proposing a change, and committing it are distinct capabilities and trust levels.
7. 07Policy as code: the gateway validates resource, action, data, subject, and execution environment; the system prompt only explains the rule.
8. 08Pinned and signed versions: client, model, system prompt, MCP, skill, container, and policy form one reproducible release.
9. 09Central traces and alerts: unusual egress, a new tool, retry growth, bulk reads, and route changes appear in one trace.
10. 10Evals and red teaming: test not only answers but refusal, injection through tool output, repeated attacks, RCE, and exfiltration. NIST emphasizes that defenses and evaluations must adapt to new attacks.
11. 11Kill switch: separate controls exist for model, route, client, tool, user, and write-action class.
12. 12Independent effect validation: schema validation is insufficient; a policy engine, dry run, business invariant, or uninvolved human validates dangerous actions.

“Internal” does not mean safe, and “external” does not mean unsafe. What matters is actual authority, the data path, revocability, and boundaries enforced by the system. This aligns with the OWASP Top 10 for Agentic Applications and the separate OWASP MCP Top 10: the attack surface spans reasoning, memory, tools, identity, protocol, and human control.

There are no scores here. The same characteristic changes with scale, model, contract, and team maturity. No configuration is labeled “high security” because security is an outcome of implemented boundaries, not a property of a name.

Quality, operations, and economics

Portability, data, and control

The tree intentionally does not start with a product. First define the permitted data path, cost of action, and operational responsibility; only then select client and model. If data cannot leave and a real air gap is required, choose configuration 1. If a de-identified plan may leave, consider 7. If the agent must act in internal systems and a platform team exists, use 4; without one, run a constrained SaaS pilot with 5. Add routing with 6 only after scale and internal evals exist. Keep the personal stack in 8 for low-risk experiments in a separate tenant.

Pilot. Start with configuration 4 or 5, but narrow the task more than feels comfortable: one repository, one data class, read-only access or a pull request instead of direct writes, and no production credentials. The pilot should measure accepted work, refusal, and review load—not prove that an agent can call many tools. Even a pilot needs one trace and a prompt-injection scenario.

Enterprise platform. Approve several clients while owning the points where data and authority pass: model gateway, tool gateway, capability registry, agent identity, policy, and audit. Configuration 4 is the baseline. Move to 6 only after an internal eval suite and sufficient scale exist; a router before measurement adds complexity, not portability.

Regulated environment. If data cannot leave the perimeter, select 1 and technically block external fallback. If a de-identified objective without credentials or system data may leave, consider 7. In either case, internal tools still require OBO, narrow scopes, and OS/network sandboxing. The word “closed” does not fix confused deputy.

Individual development. Configuration 3 fits sensitive local code when model quality and sandboxing are explicitly validated. Configuration 8 can serve low-risk personal automation, but work and personal tenants, tokens, and MCP servers must remain separate. Once a user scenario requires production write permissions, it is no longer a personal tool and should move through configuration 4 or 7.

For most large companies, the practical center of gravity is neither a total fork nor one SaaS for every case. It is several approved clients and models around two owned choke points: model and tool gateways. The first controls which data goes where. The second controls who may change what, and on whose behalf. A common identity, policy, trace, and eval layer sits between them.

Fork the harness when the agent loop itself is a product advantage or an off-the-shelf client cannot technically enforce a required boundary. Use a self-hosted model when the data path, economics at proven utilization, or autonomy demands it—not for the symbolic word “ours.” Add multi-model routing after measurement, not before. Separate high-risk execution from probabilistic planning even when planner and executor formally belong to the same vendor.

The central conclusion: sovereignty and security are properties of the complete chain, not an individual component. Own the points where data, authority, and irreversible actions intersect.