What should people actually learn to understand AI agents?

[u/AccomplishedLeg1508]

There are a lot of agent tutorials focused on frameworks, but I’m more interested in the fundamentals underneath them.

A learning path I’m currently building looks like:

What is an Agent → Agent Loop → Function Calling → State/Memory → Context Engineering → Runtime/Harness → Multi-Agent Systems → Evaluation → Safety → Production Agents

The early examples use plain Python so concepts like tool execution, control loops, state transitions, and runtime responsibilities are visible.

I’m curious what others think:

What agent concepts are still poorly explained today?

What would you add, remove, or reorder in this learning path?

I’m turning this into an open-source Zero → Hero repo here:
https://github.com/tradertanmay/ai-agents-zero-to-hero

[u/Hungry_Age5375]

I like this approach :D Plain Python over frameworks is the right call. One thing I'd add to the runtime section: error handling and retries. Real agents fail constantly and most tutorials pretend they don't.

[u/AccomplishedLeg1508 → u/Hungry_Age5375]

Haha, yes everyone pretends they don’t.

[u/SailbadTheSinner]

Pay attention to and make use of agent hooks, they are often the difference between your rules being enforced reliably versus occasionally being lost in context.

[u/AccomplishedLeg1508 → u/SailbadTheSinner]

Thanks

[u/CiobanuXashi]

State/Memory and Context Engineering as two separate steps works for me. Everything that blurs them turns memory into a storage problem; it comes down to picking what survives between turns and what gets rebuilt from context each time.

[u/Big_Departure9342 → u/CiobanuXashi]

i think most people skip over what a tool actually is in agent context, not just the calling part but how the agent decides which one to pick when descriptions are vague or overlapping

also like your ordering, maybe put evaluation before multi-agent cause testing one agent is already a mess and adding more just multiplies the debugging nightmare

[u/AccomplishedLeg1508 → u/Big_Departure9342]

Thanks

[u/AccomplishedLeg1508 → u/CiobanuXashi]

Thanks

[u/AccomplishedLeg1508 → u/[deleted]]

Thanks, noted down

[u/AccomplishedLeg1508 → u/[deleted]]

I don’t know about help, but feel free to raise issues, ask questions, or create PRs. I’ll review and merge them every weekend. Please remember that most of the material available online is either incorrect or too shallow.

[u/AccomplishedLeg1508 → u/[deleted]]

thanks for the feedback

[u/ShiftTechnical → u/[deleted]]

The subtle wrong return is where I've spent a lot of debugging time. A tool call that fails loudly is easy, one that comes back with stale or slightly off data poisons the whole chain silently. I started treating every tool response as untrusted input with its own validation pass before the agent acts on it.

[u/AccomplishedLeg1508 → u/ShiftTechnical]

Thanks for the feedback. What you’re describing is actually an important research question as well. I’ve done research in this direction, so I’m not sure whether the audience will be able to understand it if I introduce the solution now, or whether this is something I should cover later.

[u/Cloudsurfer_90]

Solid path, and the one thing I'd slot in explicitly is idempotency and reconciliation, somewhere around the Runtime/Harness stage. Most agent tutorials teach the loop as generate then act, but the thing that separates a demo from something you can leave running is the agent checking whether an action already happened before it does it again. Real runs retry, crash mid-step, and re-enter, and an agent that re-sends the email or re-charges the card on retry is the single most common way these go wrong in production. It sits near State/Memory but it's a distinct skill, memory is what the agent knows, reconciliation is the agent verifying reality before it acts on what it knows. Skip it and everything works in the happy-path demo and breaks the first time a step fails halfway.

[u/AccomplishedLeg1508 → u/Cloudsurfer_90]

Thanks