From Zero to Agent Engineer: A Realistic 90-Day Plan

Why "agent engineer" is a real job now, not a buzzword

Two years ago, nobody had "agent engineer" on a business card. Today it's a distinct hiring category, separate from "ML engineer" and separate from "backend developer," even though it borrows heavily from both. The shift happened because large language models stopped being just text-completion boxes and started being able to call tools, remember state across turns, plan multi-step tasks, and hand off work to other models. Someone has to design, wire up, test, and operate that machinery. That someone is the agent engineer.

Here's the catch: almost every "become an AI engineer" roadmap floating around online is either a glorified prompt-engineering course or a research-paper reading list that never touches production code. Neither prepares you to actually ship. This plan is different. It assumes you have zero agent experience but are comfortable writing basic code, and it walks you through 90 days that end with a working, deployed, monitored agent — not a notebook full of experiments that only run on your laptop.

We're not going to pretend this is easy or that you'll be job-ready in three months with no prior programming background. If you already know Python (or are willing to learn fast), 90 days of focused, daily work is enough to go from "I've used ChatGPT" to "I can design and ship an agent system that does real work." That's the bar we're aiming for. Let's build the plan.

The four skills that actually make an agent engineer

Before the calendar, let's define the target. An agent engineer needs competence in four areas, and the 90-day plan is structured around building each one in sequence, then combining them.

1. LLM fundamentals and API mechanics. You need to know how context windows work, what temperature and top-p actually do, how tool-calling (function calling) works at the API level, how streaming responses work, and how token costs scale. This is not optional theory — it's the difference between debugging a broken agent in five minutes versus five hours.

2. Tool use and orchestration. Agents are only useful because they can act — search the web, query a database, write a file, call an internal API. You need to design tool schemas, handle tool errors gracefully, and decide when an agent should ask for tools versus when it should just answer.

3. State, memory, and multi-step planning. A single LLM call is not an agent. An agent is a loop: observe, decide, act, observe again. You need to understand how to manage conversation state, long-term memory (vector stores, structured memory, file-based memory), and how to prevent infinite loops or runaway costs.

4. Evaluation, guardrails, and deployment. This is the part almost every course skips. Shipping an agent means testing it against real failure modes, adding guardrails so it doesn't do something destructive, logging its decisions, and deploying it somewhere that isn't your local terminal.

The 90 days below build these four skills roughly in order, with heavy overlap and constant hands-on practice, because reading about agents teaches you nothing that building them doesn't teach you faster.

Days 1-30: Foundations — APIs, prompting, and your first tool-using agent

The first month is about removing every excuse for not understanding the primitives. No frameworks yet. You write raw API calls before you touch LangChain, LlamaIndex, or any agent framework, because frameworks hide exactly the mechanics you need to debug later.

Week 1 (Days 1-7): Environment and raw API calls. Set up a Python environment, get API keys for at least one frontier model provider, and make your first calls without any SDK abstraction beyond the official client library. Your goal this week is to understand the request/response shape cold: system prompts, message roles, token limits, streaming.

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-sonnet-4-5",
    max_tokens=1024,
    system="You are a concise technical assistant.",
    messages=[
        {"role": "user", "content": "Explain what a token is in one paragraph."}
    ],
)

print(response.content[0].text)

By day 7, you should be able to explain, without looking anything up: what a system prompt does differently from a user message, why max_tokens matters for both cost and truncation, and what happens when you exceed a context window.

Week 2 (Days 8-14): Prompting as an engineering discipline. Move past "write a good prompt" and into structured prompting: few-shot examples, output format constraints (JSON mode, XML tags), chain-of-thought scaffolding, and prompt versioning. Build a small harness that runs the same prompt against multiple inputs and logs outputs to a file so you can compare versions. This is your first taste of evaluation, and it matters more than people admit — most "the model is bad at X" complaints are actually "the prompt was ambiguous about X."

Week 3 (Days 15-21): Tool calling from scratch. This is the week everything changes. Implement function calling manually: define a tool schema, send it to the model, parse the tool call the model returns, execute the actual function, and send the result back. Do this with at least three different tools — a calculator, a weather lookup (even a fake one), and a file reader. Understand the full loop:

