What AI Engineers Do Now: Build the Loop Around Agents

RESUMEN

En 30 segundos

Aparna Dhinakaran of Arize describes a widening gap between people who use AI occasionally and a small frontier group running thousands of agents. As software work moves from writing code to orchestrating agent factories, she says the AI engineer's job is changing too: instead of building one feature, engineers need to build the loop that builds, evaluates, ships, monitors, and improves features. She uses Arize's Signal as an example of an always-on agent that reads traces, remembers recurring problems, and can propose fixes. Making that work requires deliberate triggers, isolated runs, durable memory, and evaluations that are checked against human judgment. Her conclusion is that engineers should trace both the agents they build and the coding agents that build them, so production telemetry can guide continuous improvement.

1A narrow frontier is pulling awayAparna uses Andrej Karpathy's funnel to describe the gap: billions have tried an LLM, while only a small frontier group is running swarms of agents. She frames the challenge as helping more engineers move toward that kind of work.
2Build the loop, not just the featureThe work shifts from writing a feature and reading its diff to building agents that review code, evaluating nondeterministic tasks, and having agents inspect telemetry for patterns. The engineer designs the system that repeats those steps.
3Signal turns traces into a recurring jobArize's Signal reads traces for recurring problems and can open a pull request when it has repository access. It also remembers issues across runs, including cases that become more concerning as additional evidence arrives.
4Isolate each run and keep only what mattersA run gathers traces, external telemetry, repository access, and needed credentials inside a sandbox behind a proxy. Findings and traces can persist, while the sandbox, credentials, and temporary repository access are removed when the run ends.
5Test the evaluator against peopleSignal's pull requests receive their own evaluations. Dhinakaran recommends building gold datasets, comparing evaluator results with human output, and aligning the judge before shipping it; the same evaluations can then run offline and online.
6Trace the agents that build your agentsProduction traces should cover both user-facing agents and coding agents such as Claude Code, Cursor, or Codex. Together with online evaluations, those traces become feedback that helps find gaps and improve the system.

Conclusiones

An AI engineer increasingly builds the system around a feature: the loop that builds, evaluates, ships, monitors, and improves it.
Agent-readable telemetry can turn traces into both evidence and triggers for always-on agents.
A safe agent run needs scoped context and access inside an isolated sandbox, with credentials and workspace removed afterward.
Keep durable findings and traces between runs, while making the execution environment replaceable and recoverable.
Evaluate agent work against human judgments and validate the evaluators themselves before relying on their scores.
Trace coding agents as well as product agents so teams can see how their agent factory behaves in production.

TemasIngeniería de agentes Evaluaciones Observabilidad y fiabilidad Agentes de programación Infraestructura y despliegue

TEXTO COMPLETO

Lee el texto editado por capítulos

Ver transcripción

What does an AI engineer do now?

Aparna opens with the changing definition of an AI engineer and a widening gap between ordinary AI use and frontier teams operating large numbers of agents. She asks how more people can move toward that frontier.

Welcome to AI Engineer. Given that we're in New York, I want to revisit the question of what an AI engineer does. We seem to have a new answer every year, and the definition keeps changing.

As I was preparing this talk, Andrej Karpathy tweeted about a widening gap between people at the frontier, who are running thousands of always-on agents, and everyone else. His funnel starts with more than six billion people who have touched or interacted with an LLM. About one to two billion are casual free-tier users, around 20 million professionals use AI to compress weeks of work into days, and perhaps 5,000 people with frontier access run swarms of thousands of agents.

When people see that funnel, the first question is: where am I in it? It also sketches a path for how more of us might become part of the group running thousands of agents over the next few years.

From code to agent factories

As the abstraction layer rises from programming languages to local and cloud agents, the expected work expands. Engineers are moving from building features to coordinating systems of agents.

This is part of a shift that's been happening for decades: the abstraction layer keeps rising, and it has accelerated over the last few years. We moved from higher-level programming languages to copying and pasting code, then to local agents and cloud agents. Now the expectation is that we will run teams or factories of agents inside our organizations.

That changes what the AI engineer does. The job is no longer just to write an AI feature; it's to build the loop that writes and improves it. Instead of reading every diff and doing every review, engineers set up agents to review code and evaluations to judge nondeterministic tasks. Instead of only monitoring software metrics, they arrange for agents to read observability data and find patterns.

Build the loop around the feature

The role now includes setting up agents for code review, evaluations for nondeterministic work, and systems that read observability data. At Arize, Signal is an example of an agent built to carry out this loop.

The loop we've been discussing is build, evaluate, ship, monitor, and improve. An AI engineer is now responsible for building the loop that performs those steps. At Arize, we built Signal to run this loop: it reads traces and telemetry, identifies patterns, and, when it can access a repository, can propose a fix or open a pull request.

Signal reads traces and remembers issues

