A lot of the AI work I want to be around sits just off the center of classical research. I care about model progress, but I am especially interested in the layer where that progress has to become legible, testable, and operational. That usually points me toward evals, benchmark design, agent reliability, orchestration, and the tooling around all of that.

The basic question I keep coming back to is not just whether a model can do something once. It is whether a team can understand what the system is good at, where it breaks, how to compare versions, what kind of operator oversight it needs, and whether the workflow around it improves with use instead of becoming more fragile.

That is why evals matter to me. Good evals are one of the few ways to turn vague intuition into something inspectable. They help answer questions like: what got better, what regressed, what failure mode is newly appearing, and what kind of behavior actually matters for the user or operator.

I also care about benchmark design, but in a very practical sense. A benchmark is only useful if it reflects the behavior that matters for the system you are trying to build. That means I am interested in the messy part: choosing scenarios, defining success, deciding what should stay deterministic, and figuring out which proxy metrics are informative versus performative.

Agent systems make this even more interesting. Once multiple tools, prompts, memory decisions, routing rules, and review steps are involved, the real object being evaluated is no longer just the base model. It is the full workflow. That raises product questions and systems questions at the same time. Where should the agent have freedom? Where should the flow be constrained? What proof should be required before a result is trusted? What should the human see?

That is probably the cleanest way to describe my research interest: I like the layer where intelligence becomes a system that has to earn trust. In practice that means I am drawn to work around:

Eval design for real workflows
Benchmarks that reflect operator or user value
Agent reliability and failure analysis
Tooling for review, inspection, and comparison
Orchestration choices between deterministic logic and model judgment

I also like building around those questions, not just talking about them. Sometimes that means a research or recruiting workflow. Other times it means an internal tool, a small evaluation harness, a public artifact, or a fast front-end prototype that makes a system easier to inspect. If a better answer requires Python, TypeScript, an ops dashboard, or a more visual interface, I like being close enough to the implementation to test the idea directly.

That is part of why Claude Code and Codex matter to me. They reduce the cost of building the surrounding system. You can sketch a tool, add a spec, set up a test path, create a scoring flow, or mock an operator interface much faster than before. That changes how quickly a product-minded builder can learn from a question.

I think AI labs and AI-native teams will need more people working in this zone. Not everyone has to be doing core model research. Some of the most important leverage is in turning capability into something measurable, steerable, and trustworthy enough for real use.

So when I say I am interested in AI research, the most precise version is this: I am especially interested in evals, benchmarks, agent systems, workflow reliability, and the product infrastructure that helps intelligence become durable.