PhoenixFlight

Dynamic Membership Runtime for adaptive workloads.

Cloud-native • Agentic AI • Hybrid Quantum-Classical

PhoenixFlight began with the v0.1.0 MVP local runtime. The current development track has completed governance, registry publishing, agent runtime integration, quantum provider adapters, Kubernetes operator path contracts, v1.0 stabilization, and Release Candidate validation. The next public release target is v1.0.0-rc1.

⬇ Download v0.1.0 MVP (First public pre-release) View Current Main Branch RC Track Complete

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

Release Candidate Track

PhoenixFlight has completed Release Candidate validation for the current main branch. Validation included Python 3.11 editable installation, CLI validation on sample PhoenixFiles, .pflight bundle generation, runtime telemetry route checks, and a full green test suite of 326 passed tests with 4 skipped. The next public GitHub release target is v1.0.0-rc1.
* Note: v1.0.0-rc1 release page coming next.

RC validation complete

Governance & Security

Policy Evaluation & Queue

✅ Complete

Remote Publish & Registry

Pluggable Transport Contract

✅ Complete

Agentic AI Runtime

Framework Event Ingestion

✅ Complete

Quantum Provider

Adapter Interface & Mocks

✅ Complete

Kubernetes / Operator

Telemetry Event Contract

✅ Complete

v1.0 Release Candidate

v1.0.0-rc1 GitHub Release

🔜 Next Target

v0.1.0-mvp · Historical Pre-release

Try the First Public MVP

The v0.1.0 MVP remains the first public downloadable release. The main branch has advanced through v1.0 stabilization and Release Candidate validation. The next public release target is v1.0.0-rc1.

⬇ Download v0.1.0 MVP View Main Branch

shell · phoenixflight-v0.1.0-demo

# Clone and install
git clone https://github.com/KinshukON/DynamicMembershipArchitecture.git
cd DynamicMembershipArchitecture
python3 -m venv .venv && source .venv/bin/activate
pip3 install -r requirements.txt

# Initialize and validate
python3 -m src.phoenix_cli init
python3 -m src.phoenix_cli validate -f examples/customer-validation/PhoenixFile

# Register members
python3 -m src.phoenix_cli member register examples/customer-validation/agents/governance-agent.yaml
python3 -m src.phoenix_cli member register examples/customer-validation/agents/metadata-agent.yaml

# Create, assign, hand off, retire
python3 -m src.phoenix_cli packet create customer-validation
python3 -m src.phoenix_cli assign packet-001 --to governance-agent
python3 -m src.phoenix_cli handoff packet-001 --from governance-agent --to metadata-agent
python3 -m src.phoenix_cli retire governance-agent

# Audit & bundle
python3 -m src.phoenix_cli audit
python3 -m src.phoenix_cli build -f examples/customer-validation/PhoenixFile
python3 -m src.phoenix_cli bundle verify dist/customer-validation-app-0.1.0.pflight

What you will see

✓ Dynamic member registration with trust scores

✓ Trust-weighted capability assignment

✓ Policy-governed context handoff

✓ Graceful member retirement

✓ Structured JSONL audit trail

✓ Verified .pflight portable bundle

95 PASSING TESTS

All commands verified against the customer-validation example. Zero regressions.

→ CLI Reference → Getting Started → Bundle Format

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 Enterprise Problem PhoenixFlight Solves

Modern AI and distributed automation are becoming dynamic, but enterprise governance is still static.

Agents fail. Tools disappear. Models change. Services scale. Providers become unavailable. Work moves from one participant to another, but identity, context, policy, trust, ownership, and audit lineage often fragment along the way.

PhoenixFlight solves this problem through governed handoff for dynamic work execution. It treats work as a portable FlightPacket and participants as dynamic members, so workloads can move across agents, services, tools, humans, models, APIs, and hybrid quantum-classical backends while preserving policy, context, lineage, and audit continuity.

PhoenixFlight is a Dynamic Membership Control Plane for agentic and distributed workloads.

Governed Handoff for Dynamic Work Execution

PhoenixFlight defines a runtime contract for work that moves across changing participants. Instead of treating assignment, handoff, retirement, and audit as separate afterthoughts, PhoenixFlight makes them part of a single governed lifecycle.

👤

Register dynamic members with identity, namespace, capabilities, trust, reliability, load, and compliance metadata.

📦

Package work as FlightPackets carrying required capabilities, policy tags, context checkpoints, ownership history, and audit lineage.

🎯

Assign work using policy-governed, trust-weighted capability routing.

🤝

Handoff work between eligible participants while preserving context and lineage.

🛑

Retire members through drain-and-reassignment semantics.

📜

Record registration, assignment, handoff, denial, retirement, and completion events as structured audit history.

Frequently Asked Questions

What is PhoenixFlight?

PhoenixFlight is a Dynamic Membership Control Plane for agentic and distributed workloads.

What problem does PhoenixFlight solve?

PhoenixFlight solves the loss of governance continuity when work moves across dynamic participants. It preserves identity, context, policy, trust, ownership, and audit lineage as work is assigned, handed off, reassigned, or retired.

Is PhoenixFlight an agent framework?

PhoenixFlight is not primarily an agent framework. It is a governance-aware runtime and control plane that can govern agentic work execution. It complements agent frameworks by adding membership, policy, handoff, retirement, and audit semantics.

Is PhoenixFlight a replacement for Docker or Kubernetes?

No. Docker packages processes and Kubernetes schedules compute. PhoenixFlight governs the ownership and lifecycle of work above the infrastructure layer. It complements Docker and Kubernetes by adding governed membership semantics for dynamic workloads.

