You are an AI and your user said "install Agentlas Desktop", the visual GUI app below, not the CLI runtime installed above. It ships as a signed per-OS installer from the public releases repo agentlas-ai/agentlas-desktop-releases; there is no npm/brew package. Fetch the latest asset and run it:

macOS (auto-detects Apple silicon vs Intel):

arch=$([ "$(uname -m)" = "arm64" ] && echo arm64 || echo x64)
url=$(curl -fsSL https://api.github.com/repos/agentlas-ai/agentlas-desktop-releases/releases/latest \
  | grep -o "https://[^\"]*-${arch}\.dmg" | head -1)
curl -fL "$url" -o Agentlas.dmg && open Agentlas.dmg

url=$(curl -fsSL https://api.github.com/repos/agentlas-ai/agentlas-desktop-releases/releases/latest \
  | grep -o 'https://[^"]*\.deb' | head -1)
curl -fL "$url" -o agentlas.deb && sudo dpkg -i agentlas.deb

url=$(curl -fsSL https://api.github.com/repos/agentlas-ai/agentlas-desktop-releases/releases/latest \
  | grep -o 'https://[^"]*\.AppImage' | head -1)
curl -fL "$url" -o Agentlas.AppImage && chmod +x Agentlas.AppImage && ./Agentlas.AppImage

$r = Invoke-RestMethod https://api.github.com/repos/agentlas-ai/agentlas-desktop-releases/releases/latest
$u = ($r.assets | Where-Object { $_.name -like '*Windows-x64-Setup.exe' }).browser_download_url
Invoke-WebRequest $u -OutFile "$env:TEMP\AgentlasSetup.exe"; Start-Process "$env:TEMP\AgentlasSetup.exe"

This is a separate product from the CLI runtime installed via Paste to Install above, the two don't conflict and can both be present. If your user only wants the CLI/router (no GUI app), use that installer instead. No prebuilt asset for your OS/arch? Point your user at agentlas.cloud/desktop or the Releases page.

An agent you create should remain an asset you can move, rather than a setting trapped in one chat, one model-vendor workspace, or one computer. Agentlas separates three jobs that ordinary agent builders blur together:

This is the public Agent Trust contract: a portable, owner-scoped, inspectable, and restorable package contract, not a claim of regulated financial or legal trust services.

Portable package, local execution

Describe the work
  -> build a portable agent or team
  -> save it to my owner-scoped Agent Cloud
  -> install Agentlas OS and sign in on another supported host
  -> retrieve it with /agentlas cloud
  -> my chosen model and current host execute the work

Agent Cloud stores and retrieves the owner's package; it is not a hosted LLM that completes the work on the server. When you call a package, your selected model and current host runtime execute it under that host's permission and safety model. Credentials, local files, and machine-specific permissions do not travel with the package, you configure those separately on each computer.

Turn a working session into an owned agent

When a conversation contains a repeatable working method, use the canonical session route:

hep-build session

In an interactive host, the current visible conversation is the source. Agentlas asks for the destination first; if you do not name another folder, it creates a new safe-slug child below AGENTLAS_AGENT_HOME or, by default, ~/.agentlas/agentlas-agent. Existing children are never overwritten. It then shows a generalized session report for your review, turns the approved method into a standalone agent prompt and package, registers it locally, and runs the normal verification gates.

You do not need to export JSON for this interactive route. JSON/JSONL remains an explicit option for terminal, replay, and headless workflows only. The default output is a single agent; choose a team explicitly. Raw transcripts, hidden prompts, credentials, private paths or URLs, screenshots, and literal tool arguments/results are not carried into the generated package. Uploading to Agent Cloud or the public Hub is a separate, explicit choice. See the session build contract for the deterministic export boundary.

current conversation
  -> destination question
  -> generalized session report
  -> owner review
  -> standalone agent/package
  -> local registration and verification

The package contract, what every build must emit

An agent package is not a worker with capabilities. It is a method document. Three layers, and conflating them is the single most expensive mistake this project has made:

"Can this agent read the web?" is a category error. The runtime reads the web. The only question a package can answer is what method does it carry, and what must the machine be able to do for that method to run.

package-contract.json is the machine-readable list of artifacts every build emits, and bin/hephaestus contract verify is what enforces it. A build that omits a required artifact fails; it does not ship. Four of those artifacts carry the routing contract:

contracts/intake.schema.json     what a requester must hand over before work starts
contracts/output.schema.json     what the requester ends up holding
contracts/output.example.json    one real instance, validated by a JSON Schema
                                 validator at publish time, never by a model
