PhoenixFlight

Keep work moving when members change.

Open-source reference runtime for Dynamic Membership Architecture.

Dynamic systems are volatile. Pods restart, agents fail, services scale, tools appear, and resources retire. PhoenixFlight demonstrates how work can continue by moving as portable Flight Packets across dynamic members while preserving context, policy, lineage, and audit.

View GitHub

Members change. Packets move. Execution continues. Audit records everything.

Architecture Taxonomy

This page presents a research-backed runtime prototype for Dynamic Membership Architecture.

Dynamic Membership Architecture

The research framework for systems where participants dynamically join, leave, fail, recover, migrate, or hand off work while execution continues.

PhoenixFlight

The open-source reference runtime that demonstrates DMA using member registration, capability discovery, workload assignment, handoff, retirement, and audit.

Flight Packets

Portable units of work that carry identity, context, policy, ownership, handoff history, and audit lineage across dynamic members.

DMA is the pattern. PhoenixFlight is the proof. Flight Packets are the mechanism.

The Pain Point

Modern systems assume members are stable longer than they really are.

⚠️ Pods restart

⚠️ Nodes scale

⚠️ Agents fail

⚠️ Tools disappear

⚠️ Capabilities change

⚠️ Policies evolve

⚠️ Context gets stranded

⚠️ Audit trails fragment

PhoenixFlight treats this volatility as normal. Work is packaged as a portable Flight Packet, matched dynamically to eligible members, moved automatically when ownership changes, and recorded end-to-end through the Flight Recorder.

The Core Idea

Traditional systems often bind work directly to a specific machine, pod, service, or agent. PhoenixFlight separates the work from the current participant. The Flight Packet carries the work, context, policy, and audit trail. The runtime decides which dynamic member should own it now, where it should move next, and how the transition is recorded.

Kubernetes reschedules compute. PhoenixFlight reschedules ownership of work.

Kubernetes answers: where should this container run?
PhoenixFlight answers: who owns this work now, what context moved, and who can prove it?

Traditional Runtime

Workloads are hard-coded or bound directly to individual target processors or static host names. If the host becomes overloaded, undergoes scaling churn, or fails mid-execution, the application state is lost or aborted.

Application

→

Machine / Pod / Agent

PhoenixFlight

Work exists as a portable Flight Packet. The runtime matches packets to dynamic cluster members (agents, tools, services) semantic-by-semantic, maintaining execution checkpoints, lineage, and audit trails.

Application

→

Flight Packet

→

Dynamic Member

DMA Primitives to PhoenixFlight Mapping

DMA Primitive	PhoenixFlight Runtime Function
Identity	Member identity and Flight Packet identity
Discovery	Capability directory and active member registry
Assignment	Scheduler routes packets to eligible members
Migration	Context handoff moves packet ownership
Retirement	Members drain, fail, or leave without losing work
Governance	Policy, trust score, audit, lineage, and eligibility rules

The Flight Lifecycle

PhoenixFlight manages the full lifecycle of dynamic work movement.

01 / Register

Register

Dynamic members join with identity, capabilities, capacity, status, trust, and runtime metadata.

02 / Discover

Discover

PhoenixFlight discovers which members are active, what they can do, and whether they are eligible for specific work.

03 / Assign

Assign

Flight Packets are routed to eligible members based on capability, load, reliability, policy, and context.

04 / Handoff

Handoff

When a member fails, retires, or becomes overloaded, the packet can move to another eligible member.

05 / Retire

Retire

Members can drain, leave, or fail without breaking the continuity of work.

06 / Record

Record

Every registration, assignment, handoff, retirement, and completion is captured in the Flight Recorder.

Why Dynamic Membership Matters

Modern distributed environments are volatile. Pods churn, edge sensors disconnect, and LLM agent nodes boot up dynamically. Static configurations fail under pressure. PhoenixFlight offers the scheduling core to navigate this churn.

Distributed Systems

Implements consistent ring partitioning inspired by the classic Phoenix Computing Model. Distributes stateful workloads evenly across dynamic nodes with minimal remapping cost during join/leave events.

Cloud-Native Scheduling

Performs capacitated bin-packing scheduling similar to Kubernetes pod scheduling. Automatically relocates and rebalances compute workloads when resource pressure triggers threshold warnings.

Agentic AI Runtime

Acts as an orchestrator for dynamic AI Agents. Discovers specialized agents based on skill capabilities, assigns work, and migrates task logs/histories automatically if an agent retires or fails.

