Mikyo King

Mikyo King is head of open source at Arize AI, where he helps develop AI observability and evaluation tools, including Phoenix and OpenInference. His work helps developers inspect how AI applications behave across model calls, retrieval, and tools—and test whether a change actually improves the system.

From closed-source engineering to building in public

King, also known as Mikel King, worked as a senior engineer at Apple before joining the founding team at Engine ML, where he built distributed training infrastructure for deep learning. He joined Arize’s engineering team in December 2020, drawn to its focus on machine-learning fairness and transparency. He graduated summa cum laude from the University of Southern California with a degree in computer engineering and computer science.

His move into company-backed open-source development came around 2023 and required rethinking how a software business should work. After a career building closed-source products, King initially questioned why a company with a commercial platform should invest in software people could use for free. He came to see open development as a practical business strategy: developers could try tools without a sales process, inspect architectural choices, and run the software inside their own infrastructure. A larger user community also shortened the team’s learning loop. Users could report problems, contribute code, and help shape what the team built next.

That approach shapes the projects he helps build. Arize Phoenix combines tracing, evaluation, versioned datasets, experiments, and prompt management in a self-hosted platform. Traces record the sequence of operations an application performed, giving developers a way to investigate failures beyond the final answer. OpenInference supplies conventions and instrumentation for capturing model calls and surrounding retrieval and tool activity. It works with any OpenTelemetry-compatible backend, so adopting its instrumentation does not require adopting Arize’s platform.

Engineering choices that preserve developer control

• Observe the whole agent. King argues that an application can fail even when its model produces correct responses: retrieval can supply poor context, a tool can malfunction, or code can fail inside a sandbox. His approach to agent observability follows those interactions across the workflow, including memory and code execution. A model response alone cannot explain what happened throughout the system.

• Make prompts reproducible without requiring a runtime dependency. In their account of Phoenix’s prompt-management design, King and Xander Song describe why their team changed its mind about managing prompts outside application code. Experiments needed a record of which prompt configuration produced each result. That meant tracking more than a template string: model selection, tools, response format, and invocation parameters also affect behavior. Phoenix tracks those inputs together while supporting provider-native formats and allowing prompts to be copied or synced back into a codebase. Developers can use the management tools without putting the observability service in their application’s critical path.

• Bring evals into familiar test workflows. King’s guide to evaluations in continuous integration starts with ordinary pytest, Vitest, and Jest cases. He separates hard requirements that should fail a build from variable quality signals that need repetition and trend analysis. In his support-bot example, refusing an out-of-scope question is a hard assertion; the helpfulness of an answer is scored rather than checked against one fixed string. Aggregate acceptance criteria can also gate a suite. Phoenix records runs as experiments and connects results to traces, so developers can investigate why a case failed instead of stopping at a score.

Giving agents the context to improve agents

In May 2026, King and Elizabeth Hutton outlined a direction for Phoenix in which traces, evaluation results, feedback, and experiments become context that coding agents can query through APIs, command-line tools, and other programmatic interfaces. Their proposed improvement loop is concrete: inspect a failure, make a change, rerun the workload, and compare the resulting behavior. Human oversight remains part of the design; teams should delegate more when failure modes are understood and retain tighter control when the stakes are high.

Phoenix Intelligence (PXI), introduced in beta in June 2026, puts that direction into a product. King co-authored its technical introduction with Roger Yang, Nancy Chauhan, and Anthony Powell. The built-in agent uses Phoenix telemetry, documentation, prompts, and datasets to help debug traces, create evaluators, and run experiments. It receives the context of the page a user is viewing, reducing the need to copy information into a separate coding-agent session.

The team built PXI around a browser-based shell, a query client, a writable scratch space, and access to documentation before adding specialized tools. Those primitives let it investigate questions beyond a fixed menu of features. Persistent changes are staged for approval by default, and PXI’s own model calls and tool use can be traced when recording is enabled. The same infrastructure developers use to investigate their applications can therefore help them inspect—and improve—the agent doing the investigating.