Become an AI Agentic Engineer in 6 Weeks — Part 1

Full Course · Part 1

Become an AI Agentic Engineer in 6 Weeks

Most developers learn AI by copying tutorials. They install a framework, paste prompts, build a chatbot — then hit production and everything breaks. The agent hallucinates. The context blows up. It costs 10x more than expected.

AI engineering is not about knowing the frameworks. It is about understanding what actually happens inside the model — and building systems around that.

The Goal

Understand LLMs under the hood

By the end of Part 1 you will understand tokens, inference, temperature, hallucination, context windows, prefill, decode, TTFT, RAG, and tools — not the tutorial version, but the version that makes you effective in interviews and production.

Tokens Inference Temperature Hallucination Context & RAG Tools

If you are a backend engineer: your distributed systems experience transfers directly. The new layer is LLMs + agent architecture + context engineering + evaluation.

Roadmap

The 6-week path

LLM Foundations · this part

Tokens, inference, temperature, hallucination, context windows, prefill, decode, TTFT, RAG, tools.

Prompt & Context Engineering

System, user and tool messages, instruction hierarchy, dynamic prompts, prompt injection, context rot, memory.

Tool Calling & Agent Architecture

Schemas, validation, execution loops, retries, parallel tools, the core agent loop, ReAct, state machines.

RAG & Memory

Chunking, embeddings, vector search, hybrid retrieval, reranking, working / episodic / semantic memory.

Multi-Agent Systems & Production

Supervisor / worker patterns, async execution, checkpoints, rate limits, observability, token budgets, cost controls.

Evals, Security & Interview Prep

Golden datasets, LLM-as-judge, prompt injection, sandboxing, system design interviews, 3–4 real projects.

Outcome

Be ready to interview for AI Engineer, Applied AI Engineer, Agent Engineer and LLM Engineer roles — stronger than someone who only learned prompting. Agent systems involve distributed execution, APIs, concurrency, queues and observability: all areas you already know deeply.

First Principle

The one thing to understand first

An LLM does not search a database of facts. It does not verify what it says. It does not "know" things the way you know your name.

1You send text — the context.
2The model converts it to tokens.
3For each token position it calculates probabilities over the entire vocabulary.
4It samples the next token from that distribution.
5It adds that token to the context.
6It repeats until done.

That is the entire mechanism. Writing code, answering questions, hallucinating, reasoning — all of it comes from doing this repeatedly and well.

Step 1

Tokens — what the model actually reads

The model never reads raw text. It reads tokens: not always full words, but pieces of words. Each one gets a number ID.

1 token ≈ 0.75 words

Rule of thumb

1,000 tokens ≈ 750 words

Rough conversion

128,000 tokens

≈ a full novel of context

Why not just use full words? Language is messy — new words, typos, code, mixed languages. Tokens are fixed, reusable building blocks. Even a word the model has never seen can be understood by breaking it into familiar pieces.

Production implication

You pay per token, and latency scales with token count. A 100,000-token input and a 1,000-token input are not the same request. Always count your tokens.

Probability

What "92% probability" actually means

Suppose the model generates "The capital of France is Paris" — and behind the scenes it assigned 92% probability to "Paris" as the next token.

This does not mean P("Paris is factually correct") = 92%. Those are completely different statements.

Imagine a fictional "Dr. John Smith" and a made-up "HyperFlux battery." Given that context, the model might still generate "Stanford University" with 78% probability — because it is a plausible continuation.

High token probability ≠ factually true. This is the beginning of understanding hallucinations.

Sampling

Temperature — the creativity dial

Same prompt, same model, different answer every time. Why? Sampling. The model does not always pick the most likely token — it samples from the distribution like a weighted dice. Temperature controls how that sampling works.

The rule that trips up beginners

Low temperature does NOT prevent hallucinations.

Imagine the distribution is 99% wrong answer and 1% correct answer. Set temperature to zero and the model confidently generates the wrong answer — every single time. You have not made it more truthful. You have made the hallucination more repeatable.

Write these into your mental model now

Sampling is probabilistic, not proof-driven.
Temperature shapes variety, not truthfulness.
The model proposes; your system decides.

Production implication

Never ask a probabilistic model to be the sole enforcer of a deterministic business rule. For financial agents, refund systems, anything with real consequences: your backend validates. The LLM proposes.

Failure Mode

Why LLMs hallucinate — the real reason

Hallucination is not a bug they forgot to fix. It is a direct consequence of how LLMs work.

Ask: "What is the refund policy of RahulStore?" RahulStore doesn't exist. The model still has to produce probabilities. If training contained millions of similar patterns, then after "RahulStore's refund policy is" the continuation "30 days" looks extremely plausible.

The model has no step that says "I don't know." Its core process remains: given this context, what token comes next? That is why hallucinations sound convincing. The model is not lying — it is doing exactly what it was trained to do: produce plausible continuations.

Three categories of hallucination exist. All three happen in production, and each one needs a different fix.

Consistency ≠ correctness

If temperature = 0 and you ask the same question 100 times and get "30 days" every time — does that make it factually correct? No. You have demonstrated consistency, not correctness. This matters enormously when you build evals.

Core Insight

The system that surrounds the LLM

This is why RAG, tools, validators and agent architectures exist. The LLM's internal contract is: produce a plausible next token. The contracts we need are different: be correct, be grounded, be safe, be cheap.