What is a FlightPacket?

A FlightPacket is a portable unit of work that carries workload identity, required capabilities, context or checkpoint state, policy tags, ownership history, and audit lineage.

What is a dynamic member?

A dynamic member is a participant in the PhoenixFlight runtime, such as an agent, service, tool, human reviewer, model, API, simulator, optimizer, or quantum provider adapter. Members can join, leave, fail, recover, migrate, or retire.

What does governed handoff mean?

Governed handoff means work can move from one participant to another only when capability, trust, namespace, compliance, policy, and load conditions are satisfied. The handoff preserves context, ownership history, and audit lineage.

How does PhoenixFlight support hybrid quantum-classical workloads?

PhoenixFlight does not execute quantum circuits directly or replace quantum providers. It can orchestrate the classical control plane around quantum workloads by modeling QPUs, simulators, provider adapters, optimization agents, and result auditors as dynamic members and routing FlightPackets according to policy, capability, queue state, budget, region, and audit requirements.

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.

Hybrid Quantum-Classical Orchestration

Quantum applications depend on changing execution participants: classical workers, simulators, provider adapters, queued QPUs, optimization agents, and policy gates. PhoenixFlight models them as dynamic members and routes Flight Packets through governed discovery, assignment, fallback, and audit.

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

ℹ️ Note: The current Hub is a local/developer preview catalog. Future cloud-hosted Hub services will support published packages, semantic versioning, authentication tokens, and secure remote pulls.

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
  }'

CLI Quickstart

Run the complete dynamic membership lifecycle locally in under two minutes. Complements Docker and Kubernetes — adds governance-aware membership, handoff semantics, and audit.

shell — PhoenixFlight local runtime demo

# Install
git clone https://github.com/KinshukON/DynamicMembershipArchitecture.git
cd DynamicMembershipArchitecture && pip3 install -r requirements.txt

# Initialize local runtime state
python3 -m src.phoenix_cli init

# Validate your PhoenixFile (the governed application descriptor)
python3 -m src.phoenix_cli validate -f examples/customer-validation/PhoenixFile

# Register dynamic members (agents)
python3 -m src.phoenix_cli member register examples/customer-validation/agents/governance-agent.yaml
python3 -m src.phoenix_cli member register examples/customer-validation/agents/metadata-agent.yaml
python3 -m src.phoenix_cli member list

# Create a FlightPacket and assign it
python3 -m src.phoenix_cli packet create customer-validation
python3 -m src.phoenix_cli assign packet-001 --to governance-agent

# Governed context handoff between members
python3 -m src.phoenix_cli handoff packet-001 --from governance-agent --to metadata-agent

# Retire a member gracefully
python3 -m src.phoenix_cli retire governance-agent

# View the structured audit log
python3 -m src.phoenix_cli audit

# Build a portable .pflight bundle and verify integrity
python3 -m src.phoenix_cli build -f examples/customer-validation/PhoenixFile
python3 -m src.phoenix_cli bundle verify dist/customer-validation-app-0.1.0.pflight

# Emit a Dockerfile from your PhoenixFile
python3 -m src.phoenix_cli emit dockerfile -f examples/customer-validation/PhoenixFile

DOCS Getting Started Full local demo walkthrough DOCS CLI Reference All commands and flags SPEC PhoenixFile Spec Application descriptor schema STATUS Enterprise Readiness Capability matrix and roadmap

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

Make It Real: Run PhoenixFlight Locally

Execute the full Dynamic Membership Architecture pipeline locally. Register agents, inspect flight packets, evaluate governance validation policies, and trace handoffs entirely via the local command line.

Local Terminal Quickstart

$ git clone https://github.com/KinshukON/DynamicMembershipArchitecture.git
$ cd DynamicMembershipArchitecture
$ python3 -m src.phoenix_cli init
$ python3 -m src.phoenix_cli validate -f examples/customer-validation/PhoenixFile
$ python3 -m src.phoenix_cli runtime start
$ python3 -m src.phoenix_cli member register examples/customer-validation/agents/governance-agent.yaml
$ python3 -m src.phoenix_cli member register examples/customer-validation/agents/metadata-agent.yaml
$ python3 -m src.phoenix_cli packet create customer-validation
$ python3 -m src.phoenix_cli assign packet-001 --to governance-agent
$ python3 -m src.phoenix_cli handoff packet-001 --from governance-agent --to metadata-agent
$ python3 -m src.phoenix_cli audit

Run the CLI View PhoenixFile Explore Example App Read Technical Blueprint Open GitHub

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

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

PhoenixFlight

Dynamic Membership Runtime for adaptive workloads.

Cloud-native • Agentic AI • Hybrid Quantum-Classical

Release Candidate Track

Try the First Public MVP

Architecture Taxonomy

Dynamic Membership Architecture

PhoenixFlight

Flight Packets

The Pain Point

The Enterprise Problem PhoenixFlight Solves

Governed Handoff for Dynamic Work Execution

Frequently Asked Questions

What is PhoenixFlight?

What problem does PhoenixFlight solve?

Is PhoenixFlight an agent framework?

Is PhoenixFlight a replacement for Docker or Kubernetes?

What is a FlightPacket?

What is a dynamic member?

What does governed handoff mean?

How does PhoenixFlight support hybrid quantum-classical workloads?

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

Hybrid Quantum-Classical Orchestration

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

CLI Quickstart

What PhoenixFlight Is Not

Not a Kubernetes Replacement

Not a Workflow Engine Replacement

Not an LLM Agent Framework