Co-authored by Xander Song and Mikyo King in March 2025. Explains their Phoenix team's prompt-management design: identifiable experiment snapshots; versioning templates, models, tools, response formats, and invocation parameters together; provider-native prompt delivery; and adoption without a mandatory runtime dependency.
A collaborative Phoenix engineering contribution described by Song and King, rather than a solely authored product. The system connects versioned model-invocation configurations to datasets, experiments, and the playground while allowing developers to copy or sync prompts into application code.
Song's verified axiomofjoy account opened this roadmap on February 19, 2026, added it to the roadmap, assigned participants, and later added related issues. Its scope includes contextual tools, conversation persistence, tracing, evaluations, recording consent, mutation controls, and confirmation before prompt changes. This establishes roadmap authorship and coordination, not individual implementation of every feature. Another collaborator closed the roadmap as completed on July 1, 2026.
An Arize-owned, team-developed AI observability and evaluation platform. Song's co-authored article establishes his Phoenix engineering participation and collaborative prompt-management work; his separately retained roadmap establishes agents initiative activity. The repository describes tracing, evaluations, datasets, experiments, prompt management, and PXI, an embedded assistant for debugging traces and iterating on prompts. Neither employment nor roadmap participation establishes sole authorship of Phoenix or PXI.
Song's February 19, 2019 mathematical explanation and implemented genomic-data visualization project, explicitly identified as his work in the Arize interview. Applies dual and kernel PCA to 2,504 samples with roughly 81 million variant sites, using a C parser, Boolean sparse matrices, pairwise distances, and sample-by-sample Gram matrices. Includes interactive Dash/Plotly visualizations and challenges an initially tempting geographical interpretation. Song analyzed the existing 1000 Genomes dataset; he did not claim authorship of the underlying international sequencing project.
Listed on Song's verified personal portfolio with a January 2, 2019 date and a description of ranking March Madness teams using Google's PageRank algorithm. The retained homepage supports this attribution and subject, but not further implementation details or results.
Listed on Song's personal portfolio with a December 19, 2018 date and a description of an algorithm for diffusion-generated mean curvature flow. Only the portfolio listing, not the full article, is retained.
A repository listed under Song's verified GitHub account, described as implementations of vanilla RNNs, LSTMs, and GRUs in PyTorch. The retained profile supports account ownership and this description, but does not establish detailed contribution history.
Xander Song is Arize AI’s technical lead for agents on its open-source team. He works on Arize Phoenix, a platform for inspecting AI application behavior, evaluating results, and testing changes. His contributions span prompt management and in-product agents, following earlier roles in machine-learning engineering and developer advocacy.
From mathematics to production machine learning
Song studied philosophy and mathematics, contributed to a research group that published a result in matrix theory, and wrote his senior thesis on spectral graph theory’s application to semi-supervised learning. His first job after college was teaching English in South Korea. Machine learning offered a way to pursue mathematics through practical problems; manually scheduling model experiments on shared hardware and tracking results in a spreadsheet also drew his attention to the tools surrounding the model. He describes these experiences in his 2022 career interview.
His independent writing connects mathematical explanation with working software. In a 2019 genomic-data project, he applied dual and kernel principal component analysis (PCA) to data from the 1000 Genomes Project. With 2,504 samples and roughly 81 million variant sites, the challenge was to find a manageable computation: he represented variants as sparse matrices and used pairwise distances to compute a much smaller sample-by-sample matrix. He then built interactive Dash and Plotly visualizations. The post follows the mathematics through implementation and interpretation, including why an initially tempting geographical reading of the resulting plot did not hold up.
Before Arize, Song worked as a machine-learning engineer at test.ai. His earlier engineering work included no-code functional UI test automation, where he encountered the difficulty of persuading developers to abandon familiar workflows. He also diagnosed a production-model failure that threatened a crucial customer relationship. These experiences informed his emphasis on ML observability: detecting unexpected behavior matters, but engineers also need to identify its cause before they can repair it. He joined Arize as a developer advocate in 2022, with responsibilities spanning workshops, technical education, and bringing practitioner feedback into the product.
Prompt management without a mandatory runtime dependency
On the Phoenix engineering team, Song helped develop prompt management for Phoenix 8.0. In a March 2025 article co-authored with Mikyo King, he explains why the team changed its mind about building it. Keeping prompts alongside application code initially seemed sufficient, and making an application depend on an observability service at runtime seemed undesirable. But Phoenix’s datasets, experiments, and playground needed identifiable snapshots of the prompts used in each test.
Their design addressed two connected problems:
Track the whole model invocation. A template string alone does not describe an experiment. Model choice, tool definitions, response format, and invocation parameters interact with the instructions. Treating them as one versioned configuration lets engineers vary one input while holding others constant and track which configuration produced an experimental result.
Keep deployment choices with developers. Phoenix delivers prompts in provider-native formats rather than requiring application-specific wrappers or proxies. Teams can copy or sync prompts into their codebase, adopting versioning and experimentation without necessarily putting Phoenix in the application’s runtime path.
In February 2026, Song opened Phoenix’s in-app agents roadmap through his axiomofjoy GitHub account, and subsequently helped track the initiative. Its scope included contextual tools, persistent conversations, tracing, and evaluations. It also covered explicit consent for server-side recording, controls over data-changing actions, and confirmation before applying prompt changes—important distinctions for an assistant that can act on a developer’s work.
Phoenix now includes PXI, or Phoenix Intelligence, an embedded AI engineering agent for debugging traces, iterating on prompts, and navigating the product. Song’s work on the initiative extends his earlier focus on helping developers investigate model behavior into an assistant operating within the same environment where they inspect and test their applications.
Xander Song explains how isolated environments, outcome-based verifiers and reference solutions make agent changes testable, then follows a Phoenix prompt change that reduced tool calls while preserving passing results.
A Harbor task combines instructions, a seeded environment and verifier scripts. Independent trials start fresh; a job collects their outcomes and optional trajectories.
Outcome-based verifiers tolerate implementation changes. Trajectory-aware checks are useful for tool selection and skill triggering, but create additional maintenance coupling.
The SQL prompt experiment increased aggregate SQL use and reduced tool calls and turns while preserving passing rewards. Task-level comparisons and traces explained where behavior changed; larger-data benefits were not measured.
Choose the evaluation unit explicitly. Phoenix tests agent-plus-product integrations against seeded data, not the customer application or its production ingestion path; realistic fixtures determine which failures those tests can expose.
▶ Watch ↗