Move Heddle behind a separate Execution Host

What changes when execution moves out of the product process

In the embedded shape, the product backend imports Heddle directly. In the separate-host shape, only the compatible Execution Host imports the runtime. The adopter backend may be written in TypeScript, Python, Go, Java, or another language that implements the public contract.

PRODUCT USER
     |
     v
PRODUCT BACKEND
authenticates the user, derives scope, owns data and policy
     |
     | short-lived signed execution authority
     v
SEPARATE EXECUTION HOST
verifies scope, runs Heddle in an isolated workspace, streams one outcome
     |
     | exact invocation-bound product capability
     v
PRODUCT-OWNED MCP OR API
verifies authority and applies allowed product reads or effects

The network hop is not the main value. The value is a deliberate boundary: the runtime receives enough authority to complete one bounded invocation, but it does not become the owner of the product or receive a general product database credential.

One foreground invocation

A typical product flow is:

1. The product authenticates the user and creates or records one stable product invocation.
2. Trusted product state determines adopter, tenant, subject, conversation or product-session scope, workflow, model access, and allowed capabilities.
3. The backend issues short-lived execution authority and, when product tools are needed, a separate exact-tool capability.
4. The Execution Host verifies the authority, binds the runtime session to that scope, prepares the Heddle runtime and workspace, and starts the bounded execution.
5. Heddle streams ordered activity and exactly one terminal outcome. Product tool calls return through the narrow product-owned capability boundary.
6. The product projects safe progress to its UI and commits canonical results under its own authorization and transaction rules.

The browser should not call the Execution Host directly. Routing identifiers are not authorization, and prompts or tool arguments must never decide tenant identity.

Foreground and autonomous work

The public contract supports explicit workflow profiles rather than an untyped execute-anything endpoint. Foreground conversation work and coordinator-scheduled autonomous work may share identity, capability, cancellation, streaming, and settlement mechanics while retaining different scheduling and product semantics.

The Execution Host itself is not the product scheduler. A product or coordinator decides when work should run and which desired work exists. The host accepts one authorized invocation and executes it within the declared boundary.

Product authority stays outside

A separate host should not receive the product's database URL, signing key, broad cloud role, refresh credential, or unrestricted product API. When the agent needs product facts or actions, it calls a product-owned MCP or API endpoint using an invocation-bound capability. The product verifies that capability again and applies its own argument, authorization, idempotency, and transaction rules.

This distinction makes retries and ambiguous failures manageable. A workspace checkpoint can preserve agent context, but it cannot make an external purchase, message, database mutation, or other product effect exactly once. The adopter remains responsible for durable effect identity and reconciliation.

When the separate boundary is useful

Choose a Separate Execution Host when one or more of these are real requirements:

• the product backend cannot or should not import the TypeScript runtime;
• model-directed shell, filesystem, browser, or process tools need an environment isolated from the product server;
• the execution environment must be deployed, replaced, scaled, or upgraded independently;
• customer or tenant workspaces need a stronger runtime-session boundary;
• the product wants a language-neutral invocation contract; or
• several adopter products should reuse one maintained execution implementation without sharing their canonical data or policy.

Do not add the boundary merely because a turn is long-running. An embedded runtime or worker can also execute long work. Do not add it merely to obtain stable run IDs or reconnection; Agent Run Management solves that lifecycle problem without moving the runtime.

Public availability and limits

The adopter integration package, contract schemas, workflow profiles, conformance fixtures, authority helpers, and selected storage adapters are public. The current compatible Execution Host implementation, coordinator deployment, infrastructure, and operating runbooks remain private research. There is no public self-service host and no Heddle-managed cloud service today.

Public documentation describes the contract and observed research direction, not a production security certification. It does not claim general multi-tenant isolation, high availability, compliance, support SLAs, or portability across every provider. A team adopting the separate-host shape must still review and operate its actual deployment.

Start from the public adopter boundary

TypeScript backends can begin with @heddleagent/execution-host-client. Other languages can implement the published OpenAPI, JSON Schema, JWT, SSE, and lifecycle profiles without porting Heddle's model and tool loop. Continue to the public adopter guide for the exact supported workflow and ownership contracts.