Core Concepts

Platforms, agents, tasks, versions, executions, and agent sessions — how reArray's model fits together.

reArray organizes automation around a few core entities. Understanding how they connect makes it easier to design reliable workflows.

Workspace (account)

A team workspace is an isolated tenant. All platforms, agents, tasks, executions, and API keys belong to one workspace. Members share access according to team roles.

Platforms

A platform represents a website or web application your automations interact with.

Field	Purpose
Name	Display label in the UI
Handler	Identifier referenced in DSL (`in my_handler { ... }`)
URL	Default starting URL for the platform
Metadata	Optional JSON for your own notes or configuration

Platforms are defined at the workspace level. Multiple agents can use the same platform with different credentials.

Agents

An agent is a configured runtime worker. Agents:

Run task executions in isolated browser sessions
Scale worker pods based on concurrency settings (minimum, maximum, idle timeout)
Hold per-platform configuration: vault credentials, captcha settings, and max_concurrent_tasks

Agents do not contain task logic — they execute whatever task is queued against them.

Agent sessions

When an agent runs work, it creates an agent session — a live browser environment backed by a Kubernetes pod. Sessions have modes:

Mode	Purpose
`execution`	Runs queued task executions
`assistant`	Interactive AI chat to help build workflows
`maintenance`	Platform auth setup and diagnosis

Browser state (cookies, local storage) persists within a session, which enables session-aware login patterns.

Tasks and versions

A task is an automation definition. Tasks are versioned:

Each version stores a dsl_script, params_schema, and optional store_schema
Tasks link to one or more platforms they interact with
The latest version is used by default; API callers can target a specific version

Versioning lets you iterate on scripts without losing history.

Executions

An execution is a single run of a task on an agent. Executions carry:

Params — Input values passed at run time (from UI or API), available as $params.* in DSL
Reference — Optional caller-supplied identifier for correlation
Metadata — Optional free-form JSON for your systems
Result — Output data when the run completes successfully
Callback URL — Optional webhook target for status events (API-triggered runs)

Execution lifecycle

pending → queued → running → completed
                          ↘ error
                          ↘ aborted
                          ↘ cancelled

Status	Meaning
`pending`	Created but not yet queued
`queued`	Waiting for an agent worker to claim it
`running`	Active in a browser session
`completed`	Finished successfully
`error`	Failed with an error message and DSL location
`aborted`	Stopped by user or system
`cancelled`	Cancelled before or during run

How entities connect

Workspace
├── Platforms          (websites: handler, url)
├── Agents             (workers: concurrency settings)
│   └── AgentPlatforms (per-agent platform config + vault)
├── Tasks              (automation definitions)
│   ├── TaskVersions   (dsl_script, params_schema)
│   └── TaskPlatforms  (platform linkage)
├── Executions         (individual runs)
└── API Keys           (Integration API credentials)

Typical workflow

Register platforms for the sites you automate.
Create an agent, attach platforms, and store credentials in the vault.
Build tasks in DSL referencing platform handlers.
Run tasks manually or via the Integration API.
Monitor executions with live stream and video replay.