In development Community beta target Q1 2027 View roadmap
ANDIPDistributed infrastructureJoin Beta

Platform · proposed capabilities

An execution layer for agents across the servers you already operate.

ANDIP aims to unify workload scheduling, isolated execution, visibility and recovery—without requiring Kubernetes for the initial MVP.

Development status: The capabilities described on this page are planned or undergoing technical validation. This page describes a product direction, not released functionality.
Core capabilities

One system boundary, with clear ownership at every layer.

Each capability below depends on new infrastructure work and measurable engineering gates.

Unified Control Plane

Receive workflow requests, apply identity and policy checks, maintain durable execution state, coordinate scheduling and present operational context.

Planned

Distributed VPS Management

Enroll already-provisioned Linux workers, track heartbeat and resource inventory, and cordon or drain workers through explicit state transitions.

Planned

Agent Workload Scheduling

Filter workers by runtime, resource fit, region, permissions and quota; reserve capacity atomically and issue a fenced lease.

Under validation

Isolated Execution

Prepare per-attempt workspaces and rootless container boundaries, with scoped secrets, resource limits and network policy.

Planned

Durable Task Processing

Persist workflow state and queue transitions so a restarted controller can reconcile leases instead of losing the record of work.

Planned

Monitoring & Audit Trails

Collect worker health, attempt events, artifact references, usage and policy decisions; distinguish stale data from current state.

Planned

Resource & Budget Controls

Reserve resource and cost budgets before assignment, then meter usage and throttle or pause according to project policy.

Planned

Failure Recovery

Reconcile expired leases, apply fencing, resume compatible checkpoints, and send uncertain side effects to review before retry.

Planned

Model & Agent Extensibility

Keep agent adapters distinct from the distributed scheduler so supported runtimes and models can evolve independently.

Planned
Placement example

Schedule by fit, not by a fixed count per machine.

A team connects several existing VPS instances. ANDIP would inspect declared capacity and worker health, compare each task's requirements and policy, then reserve compatible resources. Coding, research and browser work can have different profiles.

If capacity or provider quota is insufficient, work remains queued rather than being overcommitted. The intended scheduler also preserves headroom and accounts for locality, cost and worker state.

Illustrative scenario only. Worker sizes, task counts and performance outcomes are not claims about a running deployment.

A central scheduler ranks VPS by workload compatibility, policy, capacity and budget. Tasks may run on different workers or remain queued.
Illustrative scheduling model. Capacity and policy constrain placement; equal distribution is not assumed.
A worker maintains outbound TLS communication to the control plane, claims a fenced lease, executes in an isolated runtime, and returns heartbeat and artifacts.
MVP communication pattern. The MVP design favors outbound HTTPS long-polling and heartbeat, avoiding an inbound worker port open to the public internet.
A pragmatic first deployment

Central coordination. Distributed execution.

A centralized control plane owns project, workflow and placement decisions. Distributed workers own local execution and resource use. This split gives the scheduler a fleet-wide view while keeping agent processes on the worker that has suitable capacity.

Why not Kubernetes first?

The MVP begins with already-provisioned VPS and a worker daemon. A Kubernetes control plane would add operational components before autoscaling, managed provisioning or service-mesh requirements justify them. The architecture can revisit that choice when evidence demands it.

Agent supervision vs. infrastructure orchestration

Agent Orchestrator can supervise local agent sessions and tools. ANDIP must separately own distributed leases, worker health, durable queue state, resource reservation and cross-server recovery.

Sequence example

Connect a fleet, submit work, collect checked artifacts.

In this proposed scenario, the user enrolls existing VPS instances, submits several agent workloads, and reviews their progress and outputs from one control layer.

  1. Connect existing servers

    An administrator enrolls a worker with a short-lived token. The worker reports machine identity and capacity through an authenticated outbound channel.

  2. Describe tasks and policy

    A workflow is decomposed into dependent tasks with declared resource requirements, allowed tools, budget and deadlines.

  3. Filter and reserve capacity

    The scheduler filters incompatible workers, reserves a suitable slot atomically and issues a lease with a fencing generation.

  4. Run isolated attempts

    A worker prepares an attempt-specific environment, launches a selected adapter and streams progress while enforcing the declared limits.

  5. Verify, persist and clean up

    A task-specific verifier checks candidate output; artifacts are stored with checksums, then credentials and temporary resources are cleaned up.

Architecture illustration—not a proven live demonstration.