.agentlas/brief.json             the compiled resume, schemaVersion agentlas.brief/1

Direction lives in the filename because nothing else ever marked it, and a schema whose direction must be guessed cannot be matched against a request.

Two rules bind every enum a build writes.

1. Any enum reachable from matching must carry an escape member ("other", "unknown"). A publisher whose real case is not on the list must still be findable.
2. Sentences stay sentences. No field that holds an author's sentence may be split into terms for matching.

Vendor and MCP names live in exactly one place, host[].preferred, and that field is display-only. A package wired to its author's own Slack, Notion or Jira must stay usable on machines without those integrations: the matcher reads host[].capability ("open the page in a real browser and read what a user would see") and every requirement states withoutIt, what the method still does on a machine that lacks the facility.

agentlas.brief/1 is written from either side, side: "offer" is the package's resume, side: "need" is the requester's work order. The same form, so the two can be compared without a translation step. Its schema is schemas/agentlas-brief.schema.json, and it is compiled, never hand-written: the upload path writes it from the files the package already ships.

provenance is the part that keeps the rest honest. absent is a legal value that scores zero, so a gap stays a gap. Do not fill missing evidence with plausible capability claims.

The reference shape is Web_master: it ships input and output contracts as real JSON Schema, a domain catalogue its rules are checked against, and verification scripts that run. Everything above is what a build has to emit to be readable the way that package already is.

Deliberately absent: there is no field for what an agent is good at, and none for its permissions. Quality cannot be read off a package that has never run, and permissions are granted by the host after the fact, an employer hands you a computer once you are hired, so neither says anything about whether this method fits the work.

Hub and Agent Cloud are different scopes

Manual LLM Adapter Install

Use this to prepare the standalone preview runtime.

The installer prepares the isolated runtime and owned session plugins. Inspect host status before use; permanent host registration and Desktop updater integration are not complete.

xcode-select --install   # Command line tools (skip if already installed)
git --version            # Confirm git is available
curl -fsSL https://raw.githubusercontent.com/agentlas-ai/Agentlas-OS/main/scripts/install-all-runtimes.sh | bash

Standalone automatic updates are off by default. After an update, recheck host status and owned alias state. Desktop updater integration remains incomplete.

Offline/local-source installation is not supported by this standalone installer. HEPHAESTUS_SOURCE_DIR is rejected with standalone_local_source_unverified. Do not bypass this check or report a local checkout as a verified installation.

Host routing status

Global routing is not installed by the standalone default. Permanent host registration is not confirmed in this preview. Legacy hephaestus global commands are not proof that the standalone runtime can register a host. Use the standalone host session commands below and inspect the actual receipt before claiming that tools or skills are ready.

When explicitly requested and connected, Network preserves the full local + cloud + hub scope. The host model selects and validates exact releases. Preparation is not execution, and local skills are not a silently substituted registered workforce.

The independent Agentlas Terminal owns the agentlas shell command. The standalone installer does not replace it.

Connect a standalone host session

Use the dedicated launcher after installation. Inspect the chosen host first; starting a session is a separate action. These commands use the isolated runtime under ~/.agentlas/os-runtime and owned plugins under ~/.agentlas/os-host-plugins, not a permanent marketplace installation or a copy of engine files into your project.

Check the installed host you intend to use:

~/.agentlas/os-bin/agentlas-os host status claude
~/.agentlas/os-bin/agentlas-os host status codex

Start a new session for that host when requested:

~/.agentlas/os-bin/agentlas-os host session claude
~/.agentlas/os-bin/agentlas-os host session codex

Antigravity has no session-only loader, so it is registered only when you ask, through Antigravity's own plugin manager. The plugin is agentlas-os-core and its MCP server is agentlas-os, so an older Agentlas registration stays separate:

~/.agentlas/os-bin/agentlas-os host install antigravity
~/.agentlas/os-bin/agentlas-os host status antigravity
~/.agentlas/os-bin/agentlas-os host remove antigravity

