How it works · architectural illustration
From a workflow request to reviewed, durable output.
A hypothetical multi-VPS scenario shows how ANDIP is designed to organize agent work. This sequence is an architectural illustration—not a proven live demonstration.
Enroll already-provisioned VPS workers
An administrator requests a short-lived, single-use enrollment token. A worker presents its public key and machine identity over TLS, receives its worker identity, runs resource probes, then waits for approval if policy requires it. Initial state is not treated as active until the required checks pass.
Describe a goal and workload constraints
A user submits a project workflow with task dependencies, adapter needs, resource requests, deadlines, permissions and budget rules. The request is validated and durably recorded before execution.
Organize work into a dependency graph
The workflow layer identifies independent tasks and prerequisites. A task whose dependency is incomplete is not eligible for assignment; unsupported capabilities remain blocked rather than silently substituted.
Select a compatible agent adapter
Agent definitions describe version, capabilities, runtime and resource profile. Coding, browser, research, data-processing and custom workloads may use different adapters; browser execution is optional.
Evaluate worker capacity and policy
The scheduler filters by worker state, runtime, CPU, memory, disk, browser slots, region, network/secret policy and budget. It accounts for current reservations and configured headroom.
Reserve resources and issue a fenced lease
Assignment, resource reservation, attempt state and lease are intended to commit atomically. A fencing generation prevents a late worker from committing over a newer attempt.
Prepare an isolated execution environment
The worker creates a per-attempt workspace or container, applies resource and network limits, and provides only short-lived, scoped secret references. Browser tasks need a distinct profile and process boundary.
Launch and monitor the agent
The worker launches the declared adapter, reports heartbeat, logs, progress and metered usage, and records compatible checkpoints. Missed heartbeat pauses new assignments and initiates lease reconciliation.
Verify outputs and handle failures safely
Candidate output is checked against a task-specific postcondition. Pure/idempotent work may be retried; uncertain external changes require reconciliation or review. A “done” event from an adapter alone is not proof.
Persist artifacts and clean up temporary state
Results, logs and traces are uploaded with checksums before completion. The worker revokes scoped credentials, terminates process trees, closes browser profiles, releases capacity and deletes temporary workspaces.
Policy note: browser activity and data processing must be authorized and respect website terms, privacy, rate limits and access controls. Unsupported or uncertain actions should be blocked or reviewed.