Signal begins by reading a configurable volume of traces on a cadence and finding possible issues. Its memory lets it revisit previous findings as more telemetry changes their importance.

Signal is an always-on agent. In its simplest form, it reads a configured volume of traces on a regular cadence and looks for issues. It also needs memory: did it see this problem before? Was something once considered minor, but does the growing body of data now make it look critical? Signal starts with traces and uses what it has seen to judge problems over time.

Design telemetry for agents

Agents are becoming the primary consumers of observability data, which can also trigger them. Runs may begin on a schedule, from an event such as a user complaint, or from a metric.

One of our early realizations was that the consumers of telemetry are changing. Observability data is no longer just for people to inspect, or for people to inspect while agents handle the follow-up. We need to shape telemetry so agents themselves can consume it. Then the data can also become the trigger that starts an always-on agent.

If you're building a factory of always-on agents, first decide what wakes them up. Signal can run on a schedule, such as every three or six hours, to read a recent window of traces and look for problems. It can also start from an event, like a user complaint in Slack, or from a metric. Those are different triggers for beginning a run.

What happens inside an agent run

Each run collects trace context and other required data in a sandbox, with a proxy controlling information entering and leaving. Results and execution traces are recorded so the team can inspect what the agent did.

Once an agent starts, we have to define what a run contains. We bring in the trace context and any relevant third-party information, including application performance logs and metrics. We also provide repository access and the keys the run needs. All of this goes into a sandbox created for that run.

The sandbox has a proxy as its only route for information coming in or going out. Everything that happens inside is traced. Outputs, including any issues the agent identifies, are saved to memory. The agent starts with its trigger and context, does its work in isolation, and leaves behind records we can examine.

When the run ends, some things are deliberately kept. If the agent found issues, those findings are saved so the next run does not start from zero. We also keep traces of what the agent called and whether it opened a pull request. Skills it learned during a run can be saved to the repository when useful.

Other things should go away: the sandbox is torn down, short-lived credentials are revoked, and repository access is removed. That distinction lets the agent retain useful findings and evidence without leaving its temporary environment or permissions behind.

Make agents durable and model-agnostic

Findings, traces, and useful skills can persist after a run, while temporary workspaces and credentials are torn down. External state lets a failed run resume, and model or harness choices can change without rebuilding the whole system.

We also designed Signal to be durable. If a sandbox or its harness fails partway through a run, the agent should not have to start from scratch. The run's state is saved outside the sandbox, so we can launch a new sandbox and harness and resume from the step that failed.

Signal is designed to work with different models and harnesses. It started with Claude Code and now also supports Cursor and Codex, with the aim of supporting other major and open-source harnesses. We want to change models too: evaluating them helps us compare agent quality and cost, so we can see whether a less expensive option still detects issues with enough rigor.

Write evaluations and test the judges

Evals test Signal's proposed changes, but need to reflect human judgment. Dhinakaran describes building gold datasets and validating evaluators against people before relying on them in offline or online testing.

That brings us back to what AI engineers need to do: learn to write evaluations. Whenever Signal finds an issue and opens a pull request, evaluations run on the agent's proposed change. An eval might start as a dataset and a prompt that checks outputs for regressions. But it needs to line up with human judgment.

As engineers build the system that runs the loop, a lot of their time should go to looking at traces with agents and identifying common errors. This is where deciding what good means becomes especially important. Evaluations help make those standards explicit and give the system a way to assess work that is not deterministic.

Teams often ask how they can trust an evaluator. At Arize, we spend time evaluating the evaluators: we build golden datasets, run evaluations, compare their results with human judgments, and tune them until the judge agrees sufficiently with people before we ship a new evaluator. These evaluations can then be used both offline and online.

More and more, this is what the AI engineering job involves. After building an always-on agent, run evaluations before shipping it. Once it is in production, trace everything—not just the agents users interact with, but also coding agents such as Claude Code, Cursor, and Codex that helped build them. That lets you see what happened inside the factory of agents.

Trace agents in production

A production loop traces both deployed agents and coding agents, then evaluates their traces online. That evidence goes back to agents that surface problems and reveal where systems need improvement.

Those traces can be evaluated online as well as offline. New production traces and evaluation results become data that agents can read to surface problems. The system then connects data collection, evaluation, and agents that locate gaps, so the product can improve.

Close the gap between labs and businesses

Business data is messier than the constrained problems in a lab, and AI engineers can help bridge that gap. Dhinakaran closes by returning to a system that traces, evaluates, and improves products rather than stopping at individual features.

There is still a large gap between what happens in AI labs and what many businesses can do. Business data is often messier than the constrained, testable problems in a lab. AI engineers can help close that gap by tracing the agents they build, evaluating them, and creating systems that learn from collected telemetry. The work is no longer only about building individual features; it is about building systems that improve the products.

That's the answer I would give to what an AI engineer does now: build systems that help agents improve the product over time. Thank you for listening.