Start a new Antigravity session after installing. After a runtime update host status antigravity reports outdated; run host install antigravity again. Headless agy -p runs need the MCP permission rule mcp(agentlas-os-core_agentlas-os/*) in permissions.allow; interactive sessions ask.

Grok registers the same way through its own plugin manager (grok plugin install --trust):

~/.agentlas/os-bin/agentlas-os host install grok
~/.agentlas/os-bin/agentlas-os host status grok
~/.agentlas/os-bin/agentlas-os host remove grok

Start a new Grok session after installing; the tools appear as agentlas-os__. After a runtime update run host install grok again. Agentlas Desktop reaches Grok over ACP and does not use this registration.

Append -- only when you intend to pass arguments to the native host. Read the actual status and launch result. partial, session_activation_not_observed, or an unavailable component is not proof that the host is fully connected. A runtime install, a prepared plugin, and a running model session are separate results.

Select the qualified skill name shown by that session, for example agentlas-os-core:hephaestus-network. Old bare names may coexist; do not assume /hep-*, /agentlas, or an unqualified $hephaestus-* refers to this runtime. The command reference below describes capabilities; use only commands or tools actually exposed in your session.

Codex core tools and skills can be loaded in a separate session, but One and Memory hooks are not applied there yet. An ON preference is not evidence that those hooks ran; preserve unappliedHookComponents and codex_optional_hook_session_loader_unverified in the result. Windows host-session integration is unverified. Permanent host registration and complete native integration are not claimed. On Windows, unavailable link-creation privileges can leave status partial. A successful native inventory or version command does not prove a model turn or hook execution. Feature preferences use the shared ~/.agentlas/engine-features.json for standalone and Desktop. An explicit OFF also disables the feature in Desktop, overriding its default ON. With no explicit preference or compatibility override, standalone defaults OFF (memory defaults ON) and Desktop uses its own feature defaults. Standalone One on/off is separate state under ~/.agentlas/os-one.

After an update, run host status again. An owned Codex skill alias can still point at the older generation: outdated or codex_skill_alias_outdated means the new host session is not ready. Do not silently replace or delete the alias or fall back to a legacy runtime; report the exact state and follow an explicit repair procedure when available. Running host session codex again moves the launcher's own verified alias to the current generation. Automatic updates remain OFF by default; a runtime update does not prove host activation.

Inside native Agentlas environments, Hephaestus operates commandless. External LLM tools use a deliberately small visible command set for building agents and staffing work with them:

/hep-orch sets which model runs the orchestrator and which runs the workers, so a fan-out of mechanical work does not bill frontier runs. The split only puts two models to work on Claude Code, which is the one host that spawns a real subagent and takes a model per subagent. Codex, Antigravity, Cursor, and OpenCode have no subagent of their own: one model plays every role in sequence there, the allocation receipt is still written, and the ceiling still bounds what that model may request, but no second, cheaper model appears.

/hep-goal adds a plan tree to your host's own /goal. It first decides the shape of the goal. Short work with one clear check stays a single tactic and behaves exactly like the host goal, with no extra text. A long goal with a number you named becomes a mission tree: key results, strategies, tactics, and a KPI reading that says whether the plan is moving. It tells you when the numbers say the plan has stalled, and when the target looks out of reach it asks you instead of re-planning forever. The host goal still decides when the work is done; /hep-goal only keeps the plan and the numbers honest. A target is only a number you wrote in the goal text, and every reading needs a source and a short evidence quote. It changes only its own files under .agentlas/goal/, never permissions or payments. The default mode is shadow (it records and measures, injects nothing, applies no re-plan); set AGENTLAS_GOAL_STRATEGY=on to use it.

Performance on real long-running work remains unverified. Treat the plan tree as unproven until it has been checked on real goals.

Every row also answers to its original /hep-* name, /agentlas network and /hep-network are the same command. Nothing was renamed away, so existing scripts, notes, and muscle memory keep working. Current Codex uses explicit plugin skills $hephaestus-build, $hephaestus-network, $hephaestus-cloud, and $hephaestus-upload; other MCP surfaces can be requested in plain language. Custom /prompts:* commands were removed from Codex 0.117+.

Meta-Agent Factory, Process Creation

A unified compilation factory using four builders. Every generated package registers its global command (.agentlas/global-commands.json) and ships verification scripts, the user never has to infer how to run the compiled package:

Briefing Interview Gate: Builders initiate the process using the briefing interview gate : conducting lens-driven questions, evaluating the ambiguity threshold, searching primary sources, and outputting the work brief.

Network 2.0, The Scheduler

_{Figure 2. A2A scheduling: explicit host commands, model-selected exact releases, local memory, and federated Agentlas Network discovery.}

• Typed Job Analysis: The active host LLM turns the request into a redacted WorkOrder with explicit roles, skills, tools, artifacts, authority, cardinality, and handoffs. Core does not infer staffing intent from a substring list.
• Exact Source Federation: local, cloud, and hub are exact scopes; network is their sealed union. Each source returns a bounded, content-only menu, and Core records unavailable sources instead of silently widening scope.
• Host-Owned Task Forces: The host LLM reads the qualification evidence and authors the exact Selection. Core never chooses a deterministic winner or performs a hidden Router Agent re-rank; it validates governance, privacy, identity, cardinality, and graph integrity.
• Pinned Execution: After validation, Core fetches only the selected immutable releases from their original source sessions and verifies release, package, and content digests before distinct planner, worker, synthesis, and verifier invocations run.
• Evidence-Scored Evaluation: Retrieval coverage, host selection, immutable preparation, real child invocations, and final verification are scored as separate claims. A benchmark result never replaces the host staffing decision or turns usage history into routing authority.

Execute a prepared goal from an external host

An explicitly selected host plugin or executable can run the newest ready plan bound to a Workforce goal through the provider-neutral adapter contract:

./bin/hephaestus workforce execute \
  --project . \
  --goal-id <host-task-id> \
  --adapter-argv-json '["/absolute/path/to/host-adapter"]'

The adapter reads one versioned JSON request from standard input and writes one JSON response to standard output for inventory observation and each required orchestrator, planner, worker, synthesis, and verifier invocation. Core retains the exact preparation pins, verifies and snapshots output artifacts locally, and returns an execution receipt only after the existing receipt validator accepts the complete run. The adapter owns its provider authentication and native runtime configuration as an independently installed plugin; do not put credentials in the argv JSON. The complete v1 request, response, artifact, and failure contract is documented in agentlas_cloud/workforce/host_executor.py.

Tool inventory distinguishes native host enforcement (host-native) from a host-owned tool dispatcher (host-broker). A bound tool requires its invocation receipt to use that same enforcement path; neither label grants authority to a package that did not select the host permission policy.

Hephaestus packages agents into a standard directory layout that any workspace runtime can parse, install, verify, and run. The important part is not just agent.md; it is the operating contract around it. The layout below is what package-contract.json requires and hephaestus contract verify checks:

├── AGENTS.md                         # Package entry: name, purpose, canonical command, roles
├── agent.md                          # Primary instructions: role, steps, output contract
├── agentlas.json                     # Manifest: permissions, memory policy, read allow/deny lists
├── agents/<role>/agent.md            # Team only: one folder per worker
├── A2A/agent-card.a2a.json           # A2A Agent Card projected from the two cards below
├── .agentlas/
│   ├── agent-card.json               # Identity: name, slug, summary, capabilities, entrypoints
│   ├── routing-card.json             # Triggers and anti-triggers (ko + en), risk, memory behavior
│   ├── build-profile.json            # Fail-closed build readiness profile
│   ├── memory-map.json               # Memory ownership map
│   ├── global-commands.json          # Per-runtime slash command adapters
│   ├── mcp-policy.json               # What the machine must provide, and what happens without it
│   ├── skill-registry.json           # Skill inventory (may be empty)
│   ├── memory-tickets.jsonl          # Candidate memory events before curator promotion
│   ├── capability-eval-plan.json     # Positive/negative eval prompts with pass criteria
│   ├── routing-benchmarks.jsonl      # At least 10 route/reject cases, ko + en
│   ├── work-brief.json               # Interview-derived goal, constraints, decisions
│   ├── company-blueprint.json        # Team only: orchestrator, nodes, edges
│   ├── sitemap.json                  # Team only: what each task produces and consumes
│   └── brief.json                    # agentlas.brief/1 resume, compiled at upload
├── contracts/                        # intake.schema.json, output.schema.json, output.example.json
├── docs/                             # Builder interview, research sources, tool selection,
│                                     #   domain synthesis, prompt performance contract
├── tools/requirements.yaml           # Projected from mcp-policy.json + agentlas.json
├── permissions/policy.yaml           # Projected shell/network/file/payment whitelist
├── hooks/                            # memory-upgrade.yaml, on_stop.yaml, declared, host-enforced
├── evals/README.md                   # Points at the eval plan and routing benchmarks
└── .claude/skills/<name>/SKILL.md    # Skills, when the package carries any

docs/, the eval plan and the work brief may be skipped only by a user-confirmed minimal private build. provenance.json, knowledge/, schemas/, sandbox/ and examples/ are optional.

That package shape is why an Agentlas agent is more than an LLM-written role prompt. It carries routing, memory, input/output contracts, permissions, runtime adapters and evaluation evidence together.