Where a harness runs

A harness remains the same intelligent application while the surface, process boundary, machine, model placement, and operator change around it.

Platform map. Availability varies by surface and placement: mobile/on-device and paved managed or BYOC deployment workflows remain planned. Recovery and trace-based rehydration are shipped.

You already know this architecture

The closest familiar analogy is MVC with a live language model as the Model:

• product surfaces are the Views;
• the harness—ordinary TypeScript—is the Controller;
• a resident model holds the live generative state.

The analogy continues into the serving layer. Rails separated the application from the server that happened to run it. Lloyal separates the harness from the surface, process boundary, and host that happen to carry it.

The load-bearing Rails lesson is not the nouns. It is the separation:

Where the harness runs is a deployment decision, not an application decision.

Read the full Rails analogy

One application contract

Every harness exposes the same headless shape:

export function* harness<E, C>(
  ctx: SessionContext,
  events: EventBus<E>,
  commands: Signal<C, void>,
): Operation<void>

The harness owns the intelligent procedure. It accepts typed commands, emits typed events, and runs over an injected model context. The surface and placement bind to that contract rather than redefining it.

surface
   ↓ commands
harness(ctx, events, commands)
   ↓ events
surface

Unlike Rack's request/response cycle, this contract is a stream. A live harness may emit tokens, Agent lifecycle events, Tool progress, pressure changes, and results while a Session remains active.

Convention below, code at the centre

lloyal-ai generates the repetitive wiring: targets, bindings, runners, and build configuration. Harness authors work at the centre—the procedure and domain rules that are genuinely theirs.

That is convention over configuration with an intentional boundary:

Infrastructure is conventional. Intelligent behaviour remains code.

Surface is not placement

Several independent choices are often collapsed into one word such as “deployment.” Keep them separate.

A browser does not imply a public cloud. It may connect over WSS to a host on the same laptop, a private network, an on-prem appliance, or a GPU box. Likewise, “local” does not force an in-process surface: the scaffolded web target runs a browser against a local resident-model host.

Two execution families

Model on user-controlled compute

01 · Local edge

CLI or desktop surface
        ↕
local runner
        ↓
SessionContext + resident model

Use local edge for offline or zero-egress operation, user-owned data and compute, a single-user application, or the lowest operational surface area.

One model, isolated Sessions

02 · Shared residency

clients ─ WSS ─ host
               ├ Session A
               ├ Session B
               └ Session C

The host loads a model once and gives each admitted Session its own context, KV/recurrent state, configuration, Agent population, and structured lifetime.

The host is the Puma side of the analogy: density through multiplexing — Serve to many users runs it. The relay is the Unicorn side: stronger kernel isolation, but each process pays its own residency. The harness contract remains unchanged either way.

Shifting the harness left

application → network → model endpoint

surface → harness + Abilities + live inference → placement

That changes the unit a developer builds and deploys. It is no longer merely an inference endpoint that another application must orchestrate. It is the intelligent application itself—its topology, Tools, evidence rules, policy, authority, completion, and continuity intact.

The runtime owns KV tenancy, branch sharing, Continuous Tree Batching, scheduling, and accelerator execution beneath the harness. Application code owns what those mechanics mean.

Read “Shifting the harness left”

Where the Rails analogy bends

The Model runs

An Active Record model is silent until called. A resident language model may continuously produce and react inside a Session. The binding is therefore a bidirectional event/command stream rather than a request cycle.

The Model forks

Agents inherit shared decoded state and diverge into application-owned lineages. Topology is part of the program, not a server-side implementation detail.

The Model persists differently

Physical attention state is tied to its model and runtime configuration. Portable Session continuity is based on accepted logical state that can be reconstructed, with physical snapshots treated as optional accelerators.

Placement portability and durability are distinct:

• Placement portability means the same harness contract can run elsewhere.
• Output reattach reconnects a surface to a Session that is still live.
• Session rehydration reconstructs accepted state after the original runtime has gone.
• Mid-execution recovery reconstructs an active multi-branch graph after its runtime is gone. Not to be confused with the pool’s recovery, which salvages a stopping Agent’s findings while the pool is still running.

Placement portability, trace-based Session rehydration, and mid-execution recovery are part of the platform shape today. What remains planned is the live durability plane: checkpointLive, agent-shaped retrospective rebase, and binary resume-after-restart.

Choose a placement

Current and planned

The harness is the application. Placement wraps it; placement does not redefine it.