How to Become an Agent Engineer

A support agent built on an AI model gets a refund request. It looks up the order, decides the refund is fair, and calls the refund tool. Then the server restarts before the agent records that it finished. When it comes back, it sees an open request and refunds the order again.

An agent engineer builds the software around the model so that doesn't happen. An agent is a program where the model picks its own next step and can take real actions, like changing a record or sending a message. The engineer decides what it's allowed to do, what gets checked before anything changes, and what happens when it crashes halfway.

The fastest way into the job is to build one small agent that fails safely, then show a reviewer exactly how it fails. Employers ask for tool design, testing and reliability far more often than for a framework name.

This guide covers what to learn from three common starting points, the course lessons to take in order, and the three pieces worth putting in a portfolio. It's a research guide. It doesn't promise a timeline or an offer, and the postings cited were read on September 26, 2026.

What the job asks for

Start from job posts, 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 customers' work. Scale AI's Frontier Agents Engineer (Applied AI) and Elastic's Agentic AI Engineer sit closer to the platform underneath. The comparison with AI and ML engineering quotes what each of them owns.

Across those posts, four abilities keep coming up:

• Tool limits. Deciding what the model can call, with what inputs, and what your code checks before anything changes.
• Saved progress and recovery. Knowing what survives a crash, a retry, or an approval that's gone out of date.
• Testing. Measuring whether the task actually succeeded, keeping failures in the count, and telling a model problem from a problem in your own code.
• Ordinary backend skill. APIs, databases, tests and running things in production. When an agent makes a bad choice, it usually turns into a normal software bug at the moment 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 three causes: too many functions, too many permissions and too much freedom to act alone. 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 two things. In a workflow, your code fixes the steps. In an agent, the model decides its own steps and which tools to use. Its advice is to find "the simplest solution possible" and add complexity only when it improves results.

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

Where you're starting from

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

The software engineer's risk is treating the model like a function that always gives the same answer. The data person'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.

Take the course in order

The site's agent course is 17 hands-on labs, grouped in four stages on the agents and AI engineering pillar page. Every lab runs on your own machine, and each one says which parts are simulated. Take them in this order. The capstone builds on most of the earlier lessons.

Stage 1: Set the limits

1. AI APIs for beginners: send a request, check the response, and test what happens with a bad key, a rate limit or garbled output.
2. Build a webhook receiver that verifies and recovers: confirm an incoming message really came from the sender, and handle getting the same one twice.
3. Three prompt contracts with evaluation fixtures: write prompts whose output you can check.
4. Run a bounded tool-calling loop: keep what the model suggests separate from what your code allows.
5. Build an MCP server and client: find and test a tool over the Model Context Protocol, a standard way to offer tools to models.

Stage 2: Add context and control

6. Build a small RAG pipeline: look up documents the user is allowed to see, and measure what the lookup misses.
7. Persistent agent memory: decide what the agent remembers, update it, and let it expire.
8. Plan and execute: keep a plan small and stop when a step it depends on fails.
9. Human approval for agents: tie a person's approval to the exact change they approved.

Stage 3: Test failure and recovery

10. Evaluate a ticket agent: run a test set and keep failures in the total.
11. Agent evaluation tools: rerun a local test and compare tools on one task.
12. Agent design patterns: run four ways of structuring an agent and see how each one fails.
13. Choose an agent starter: check the assumptions a template makes for you.

Stage 4: Build and review

14. GitHub Copilot on a stale-delete bug: review an AI-written fix by what it actually does.
15. Cursor for a ticket approval interface: make one change with a clear, testable promise.
16. n8n ticket-triage workflow: test the failure paths of a visual workflow.
17. The capstone: connect a verified incoming request, document lookup and approval, then check that it survives a restart and a repeat.

If time is short, lessons 4, 9, 10 and 17 matter most for this role. They cover the tool limit, the approval record, the test report and the full system.

Build three portfolio pieces

A reviewer has minutes, not hours. Three small pieces with clear evidence beat one big demo with none. Each one below answers a line that shows up in agent job posts.

1. A tool limit with a rejected call

Build one narrow tool, like changing a ticket's label, and a loop that lets a model suggest calls to it. Your code checks who's asking, whether they own the ticket, and whether the inputs are the right shape, before anything runs.

What to show:

• The tool's input format, what it returns, and what its errors look like.
• One allowed call, and one your code rejects. For example, a ticket ID in the right format that belongs to someone else.
• A limit on how many turns the loop can take, and what it returns when it hits that limit.

This answers the permissions part of Excessive Agency directly. Lessons 4 and 5 are your starting code.

2. An approval that survives a crash and rejects stale decisions

Change the tool so a suggestion waits for a person to approve it. Store the suggestion, the decision and the receipt for the action as separate records. Then break it on purpose.

What to show:

• Restart the program between the suggestion and the approval, and show the suggestion is still there.
• Change the ticket after it's approved, and show the system refusing to act on the now out-of-date approval.
• Send the same approved request twice, and show one action and one receipt. That's the refund problem from the top of this page, solved.

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

3. A test report someone can argue with

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

What to show:

• The test cases, how they were made, and which ones you tuned against.
• Scores that show "out of how many": right results, wrong results, timeouts and refusals, each counted separately.
• A table of failed cases with what you expected, what happened, the likely cause and what you'd try next.
• A clear line between tests of your own code, which give the same result every time, and any runs against a live model.

Lessons 10 and 11 give the structure. A small set of cases you wrote shows your method. It doesn't prove the agent works for real users, and the report should say so.

A worked example

This is made up, to show how the three pieces fit together.

Riley comes from Zapier automations. Riley's repo has one tool: relabel a support ticket. Piece 1 shows the model trying to relabel a ticket owned by another customer, and the code refusing. Piece 2 shows Riley killing the program after a manager approved a relabel, restarting it, and the relabel happening exactly once. Then Riley edits the ticket after approval, and the system asks for a fresh approval instead of acting. Piece 3 is a table of 30 test tickets, with the four the agent got wrong and a guess at why.

None of it needs a big model or a big framework. It shows judgment.

Package the work

Put all three in one repository with setup commands, test data, a diagram of the states a request moves through, and a short design note. The note answers four questions: what the model may decide, what your code enforces, what survives a crash, and what the tests don't cover. Someone with a fresh copy should be able to reproduce your results without a paid API key. Label every simulated part.

Apply with the right evidence

Before you send anything, figure out where the job sits. A post about the agent runtime or platform wants piece 2 and some sign you've thought about scale. A post about shipping agents to customers wants pieces 1 and 3, plus some sign you can work with a customer's messy process. The comparison with nearby roles has a table for reading a posting this way.

Lead with the piece that matches, not the whole 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 exact 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" plus the name of an agents team.

Common mistakes

• Framework first. A LangGraph or CrewAI project with no failure cases shows you can follow a tutorial. Look at a starter template only after your own simple version works, as lesson 13 suggests.
• Putting the rules in the prompt. "Only use this user's data" in a system prompt isn't access control. Put the check in code.
• A score with no total. "92 percent accurate" with no count of timeouts and refusals invites the first interview question you can't answer.
• Claiming scale you didn't test. A local SQLite demo shows the agent behaves correctly when interrupted. It doesn't show how much traffic it can handle, and saying otherwise costs you 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 piece is done.
• If you're changing careers from outside software, the career transition guide helps you map your existing experience first.