AI Agent Engineers: hire for shipped agents, not for prompts

An AI Agent Engineer builds software that takes real actions through tools it is explicitly allowed to use. The agent plans a task, calls those tools, holds state and recovers when something fails. The engineer decides what it may and may not do.

The work is changing because the surrounding tooling has matured. Tracing, evaluation and governed tool access are now product features, not things each team builds alone. That moves the value from wiring up a loop to deciding how far an agent can be trusted.

The title is still fragmented, and most agent work never left prototype. The hire you need is the one who has run an agent in production and can say what broke.

What agents already do

Agents now handle a good share of the routine engineering around agents themselves. They plan, use tools, check the result of each action and revise. One Thoughtworks write-up describes an agent working inside an IDE, with access to the file system, terminal and running services, producing a multi-service enterprise platform from natural language specifications.

In operations, agents read logs, test results and pipeline state through scoped access. Buildkite offers an MCP server for this and records every agent action for an audit trail. It reports that Wayfair cut its build-fix time from 30 minutes to under 5 using it.

Agents also do the instrumentation work. Arize describes automatic tracing of model calls, tool activity, handoffs and state changes, so a team can see where a run diverged. Job adverts for this work, such as the Valsoft posting, describe agents taking on support triage, onboarding tasks, reporting and integration with CRM and ERP systems.

Where agents help and a person decides

Much of the job is shared. A coding agent can draft a tool wrapper, a test harness or a first set of task evaluations. The engineer reads it, tightens the inputs and decides whether the permissions are narrow enough.

Testing is a good example. AgentGarage uses a model to predict where an agent might fail, then replays those paths in a sandbox. Its rule is that a predicted failure stays a hypothesis until the real agent reproduces it. The machine proposes. A verifier, and a person behind it, confirms.

Evaluation works the same way. Tools can score traces and sessions, but someone has to define what a completed, authorised task looks like and check it in the system where the action happened.

An agent can write its own tools. It cannot decide what it should be trusted to do.

What still needs a person

Permissions. Deciding what an agent may touch, and who signs that off, is a business and security call. Broad access by default is the mistake to watch for.

Where a human steps in. Insurance agent company Liberate describes a supervisor layer that escalates to a human when one is needed. Someone has to design that line, and move it as evidence comes in.

Recovery. Agents are non-deterministic, and Microsoft notes that behaviour drifts silently as models update and tools change. Timeouts, bad tool output and half-finished tasks need checkpoints, rollback or compensating steps. Relying on the model to notice is not a plan.

Accountability. Even in Google's governed architecture, re-architecting the agent hierarchy happens with human sign-off. Someone owns the outcome.

What this means for who you hire

Look for engineers who have shipped a bounded agent into real use and can show the permission model, the action logs and a task evaluation set the team can rerun. Application engineering, integration and security thinking all matter, and few candidates have all three.

The profile losing value is the framework enthusiast. Someone who can assemble a planning loop from a tutorial, or who talks only about prompts, is now competing with the tools. Demo builders lose ground to people who can say how often their agent needed a human and why.

Success is measurable: authorised task completion, and intervention and failure rate. Hire someone who already thinks in those terms.

How to spot a strong candidate

Describe an agent you shipped. What actions could it take, and who decided its permissions?

A good answer names specific tools, explicit limits and who approved them, and covers what changed after launch. A prototype-only story is a warning.

An agent completes a task but takes a wrong action halfway. How do you find out and recover?

Look for action logs, traces, checkpoints, rollback or compensating steps, and escalation to a person. Retrying the whole run is not recovery.

Where to find them

Search on shipped agents and framework contributions, not titles. The same work appears as agentic AI engineer, agent developer, AI automation engineer or plain software engineer.

Most come from application engineering, workflow automation or systems integration, then moved into LLM work. Look for people who have built tool or MCP integrations, run workflow engines or worked with agent SDKs in Python or TypeScript.

They sit in AI startups, SaaS companies and enterprise automation teams. Enterprise adverts, like the Cisco AI Operations Engineer role, show large employers building the same skills in-house, so expect competition.

Our own analysis, drawn from the role profile in our job families library and recent public reporting on how agents are used in this work. Titles and practice vary by company.