Core Narrative Concept

Flight Packets

Portable units of work, context, policy, and audit.

A Flight Packet is the atomic unit of movement in PhoenixFlight. It carries the workload identity, required capabilities, current owner, context checkpoint, policy constraints, handoff history, and audit trail. Because the packet is portable, work can continue even when the member currently handling it changes.

// PORTABLE WORKLOAD ENVELOPE

{

"packet_id": "fp-001",

"workload_type": "customer-remediation",

"required_capabilities": ["customer_validation", "policy_review"],

"current_owner": "agent-customer-01",

"previous_owners": ["agent-triage-02"],

"context_checkpoint": {

"case_id": "CUST-88291",

"step": "policy_review_pending",

"state_hash": "sha256:9c12..."

"policy_constraints": {

"pii_review_required": true,

"minimum_trust_score": 0.90,

"allowed_regions": ["us-east"]

"handoff": {

"allowed": true,

"reason": "source_member_unhealthy"

"audit": {

"created_at": "2026-06-13T20:00:00Z",

"last_event": "handoff_completed",

"lineage_id": "lin-7742"

"status": "ASSIGNED"

}

Artifact ecosystem

PhoenixFlight Hub

Discover installable Flight Packs for dynamic membership runtimes.

PhoenixFlight Hub is the registry layer for runtime-ready participants, policies, adapters, and agentic execution blueprints. Docker Hub tells you where an image lives. PhoenixFlight Hub tells you what a participant can do, how it joins, how it migrates, how it retires, what policies govern it, and how its lifecycle is audited.

customer-validation-agent Agent

Verifies customer record profile data and flags golden record matches for MDM resolution.

customer-validation policy-review golden-record-suggestion

Migration Supported

Governance PII Review Required

Trust Level High

Version 1.0.0

k8s-pod-handoff-adapter K8s Adapter

Handles node-pressure rescheduling, pod draining, and remapping compute allocations.

pod-drain workload-remap node-pressure-response

Migration Partial

Governance Cluster RBAC

Trust Level Medium

Version 1.1.0

consistent-hash-vnode-runtime Runtime

Implements virtual node consistent hashing rings to route packets with minimal re-mappings.

vnode-mapping hash-ring-routing minimal-remap

Migration Supported

Governance Optional

Trust Level Medium

Version 2.0.4

agent-context-migrator Handler

Handles memory transfer, serializes context states, and handles handoff triggers.

context-snapshot memory-transfer agent-handoff

Migration Native

Governance Audit Required

Trust Level High

Version 1.0.0

governed-mdm-workflow-agent Blueprint

Enterprise data validator and manager routing records with approval controls.

master-data-validation workflow-routing stewardship-escalation

Migration Supported

Governance Data-Domain Auth

Trust Level High

Version 0.9.5

flight-recorder-audit-pack Governance

verifiable logging daemon capturing membership changes and assignment lineages.

event-log lineage-recording decision-reason-capture

Migration N/A

Governance Required

Trust Level High

Version 1.2.0

Why PhoenixFlight Hub Is Not Docker Hub

Dimension	Docker Hub	PhoenixFlight Hub
Artifact Type	Container image	Flight Pack (agent, policy, adapter, migration handler, governance profile)
Main Question Answered	Where is the container image?	What can this participant do, how can it move, and how is it governed?
Runtime Metadata	Image layers, target architectures, and tags	Identity, capabilities, migration protocols, trust metrics, policy gates, and audit levels
Deployment Target	Container runtimes (containerd, runc, Docker Engine)	Dynamic membership runtimes, Kubernetes clusters, agentic AI execution layers
Governance Model	External and decoupled (orchestrated by third-party tooling)	Built directly into the artifact manifest schema and validated at registration

Ecosystem Concepts

Packaged Blueprint

Flight Pack

A schema-validated directory containing metadata, capabilities, migration logic, and trust/governance gates defining a participant.

Portable Unit

Flight Packet

An active unit of work carrying execution checkpoints, routing formulas, ownership claims, policies, and lineage hashes.

Active Participant

Dynamic Member

A node, microservice, agent, or tool that has registered capability claims, handles assigned tasks, and supports migration.

Verifiable Lineage

Flight Recorder

A cryptographically verifiable transaction ledger logging all member joins, exits, assignment decisions, and handoff actions.

Shift from Container Images to Runtime Membership

Traditional devops models deploy binaries to static hosts. PhoenixFlight orchestrates capability-based units of work to active, self-balancing networks.

Container World (Static Infrastructure)

Container Image: Static binary snapshot & environment package.

↓

Container / Pod: Isolated execution process scheduled on physical nodes.

↓

Infrastructure Scheduling: Focuses on compute resources (CPU/Memory).

PhoenixFlight World (Dynamic State & Governance)

Flight Pack: Schema-declared capabilities, policies & adapter profiles.

↓

Flight Packet: Portable task packet carrying active execution state.

↓

Dynamic Handoff: Work transfers dynamically across nodes based on trust/load.

Install, Pull, Register, Run

Get started with the PhoenixFlight Command Line Interface to interact with registries and coordinate memberships.

cli sequence walkthrough

# 1. Install the runtime binary package

$ curl -sSL https://phoenixflight.io/install.sh | sh

# 2. Pull an agent Flight Pack from the Registry Hub

$ phoenixflight pull hub/customer-validation-agent:1.0.0

# 3. Register the Flight Pack as an active member in your local node topology

$ phoenixflight register --pack hub/customer-validation-agent:1.0.0 --name validation-agent-01

# 4. Deploy and execute context-preserving workload packets

$ phoenixflight run --workload mdm-cleanup-task.json

Designed for the Entire Tech Stack

How different roles build, deploy, and audit dynamic execution rings.

For Developers

Define agent capabilities, package dependencies, implement standard handoff interfaces, and test dynamic reassignments locally using the PhoenixFlight CLI.

Declare capability schemas in YAML
Write stateless state context hooks
Run mock failover loops

For Architects

Orchestrate networks of micro-agents, load-balance capacity pools, set strict data boundary policies, and bridge Kubernetes compute with cognitive AI tasks.

Define policy gates & trust rules
Configure multi-cluster rebalancing
Control target handoff metrics

For Researchers

Study virtual-node placement ring algorithms, calculate workload routing churn coefficients, and audit cryptographic lineage state histories.

Analyze consistent hash ring load skew
Evaluate semantic matching ratios
Investigate failover performance decay

Above the Pod Layer

PhoenixFlight does not replace Kubernetes. Kubernetes manages where containers run. PhoenixFlight manages who owns a portable unit of work, how that work moves when members change, and how the lifecycle is audited.

PhoenixFlight Layer

Dynamic Members

Flight Packets

Handoffs

Flight Recorder

Kubernetes Layer

Pods

Nodes

Services

Infrastructure Scheduling

Where PhoenixFlight Helps

See how PhoenixFlight coordinates work packets across dynamic resources in enterprise architectures.

Agentic AI Handoff

An AI agent begins a task, fails or loses eligibility, and PhoenixFlight moves the Flight Packet to another agent with context and audit history intact.

Kubernetes Pressure Rebalancing

A node becomes overloaded. Kubernetes can move pods, but PhoenixFlight tracks work ownership, context handoff, and lifecycle audit above the pod layer.

Governed Enterprise Workflow

A customer data remediation task must only run on members with the right trust score, governance profile, and data-domain permission.

Why Agentic AI Needs Dynamic Membership

Agentic systems are dynamic by nature. Agents are not permanent workers. Tools appear and disappear. Capabilities change over time. Context must survive handoff. Trust and policy must follow the work. Audit must explain why an agent was selected.

PhoenixFlight treats agents as dynamic members and treats work as portable Flight Packets. This makes agent orchestration inspectable instead of magical.

// INSPECTABLE EXECUTION FLOW

Task

→

Planner

→

Capability Match

→

Agent Assignment

→

Context Handoff

→

Audit Event

Governed Lineage

Flight Recorder: Governed Lineage for Dynamic Work

Lifecycle audit for dynamic work movement.

Without governance, dynamic membership becomes chaos. PhoenixFlight records each membership event, assignment decision, handoff, and retirement so runtime behavior can be explained after the fact.

Logs tell you that something happened. The Flight Recorder answers critical governance and audit questions:

Who registered? (Member Registration events)
What capability was advertised? (Capability Discovery records)
Why was this member selected? (Scheduling Score logs)
What context moved? (Context Checkpoint snapshots)
Why did handoff occur? (Handoff trigger events)
Which policy allowed it? (Policy Validation reports)
When did the member retire? (Graceful retirement/drain events)

member_registered

packet_created

capability_discovered

assignment_decision

handoff_started

handoff_completed

member_retired

packet_completed

PhoenixFlight Capabilities

Designed as an inspectable reference prototype, PhoenixFlight provides core primitives out-of-the-box.

Member Registration

Dynamic endpoints and servers register identities, specific capabilities, capacity limits, and credentials.

Capability Directory

A searchable catalog mapping skills and services to their registered providers.

Workload Assignment

Matches tasks to resources using consistent hash mapping, bin-packing score carding, or capability filters.

State/Context Handoff

Transfers task context snapshots from one member to another to preserve task progress during failure.

Draining & Eviction

Gracefully migrates tasks from a retired member before marking it inactive, preventing task losses.

Audit Event Trails

Records all cluster activities and policy routing choices into a structured queryable log stream.

The Developer Journey

See how you can programmatically interact with the PhoenixFlight API to drive the runtime lifecycle.

Register a Member

Bootstrap nodes, agents, or tools into the dynamic membership pool with metadata.

Submit a Workload

Queue running workloads with capacity demands or capability requirements.

Discover Eligible Members

Query the dynamic discovery engine to find active members meeting specific filters.

Trigger Stateful Handoff

Force migrate workload context from a source resource to a new target resource.

HTTP Request - Curl Command

curl -X POST http://localhost:8000/api/members/register \
  -H "Content-Type: application/json" \
  -d '{
    "id": "agent-planner-01",
    "type": "agent",
    "capabilities": ["planning", "routing"],
    "cpu_capacity": 50.0,
    "memory_capacity": 500.0,
    "trust_score": 0.95
  }'

What PhoenixFlight Is Not

To prevent confusion and build trust, here is a clear boundaries framework.

Not a Kubernetes Replacement

It is not an infrastructure orchestrator or a container runtime manager. It does not manage system namespaces, VM provisioning, or network subnets.

Not a Workflow Engine Replacement

It is not a static DAG execution engine or a state machine runner. It does not replace tools like Temporal, Airflow, or AWS Step Functions.

Not an LLM Agent Framework

It is not a framework for prompting, prompt chaining, or vector databases. It works above agent frameworks (LangChain, AutoGen) to manage their execution boundaries.

Not a Production Control Plane

It is not yet hardened for mission-critical production clusters. It is currently a reference runtime, simulator, and validation prototype.

PhoenixFlight is a reference runtime and simulator for studying Dynamic Membership Architecture: portable work, dynamic participants, governed handoff, and observable execution continuity.

Architecture Overview

Verifiable execution layer layout connecting web UI inputs to the background resource registers.

Simulation Experiments

The simulator answers one question: what happens to work when the members responsible for it keep changing?

Phoenix-style virtual nodes

How much workload remapping happens dynamically when physical resources join, leave, fail, or recover in a consistent ring?

Kubernetes-style scheduling

How does capacity pressure, CPU/memory limits, and active member churn trigger workload eviction and safe reassignment?

Agentic AI routing

How do reliability scores, dynamic capability changes, and semantic trust matching affect total task completion rates?

Integrated Simulation Showcase

The simulator demonstrates PhoenixFlight across Phoenix-style virtual nodes, Kubernetes-style scheduling, and agentic AI-style capability routing. It visualizes partition ring rebalances, capacity constraint bin packing, and Agentic reliability scores under dynamic churn conditions.

✓ Consistent Hash Ring: Visualizes how virtual node tokens partition and map keys on a circular consistent hashing boundary.

✓ Compute Capacity Graphs: Track CPU core usage and memory consumption card limits on active hosts.

✓ Agent Skills Directories: Observe how active agents execute tasks based on availability and tool accuracy rates.

Simulator Snapshot Layout

Ring

Node 0: [████░░░░] 50%

Node 1: [██████░░] 75%

Agent: active, 92% rel

Steps Complete

Build with PhoenixFlight

PhoenixFlight gives developers a reference runtime for systems where participants continuously join, leave, fail, recover, and hand off work. Use it to experiment with dynamic member registration, capability discovery, Flight Packet assignment, handoff, retirement, and lifecycle audit.

1. Clone Repository

Clone the open-source reference implementation to your local workspace.

git clone https://github.com/...

2. Install Core Libraries

Install the required charting and comparison data tools.

pip install matplotlib pandas...

3. Boot Backend Server

Start the API server. By default, it binds to localhost on port 8000.

python3 server.py --port 8000

Roadmap

v0.1

Reference Simulator

Simulator and runtime console

v0.2

Registry & Store

Persistent registry and audit store

v0.3

Policy Engine

Policy-aware assignment engine

v0.4

Agentic SDK

Agentic handoff SDK

v0.5

K8s Integration

Kubernetes integration experiment

v0.6

Lineage Export

Governance and lineage export

v1.0

Stable Runtime

Stable reference runtime release

FAQ

What is Dynamic Membership Architecture?

Dynamic Membership Architecture is a framework for systems where participants dynamically join, leave, fail, recover, migrate, or hand off work while execution continues.

What is PhoenixFlight?

PhoenixFlight is the open-source reference runtime that demonstrates DMA using portable Flight Packets.

Does PhoenixFlight replace Kubernetes?

No. Kubernetes schedules containers onto infrastructure. PhoenixFlight manages ownership, handoff, context, policy, and audit of portable units of work above the infrastructure layer.

Why does this matter for agentic AI?

Agentic AI systems rely on dynamic agents, tools, memory, and policies. PhoenixFlight provides a runtime pattern for assigning, handing off, and auditing work as those members change.

What is a Flight Packet?

A Flight Packet is a portable unit of work that carries workload identity, required capabilities, context checkpoint, policy constraints, ownership history, and audit lineage.

What is Flight Recorder?

Flight Recorder is the audit and governance layer that records membership events, assignment decisions, handoffs, retirements, and policy decisions.

Research Foundation

Dynamic Membership Architecture generalizes a recurring systems pattern: execution must continue even when the participants responsible for work change.

The idea traces back to the Phoenix Computing Model, which introduced virtual nodes to separate logical execution identity from physical processors. PhoenixFlight extends that idea into a modern reference runtime for cloud-native systems and agentic AI environments.

Download Paper View GitHub

The Six Primitives of DMA

Identity

who participates in execution boundaries

Discovery

what capabilities are advertised and available

Assignment

who owns the portable work envelope right now

Migration

how execution context travels safely between hosts

Retirement

how members gracefully drain, fail, or leave the registry

Governance

how policy constraints, trust score rules, and lineages follow work

Runtime Console Overview

Real-time status of the PhoenixFlight Dynamic Membership Architecture runtime.

Active Members

Registered nodes and agents

Capability Catalog

Registered unique skills

Active Workloads

Workloads currently running

Audit Trail Events

Verifiable state events recorded

Flight Core Status: Active

PhoenixFlight endpoints are operational. Workload scheduler and capability routers are running in-memory. Navigate through tabs to manually inspect registry pools and trigger state migrations.

1. Register

→

2. Discover

→

3. Assign

→

4. Handoff

→

5. Audit

Member Registry

View active participants (servers, microservices, nodes, agents, and tools) and add new ones to the pool.

Register Dynamic Member

Member ID

Name

Member Type

Capabilities (Comma-separated)

CPU Cores

Memory (MB)

Reliability Score (0.0 to 1.0)

Trust Score (0.0 to 1.0)

Active Members Pool Directory

ID	Type	Capabilities	Load (CPU)	Reliability	Status	Actions
Initialize simulation or add member to populate list.

Capabilities Directory

Search active skills and discover which members own and advertise them.

Capability	Category	Verifiable Description	Owner Provider Members	Version
Initialize simulation to map directory.

Hub Registry

Discover and register packaged Flight Packs directly into the active member ring.

Pack Name	Type	Version	Capabilities	Migration	Governance	Trust Score	Actions

Workload Queue Management

Create active tasks or workloads, and observe their scheduled routes and capacities.

Submit Running Workload

Workload ID

Task Name

Workload Type

Hash Routing Key

Required Skill / Capability

CPU Demand Cores

Memory Demand (MB)

Priority

Active Queue Stream

ID	Name	Type	Demand	Assigned To	Status	Actions
Initialize simulation to populate queue.

Assignment & Scheduling Decisions

Analyze how workloads are scheduled based on eligibility rules and resource loads.

Live Assignment Routing Matrix

Routing Formulas:
- Consistent Hashing (Phoenix): Token = MD5(Key) % 10000. Scheduled on the clockwise closest virtual node token.
- Capacitated Bin Packing (Kubernetes): Score = Fraction CPU Free + Fraction Memory Free on active nodes.
- AI Agents Routing: Score = Agent Reliability / (1 + Active Task Count) for agents with matched skills.

Workload Task	Type	Routing Requirements	Selected Member Target	Status
Initialize simulation to view assignments.

Context Handoffs & Migrations

Coordinate or trigger state migrations of workloads between cluster resources.

Trigger Task Handoff

Select Workload

Source Node (Current host)

Target Node (New destination)

Reason for Handoff

Migration Logs & Context Snapshots

Handoff ID	Workload	Source	Target	Reason	Status
No state context handoffs logged yet.

Audit Log & Verifiable Governance

A queryable event stream logging every membership registration, scheduling decision, and handoff.

Runtime Health Analytics

Performance indexes and stability scores aggregated across dynamic operations.

System Churn Rate

0.0000

Remappings per step

Stability Index (SI)

1.0000

High SI represents system resilience

Successful Migrations

Handoffs completed

Task Success Rate

100.0%

0 / 0 completed

Verifiable Operations Record

PhoenixFlight maintains zero packet loss during context migration handoffs. Active consistency hashing re-routes less than K/N workloads during resource volatility sweeps, maximizing balance efficiency.

Simulator Mode

The simulator demonstrates PhoenixFlight across three dynamic membership patterns: Phoenix-style virtual nodes, Kubernetes-style capacity scheduling, and agentic AI-style capability routing.

Phoenix-style Virtual Nodes Kubernetes-style Scheduling Agentic Capability Routing

Load Scenario Preset:

Total Steps

Initial Nodes

Threshold

Seed

Stability Index

1.0000

Cumulative system resilience

Churn Rate

0.0000

State transitions per step

Total Migrations

Active workload relocations

Task Completion

100.0%

0 / 0 completed

Consistent Hash Ring

Phoenix Partitioning

Physical Compute Resources

K8s Bin Packing

Initialize simulation to view nodes.

Agentic AI Registries

Capability Routers

Initialize simulation to view agents.

Simulation Analytics Metrics

Step: 0 / 100

Load Balance Efficiency

Running Churn Rate

Workload Relocations

Live Event Logs

Simulator server connection ready. Adjust parameters and click "Initialize".

Step Explainer Narrative

Step 0

Waiting for simulator actions...

Initialize the simulation to generate real-time routing analysis and step-by-step handoff explainers.

PhoenixFlight

Keep work moving when members change.

Open-source reference runtime for Dynamic Membership Architecture.

Architecture Taxonomy

Dynamic Membership Architecture

PhoenixFlight

Flight Packets

The Pain Point

The Core Idea

Kubernetes reschedules compute. PhoenixFlight reschedules ownership of work.

Traditional Runtime

PhoenixFlight

DMA Primitives to PhoenixFlight Mapping

The Flight Lifecycle

Register

Discover

Assign

Handoff

Retire

Record

Why Dynamic Membership Matters

Distributed Systems

Cloud-Native Scheduling

Agentic AI Runtime

Flight Packets

PhoenixFlight Hub

Why PhoenixFlight Hub Is Not Docker Hub

Ecosystem Concepts

Flight Pack

Flight Packet

Dynamic Member

Flight Recorder

Shift from Container Images to Runtime Membership

Container World (Static Infrastructure)

PhoenixFlight World (Dynamic State & Governance)

Install, Pull, Register, Run

Designed for the Entire Tech Stack

For Developers

For Architects

For Researchers

Confirm Metrics Export

Metrics Export Completed

Above the Pod Layer

Where PhoenixFlight Helps

Agentic AI Handoff

Kubernetes Pressure Rebalancing

Governed Enterprise Workflow

Why Agentic AI Needs Dynamic Membership

Flight Recorder: Governed Lineage for Dynamic Work

PhoenixFlight Capabilities

Member Registration

Capability Directory

Workload Assignment

State/Context Handoff

Draining & Eviction

Audit Event Trails

The Developer Journey

Register a Member

Submit a Workload

Discover Eligible Members

Trigger Stateful Handoff

What PhoenixFlight Is Not

Not a Kubernetes Replacement

Not a Workflow Engine Replacement

Not an LLM Agent Framework

Not a Production Control Plane

Architecture Overview

Simulation Experiments

Phoenix-style virtual nodes

Kubernetes-style scheduling

Agentic AI routing

Integrated Simulation Showcase

Simulator Snapshot Layout

Build with PhoenixFlight

1. Clone Repository

2. Install Core Libraries

3. Boot Backend Server

Roadmap

FAQ

What is Dynamic Membership Architecture?