We are trying to harness a probabilistic generator while surrounding it with reliable software.
The LLM is one component. Not the whole system.

That is the core insight of AI engineering.

Grounding

RAG — why it exists and what it is

A user asks: "What is RahulStore's refund policy?"

Without grounding Model weights → learned patterns → "probably 30 days…"

With grounding Retrieve the real document → put it in context → generate from it

RAG = Retrieval-Augmented Generation

R — Retrieve relevant information
A — Augment the LLM's context with it
G — Generate an answer using that context

Common mistake

"We'll store it in RAG." RAG is not a database — RAG is a pattern. You might retrieve from SQL, Elasticsearch, a vector database, a knowledge graph or an API, then give that to the model.

What RAG does NOT do: it does not eliminate hallucination. Even with perfect retrieval, the model can still overlook a condition, combine two facts incorrectly, ignore an exception, or follow a prior learned pattern instead of the document.

Policy says: "Opened electronics cannot be returned." The user asks: "Can I return my opened laptop?" The model may still answer "Yes" because it is within the 14-day window. It overlooked the exception.

That is a reasoning failure, not a retrieval failure. You need to tell the difference. Correct retrieval ≠ correct answer.

Architecture

RAG vs Tools — when to use which

RAG Retrieve knowledge and information.

Tools Interact with systems, fetch live data, perform actions.

Now consider: "Can I return order #12345?" That requires both — the policy knowledge and the live order state.

Design rule

If you have two predictable dependencies, backend orchestration can handle it deterministically. Only use an LLM planner when there are many possible tool combinations and the sequence is truly dynamic. Don't use AI where application logic is sufficient.

Working Memory

Context windows

The context window is the maximum amount of text the model can process in one request.

The beginner mistake: "huge context window = send everything." No.

Ask a developer to find the race condition in a 20-line function — fine. Now hand them the entire Linux kernel plus your company's monorepo plus those 20 lines. The answer might technically be in there, but finding it is much harder. LLMs have the same problem.

More context has three real costs. Context engineering is not "send more." It is "send the right information."

Latency

Prefill, Decode and TTFT

Say you send 57,200 input tokens and need 300 output tokens in return. There are two distinct phases.

Phase 1 — Prefill

The model processes your entire input before it generates the first output token.

Phase 2 — Decode

Generating the output, one token at a time.

TTFT = Time To First Token

The time the user sits waiting before anything appears. A huge input dramatically increases TTFT because of prefill.

Critical point

Streaming does NOT reduce TTFT. If prefill takes 4 seconds, streaming does not change that. Streaming reduces the perceived latency of the decode phase — it does not speed up prefill.

Without streaming, the user waits for the whole answer. With streaming, the user sees output as it generates.

Debugging

How to debug a broken AI pipeline

Suppose your customer support agent answers correctly only 85% of the time.

Weak diagnosis "Our AI accuracy is 85%."

Strong diagnosis Break the pipeline into measurable stages, then you know exactly where to investigate.

Measure every stage

Retrieval recall
Context construction
Reasoning and answer accuracy
Validation and output

"Our RAG is bad" is not an engineering diagnosis. "Our retrieval recall is 96% but answer accuracy is 68%, so the failure is in reasoning or context construction" is an engineering diagnosis. You will build evals for every stage in Week 6.

Takeaways

What you know now

LLMs generate plausible tokens, not verified facts.
Tokens are the unit of cost, latency and context.
Temperature 0 makes errors repeatable, not truthful.
RAG grounds, but does not eliminate hallucination.
Backends validate; the model proposes.
Debug by stage, never by vibes.

This is the foundation everything else is built on.

Practice

Questions before Part 2

These are the kind of questions you will get in interviews. Work through them before the next part.

Q1 · Production hallucination

Your agent has 100% retrieval accuracy but 85% answer accuracy. Walk through every stage of the pipeline and identify where the failure might be. What would you measure first?

Q2 · Context cost calculation

Your support agent sends a 2,000-token system prompt + 5,000 tokens of tool definitions + 30,000 tokens of conversation history + 60,000 tokens of documents + a 200-token question = 97,200 tokens per request. At 10,000 requests per day and $0.003 per 1K input tokens, what is your daily input cost? What are the top 3 things you would cut first?

Q3 · Architecture decision

The user asks: "Can I return order #12345?" Design the full flow. What do you call, in what order, and why? What does the LLM receive? What does the backend validate?

Q4 · Temperature in production

Your teammate says: "Let's set temperature to 0 for our financial agent so it never hallucinates." How would you respond? What is the right architecture?

Q5 · TTFT problem

Your agent has a TTFT of 8 seconds, users are complaining, and the target is under 2 seconds. You have 57,200 input tokens. Walk through your investigation. What do you check first?

Part 2 is coming

Prompt & Context Engineering: system messages, user messages, tool messages, instruction hierarchy, context construction, dynamic prompts, prompt injection, context rot, compaction, handoffs and memory.

The stuff that determines whether your agent actually follows instructions in production — or does whatever it wants.

If this was useful

→ Repost it to share with every developer learning AI engineering

→ Follow @sairahul1 for Part 2 and the rest of the series

→ Bookmark it — the mental model at the end is the reference you will come back to

Generated by CuteNote.co Visual Notes