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"

}

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.

Agent Failure and Handoff

An agent receives a Flight Packet, fails mid-task, and PhoenixFlight transfers the packet to another eligible member with full audit history.

Policy-Aware Assignment

Two members may be technically capable, but only one satisfies the required trust score, data policy, and runtime constraints.

Dynamic Capability Churn

New members join, old members retire, capabilities change, and packets continue moving without being hard-bound to one participant.

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 lifecycle 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, micro-services, nodes, 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.

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

Formulae:
- 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.

Timestamp	Event Type	Actor	Decision	Audit Reason
No audit entries. Start runtime activities to generate records.

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".