tools = [
    {
        "name": "get_stock_price",
        "description": "Get the current price for a stock ticker symbol.",
        "input_schema": {
            "type": "object",
            "properties": {
                "ticker": {"type": "string", "description": "Stock ticker, e.g. AAPL"}
            },
            "required": ["ticker"],
        },
    }
]

def get_stock_price(ticker: str) -> str:
    # Replace with a real data source in production
    return f"{ticker}: $184.32"

response = client.messages.create(
    model="claude-sonnet-4-5",
    max_tokens=1024,
    tools=tools,
    messages=[{"role": "user", "content": "What's the price of AAPL?"}],
)

for block in response.content:
    if block.type == "tool_use":
        result = get_stock_price(**block.input)
        print("Tool result:", result)

Once you can trace a tool call through the entire round trip by hand, you understand agents at the level that separates engineers from prompt tinkerers.

Week 4 (Days 22-30): Your first real loop. Combine everything into a basic agent loop: the model receives a task, decides whether to call a tool, you execute it, feed the result back, and repeat until the model produces a final answer. Build a small "research assistant" that can search a local set of documents and answer questions by citing them. Add a hard iteration cap (say, 6 loops) so a confused model can't spin forever — this is your first guardrail, and you'll thank yourself for it later. By day 30 you should have a working repository with: raw API wrapper, a tool registry, a loop controller, and basic logging of every step the agent took.

Days 31-60: Frameworks, memory, and multi-agent patterns

Month two is where you stop reinventing wheels and start using production frameworks, but with the informed eye of someone who already built the wheel by hand. You'll also tackle the parts of agent engineering that separate toy demos from systems that survive contact with real users: memory and coordination between multiple agents.

