Minimal setup
Point--harness at the headless harness entrypoint. For an Exo-style app, that is usually a thin file like .archal/harness.ts that imports the real agent runtime while Archal intercepts the service traffic underneath:
- an explicit harness entrypoint such as
.archal/harness.ts package.json#archal.harnessarchal-harness.json- a narrow legacy fallback from
package.jsonscriptsarchal:harnessorarchal, or rootagent.mjs/js/ts
eval scripts.
Want a concrete fixture to adapt? Start from:
assistant-baseline, so you can omit both Setup and seed: for this first smoke test.
First command to run
Usearchal harness check before the first scenario run:
archal run uses later.
What “headless” means
Headless does not mean “no product UI exists.” It means Archal can run the agent without starting the app shell. Good fit:- a Node command that imports the real agent runtime
- the same tools and provider wiring the app normally uses
- service calls going through clients or proxies that can be redirected
- booting Electron just to reach the agent
- renderer-only entrypoints
- UI click simulation as the main integration path
.archal/harness.ts adapter that imports the same runtime and skips the shell.
Where traces go
During a run, Archal gives the harness temp file paths for metrics and agent trace collection. The harness can write to those paths, and Archal ingests them into the run result before cleaning up the temp files. If you want a coding agent to inspect the full run result afterward, use JSON output and save it:Adding a manifest
For more control, drop anarchal-harness.json at the resolved harness root. For the .archal/harness.ts convention, that means the repo root. This is optional but lets you configure the command, model, prompt files, and environment variables.
Minimal .archal/harness.ts
This file is just a headless entrypoint. Archal runs it for you.
runMyAgent() should call the same model runtime and tool wiring your app already uses. The harness file is just the thin adapter that turns that runtime into a headless command.
What the harness needs to do
The required contract is small:- read
ARCHAL_ENGINE_TASK - call the real model runtime
- use service clients or proxies that can be redirected under Archal
- print the final result to stdout
First run
archal run automatically boot-checks a local harness before it provisions hosted twins. If that preflight fails, Archal now classifies the error into the usual buckets:
- headless boot issues such as Electron-only imports or Vite-only globals on the harness path
- native dependency issues such as Node vs Electron ABI mismatches
- service bridge issues such as unwired
dbProxyorgmailProxyboundaries - service config issues such as missing OAuth credentials or API keys
archal harness check fails, run the harness directly:
Set the directory once
ARCHAL_DEFAULT_HARNESS is set and no --engine-endpoint is provided.