EtherDocs
Guide/Personas

Who builds on Ether?

Ether is a platform. Different integrators connect at different layers — all through the same task and delivery model.

Personas

1. Harness builder (coding / research agent)

You run models and tools against a repo or corpus. You do not want to rebuild user memory, task grids, or delivery cards.

You use: Harness API — claim, context docs, steps, result.
Reference: Ether Code, @ether/os-sdk.

Example: A startup ships “Acme Code” — a CLI that claims Ether tasks and opens PRs on GitHub.

2. Product / frontend integrator

You have a UI where users submit work and watch outcomes. You may or may not run the agent yourself.

You use: Product API (POST /api/tasks), Realtime WebSocket, delivery payload rendering.
Reference: ether-app design — subscribe to tasks/{task_id}.

Example: An internal ops dashboard submits tasks and renders task.delivered blocks in your design system.

3. Automation / backend integrator

Cron jobs, Slack bots, or CI pipelines that enqueue work for Ether to track.

You use: Auth + POST /api/tasks; optionally poll activity or subscribe to WS.
Example: Nightly “scan dependencies” task created via API; harness picks it up from the grid.

4. First-party Ether surfaces

  • ether-app — consumer product UI
  • Ether Code — reference harness
  • In-process OS brain — default coding path when no external harness is configured

Third-party integrators use the same contracts as first-party code.

Choose your integration path

mermaid
flowchart TD
  Q{What does your software do?}
  Q -->|Runs the agent loop| H[Harness path]
  Q -->|Submits work + shows UI| P[Product path]
  Q -->|Both| B[Both APIs]

  H --> C[POST claim → execute → POST result]
  P --> T[POST tasks → WS subscribe → render delivered]
  B --> C
  B --> T
PathMinimum integration
Harness onlyJWT + Harness API + X-Ether-Harness-App header
UI onlyJWT + tasks + realtime (no harness if Ether runs in-process brain)
Full stackYour UI submits tasks; your harness claims and returns results

Anti-patterns

  • Importing ether-core Rust into your agent repo — use HTTP/SDK only; stay decoupled like Ether Code.
  • Treating open folder as scope — scope comes from the ExecutionBundle after claim, not from whatever directory the user opened.
  • Skipping submitResult — without it, Ether cannot complete the task or publish delivery.