Week 5 (Days 31-37): Adopt a framework, deliberately. Pick one agent framework (the ecosystem changes fast, so evaluate what's actively maintained when you start) and rebuild your Week 4 research assistant inside it. Because you already understand the primitives, you'll spend this week noticing what the framework does for you — retries, structured tool registration, streaming callbacks — instead of being mystified by magic. Keep a running list of "things this framework does that I didn't have to write myself." That list is your mental model of what frameworks are actually for.

Week 6 (Days 38-44): Memory systems. An agent without memory re-reads the same context every call, which is slow and expensive. Build three kinds of memory in small isolated examples: (1) simple conversation buffer memory, (2) a vector-store-backed retrieval memory for long documents, and (3) structured/file-based memory for facts that should persist across sessions (user preferences, project state). Understand the tradeoffs — vector search is great for "find something similar" but bad for "recall this exact fact I was told three days ago." Most production agents use a hybrid.

Week 7 (Days 45-51): Multi-step planning and task decomposition. Single-loop agents fall apart on complex tasks. This week, build an agent that plans before acting: given a goal, it first produces a task list, then executes each subtask, checking in against the plan as it goes. Test it against a genuinely multi-step task — something like "read these five files, summarize each, then write a combined report highlighting contradictions." Watch where it fails. It will fail. That's the point — you're learning the failure modes of planning agents (plan drift, forgetting earlier steps, over-decomposition) before you have to debug them in production under time pressure.

Week 8 (Days 52-60): Multi-agent coordination. Introduce a second agent role — a specialist that the main agent can delegate to. A common pattern: an orchestrator agent that breaks down a task and dispatches subtasks to worker agents with narrower tool access, then synthesizes their results. Build this for a concrete use case, such as a coding assistant where one agent writes code and a separate agent reviews it before it's accepted. Pay close attention to cost and latency here — multi-agent systems multiply API calls fast, and this is exactly the kind of design decision that gets scrutinized in real engineering interviews and real production budgets.

def orchestrate(task: str) -> str:
    subtasks = plan(task)          # one model call: decompose task
    results = []
    for subtask in subtasks:
        worker_output = run_worker_agent(subtask)   # scoped tool access
        results.append(worker_output)
    return synthesize(task, results)   # one model call: combine results

By day 60 you should have shipped at least two multi-file agent projects to a personal GitHub repo, each with a README explaining the architecture and known limitations. Employers and clients read READMEs before they read code.

Days 61-90: Evaluation, guardrails, and shipping to production

This final month is where most self-taught learners stop short, and it's exactly why it's the most valuable stretch to push through. Anyone can get a demo working. Few people can tell you their agent is reliable, safe, and cheap enough to run at scale.

Week 9 (Days 61-67): Build an evaluation harness. Before you can improve an agent, you need to measure it. Create a test set of 20-30 representative tasks with expected outcomes (or at least clear pass/fail criteria), and write a script that runs your agent against all of them and scores the results. Use an LLM-as-judge pattern for outputs that are hard to check programmatically, but always pair it with a handful of hard-coded checks (did it call the right tool, did it stay under N steps, did it avoid a banned action).

test_cases = [
    {"input": "Cancel order #4521", "expected_tool": "cancel_order"},
    {"input": "What's my order status?", "expected_tool": "get_order_status"},
]

def evaluate(agent_fn):
    passed = 0
    for case in test_cases:
        trace = agent_fn(case["input"])
        tool_used = trace.get("tool_name")
        if tool_used == case["expected_tool"]:
            passed += 1
        else:
            print(f"FAIL: expected {case['expected_tool']}, got {tool_used}")
    print(f"{passed}/{len(test_cases)} passed")

Run this harness every time you change a prompt, a tool, or a model version. This habit alone will put you ahead of most people calling themselves agent engineers.

Week 10 (Days 68-74): Guardrails and failure handling. Now stress-test deliberately. Feed your agent adversarial inputs, ambiguous requests, and tool failures (simulate an API timeout, a malformed response, a rate limit). Add explicit guardrails: input validation before a destructive tool call, confirmation steps for irreversible actions, spend caps per session, and timeouts on the whole loop. If you're building anything that touches money, user data, or external communication (sending emails, posting to social media, making purchases), this week is not optional — it's the difference between a portfolio project and something you could actually be trusted to run.

Week 11 (Days 75-81): Observability and deployment. Wrap your agent in a minimal API (FastAPI or similar), add structured logging for every model call and tool call (input, output, latency, cost), and deploy it somewhere reachable — a small VM, a serverless function, or a container platform. Add a basic dashboard or even just a log-aggregation view so you can see, after the fact, exactly what the agent did and why. This is the week your project stops being "code on my laptop" and becomes "a system," which is the actual deliverable agent engineering jobs pay for.

Week 12 (Days 82-90): Ship, document, and present. Polish one project — pick your strongest agent from the previous 11 weeks — into a portfolio piece. Write a clear README with architecture diagram (even a simple one), explain the design tradeoffs you made, document known failure modes, and record a short walkthrough video. Then do the less comfortable part: share it. Post it, apply it to a real problem for a friend's business, or use it as your interview centerpiece. A single well-documented, genuinely working agent beats ten half-finished tutorials every time a hiring manager looks at your GitHub.

What to skip (and what not to skip)

Ninety days is not enough time to do everything, so triage matters. Skip: chasing every new framework release, fine-tuning your own models (not needed for 95% of agent engineering roles), and building elaborate UI — a working CLI or bare-bones API is enough for a portfolio project. Do not skip: the evaluation harness, the guardrails week, and the deployment step. These three are exactly what separates candidates who can talk about agents from candidates who can be handed an ambiguous business problem and trusted to ship something that works unattended.

If you have less than 90 days of full-time focus available — say you're doing this alongside a job — stretch the plan to 5-6 months at the same daily cadence rather than compressing the content. The skill compounds through repetition, not through cramming.

Realistic expectations for day 90

By the end of this plan you will not be a research scientist, and you won't have invented a new agent architecture. What you will have is something rarer in this market: hands-on proof that you can take an ambiguous task, design an agent to handle it, instrument it so you can trust it, and put it somewhere real. You'll be able to speak fluently about tool-calling mechanics, memory tradeoffs, multi-agent cost implications, and evaluation design — because you built all of it yourself, not because you read about it.

That's the actual bar for an entry-level to mid-level agent engineering role right now. The field is young enough that demonstrated, working projects still count for more than credentials. Ninety days of consistent, hands-on effort following this arc — foundations, then frameworks and memory, then evaluation and shipping — gets you there.

If you want the daily structure done for you instead of assembling it yourself from blog posts and scattered docs, that's exactly what 30 Days of Hermes Agent on teachyou.ai is built for: a guided, project-based path through building, evaluating, and deploying real agents, with working code at every step instead of theory alone. Treat it as an accelerant for the plan above, not a replacement for the reps — the reps are what actually make you an agent engineer.