AI Agents Engineer Roadmap
A path from LLM and programming fundamentals through agent orchestration, tool use, and production deployment for building autonomous AI agent systems.
This path assumes you write Python and call REST APIs comfortably, but have not built agentic systems. If you have used an LLM API for a chatbot or a summariser, you have started.
One property makes this different from everything else you have built: the same input does not produce the same output. Unit tests asserting exact values, bugs that reproduce, "works on my machine" — none of it holds. An agent that succeeded nine times can fail the tenth with no line of code to fix. That is why evaluation and safety come before production deployment here, and it is the ordering people most often skip. It is also why agents fail differently: a conventional bug throws, while an agent produces something plausible and wrong, confidently, and a user may act on it before anyone notices.
The arithmetic that constrains every design below: a single call at 95% reliability is usually fine, but ten chained calls at 95% each land near 60%.
Each phase lists what to learn, what to build, and how to know you are done. Expect 9–14 months. Treat the named frameworks as a current starting point rather than a permanent stack — the field moves, but tool design, evaluation rigour and failure analysis transfer.
The path, phase by phase
LLM & Programming Foundations
How models behave at a level useful for engineering. Done when you can predict which prompts will fail before running them, and explain a wrong answer in terms of context and sampling rather than "the model is dumb". Build on a system whose behaviour surprises you and you write workarounds for problems you have misdiagnosed.
1-2 months8 SkillsPython for AILLM FundamentalsTokenisation & Context WindowsSampling ParametersPrompt EngineeringStructured Output & JSON ModeModel Selection & TradeoffsAPI IntegrationShow details, projects and resourcesSkills you'll master
Python for AIintermediateLLM FundamentalsadvancedTokenisation & Context WindowsintermediateSampling ParametersintermediatePrompt EngineeringadvancedStructured Output & JSON ModeintermediateModel Selection & TradeoffsintermediateAPI IntegrationintermediateHands-on projects
- 01Build a CLI that summarises a text file with configurable length and reports token usage and cost per run
- 02Write a harness that runs one task against three prompt variants and scores the outputs against a rubric you defined in advance
- 03Run the same prompt twenty times at temperature 0 and at temperature 1, and characterise the difference in the output distribution
- 04Deliberately overflow a context window and observe what the model loses first, then design around it
- 05Get the same task working on a small cheap model and a large one, and record the quality and cost difference — the answer is often not the expensive one
- 06Force structured JSON output and handle the cases where it comes back malformed anyway
Tool Use & Function Calling
The smallest complete agent: one model, one tool, one decision about whether to call it. Done when your agent picks the right tool for ambiguous requests and recovers when a tool returns an error instead of stopping or inventing a result. The tool description matters more than its implementation — it is what the model actually reasons over.
1-2 months7 SkillsFunction CallingTool Description DesignStructured Output ParsingArgument ValidationError Handling in Agent LoopsRetry & Fallback StrategyModel Context Protocol (MCP)Show details, projects and resourcesSkills you'll master
Function CallingadvancedTool Description DesignadvancedStructured Output ParsingadvancedArgument ValidationintermediateError Handling in Agent LoopsadvancedRetry & Fallback StrategyintermediateModel Context Protocol (MCP)intermediateHands-on projects
- 01Build an agent that answers questions using two tools and picks correctly based on the request
- 02Implement retry and fallback so one failed call does not end the task, and make the failure legible to the model rather than opaque
- 03Give the agent a deliberately ambiguous request and watch which tool it picks — then improve the descriptions until it picks right
- 04Return a malformed response from a tool on purpose and verify the agent recovers instead of hallucinating a result
- 05Validate tool arguments before execution and handle the case where the model invents a parameter that does not exist
- 06Write the same tool with a vague description and a precise one, and measure the difference in selection accuracy
Agent Orchestration & Memory
Where errors start compounding: ten chained calls at 95% reliability each land near 60%. Done when your agent completes a five-step task reliably, and when it fails you can say which step and why from the trace alone. This phase is about structuring work so failure does not multiply unchecked.
2-3 months8 SkillsAgent Orchestration FrameworksTask DecompositionPlanning & ReplanningState Management Across StepsContext Window ManagementLong-Term Memory DesignRetrieval (RAG)Vector DatabasesShow details, projects and resourcesSkills you'll master
Agent Orchestration FrameworksadvancedTask DecompositionadvancedPlanning & ReplanningadvancedState Management Across StepsadvancedContext Window ManagementadvancedLong-Term Memory DesignintermediateRetrieval (RAG)intermediateVector DatabasesintermediateHands-on projects
- 01Build a research agent that plans a multi-step task, executes it, and revises the plan when a step fails or returns something unexpected
- 02Add a memory layer so the agent recalls facts across sessions, and demonstrate correct recall after twenty-plus turns
- 03Measure your agent's per-step success rate, then compute the end-to-end rate — and see whether the arithmetic matches what you observe
- 04Take a task that fails end to end and decompose it until each step is reliable enough that the chain holds
- 05Handle a conversation that outgrows the context window without losing the thread
- 06Build the same feature twice, once with retrieval and once with a well-designed tool call, and decide which was actually warranted
Evaluation, Safety & Guardrails
Before deployment, deliberately. With non-deterministic output, "it seemed better" is not measurement, and the evaluation harness is what tells you whether the thing works at all. Done when you can say whether a prompt change made things better with a number rather than an impression.
1-2 months8 SkillsEvaluation Set DesignAutomated Scoring & LLM-as-JudgeRegression Testing for AgentsGuardrail DesignRed-TeamingPrompt Injection DefenceHuman-in-the-Loop ReviewLeast-Privilege Tool AccessShow details, projects and resourcesSkills you'll master
Evaluation Set DesignadvancedAutomated Scoring & LLM-as-JudgeadvancedRegression Testing for AgentsadvancedGuardrail DesignadvancedRed-TeamingintermediatePrompt Injection DefenceadvancedHuman-in-the-Loop ReviewintermediateLeast-Privilege Tool AccessadvancedHands-on projects
- 01Build an evaluation suite of 30+ cases covering both expected-success and expected-refusal, running in CI on every change
- 02Implement a guardrail that blocks destructive tool calls without explicit human confirmation
- 03Make a prompt change and prove with your eval set whether it helped — including the case where it helped one thing and broke another
- 04Red-team your own agent with prompt injection through tool output, not just through user input, and fix what gets through
- 05Scope your agent's credentials to the minimum, then verify by removing a permission and confirming it fails safely rather than silently
- 06Build a human review queue for low-confidence outputs and define what "low confidence" concretely means
Production Deployment & Observability
Agent observability is its own problem: traditional metrics tell you it responded in 800ms and cost $0.02, not that it was wrong. Done when you know your per-request cost, your p95 latency and your task success rate in production — especially the third, which most teams never measure.
2-3 months8 SkillsAgent Observability & TracingTask Success Rate MeasurementCost & Token MonitoringCaching & Cost ReductionLatency Optimisation & StreamingRate Limiting & BackpressureDeployment PipelinesGraceful Degradation & Fallback ModelsShow details, projects and resourcesSkills you'll master
Agent Observability & TracingadvancedTask Success Rate MeasurementadvancedCost & Token MonitoringadvancedCaching & Cost ReductionintermediateLatency Optimisation & StreamingintermediateRate Limiting & BackpressureintermediateDeployment PipelinesintermediateGraceful Degradation & Fallback ModelsintermediateHands-on projects
- 01Deploy an agent behind an API with request logging, per-user rate limiting and a dashboard for token spend and latency
- 02Instrument task success rate in production, not just latency and cost — decide what "success" means before you can measure it
- 03Alert on error rate and cost per request crossing a threshold, with a runbook for whoever is on call
- 04Cut cost per request by at least 30% through caching, prompt trimming or model routing, and show the before and after
- 05Trace one production request end to end across every model and tool call it triggered
- 06Add a fallback path for when the primary model is unavailable, then test it by blocking the primary
Resources
LangSmith Observability DocumentationLangChain · FreeOpenTelemetry GenAI Semantic ConventionsOpenTelemetry · FreeAnthropic Prompt CachingAnthropic · FreeAnthropic Streaming DocumentationAnthropic · FreeDesigning Data-Intensive ApplicationsMartin Kleppmann · Paid · aff — Affiliate link — we may earn a commission at no extra cost to you. A free alternative is always listed alongside.Some resources are affiliate links, marked AFF. They cost you nothing extra, we may earn a commission, and a free alternative is listed alongside wherever one exists.
Multi-Agent Systems & Coordination
One agent hits a ceiling a team of specialists does not: a single prompt trying to plan, research and write well is worse at all three than three agents doing one each. Done when you can hand a task to a coordinator, watch it delegate to two or more sub-agents, and explain from the trace why the split made the result better rather than just slower and more expensive.
3-4 weeks7 SkillsMulti-Agent Architecture PatternsAgent-to-Agent CommunicationTask Delegation & HandoffShared State & CoordinationDeadlock & Loop DetectionSub-Agent EvaluationCost-Aware Agent RoutingShow details, projects and resourcesSkills you'll master
Multi-Agent Architecture PatternsadvancedAgent-to-Agent CommunicationadvancedTask Delegation & HandoffadvancedShared State & CoordinationintermediateDeadlock & Loop DetectionintermediateSub-Agent EvaluationintermediateCost-Aware Agent RoutingintermediateHands-on projects
- 01Build a coordinator agent that delegates research, drafting and review to three separate sub-agents and merges their output into one deliverable
- 02Compare a single generalist agent against your multi-agent split on the same ten tasks, and report where the split won, lost and tied — not just the average
- 03Add loop detection so two agents handing a task back and forth terminate with a clear failure instead of burning budget silently
- 04Give one sub-agent a cheaper model than the others and measure the cost and quality tradeoff on the whole pipeline
- 05Instrument per-agent cost and latency so you can say which sub-agent is the bottleneck, not just the total
Enterprise Integration & Data Access
Agents earn their keep against real systems, not demo data — a CRM with inconsistent fields, a database you cannot rewrite, an API with rate limits nobody documented. Done when your agent reads from and writes to a production-shaped system under real permission constraints, and a bad write is rejected before it lands rather than cleaned up after.
3-4 weeks7 SkillsDatabase & API Integration for AgentsSchema-Aware QueryingWrite-Action Safety & ConfirmationAuthentication & Scoped CredentialsData Freshness & Caching TradeoffsEnterprise Search & Document RetrievalAudit LoggingShow details, projects and resourcesSkills you'll master
Database & API Integration for AgentsadvancedSchema-Aware QueryingintermediateWrite-Action Safety & ConfirmationadvancedAuthentication & Scoped CredentialsadvancedData Freshness & Caching TradeoffsintermediateEnterprise Search & Document RetrievalintermediateAudit LoggingintermediateHands-on projects
- 01Connect an agent to a real database schema with 10+ tables and have it answer questions that require a join, verifying the generated query before execution
- 02Build a write action — creating a ticket, updating a record — that requires explicit confirmation and logs who approved it and why
- 03Scope the agent's database credentials to read-only on everything except one table, then verify a write attempt elsewhere fails safely
- 04Integrate an internal document search so the agent cites the specific document and section it drew an answer from, not just "based on our docs"
- 05Simulate a stale-cache scenario and show your agent either refreshes the data or flags that its answer may be out of date
Specialization & Portfolio
Pick a direction — agent platform tooling, a vertical like legal or customer support, or research-adjacent evaluation work — and build the piece that shows judgment under real constraints, not another tutorial clone. Done when someone outside your team used something you built, on their own data, without you sitting next to them.
3-4 weeks6 SkillsDomain SpecializationAgent Platform ToolingTechnical Writing & Case StudiesOpen Source ContributionStakeholder CommunicationCost Modelling for Agent ProductsShow details, projects and resourcesSkills you'll master
Domain SpecializationadvancedAgent Platform ToolingintermediateTechnical Writing & Case StudiesintermediateOpen Source ContributionintermediateStakeholder CommunicationintermediateCost Modelling for Agent ProductsintermediateHands-on projects
- 01Ship an agent for a real workflow in a domain you chose, get a person outside your team to use it unsupervised, and fix what they got stuck on
- 02Get one non-trivial pull request merged into an open-source agent framework — a bug fix, an integration or documentation that someone needed
- 03Write a case study of a production agent you built, including what failed, what the evaluation numbers actually said, and what you would change
- 04Build a cost model that predicts monthly spend from expected request volume, then check it against a week of real usage
- 05Present your production agent's failure modes and mitigations to someone technical who was not involved, and revise based on the questions they ask
Resources
Anthropic Engineering BlogAnthropic · FreeLangChain BlogLangChain · FreeDesigning Data-Intensive ApplicationsMartin Kleppmann · Paid · aff — Affiliate link — we may earn a commission at no extra cost to you. A free alternative is always listed alongside.Some resources are affiliate links, marked AFF. They cost you nothing extra, we may earn a commission, and a free alternative is listed alongside wherever one exists.
What the job is actually like
- Day to day
- Far more evaluation than prompting. A normal week is reading traces of agent runs that went wrong, deciding whether the failure was the model, the tool contract or the context you assembled, and turning the interesting ones into test cases. Real time goes on unglamorous plumbing: retries around flaky APIs, token budgets, and the schema of a tool the model keeps calling incorrectly. The hardest habit to build is refusing to fix a failure you cannot reproduce — an agent that behaves differently on identical input is telling you something about your context assembly, not about the model.
- The interview
- Usually a take-home where you build a small agent against a real API, and the review is about your evaluation harness more than the agent. Expect to defend why a step is a tool call rather than a prompt instruction, and to be pushed on what happens when the model returns something malformed. A systems round covers cost and latency: how many model calls does this design make, what caches, what runs in parallel. Teams that have actually shipped agents will ask what broke in production and how you found out, which is where a candidate who has only built demos becomes obvious.
- How people get in
- Most arrive from backend or application engineering, bringing the API design instinct that matters most here — a tool the model can call reliably is a well-designed interface, not a clever prompt. Data and machine learning engineers arrive with evaluation habits and tend to underrate the systems work. A smaller group comes from the AI security path, and traffic moves in both directions: the two roles read the same traces looking for different things. What transfers from any origin is debugging under uncertainty. What does not is the expectation that the same input gives the same output.
- After senior
- Titles are still unsettled, which is both the opportunity and the risk. The technical fork leads toward agent infrastructure — the platform other teams build agents on, which is closer to platform engineering than to prompting. A second fork goes deep on evaluation, owning whether the systems are getting better rather than building them. A third moves toward AI security, as the permission and blast-radius questions stop being someone else's job. Because the ladder is not yet standard, seniority here is argued with shipped systems and their failure data rather than with a title.
- Why people leave
- The common one is a demo that never became a product. Agents are unusually easy to make impressive in a controlled run and unusually hard to make dependable, and an engineer who cannot show what their system does on its worst inputs has not finished the job. The second is building on abstractions you do not understand: frameworks change fast, and a career resting on one vendor's orchestration layer ages badly. The third is organisational — being hired to add agents to a product with no problem an agent solves, where success is measured by adoption of a feature nobody asked for.
Frequently asked questions
Related certifications
- AI-103: Developing AI Apps and Agents on AzureThe replacement for the retired AI-102, and the first Microsoft exam with agents in its title — a third of the marks on generative and agentic solutions, and another 39% on the vision, language and extraction services most agent builders never touch.
- Artificial Intelligence Governance Professional (AIGP)A knowledge-based certification covering AI governance foundations, the laws and standards that apply to AI, and how to govern AI development, deployment and ongoing use.
Related roadmaps
- AI Security Engineer RoadmapA defensive security path for engineers who secure LLM and agent systems, covering AI threat modelling, prompt injection defence, supply chain integrity, agent permissions, guardrails, governance and incident response.
- Observability Engineer RoadmapA path into observability as a craft of its own — wide events, signal correlation, telemetry cost, collector pipelines, high-cardinality analysis, continuous profiling, and running observability as a platform other teams consume.
- Platform Engineer RoadmapThe path DevOps engineers move into — building an internal developer platform as a product, covering Kubernetes as substrate, IaC at scale, GitOps, golden paths, portals, policy, multi-tenancy and adoption.