Skip to main content
An environment is a complete EaaS unit: app under test, backend, fixture/seed protocol, task bank, and verifiers. Agents drive the app against a deterministic backend with a fixed catalog and seeded session state.

​
Selecting an environment

Pass env_id on POST /evaluations/run (and related APIs): The public API host is shared; environment selection is entirely via env_id.

​
Reset contract

Every episode starts from a reset payload (seed, fixture_id, max_steps, task_spec). On the private orchestrator this is often nested under a legacy field named harbor_reset on the task bank row.
Operators with private orchestrator access can load the reset object from GET /tasks/{task_id} and POST it to POST /v1/env/reset. Most clients should use POST https://agi.akhara.ai/evaluations/run instead.

​
Observation surface

Each step returns (via env API or eval wrapper) roughly:
  • Screenshot: JPEG / base64 (wrapper always; some mock capabilities omit screenshot modality)
  • screen_id: canonical screen (HOME, SEARCH_RESULTS, PDP, CART, CHECKOUT_REVIEW, ORDER_CONFIRMATION, …)
  • UI element ids: stable automation ids (e.g. home.search.input, pdp.add_to_cart)
  • Env state refs: user_id, cart_id
  • Verifier snapshots: PASS / FAIL / IN_PROGRESS per verifier
Checkout success typically ends on ORDER_CONFIRMATION. Search-add tasks often terminate on CART. Screen graphs differ by environment; shopping environments share the flow below.

​
Screen graph (shopping environments)

​
State truth

Production Android scoring often uses a hybrid terminal reward: primary VU must PASS and device DB must PASS when evaluated. See Verifiers.

​
Isolation notes

  • Each episode gets its own cart / session binding.
  • Device capacity is physical: one executor serial runs one episode at a time.
  • Seed-derived stock masks filter out-of-stock SKUs before verifiers pick expected targets.