How to Become an Agent Engineer

The fastest route into agent engineering is to build one small agent that fails safely, then show a reviewer exactly how it fails. Employers hiring for the work ask for tool design, evaluation and reliability far more often than for a framework name. This guide lays out what to learn from three common starting points, the course lessons to work through in order, and the three artifacts worth putting in a portfolio.

It is a research guide. It does not promise a timeline or an offer, and the postings cited were read on September 26, 2026.

What the job asks for

Start from the postings, not from a list of frameworks. Sierra's Software Engineer, Agent and Decagon's Senior Software Engineer, Agent Product both describe engineers who ship agents into customer workflows. Scale AI's Frontier Agents Engineer (Applied AI) and Elastic's Agentic AI Engineer sit closer to the platform. The comparison with AI and ML engineering quotes what each of them owns.

Across those postings, four abilities come up again and again:

• Tool boundaries. Defining what a model can call, with what arguments, and what the application checks before anything changes.
• State and recovery. Knowing what survives a crash, a retry or a stale approval.
• Evaluation. Measuring whether the task succeeded, keeping failures in the count, and telling a model problem from a system problem.
• Ordinary backend skill. APIs, databases, tests and production operations. An agent's bad choice usually becomes a normal software bug at the point where it writes something.

Security teams have a name for what goes wrong when the first two are missing. OWASP's 2025 list for LLM applications calls it Excessive Agency, and traces it to excessive functionality, excessive permissions and excessive autonomy. A good agent portfolio shows the opposite of all three.

Know when not to build an agent

Anthropic's Building effective agents, published December 19, 2024, separates workflows, where code fixes the path, from agents, where the model directs its own steps and tool use. Its advice is to find "the simplest solution possible" and add complexity only when it improves outcomes.

Hiring managers test for this judgment. A candidate who reaches for a multi-agent framework to route a ticket with three fixed steps is showing the wrong instinct. Build the fixed workflow first, then point to the one decision that needs a model.

Where you are starting from

Most people arrive from one of three directions. Each has a different gap.

The software engineer's risk is treating the model like a deterministic function. The data practitioner's risk is a notebook that never meets a real failure. The automation builder's risk is a workflow nobody else can test or review. Pick the lessons that close your gap and skim the rest.

Work through the course in order

The site's agent course is 17 reproducible labs, grouped in four stages on the agents and AI engineering pillar page. Every lab runs locally, and each one names what is simulated. Take them in this order. The capstone depends on most of the earlier lessons.

Stage 1: Define the boundaries

1. AI APIs for beginners: send a request, validate the response and test authentication, rate-limit and bad-output failures.
2. Build a webhook receiver that verifies and recovers: verify a signed delivery and survive a duplicate.
3. Three prompt contracts with evaluation fixtures: write prompts with explicit outputs you can check.
4. Run a bounded tool-calling loop: separate what the model proposes from what the application authorizes.
5. Build an MCP server and client: discover and test a tool over the Model Context Protocol.

Stage 2: Add context and control

6. Build a small RAG pipeline: filter retrieval by access and measure what it misses.
7. Persistent agent memory: scope, update and expire remembered facts.
8. Plan and execute: bound a plan and stop when a dependency fails.
9. Human approval for agents: bind an approval to the exact proposed change.

Stage 3: Evaluate failure and recovery

10. Evaluate a ticket agent: run a dataset and keep failures in the denominator.
11. Agent evaluation tools: reproduce a local evaluation and compare tools on one task.
12. Agent design patterns: run four control flows and inspect how each fails.
13. Choose an agent starter: audit the assumptions a template makes for you.

Stage 4: Implement and review

14. GitHub Copilot on a stale-delete bug: review an AI-written patch against behavior.
15. Cursor for a ticket approval interface: make one change with a testable contract.
16. n8n ticket-triage workflow: test the failure branches of a visual workflow.
17. The capstone: connect signed delivery, retrieval and approval, then verify restart and replay.

If time is short, lessons 4, 9, 10 and 17 carry the most weight for this role. They cover the tool boundary, the approval record, the evaluation report and the full system.

Build three portfolio artifacts

A reviewer has minutes, not hours. Three small artifacts with clear evidence beat one large demo with none. Each one below answers a line that shows up in agent postings.

1. A tool boundary with a rejected call

Build a single narrow tool, such as changing a ticket label, and a loop that lets a model propose calls to it. The application checks identity, ownership and argument shape before executing anything.

What to show:

• The tool's schema, its result shape and its error shape.
• One allowed call and one call the application rejects, for example a correctly formatted ticket ID the user does not own.
• A turn limit, and what the loop returns when it hits it.

This answers the permission half of Excessive Agency directly. Lessons 4 and 5 are the starting code.

2. A recoverable approval with a stale rejection

Extend the tool so that a proposal waits for a person. Store the proposal, the decision and the action receipt as separate records. Then break it on purpose.

What to show:

• Restart the process between proposal and approval, and show the proposal still there.
• Change the underlying record after approval, and show the executor rejecting the stale decision.
• Send the same approved request twice, and show one action and one receipt.

Most demos skip this, and it is the part a reviewer remembers. Lesson 9 and the capstone cover the mechanics. The agent engineer career guide describes a similar exercise with a five-minute demonstration script.

3. An evaluation report someone can challenge

Run a fixed set of cases through the agent and write down what happened, including the failures.

What to show:

• The dataset, with how it was built and which cases you tuned against.
• Scores with explicit denominators: correct outcomes, wrong outcomes, timeouts and refusals counted separately.
• A table of failed cases with the expected result, the observed result, the likely cause and the next experiment.
• A clear line between deterministic tests of the executor and any live-model run.

Lessons 10 and 11 give the structure. A small authored dataset shows your method. It does not prove quality for real users, and the report should say so.

Package the work

Put all three in one repository with setup commands, fixtures, a state diagram and a short design note. The note answers four questions: what the model may decide, what the application enforces, what survives interruption, and what the evaluation does not cover. A fresh checkout should reproduce your results without a paid API key. Label every simulated part.

Apply with the right evidence

Read each posting for where the job sits before sending anything. A posting that owns agent runtime or platform wants artifact 2 and scale evidence. A posting that ships agents to customers wants artifact 1, artifact 3 and some sign that you can work with a customer's messy process. The comparison with adjacent roles has a table for reading a posting this way.

Lead your application with the artifact that matches, not the full repository. One link, one sentence on what it proves, and the failure it handles.

Titles vary. Search for "Software Engineer, Agents", "Agent Platform", "Agentic Applications" and "Applied AI Engineer" as well as "Agent Engineer". On the Ashby and Greenhouse boards checked for this guide, the literal title was rare. Scale AI's Frontier Agents Engineer and Elastic's Agentic AI Engineer were the closest matches, and most employers used "Software Engineer" with an agents team name.

Common mistakes

• Framework first. A LangGraph or CrewAI project with no failure cases shows that you can follow a tutorial. Inspect a starter only after your own baseline works, as lesson 13 suggests.
• Authority in the prompt. "Only use this user's data" in a system prompt is not access control. Put the check in code.
• A score without a denominator. "92 percent accurate" with no count of timeouts and refusals invites the first interview question you cannot answer.
• Claiming scale you did not test. A local SQLite demo shows correctness under interruption. It does not show throughput, and saying otherwise costs credibility.

Next steps

• Follow the Agent Engineer career path: reading order, posted pay and practice prompts.
• Read the agent engineer career guide for the layers of the work.
• Prepare with the agent engineer interview guide once your first artifact is done.
• If you are changing careers from outside software, the career transition guide helps map existing experience first.