You've probably noticed it too when someone posts "we built an AI agent" and it turns out to be a chatbot with a search plugin…:) Someone else says the same phrase and means a system where five different AI processes negotiate with each other to close a supply chain gap. Same words, wildly different reality.

This isn’t just marketing spin. It’s a symptom of a real gap that most of the AI conversation right now skips the middle. You either get the toddler version (”agents are like little helpers!”) or the engineering-whitepaper version which are dense with jargon that assumes you already know what “grounding” or “tool orchestration” means. Almost nothing sits in between and just tells you: here’s where things actually stand, and here’s where you actually stand.

The result is that “agentic AI” has become one of those terms everyone nods along to in meetings without anyone quite agreeing on what it means. That’s a problem because it makes it nearly impossible to evaluate a claim, compare two products or even know what to learn next. If you can’t tell the difference between a system that fetches documents and one that autonomously plans and negotiates, you can’t tell whether a claim is impressive or inflated.

That’s what this post is for. Not another definition of “AI agent”, but a map you can place yourself on.

Your Customers Are One Text Away

^{You already know email gets buried and calls go unanswered. But texts? They get read — 98% of the time, within minutes. That’s why 230,000+ businesses use EZ Texting to reach their customers on the channel they engage with most Whether you’re sending promos, appointment reminders, or urgent alerts, EZ Texting makes it easy to send to 10 or 10,000 contacts in just a few clicks. No tech skills required. [Newsletter Name] readers can try it free — no credit card needed.}

Start Your Free Trial with EZTexting

^{* Offer valid for new customers only. Use promo code EZWORKFLOW at checkout.}

^{❤️ The best way to keep our mission going - at zero cost to you - is by checking out this free guide from our sponsor}.

A Framework to Locate Yourself, Not Define a Buzzword

Rather than a glossary, think of this as a ladder with seven rungs. Each rung represents a real jump in capability not just a fancier name for the same thing. The framework below is adapted from a maturity model laid out in Agentic Architectural Patterns for Building Multi-Agent Systems, a technical book on how production-grade AI agent systems actually get engineered. The value of a model like this is that it forces precision which means instead of “we use AI agents,” you can say “we’re at stage 3,” and that phrase actually means something specific.

The honest purpose here isn’t to make you feel behind. It’s to give you a way to cut through the noise the next time you read a headline or a LinkedIn post claiming some agentic breakthrough, you’ll have a lens to ask, “okay, but which stage is this really?”

Stages 0–4: The Groundwork Before "Agent" Even Applies

Most of the work that makes “AI agents” successful happens before the agent even exists. These five stages aren’t exciting or talked about much, but they are where most real-world projects get stuck.

Stage 0 → Getting your data agent-ready

Before any model touches your problem, someone has to acquire, clean and structure the data it will lean on. No AI system, agentic or otherwise, outruns the quality of what it's fed. You're here if your AI project keeps getting delayed by "we need to clean this up first" conversations.

Stage 1 → Prompting and basic tool use

This is picking a foundation model, writing prompts that reliably get what you want out of it and maybe letting it call a basic tool or API. You're here if your "AI system" is, functionally, a well-crafted prompt with some plumbing around it.

Stage 2 → Giving the model outside knowledge (RAG)

Retrieval-Augmented Generation is the fix for the model's biggest weakness: it only knows what it was trained on and that's frozen in time. RAG lets it pull in your actual documents, your actual policies, your actual product catalog before answering. You're here if your chatbot suddenly got good at citing internal docs it was never trained on.

Stage 3 → Fine-tuning: teaching the model your accent

RAG gives a model knowledge it didn't have. Fine-tuning changes how it talks, like its tone, its domain vocabulary, its instincts for your specific field. This is a deeper, more expensive intervention and it's often confused with RAG even though they solve different problems. You're here if you've trained a model on your own data so it stops sounding like a generic assistant and starts sounding like it works at your company.

Stage 4 → Grounding and evaluation: the trust layer nobody markets

This is the stage that separates a demo from something you'd actually put in front of customers: making sure outputs are traceable to real sources, and building evaluation systems that continuously check for accuracy, bias and safety. It's invisible when done right and catastrophic when skipped. You're here if you've started asking "how do we actually know when this is wrong?"

None of these stages involve an agent making autonomous decisions yet. That's important because a huge share of what gets branded "agentic AI" online is really one of these five stages with better packaging.

Let’s get to stage 5…

Set it, forget it, and save for your goals

^{Make saving automatic with Cash App. Round up your spare change from every purchase, earn up to 3.25% interest, and transfer money between your balances whenever you want—all with no hidden fees or minimum balance requirements.}

^{Make unlimited transfers between your Cash and Savings balances Keep your money safe with 24/7 fraud monitoring and built-in security features}

^{Saving is easier with Cash App}

Start saving with Cash App

^{* Cash App is a financial services platform, not a bank. Banking services provided by Cash App’s bank partner(s). Prepaid debit cards issued by Sutton Bank, Member FDIC. See Terms & Conditions. Eligibility restrictions apply to some benefits. See Terms and Conditions for more information.}

Stage 5: What Having an "AI Agent" Actually Means

This is where the word “agent” starts to earn its keep. A single-agent system isn’t just a model that responds to you, it’s one that can reason across multiple steps, decide which tools to use and when and carry out a goal with a meaningful degree of autonomy without a human manually chaining each step together.

Think of the difference between a model that answers “what’s the weather in Lisbon?” and one that’s told “book me a trip to Lisbon next weekend” and then actually checks flight prices, compares hotel options, and makes the booking, adjusting its plan as it goes if a flight is sold out. That shift from responding to pursuing a goal across multiple decisions is what Stage 5 actually is.

a lot of what gets called an “AI agent” in casual conversation is really a Stage 1 or Stage 2 system with a more autonomous-sounding name (which kinda bugs me a lot tbh).

True single-agent maturity requires real infrastructure behind it, monitoring what the agent is doing, logging its decisions and managing its lifecycle so it doesn’t quietly go off the rails. Without that scaffolding you don’t have an agent; you have a script that sometimes works.

Stage 6: When Agents Negotiate, Divide Work and Correct Each Other

This is what’s really happening, and it’s better to describe it clearly instead of just calling it “multiple AIs working together.”

At this stage several specialized agents operate at once, each handling a different slice of a problem, coordinating so their work fits together rather than colliding. A “meta-agent” often sits above the others, reassigning tasks in real time as conditions change, closer to a project manager reshuffling a team’s workload mid-sprint than to a single model doing more work.

The most advanced version of this stage involves agents that critique and correct each other’s outputs in ongoing feedback loops, one agent proposes an answer, another checks it, a third refines it, and the system improves iteratively without a human intervening at each step. Picture a supply chain system where a forecasting agent flags a demand spike, a logistics agent recalculates routing, and an inventory agent adjusts orders, each acting independently but staying coordinated toward the same outcome. This is genuinely difficult to build well: it requires handling disagreements between agents, allocating resources without conflicts and keeping the whole system auditable enough that a human can still understand why a decision was made. The book goes considerably deeper here, walking through the actual coordination patterns that make this stage possible instead of just decorative.

The Reality Check: Where Most Teams Actually Stand

Here’s the part worth sitting with. Despite how often “agentic AI” comes up in company announcements and product launches, the large majority of real deployments live at Stage 2 or Stage 3. Solid RAG. Maybe some fine-tuning. Useful, often genuinely valuable but a long way from Stage 5, let alone Stage 6!

That’s not a criticism. Stages 0 through 4 are hard and skipping them to chase “agentic” branding is exactly how systems become unreliable in ways that erode trust fast. A shaky data foundation or a missing evaluation layer will sink a flashy multi-agent pitch just as fast as a simple chatbot, arguably faster, because there’s more surface area for things to go wrong. But it does mean that when you read confident claims about multi-agent systems running the show, it’s worth a healthy dose of skepticism about which stage is actually being described, and whether the groundwork underneath it is as solid as the pitch suggests.

How to Use This Map Next Time You Hear "We Built an AI Agent"

The next time that phrase comes up, in a pitch, a headline, a coworker’s excited Slack message, you now have a genuine framework to ask a sharper question than “how does it work?” You can ask: which stage is this? Is it pulling in outside knowledge, or actually making autonomous, multi-step decisions? Is there one agent, or several coordinating?

That single question will filter out a surprising amount of noise. And if you find yourself wanting to go further, not just identifying stages but understanding the actual engineering patterns that let systems climb from one to the next (how agents avoid getting stuck, how they recover from failure, how multiple agents resolve disagreements without a human refereeing every step) that’s the deeper territory Agentic Architectural Patterns for Building Multi-Agent Systems is built to cover. This post gave you the map. The book is where you’d go to actually learn to build what’s on it.

An Exciting Update For Our Readers!

You asked, we listened! 💛

Tickets were sold out but due to the overwhelming demand, we’ve opened a limited number of additional spots for our upcoming AI Agents Simplified Live event.

Grab yours before they’re gone! See you soon.

Get Your Free Ticket

​To tackle this head-on, I am absolutely thrilled to invite you to the premiere episode of our newly launched live event series from AI Agents Simplified!

​For our kickoff event, we’re sitting down with Rob Zuber, CTO of CircleCI, for an exclusive live Q&A on Scaling CI/CD for the Machine-Generated Code Era

​We’ll be talking about the exact tactics engineering leaders are using to handle the massive surge in AI-generated pull requests, set machine-enforceable quality bars, and stop flaky tests from slowing down delivery.

​We are bringing together top minds in AI, tech, and DevOps for this launch, and I’d love for you to be in the virtual room with us.

Grab your FREE spot here 👉

​Looking forward to seeing you there!
​Best,
Mina
Founder, AI Agents Simplified

This issue is brought to you by CircleCI

If you’re anything like me, you’ve probably opened ten browser tabs trying to learn AI, only to close all of them an hour later feeling more confused than when you started. There’s no shortage of tutorials out there, the problem is figuring out which ones are actually worth your time.

I’ve spent quite a lot of time during the last few years bouncing between courses, GitHub repos, and half-finished side projects and I’ve landed on a shortlist of resources I keep coming back to. These aren’t flashy paid courses or four-hour YouTube crash courses. They’re free, well-maintained repositories that people who actually know what they’re doing put together and they cover everything from “I’ve never written a line of Python” to “I want to build a production AI agent.”

Here’s my personal list along with some honest thoughts on who each one is really for.

1. Start With the Basics: Python - 100 Days

If you're brand new to programming, don't skip this step no matter how tempting it is to jump straight into AI. This repo walks you through Python fundamentals over a hundred days, gradually moving into things like data analysis and web development. It's a slow burn but that's kind of the point. It helps you build a real foundation instead of memorizing code you don't understand.

My advice

you don’t need to do all 100 days before moving on. Once you’re comfortable writing basic scripts and understand how functions and data structures work, you’re ready to move forward.

2. Get the Big Picture: Generative AI for Beginners

This one from Microsoft, is a genuinely solid starting point if you want to understand what generative AI actually is before you start building anything. It covers the basics of how large language models work, how to write effective prompts, what retrieval-augmented generation (RAG) means, a first look at AI agents, and even some fine-tuning concepts.

Think of this as your orientation course. It won’t make you an expert, but it’ll make sure you’re not lost when people start throwing around terms like “RAG” or “fine-tuning” in conversation.

Unmissable Event of Augest^*

This is our very first AI Agents Simplified event, marking the start of a new ongoing series. We’re always looking for industry experts to feature, so please reply with ‘Speaker‘ if you’d like to apply for a future session.

Join us online to learn how to optimize your CI/CD pipelines for auto-generated code. We’ll explore practical strategies, new tools, and real-world tips to keep your development cycles smooth and efficient. Perfect for teams ready to improve their automation processes.

Get Your FREE Ticket 👉

3. See What's Really Going On: LLMs From Scratch

This is one of my personal favorites, and it's for people who want to go a level deeper. Instead of just using a large language model, you actually build one piece by piece. You'll work through tokenization, embeddings, attention, transformers, and training, ending up with a real understanding of what's happening under the hood.

Fair warning!

this isn't a weekend project. It's for people who genuinely want to understand the mechanics rather than just use the tools. If that's you, it's one of the best resources I've come across.

4. Build Your ML Foundation: Machine Learning for Beginners

Before you dive headfirst into LLMs, it helps to understand classical machine learning , the concepts that everything else is built on. This is a structured, 12-week curriculum with 26 lessons that walks you through those fundamentals in a logical order.

If you’ve ever felt like you jumped straight to the “advanced” stuff without understanding the basics, this is a good way to backfill that knowledge

Become the go-to AI expert in 30 days with Superhuman AI

^{AI keeps coming up at work, but you still don't get it?
That's exactly why 1M+ professionals working at Google, Meta, and OpenAI read the Superhuman AI newsletter daily.
Here's what you get:}

• ^{Daily AI news that matters for your career – Filtered from 1000s of sources so you know what affects your industry.}

• ^{Step-by-step tutorials you can use immediately – Real prompts and workflows that solve actual business problems.}

• ^{New AI tools tested and reviewed – We try everything to deliver tools that drive real results.}

• ^{All in just 3 minutes a day}

Join 1M+ pros who read Superhuman AI

5. Move From Learning to Building: OpenAI Cookbook

At some point, you have to stop reading and start building. This is where the OpenAI Cookbook comes in. It’s a collection of practical, real-world examples for building applications using OpenAI’s models. Instead of theory, you get working code you can learn from and adapt.

I’d treat this less like a course and more like a reference you keep open in a tab while you’re actually building something.

6. Explore the Visual Side: Stable Diffusion

Not everyone in AI is working with text. If image generation interests you, this is the original repository behind Stable Diffusion, straight from the researchers who built it. It’s more technical than a beginner tutorial, so I’d recommend having some machine learning basics under your belt before diving in.

7. Learn to Build Agents: AI Agents for Beginners

AI agents are having a real moment right now, and for good reason, they’re what turn a chatbot into something that can actually take action. This course covers the core ideas behind agentic AI, RAG, popular agent frameworks, tool use, and even multi-agent systems, where several agents work together.

If you’ve already got a handle on the basics from resource #2, this is a natural next step.

8. Round Out Your Foundation: AI for Beginners

This is another structured Microsoft curriculum, 12 weeks and 24 lessons, but broader in scope than the ML-focused one above. It touches on neural networks, computer vision, natural language processing, deep learning, and even some classical AI concepts. It's a good option if you want one comprehensive resource that ties everything together rather than piecing it together from multiple sources.

9. Build Real Applications: LLM App

Once you're past the learning stage and want to build something that could actually run in production, this repo is worth a look. It focuses on practical LLM applications: RAG pipelines, enterprise search, real-time data handling, and vector search. It's less about learning concepts and more about seeing how those concepts come together into something usable.

10. Dive Into Computer Vision: Segment Anything

Last but not least, if computer vision is your thing, this is Meta’s foundation model for image segmentation, essentially, teaching a model to identify and separate objects within an image based on a prompt. It’s a great one to explore if you’re interested in the intersection of vision and multimodal AI.

So Where Should You Actually Start?

Here’s the honest truth: you don’t need all ten of these. Bookmarking every resource on this list and never opening any of them isn’t going to teach you anything. My advice is to figure out where you currently are and pick just one:

• New to programming? Start with Python - 100 Days.

• Want ML fundamentals first? Go with ML for Beginners.

• Want the big picture on AI? Try AI for Beginners.

• Curious how LLMs actually work? Dig into LLMs from Scratch.

• Want to understand generative AI specifically? Generative AI for Beginners is your best bet.

• Interested in agents? AI Agents for Beginners will get you there.

• Ready to build something real? The OpenAI Cookbook or LLM App will get your hands dirty.

• More into images than text? Segment Anything is worth your time.

Pick the one resource that matches where you are right now. Work through it. Build something small with what you learned, even if it’s rough around the edges. Then, and only then, move on to the next one.

AI engineering isn’t something you learn by collecting resources, it’s something you learn by using them. So do yourself a favor: close nine of these tabs, keep one open, and get started.

Let’s Collaborate

Hey there, I’m Hana, co-founder and technical writer at AI Agents Simplified. If you’re building in the AI space, have feedback on today’s post, or want to explore a collaboration, let’s chat! You can find me on LinkedIn or drop me an email. I read every message and would love to hear from you.

What's in this issue:

• What changed. AI-referred visits went from worth 84% less to worth 53% more in nineteen months. Break-even was October 2025.

• How AI assistants read a page. They don’t scroll, hover, or wait for JavaScript. That single constraint decides everything below.

• Which content survives and which vanishes. Two rules, both about structure rather than copy, both measurable.

• How to test your own site. One curl command and three questions, in about 20 minutes. Most people don’t like their first result.

• What that test can’t show you. which prompts your category gets asked, whether you appear, and who appears instead.

• Why this applies outside retail. to documentation, pricing pages, and API references just as much as product pages.

Something inverted over the last twelve months, and most engineering teams missed it because it first showed up in a marketing dashboard.

Traffic that arrives at a US retail site from an AI assistant now converts 54% better than traffic from everything else, like search, social, email, paid, all of it combined. It generates 53% more revenue per visit. It bounces 36% less and sticks around 53% longer. Twelve months earlier, the same channel converted at roughly half the rate of ordinary traffic and non-AI visits were worth 128% more!

That’s Adobe’s Q3 2026 AI Traffic Trends Report, built on Adobe Analytics data covering more than a trillion visits to US retail sites, plus a March 2026 survey of over 5,000 US consumers.

The volume story is loud too, AI-referred visits up 138% YoY to retail sites in May 2026, 194% to travel, 105% to financial services. But volume was never the surprising part. Everyone saw the volume coming. The surprising part is that the traffic is good and getting better while the rest flattens.

Here’s where it stops being a marketing story.

How AI Assistants Actually Read Your Website

When someone asks ChatGPT or Perplexity “what’s a good waterproof running shoe under $150” a machine goes and reads pages on your behalf. It doesn’t scroll or hover. It doesn’t wait for your carousel. It pulls text, tries to parse it into something it can reason over and either uses it or drops it.

So the question that actually matters isn’t “how do we rank.” It’s the same question you’d ask about any client integration: when this thing hits my page, does it get back something usable?

Adobe’s research team built a metric for exactly that and it’s the most interesting thing in the report. They call it the Citation Readability Score, a measure of how much of a page’s content is genuinely visible and parseable to an AI system, and therefore how likely that page is to get cited in a generated answer:

• Structured, complete, context-rich content scores high

• Sparse, poorly organized, or missing content scores low

Think of it as a lint score for machine consumption. Same page, two audiences:

1. A human who can infer from a photo and a layout

2. A model that can only work with what came back in the text

Structured Text Gets cited. Images And Layout Don't!

The aggregate numbers are fine. The breakdown by page type is the part I'd actually write on a whiteboard.

Grocery beats Apparel by 20 points on the same page type. Not because grocery sites are better engineered, because a nutrition panel is structured text and a lookbook is a JPEG. Ingredient lists, gear specs, and dimensions survive the trip to a language model. Visual merchandising doesn't.

Why Dynamic Pages Disappear From AI Answers

Travel is where the pattern becomes impossible to miss because the same brands publish both kinds of pages.

One rule falls out of the data on its own:

AI readability collapses exactly where your app gets dynamic.

Anything static, descriptive and complete reads well. Anything that depends on user input, live availability, session state, personalization or a click to render, a fare search, a filtered result set, a spec table behind a tab, is close to invisible. An airline’s booking engine is a genuinely impressive piece of software and it scores 24% because there’s nothing there until you tell it where you want to go.

There’s a fourth signal that ties it together. Adobe compared the top 20% of companies by AI visit share against the bottom, and measured missing words, content gaps on the page. Top performers had 53% fewer on homepages, 38% fewer on brand landing pages, 28% fewer on editorial content. The gap between winning and losing here isn’t clever schema markup. It’s whether the words are on the page at all.

How to Test Whether AI Can Read Your Site

You don't need a platform to find out where you stand. You need to see your page the way an agent sees it, no JavaScript, no session and no scroll.

Pick your most commercially important page and pull the raw response:
curl -sL -A "Mozilla/5.0" https://yoursite.com/your-key-page \
| python3 -c "
import sys, re, html
t = sys.stdin.read()
t = re.sub(r'<(script|style|nav|footer)[^>]*>.*?</\1>', ' ', t, flags=re.S|re.I)
t = re.sub(r'<[^>]+>', ' ', t)
print(html.unescape(re.sub(r'\s+', ' ', t)).strip()[:8000])

Take whatever comes out, hand it to any model, and ask three questions:

1. What does this product or service actually do and who is it for?

2. What are its concrete specs, terms, price, or constraints?

3. Why would someone pick this over a competitor?

If the model hedges, guesses or asks you for the page, an AI assistant reading it in the wild will do the same thing and it’ll cite whoever answered those three questions more clearly. Usually a review site or a competitor.

Two things people find on their first run. The first is that a client-rendered page returns almost nothing; the interesting text never made it into the HTML. The second is subtler and more common because everything renders fine but the actual answers live in an image, a spec PDF or a tabbed panel and the extracted text is navigation and legal boilerplate.

That’s a five-minute diagnostic on one page. Which is exactly where it stops being useful.

Why A One-Age Test Isn't Enough to Track AI Visibility

The curl test tells you whether a page is readable. It tells you nothing about the questions that decide whether you get cited:

• which prompts your category actually gets asked

• whether you show up in the answer

• who shows up instead

• whether last month’s fix moved anything

That’s the gap Adobe Brand Visibility is built for, launched June 17, 2026. It pairs Semrush’s AI search intelligence, Adobe completed the Semrush acquisition in April 2026, with Adobe’s own content optimization tooling. The practical shape of it is a corpus of roughly 300 million real-world AI search prompts. It includes mention frequency, competitive share of voice across ChatGPT, Google AI Mode, Microsoft Copilot, and Perplexity, along with content-gap recommendations you can deploy and measure against actual pipeline through Adobe Analytics. It runs standalone or natively inside Adobe Experience Manager.

The part I find architecturally interesting is that it closes the loop. Most AI-visibility tools on the market are monitoring dashboards, they tell you your score dropped and leave you to guess why. Brand Visibility connects the prompt data to the specific pages that need to change and then back to revenue, which is the only version of this that survives a budget review.

The Same Rules Apply To Your Docs, Pricing, And API Reference

Strip out the retail framing and the finding holds for anything you’re building.

Your documentation, your pricing page, your API reference, your changelog, these are now read primarily by machines acting for users. The rendering pipeline you built for humans is a lossy channel for that reader. Everything you moved out of the HTML for performance, everything you put behind an interaction for cleanliness, and everything you expressed as a diagram instead of a sentence effectively doesn’t exist from an agent’s perspective.

The cheapest fix is also the least glamorous one. Put the answer in the text. Server-render the part that matters. Say the spec instead of showing it.

Next Step

In out next issue, we're going hands-on, building a small citation-readability checker you can point at a whole sitemap, scoring pages against the same page-type categories Adobe uses, and walking through what Brand Visibility surfaces that a local script can't. If there's something specific you want covered in that one, reply and tell me.

Unmissable Event of Augest

This is our very first AI Agents Simplified event, marking the start of a new ongoing series. We’re always looking for industry experts to feature, so please reply with ‘Speaker‘ if you’d like to apply for a future session.

Join us online to learn how to optimize your CI/CD pipelines for auto-generated code. We’ll explore practical strategies, new tools, and real-world tips to keep your development cycles smooth and efficient. Perfect for teams ready to improve their automation processes.

Get You FREE Ticket

Let’s Collaborate

Hey there, I’m Hana, co-founder and technical writer at AI Agents Simplified. If you’re building in the AI space, have feedback on today’s post, or want to explore a collaboration, let’s chat! You can find me on LinkedIn or drop me an email. I read every message and would love to hear from you.

References

• Adobe, Introducing Adobe Brand Visibility (June 17, 2026)

• Adobe, Adobe Completes Semrush Acquisition (April 28, 2026)

• Adobe, AI traffic grows but retail sites lag in AI search visibility

• TechCrunch, AI traffic to US retailers rose 393% in Q1 (April 16, 2026) — prior-quarter baseline

• Adobe, CX Enterprise Coworker (April 2026)

This issue is brought to you by CircleCI

I had a marketing idea in my head that I wanted to test. The process sounded simple enough: find the right companies, send them an email, follow up if they didn’t respond, and stop if they did.

I could have handled it manually, at least in the beginning, but I knew that approach wouldn’t scale very far. The other option was paying for another outreach platform every month, and I didn’t really want to do that for something that felt specific enough to build myself. So I opened n8n and started putting the workflow together.

What surprised me was how quickly a simple idea became a much bigger system. The first version had seven nodes. After using it, finding the weak points, and adding what I actually needed, it ended up with fourteen.

The First Version Was Pretty Simple

The first workflow did only the essentials. It ran on a schedule, pulled the contacts that needed an email from PostgreSQL, processed them, and decided whether it should send a new email or reply to an existing thread. After sending, it updated the database so the same contact wouldn’t be treated as new again.

In my head, the whole thing was basically:

Find contact
↓
Decide what to send
↓
Send email
↓
Update database

And at first, that was enough. I wasn’t trying to build some highly autonomous agent. I just wanted to remove a repetitive piece of work and make sure the workflow could run without me sitting there and doing every step manually.

The problems started once I thought about what would happen after the first few emails went out.

Then the Real Questions Started Appearing

The first thing I kept coming back to was replies. What if somebody answered the first email before the next follow-up was scheduled? If the workflow didn’t know about that reply, it would happily send another automated message anyway.

Then there were other details. A follow-up should stay in the same email thread. Some contacts should be handled before others. The system had to remember which stage each person was in, and eventually I also wanted the message itself to change depending on the company I was contacting.

None of those things felt like a big feature on its own, but every one added another piece to the workflow. Eventually the seven-node version became the fourteen-node version I’m using now.

One of the biggest changes is actually at the beginning. The system now checks recent replies before it starts sending anything. It extracts the sender information, tries to match the reply to a contact in the campaign, updates that contact if necessary, and only then continues with outbound emails.

That made the workflow feel very different. It wasn’t only executing a sequence anymore. It was checking what had happened since the last run and using that information before deciding what to do next.

Open Positions^*

If you are learning AI systems, MLOps, LLMs, or agentic workflows, these roles cover a strong mix of real production use cases.

Role: AI Engineer

Company: Booz Allen Hamilton

Location: San Antonio, Texas, US

Strong fit for people interested in ML, DevOps, CI/CD, cloud tooling, and AI agents applied to cyber infrastructure.

Apply Here ➡️

Role: Machine Learning Engineer

Company: ExaCare AI

Location: New York, US

Covers the full ML lifecycle, including LLM fine-tuning, RAG, experiment tracking, and model optimization.

Apply Here ➡️

Role: Machine Learning Engineer

Company: Aionia Group

Location: Mountain View, California, US

Focused on autonomous AI agents, RAG systems, ML infrastructure, and customer-facing AI applications.

Apply Here ➡️

The Database Ended Up Being More Important Than I Expected

When I started building this, I thought sending the emails would be the main part of the work. It wasn’t. Sending an email is relatively straightforward; remembering the history around that email is where things get more interesting.

The workflow has to know whether a contact has already received something, which follow-up should come next, when the previous message was sent, whether that person has replied, and whether the campaign should continue at all.

That’s when PostgreSQL stopped feeling like a place where I was simply storing a list of contacts. It became the part of the system that gave every new execution some memory of what had happened before.

Without that state, the automation would basically wake up every day with no idea what it had done yesterday.

Where I Decided to Use AI

The latest version also has an LLM inside the workflow, but I didn’t want to put AI everywhere just because I could.

There are parts of this system where I want exactly the same behavior every time. Checking campaign status, matching replies, deciding whether a message should be sent as a new email or as a reply, and updating the database are all much easier to trust when they’re handled with normal logic.

The part where AI made sense to me was the message itself. If I already have information about the company, its industry, and the person I’m contacting, an LLM can use that context to create something much more specific than the same template with a first name swapped in.

Building it this way gave me a rule that I’ve started using in other automations too: use normal software when the result needs to be predictable, and use AI where some variation is actually useful.

For me, that feels much more practical than trying to make the entire workflow “AI-powered.”

Looking at the Two Versions Side by Side

When I look at the first screenshot and the current one, the obvious difference is that the workflow got bigger. But the more interesting difference is where that complexity went.

The AI model itself is only one part of it. Most of the additional work is reply detection, campaign state, database queries, branching, thread handling, and making sure the workflow knows enough about what happened previously to make the next decision correctly.

That was probably the biggest lesson for me while building this. The model can make one part of the system smarter, but most of what makes the overall workflow useful comes from everything around the model.

The AI writes the message. The rest of the system makes sure that message is being written for the right person, at the right time, for the right reason.

Unmissable Event of Augest^*

This is our very first AI Agents Simplified event, marking the start of a new ongoing series. We’re always looking for industry experts to feature, so please reply with 'Speaker' if you'd like to apply for a future session.

Join us online to learn how to optimize your CI/CD pipelines for auto-generated code. We’ll explore practical strategies, new tools, and real-world tips to keep your development cycles smooth and efficient. Perfect for teams ready to improve their automation processes.

Get Your FREE Ticket 👉

My Take

What I like about this project isn’t really the fact that I automated outreach. There are already plenty of products that do that, and probably with far more features than I need.

What I found interesting was being able to take a fairly specific idea in my head and gradually turn it into software without starting a traditional software project. I could build a rough first version, run it, notice what was missing, change the logic, add another piece, and keep going.

The first version didn’t need to be impressive. It only needed to solve the first problem. The rest of the architecture appeared because I actually used it and started running into situations I hadn’t considered at the beginning.

I think that’s one of the bigger changes happening around AI and automation right now. A lot of small internal tools that would have felt too expensive or too annoying to build a few years ago are becoming realistic projects for one person.

For me, that might be more interesting than the idea of AI simply making existing software smarter. It’s making it possible to build software for problems that previously weren’t worth building software for.

This issue is brought to you by HubSpot

If you've finished Titanic and House Prices and you're looking for something with real impact, the Rossmann Store Sales competition is where I'd send you next. There’s no images text, or GPU required. Just a wide table of dates and store attributes, and a problem that turns out to be much sharper than it looks.

Rossmann is the second largest drugstore chain in Germany. Back in 2015 they put a question to Kaggle that their store managers were already answering by hand every month: what will daily sales look like six weeks from now? Managers were forecasting on gut feel and local knowledge and the quality of those forecasts varied enormously from one store to the next. That variation costs money because staffing rotas and stock orders get built on top of those numbers.

By the end of this post you’ll have a submission file, two working models and a decent sense of why certain choices matter here and others don’t.

Go from AI overwhelmed to AI savvy professional with Superhuman AI

^{AI will eliminate 300 million jobs in the next 5 years.}

^{Yours doesn't have to be one of them.}

^{Here's how to future-proof your career:}

• ^{Join the Superhuman AI newsletter – read by 1M+ professionals working at Google, Meta, and OpenAI}

• ^{Learn AI tools, tutorials and news in just 3 minutes a day}

• ^{Become the go-to AI expert on your team}

^{Start learning AI now and join Superhuman AI!}

Join Superhuman AI 👉

The Metric Is The Whole Game

Most tutorials mention the metric and move on. Don’t skip this part because everything downstream follows from it.

Rossmann scored submissions on Root Mean Square Percentage Error. For every store-day you take the error, divide it by the actual sales figure, square that, average across all rows, and take the square root.

The division is the interesting bit. A miss of 50 euros on a day when the store took 500 euros counts ten times as heavily as the same 50 euro miss on a 5,000 euro day. So the quiet little stores in small towns carry far more weight in your score than the big performers, even though they contribute almost nothing to Rossmann’s revenue. If you optimise for plain squared error, you’ll build a model that pours all its effort into getting the busy stores right and gets punished for it.

Two more properties worth knowing. The error is asymmetric! predicting 800 when the truth is 1,000 gives you a percentage error of 0.20, while predicting 1,200 gives you 0.20 as well, but push further and the asymmetry shows. Predict 100 against a truth of 1,000 and you get 0.90, the worst possible outcome. Predict 1,900 and you get 0.90 too but you had to be off by nine times as much in absolute terms to earn it. Under-prediction is cheaper to get wrong in absolute euros, which nudges models toward guessing high.

And the rule that matters most practically:

any store-day with zero sales is thrown out of the scoring entirely.

Closed Sundays, public holidays, refurbishment periods. None of them count. Which means you can predict whatever you like on those days and it won’t touch your score and you shouldn’t waste any model capacity learning them.

Here’s the metric in code, plus the versions the two libraries need:

Notice the expm1 calls. We're going to train on the logarithm of sales rather than sales themselves, and it’s because squared error on a log scale is roughly proportional error on the original scale. Taking the log turns the metric we're stuck with into the metric the models optimise natively. It's a one-line change that buys you a lot.

Getting The Data In

There are three files. train.csv has the daily sales history, test.csv has the rows you need to predict, and store.csv has one row per store describing what kind of shop it is.

That dtype argument helps you avoid confusion. The StateHoliday column mixes the integer 0 with the strings '0', 'a', 'b' and 'c', so pandas will happily read the same column as two different types in the two files and then refuse to line them up later.

The daily columns are straightforward: Store, DayOfWeek, Date, Sales, Customers, Open, Promo, StateHoliday, SchoolHoliday. The store metadata is where the interesting stuff hides:

• StoreType and Assortment, both unlabelled categories (a, b, c, d) telling you the format of the shop and the range of products it carries.

• CompetitionDistance, in metres to the nearest competing store, plus the month and year that competitor opened.

• Promo2, a longer-running promotion some stores joined, with the week and year they signed up and a PromoInterval string listing which months it runs in.

Two things about test.csv to note now. It has an Id column that your submission has to preserve. And it does not have a Customers column, which is going to matter more than you’d expect.

Turn AI into Your Income Engine

^{Ready to transform artificial intelligence from a buzzword into your personal revenue generator? Our groundbreaking guide "200+ AI-Powered Income Ideas" is your gateway to financial innovation in the digital age.}

^{Inside you'll discover:}

• ^{A curated collection of 200+ profitable opportunities spanning content creation, e-commerce, gaming, and emerging digital markets—each vetted for real-world potential}

• ^{Step-by-step implementation guides designed for beginners, making AI accessible regardless of your technical background}

• ^{Cutting-edge strategies aligned with current market trends, ensuring your ventures stay ahead of the curve}

^{Download your guide today and unlock a future where artificial intelligence powers your success.}

^{Your next income stream is waiting.}

Get Your Guide 👉

Looking At The Data Before Touching a Model

Rather than going through dozens of charts, I'll focus on four plots that changed how I built this and what each one taught me.

1.Sales distribution

There’s an enormous spike at exactly zero, roughly 17% of all rows. Cross-reference with Open and it’s obvious: those are closed days. Sunday closures mostly, plus holidays.

2.Sales by day of week

Monday is the busiest day by a clear margin, then it slopes downward through the week. Sunday is near-empty because most stores are shut, but a small group of stores does open on Sundays, and those stores behave differently enough that a model needs the store identity to make sense of them.

3. Sales by promo flag

A promotion lifts a typical day by somewhere in the region of 20 to 30%. Plot promo over time for a single store and you’ll see it running every other week in a regular cycle. That two-week rhythm is real and the model will pick up on it.

4. Sales over the full time span

Most stores are remarkably flat. There’s a hard December spike and a matching January lull, but very few stores show a strong multi-year trend. That’s useful, because it means we can lean on per-store historical averages without worrying much about them going stale.

Then there’s the plot that looks like great news and isn’t. Sales against Customers is almost a straight line, correlation around 0.82. Which stands to reason. More people through the door, more money in the till.

Three Hidden Traps!

These are the ones I want you to see coming, because each of them will quietly cost you and none of them throws an error.

The Customers Column Is Unusable

It’s the single strongest predictor in the training set and it does not exist in the test set. You’ll never know how many people walked into store 431 on 3 September 2015, because that’s the same unknown future you’re trying to forecast. Feed it to a model and your validation score will look wonderful right up until you try to predict on the test rows and discover you don’t have the column.

You can’t use it directly but you don’t have to throw it away either. Historical customer levels per store are a legitimate feature since they describe the store rather than the day:

180 Stores Are Missing Half a Year

Count the rows per store and you'll find two clusters:

A complete history is 942 days. But 180 stores only have 758, and the 184 missing days are all of July through December 2014. Rossmann never explained the gap in the data itself; the working theory on the forums at the time was refurbishment.

This is nasty precisely because it’s invisible. Any per-store average you compute is silently built from a different time window for those 180 stores, one that happens to exclude the entire Christmas period. If you’re computing seasonal features, you now have 180 stores whose December behaviour you’ve never observed. At minimum, know which stores they are.

Random Splits Lie to You About Time Series

The reflex is train_test_split(X, y, test_size=0.2). Please don’t, not here!

A random split scatters your validation rows throughout the same 31 months as your training rows. So for almost every validation row, the model has already seen the days immediately either side of it. Predicting Wednesday when you’ve been shown Tuesday and Thursday is a much easier exercise than the one Kaggle actually set, which is predicting six weeks with nothing in between to anchor you.

Build a holdout that copies the real task instead. The last six weeks of training data, held back:

The score you get from this will be worse than the score from a random split. It will also be roughly true, which is the entire point. Every decision from here gets judged against this holdout.

Building Features

First, cut the rows we don't need:

….

Let’s Collaborate

Hey there, I’m Hana, co-founder and technical writer at AI Agents Simplified. If you’re building in the AI space, have feedback on today’s post, or want to explore a collaboration, let’s chat! You can find me on LinkedIn or drop me an email. I read every message and would love to hear from you.

Welcome back to the Agentic Reading Roadmap. Same deal as always: dense technical books are worth reading, but almost nobody finishes them, and the people who try usually stall out somewhere around the chapter where the math shows up. So instead of another summary, you get a plan, the chapters that earn their page count, the order that actually builds on itself, and explicit permission to skip the rest.

This one is different from the last book we covered though. Chip Huyen’s AI Engineering had zero code in it. This one is 800 pages of almost nothing but code. Which means the failure mode is different, and so is the reading strategy. Let’s get into it.

If you missed the previous Agentic Roadmap blog post, you can read it here:

Is This Book For You?

You cannot reason about ML systems you have never built. Géron’s bet is that you get an engineer’s intuition by shipping working models on real datasets, in order, from linear regression to diffusion models and picking up the theory on the way rather than in advance. This is the book that turns “I’ve watched a lot of YouTube about ML” into “I can build this.”

Who should read it

Software engineers who want to move into ML and are tired of tutorials that stop at model.fit(). Data scientists who can use Scikit-Learn but couldn’t tell you why their gradient boosting model is overfitting. Anyone who has been doing LLM API work for a year and is starting to feel the hole where the fundamentals should be, this is the book that fills it. Also, people who read the 3rd edition and want the PyTorch rewrite.

Who should skip it

Researchers who want mathematical rigor. The derivations here are deliberately minimal and occasionally hand-wavy; go read Murphy or Bishop. People who want to build LLM applications right now and don’t care how a transformer works, read Huyen instead, come back later. And anyone who won’t run the code. I’ll say this more than once:

this book is 40% worse if you read it like a novel, and it’s a long novel!

Prerequisites

Real Python ( functions, classes, list comprehensions, not just scripting). NumPy and pandas at a working level (Géron links tutorials if you're rusty). Linear algebra to the level of "I know what a matrix multiplication does and why the shapes have to line up." Calculus is genuinely optional for Part I and helpful-not-required for Part II; you can understand what a gradient is doing without being able to derive one.

Time Investment

Eight to ten hours for the Fast Track with your laptop open. Forty to sixty hours for the full Practitioner’s Deep Dive, realistically spread over two to three months. If someone tells you they read this book in a week, they read the words. That’s a different activity!

What Changed From The 3rd Edition

Since roughly everyone reading this owns the previous one:

• Keras and TensorFlow are gone. It’s PyTorch now. Every deep learning chapter has been rewritten.

• Support Vector Machines got demoted. SVMs used to be Chapter 5; they’re now Appendix C and the printed table of contents only lists Appendices A and B, so C through E live online at homl.info. Read that as an honest signal about where SVMs sit in 2026.

• Chapter 17 (Speeding Up Transformers) is online-only. Two pages in the print book, a pointer, and a note that it was moved online to make room. It covers KV caching, speculative decoding, FlashAttention, MoE, and LoRA, which is to say, most of what you’d actually need to serve a model in production. Don’t miss it because it looks like a stub.

• New chapters worth the upgrade on their own: Chapter 16 (Vision and Multimodal Transformers), and a substantially expanded Chapter 15 that now walks all the way to SFT, DPO, tool calling, and the Model Context Protocol.

• New online appendices on relative positional encodings and state-space models.

Return on Time Investment (ROTI)

If you put in the hours, here’s what you walk out with:

Conceptual Upgrades:

• Bias and variance as a working diagnostic, not a phrase from an interview. By Chapter 4 you’ll be able to look at a learning curve and say “more data won’t help me, I need a bigger model”, or the reverse, instead of guessing. This single skill saves weeks per project.
  

• The understanding that your metric is your problem definition. Chapter 3 will permanently break your habit of reporting accuracy. Once you’ve watched a 99.5%-accurate classifier turn out to be useless, you start every project by asking what kind of mistake you’re willing to make.
  

• One unified story for why deep networks are hard to train. Initialization, activation functions, normalization layers, residual connections, gradient clipping, Chapter 11 presents these as five separate attacks on the same enemy. Most people learn them as five unrelated tricks. Learning them as one story is the difference between debugging a model and rerolling the dice on it.
  

• A calibrated sense of when not to reach for a neural network. Géron says it plainly in the preface and then spends Part I proving it: a gradient boosted tree ensemble beats a deep net on most tabular problems, trains in seconds, and doesn’t need a GPU.

Why Most AI Agents Fail in Production

^{Most AI agents don’t fail because of the model. They fail because they have no clear architecture for planning, verification, memory, evaluation, or stopping.}

^{If you’re building AI agents that interact with tools, write code, or automate engineering workflows, it’s time to think beyond prompts.}

^{Join Rick Hightower, Claude Certified Architect and Co-founder of Spillwave, for a live, hands-on workshop on Engineering Reliable Agentic AI Systems. Learn how System Architecture, Harness Engineering, and Loop Engineering work together to build AI agents that are reliable, observable, cost-efficient, and ready for production.}

^{Save 40% with code: AISIMPLIFIED40}

Sign Up NOW 👉

The Non-Linear Reading Algorithm

Do not read this book front to back on your first pass. It’s 19 chapters and the dependency graph is much looser than the page order suggests, Géron even prints the graph in the preface (Figure P-1) which is the most useful diagram in the front matter and almost everyone skips it.

Here’s the short version of that graph: Chapters 1–4 unlock everything. After that, Chapters 5–6 are one unit, 7–8 are one unit, and 9–12 are the deep learning on-ramp that leads to everything else. Follow this execution path instead.

The 80/20 Fast Track → If you only have a weekend

Read Chapter 2 (End-to-End ML Project) with your hands on the keyboard. Type it. Don't read it, don't copy-paste it, TYPE IT. This chapter is the whole job compressed into 60 pages: frame the problem, pick a metric, split the data, explore, clean, engineer features, pipeline it, cross-validate, tune, and only then touch the test set.

Read Chapter 4 (Training Models) analytically. This is the chapter where “the model learns” stops being a metaphor. Gradient descent, the normal equation, why batch/stochastic/mini-batch each exist, regularization, and most importantly, learning curves.

Read Chapters 10 and 11 (PyTorch, and Training Deep Neural Networks) as one unit. Chapter 10 is mechanics, tensors, autograd, the training loop, DataLoaders, saving and loading. Chapter 11 is the payoff, and it’s the best chapter in Part II.

The Practitioner's Deep Dive → Where to slow down

Chapter 3 (Classification) The most underrated chapter in the book, and the one that separates people who can ship a model from people who can ship a useful one. Precision, recall, the trade-off between them, ROC curves, and error analysis via the confusion matrix.

Chapter 6 (Ensemble Learning and Random Forests) Highest practical ROI in Part I. If your job involves tabular data, this chapter will do more for your model quality than all of Part II combined. Read Chapter 5 (Decision Trees) first, it's short and it's a hard prerequisite.

Chapter 12 (Deep Computer Vision Using CNNs) Long, dense, and worth it, but read it with a filter. The architecture tour (LeNet → AlexNet → GoogLeNet → ResNet → Xception → SENet) is genuinely educational as a history of ideas, but you are almost certainly never going to train one from scratch.

Chapter 15 (Transformers for NLP and Chatbots) The centerpiece of Part II and, at 65 pages, effectively a short book. It goes from the original encoder-decoder architecture through BERT, through the GPT lineage, all the way to SFT, DPO, tool calling, and MCP.

The Skim/Skip List → What you can safely deprioritize

Chapter 1 (The Machine Learning Landscape): Skim. The taxonomy (supervised/unsupervised, batch/online, instance-based/model-based) is worth having and the section on the main challenges is the conceptual spine of the whole book. The application examples read like a brochure. Twenty minutes, then move on.

Chapter 7 (Dimensionality Reduction): Read the PCA sections, skim the rest. PCA is genuinely useful and you should understand what “explained variance ratio” means well enough to choose a number of components deliberately. Random projection and LLE are interesting and you will probably never use them. Come back if you do.

Chapter 8 (Unsupervised Learning): Depends entirely on your work. If you’re doing customer segmentation or anomaly detection, this is a deep-dive chapter and you should treat it as one — the semi-supervised learning section (use clustering to decide which examples are worth paying a human to label) is a genuinely clever trick that saves real money. If you’re not, skim k-means and DBSCAN and move on.

Chapters 13 and 14 (RNNs, and NLP with RNNs and Attention): Read these as history, quickly, unless you work on time series, in which case Chapter 13 is a deep dive and the ARMA comparison is unusually honest about classical methods beating neural ones on small data.

Chapter 16 (Vision and Multimodal Transformers): Treat it as a reference, not a read-through. It’s a well-organized tour of ViT, Swin, DINO, CLIP, DALL·E, Perceiver, Flamingo, and BLIP-2. Read the ViT section and the CLIP section properly, CLIP in particular, because contrastive text-image pretraining is the idea underneath a surprising amount of what shipped in the last three years, and skim the rest until you need it.

Chapters 18 and 19 (Autoencoders/GANs/Diffusion, and Reinforcement Learning): These are the fun chapters and they are the last ones you should read. Both are excellent. Neither is load-bearing for most jobs. Chapter 18’s diffusion section is a rare clear explanation of an idea that sounds impossible until you see it (train a network to remove a little noise, then start from pure static and run it a few hundred times), and Chapter 19 covers the credit assignment problem well. Save them as a reward.

Appendix A (Autodiff): Skip unless you’re curious how autograd actually works. Appendix B (Mixed Precision and Quantization) is the opposite, short, practical, and directly relevant the moment you have to fit a model on constrained hardware. Read B.

Terms to Know Before You Start

• Bias/variance trade-off → bias is error from your model being too simple to capture the pattern; variance is error from it being so flexible it fits the noise. Nearly every knob in the book moves you along this axis.

• Data snooping bias → the contamination you cause by making modeling decisions after looking at data that’s supposed to be held out.

• Cross-validation → splitting the training set into k folds and training k times so you can estimate performance without touching the test set.

• Pipeline / ColumnTransformer → Scikit-Learn’s mechanism for chaining preprocessing to a model so that the same transformations are learned on train and merely applied to test. This is leak prevention as an API design.

• Bagging vs. boosting → averaging many independent strong learners (variance reduction) vs. sequentially correcting a chain of weak ones (bias reduction).

• Autograd → PyTorch’s automatic differentiation. It records every operation on a tensor into a graph, then walks the graph backward to compute gradients. You never write a derivative by hand.

• Vanishing / exploding gradients → the reason deep networks were considered untrainable until roughly 2010, and the organizing problem of Chapter 11.

• Batch norm vs. layer norm → normalizing activations across the batch vs. across the features of a single example. Batch norm dominates in CNNs; layer norm dominates in transformers, because batch statistics are unreliable with variable-length sequences.

• Transfer learning / fine-tuning → starting from a model someone else trained on far more data than you have, and adapting it. In practice this is most of applied deep learning.

• Latent representation → the compressed internal encoding a model learns. Called embeddings, codings, or features depending on which chapter you’re in.

• LoRA / PEFT → fine-tuning a huge model by training a small number of extra low-rank parameters instead of all of them. Covered in the online Chapter 17.

The Execution Protocol

This is a code book. There are notebooks for every chapter at github.com/ageron/handson-mlp, and they’re designed to run in Google Colab with zero setup. That’s the book’s biggest strength and also its biggest trap, because notebooks that already work are the easiest thing in the world to scroll past.

How to read it so it sticks:

• Type the code. Do not copy-paste it. I know! Type it anyway. Reading working code produces a very convincing illusion of understanding that evaporates the moment you face a blank file. Typing it forces you through every argument name and every shape, which is exactly where the actual learning is. This is the single highest-leverage habit for this book and it’s the one people skip.
  

• Break things on purpose. After each chapter’s main example runs, sabotage it. Remove the feature scaling and see what happens to the linear model. Set the learning rate to 10. Take the batch normalization layers out of the deep net. Train the random forest with one tree. You learn what a component does by watching what fails without it, and you’ll build the failure-mode intuition that lets you debug a model in ten minutes instead of a day.
  

• Do the exercises. Every chapter ends with them, solutions are at the end of each chapter’s notebook, and they are unusually good, the later ones are small projects rather than quiz questions. This is where the material moves from recognition to recall. If you do nothing else from this list, do the exercises for Chapters 2, 3, 4, and 11.
  

• The math sidebar trap. You will hit an equation, decide you need to fully understand it before continuing, and lose an evening. Don’t. Géron’s structure is intentional: the code always comes with or right after the math, and running the code will usually explain the equation better than staring at it. Mark it, keep going, come back at the end of the chapter. If it still doesn’t click, that’s what Khan Academy is for, but do it after you’ve seen the thing work.
  

• Budget for compute. Part I runs fine on a laptop. From Chapter 12 onward, Colab’s free tier will start disconnecting on you mid-training. Either accept that you’ll train on subsets of the data (fine, you’re learning the mechanics, not chasing benchmarks), or budget for Colab Pro for the two months you’re in Part II. Deciding this up front prevents the very common failure of quitting the book at Chapter 12 out of pure friction.

The Syntopical Map: Where It Fits

Géron is the how. It teaches you to build the machinery. It is not a book about building AI products, and if you read it expecting one you’ll be confused about why you spent a weekend on decision trees.

• Before this: if you’re not sure you want to commit 50 hours, read Burkov’s The Hundred-Page Machine Learning Book first as a map of the territory.

• Alongside this: Andrew Ng’s courses cover much of the same Part I ground with more math and less code. They complement each other well.

• After this, for depth: Murphy’s Probabilistic Machine Learning or Hastie’s Elements of Statistical Learning for the theory Géron deliberately skips. Raschka’s Build a Large Language Model (From Scratch) if Chapter 15 leaves you wanting to go all the way down.

• After this, for breadth: Huyen’s AI Engineering (the book from our last issue) picks up exactly where Géron stops. Géron teaches you how a transformer works; Huyen teaches you how to build a product on top of one and evaluate it. Read in that order, they’re close to a complete curriculum.

Next Step

Have you worked through this one or the 3rd edition? Reply and tell me whether the PyTorch rewrite justified the upgrade for you, and which chapter you stalled out on.

Let’s Collaborate

Hey there, I’m Hana, co-founder and technical writer at AI Agents Simplified. If you’re building in the AI space, have feedback on today’s post, or want to explore a collaboration, let’s chat! You can find me on LinkedIn or drop me an email. I read every message and would love to hear from you.

This issue is brought to you by HubSpot

Every AI agent demo works, and that’s exactly what makes them dangerous. You have one user, one channel, a model that answers in under a second, and a path through the code that you’ve walked a hundred times. Everything you’d need to worry about at scale is simply absent from the room.

Then you connect it to a real Slack workspace. A plugin throws an exception on startup, somebody pastes forty thousand tokens of log output into a thread, a webhook fires while two hundred sessions are mid-turn, and the thing you thought was an agent turns out to have been a prompt with no runtime underneath it.

The work of closing that gap has a name, and it’s a useful one to know: harness engineering. It’s the discipline of building the machinery around the model, the gateway that receives traffic, the permission system that decides what the agent may touch, the memory that survives a restart, the telemetry that tells you what happened, and the recovery paths that catch things when they go wrong. Almost nobody writes about it, and it’s the part that determines whether your agent survives contact with actual users.

If you haven’t read our previous blog post about Harness Engineering, this is the best time to take a look at it:

What follows are seven failure modes I keep running into, and the pattern that addresses each one. None of them are exotic. All of them are cheap to check for, and most teams discover them the expensive way.

1. One Plugin Can Take Everything Down

Picture a plugin that fails while loading. Maybe a dependency is missing, maybe there's a syntax error, maybe a service it depends on can't reach its backend. In a naive architecture, that exception travels straight up through the startup sequence, and the result is that your entire gateway never comes online. One misbehaving component, and nothing works.

The instinct is to write more careful plugins. The better move is to assume plugins will fail, because eventually they all do and structure the system so that failure stays where it happened.

The pattern that solves this is called a bulkhead and the name comes from shipbuilding, where you divide a hull into sealed compartments so a breach in one doesn't flood the whole vessel. In an agent platform, the compartments are the plugin lifecycle phases (loading, registering, starting, running), and each one gets wrapped in its own error boundary. So when a plugin throws while loading, that boundary catches the exception, records it as a diagnostic, and lets the loader carry on to the next plugin. Your gateway still comes up, and you get a log line naming the plugin that's broken, which is considerably more useful than a stack trace and no service at all.

It’s worth understanding what this protects you from and what it doesn’t, because the distinction catches people out. If your platform runs in a single process, these boundaries contain errors but they can’t contain resource consumption, a plugin stuck in a tight loop will still eat the CPU its siblings need, and no amount of try/catch will help. What you’re buying is containment of failure rather than true isolation between components, and that’s genuinely valuable as long as you know which of the two you have.

Sitting above that is an idea I find more interesting which is that a platform shouldn’t only have two states. Instead of being either up or down, it can descend through levels. At full operation everything runs. Drop a level and you’re in core-only mode, drop again and you reach read-only diagnostics. At the bottom is offline, where health checks respond and nothing else does.

Each of those rungs is a deliberate engineering decision about what to sacrifice and in what order, which is why Ken Huang spends a full chapter on it in OpenClaw AI in Production, Chapter 3 walks through all four levels, including which function owns each one and where the boundary actually gets enforced. That last part matters more than it sounds, because "graceful degradation" is a comfortable phrase that hides a lot of fiddly implementation.

2. Your Allowlist Probably Allows Everything

This is my favourite failure on the list, because it doesn’t look like a failure at all. It looks like security.

Here’s the setup. You write a tool policy for your agent. You define a deny list and an allow list, both are present, the config validates cleanly, and you ship it feeling reasonably good. What you may not have realised is that in a deny-first matcher, an empty allow list usually means permit everything rather than permit nothing. So a policy block that reads as tightly locked down is in fact granting every tool that you didn’t explicitly name in the deny list.

That isn’t a bug, to be clear. It’s a coherent design called allow-unless-denied, and it’s a sensible default for a system that has to stay usable. The problem is purely that it’s not what most people think they configured, and the gap between those two beliefs is where trouble lives.

The model underneath is a composition stack rather than a single setting. Built-in defaults sit at the bottom, then global config, then per-agent config, then channel group policy, then sandbox policy, then subagent depth limits, and finally per-session overrides at the top. What makes it a composition stack rather than a simple override chain is that all seven layers get consulted together, a tool is permitted only when nothing in any layer denies it, and every layer that does define an allow list agrees to it. Deny always wins, no matter how high up the permission came from.

The practical upshot is that you get two workable strategies:

• You can set restrictive global defaults and selectively relax them for individual agents

• or you can set permissive defaults and tighten them where the risk is highest. Either works fine on its own.

Chapter 5 of the book lays out the full precedence stack along with the glob expansion that sits underneath it, including a detail that catches people regularly:

group expansion is only single-level, so if you’ve defined nested tool groups expecting them to resolve recursively, they don’t.

Your Customers Are One Text Away

^{You already know email gets buried and calls go unanswered. But texts? They get read — 98% of the time, within minutes. That’s why 230,000+ businesses use EZ Texting to reach their customers on the channel they engage with most}

^{Whether you’re sending promos, appointment reminders, or urgent alerts, EZ Texting makes it easy to send to 10 or 10,000 contacts in just a few clicks. No tech skills required. AI Agents Simplified’s readers can try it free — no credit card needed.}

Start Your Free Trial with EZTexting

^{Offer valid for new customers only. Use promo code EZWORKFLOW at checkout.}

3. The Agent Forgets What Actually Mattered

Conversations outgrow context windows, and everyone knows that. What gets underestimated is what specifically gets destroyed when you compact one.

The prose survives compaction perfectly well, because summarizing prose is what language models are good at. The UUID does not. Neither does the file path, the container ID, or the API endpoint the agent was halfway through calling. What happens is that the model does something helpful and reasonable and now every tool call that depends on that identifier fails, several turns later, for reasons that look completely unrelated to compaction.

Three things make the difference between compaction you can trust and compaction that quietly corrupts your session.

The first is triggering it early. You want to compact somewhere around 70-80% of the context window rather than waiting until you’re up against the ceiling. That’s because token estimators are heuristics and they undershoot, and a buffer of roughly 20% is what stands between compacting on your own schedule and overflowing the window in the middle of a tool call, which is a much worse place to find out.

The second is chunking by token weight instead of message count. If one assistant turn is six thousand tokens long, it should fill a chunk on its own, even if it’s surrounded by dozens of two-word user replies. Summarising coherent segments independently and then merging them produces noticeably better results than compressing a thousand messages in a single pass, because the model can actually hold each segment in view while it works.

The third is pinning identifiers explicitly, which means your summarization prompt needs a hard instruction to reproduce opaque strings exactly as written It feels like an obvious instruction until you see what happens without it.

Chapter 6 goes considerably deeper than I can here, into append-only event logs, the timing of memory flushes before compaction runs, and how to merge summaries that cover overlapping turns. If you’ve ever watched an agent lose the thread halfway through a task and couldn’t explain why, that chapter explains the mechanism.

4. The Retry That Charges Twice

Networks fail, so you add retries. It’s the most natural reflex in distributed systems and it’s usually correct. But now the same Slack event can get processed twice which means → the same tool fires twice which means → the same order gets created twice and you’ve turned a transient network problem into a data problem that’s much harder to unwind.

Retries without deduplication aren’t resilience. They’re duplication with a scheduler attached.

What makes retries safe is a deduplication key built from the message’s provenance, the provider it came from, the account, the session scope, the peer, the thread, and the message ID, all joined into a single fingerprint. When a message arrives, you check whether you’ve seen its fingerprint before. If you have, you skip the work entirely and return the result you produced the first time. Pair that with bounded exponential backoff on the model invocation, which is the phase most likely to fail for transient reasons, and retrying becomes something you can do freely instead of something you have to reason about each time.

Two details in that design are worth borrowing:

• The first is that the key should return null when provenance is incomplete rather than falling back to something approximate.

• The second is that deduplication is a property that wraps the whole request flow rather than a stage inside it. It isn’t step four of six; it’s a guarantee that holds across all six.

Chapter 2 traces the entire six-phase request path and shows precisely where the dedupe check and the backoff sit relative to context assembly, authorisation, and the model run, which is the kind of thing that’s much easier to get right when you can see it laid out.

5. The $40,000 Weekend

An agent enters a reflection loop on a Friday evening. Nothing is down, no health check fails, no alert fires. It is simply thinking, in a circle, at per-token prices, until somebody looks at a dashboard on Monday…

Demystify AI for Your Business in Just 4 Steps

Overwhelmed by AI? HubSpot's free guide cuts through the noise. Get the ultimate crash course for non-technical entrepreneurs who want to harness AI's power—without getting lost in the jargon.

"AI for Business Builders" delivers:

• A 4-part roadmap to AI mastery

• Jargon-free explanations of large language models

• Practical prompt engineering tips you can use today

• Real-world examples of AI boosting businesses like yours

Arm yourself with the knowledge to make informed AI investments and skyrocket your startup's growth.

Download Your Free Guide Now

Let’s Collaborate

Hey there, I’m Hana, co-founder and technical writer at AI Agents Simplified. If you’re building in the AI space, have feedback on today’s post, or want to explore a collaboration, let’s chat! You can find me on LinkedIn or drop me an email. I read every message and would love to hear from you.

This issue is brought to you by Novu Connect

The Biggest AI Failures Start With Tiny Mistakes

A cybersecurity paper that completely changed how I think about building reliable AI systems.

If I told you that changing just a handful of bits inside an AI model could make it almost useless, you would probably assume the model was poorly designed.

That was exactly my first thought.

Modern AI systems contain millions, and sometimes billions, of parameters. We constantly hear about larger models, longer context windows, and better benchmark scores. Intuitively, it feels like systems this large should also be incredibly resilient. After all, how much damage could a few tiny changes really cause?

This week, I read the research paper “Bit-Flip Attack: Crushing Neural Network with Progressive Bit Search“. At first glance, it looked like another cybersecurity paper describing a new way to attack neural networks. But after finishing it, I realized the paper wasn’t really about attacks.

It was about something much bigger.

It was about how complex AI systems fail.

Bigger Doesn’t Always Mean Stronger

Imagine you’re standing beneath a suspension bridge.

The bridge is held together by thousands of steel cables, bolts, and support beams. If someone randomly removed ten bolts from different parts of the structure, chances are nothing would happen. The bridge was designed with redundancy, so a few random failures aren’t enough to bring it down.

Now imagine an engineer who knows that bridge perfectly.

Instead of removing ten random bolts, they remove the three carrying the highest amount of stress.

Suddenly, the entire structure becomes unstable.

The bridge didn’t collapse because many things went wrong.

It collapsed because the wrong thing went wrong.

That analogy stayed with me throughout the paper.

The researchers demonstrated that they didn’t need to corrupt an entire neural network to make it fail. Instead, they identified an extremely small number of carefully selected bits inside the model’s stored weights. By changing only those critical locations, they dramatically reduced the model’s performance. Random changes had little impact, but targeted ones completely changed the outcome.

The lesson wasn’t simply that AI models can be attacked.

The lesson was that complex systems often have hidden weak points.

Stop Rebuilding Integrations

Bring Your Claude Agents to Any Channel in Minutes

^{If your Claude agent is trapped inside your app, it’s time to move the conversation to where your customers actually live. Without the headache of maintaining custom infrastructure.}

^{Novu Connect is the new standard in Agent Communication Infrastructure (ACI). It bridges the gap between your AI agents and any messaging platform, including Slack, Teams, WhatsApp, and email. You don’t need to spend weeks building pipelines; just pick a template, connect your tools, and you’re live in under 2 minutes.}

^{No infrastructure to babysit, no custom plumbing to rebuild. Just immediate, two-way conversations with your customers.}

^{Join the challenge: deploy your agent in under 2 minutes and unlock a free month of our Pro tier.}

Join the Challenge NOW 👉

Complexity Creates Fragility

As AI systems become more capable, they also become more interconnected.

Today’s AI applications are no longer just models. They combine retrieval pipelines (RAG), memory systems, tool calling, Model Context Protocol (MCP), external APIs, planning modules, databases, browser automation, and dozens of moving parts working together.

That complexity is what makes modern AI so powerful.

It’s also what makes it difficult to reason about.

Most components inside a system are surprisingly forgiving. If something small goes wrong, the application usually continues working. But every complex system also contains a handful of hidden dependencies where a tiny failure can quietly propagate through everything else.

Reading this paper made me realize that the size of a system tells us very little about its resilience.

Sometimes the most dangerous weakness isn’t obvious.

Sometimes it’s hidden inside one small component that nobody thinks to question.

Why This Matters For AI Agents

I think this idea becomes even more important as we build increasingly autonomous AI agents.

When we evaluate agents today, we usually focus on capability. We ask whether they can solve harder problems, write better code, reason more effectively, or complete longer workflows.

Those are important questions.

But I think another question is becoming just as important:

Where is this system most likely to fail?

A single incorrect retrieval result can influence every decision that follows. One faulty tool call can trigger an entire chain of unnecessary actions. A small mistake in memory can quietly change an agent’s behavior for hours without anyone noticing.

The problem isn’t that AI systems make mistakes.

The problem is that some mistakes travel much further than others.

As our systems become larger, identifying those critical failure points becomes just as important as improving the models themselves.

My Take

One sentence from this paper stayed with me long after I finished reading it, not because the authors wrote it explicitly, but because it emerged from their results.

Complex systems rarely fail because everything goes wrong. They fail because one important thing goes wrong.

I think that’s a lesson we’ll hear much more often over the next few years.

As AI moves from demos into production, reliability becomes just as valuable as intelligence. The companies building the next generation of AI products won’t succeed only because they have the smartest models. They’ll succeed because they’ve designed systems that can detect small failures, contain them, and recover before they become expensive.

Because in the end, the biggest AI failures rarely begin with something dramatic.

They begin with something so small that nobody noticed it, until it was too late.

A Hands-On Workshop for the Next Generation of Engineers

10 Essential AI Agents Every Engineer Must Build

A hands-on, build-along workshop where you build and run 10 production-inspired AI agents across finance, healthcare, and education. Walk away with a complete GitHub repo and implementations for OpenAI, Claude, Gemini, and local models.

🗓️ September 12th · 11:00 AM EDT onwards

Use code AGENTS50 for 50% off the early bird price. First 10 sign-ups only.

Sign Up Now 👉

📖 Inspired By

This issue was inspired by the paper:

Bit-Flip Attack: Crushing Neural Network with Progressive Bit Search

Authors: Adnan Siraj Rakin, Zhezhi He, and Deliang Fan

Read the paper: https://arxiv.org/abs/1903.12269

🤝 Let’s Collaborate

Hey, I’m Arian, Product Manager and Partnership Manager at AI Agents Simplified.

If you’re building AI products, working on AI agents, or exploring partnerships in the AI ecosystem, I’d love to connect. Feel free to reach out through my LinkedIn or email. I’m always happy to discuss ideas, collaborations, and the future of AI.

This issue is brought to you by Novu Connect

Welcome to the Agentic Reading Roadmap. Here's the deal: dense technical books are worth reading, but almost nobody reads them cover to cover, and the ones who try usually stall out around chapter four. So instead of another summary, you get a plan: the chapters that earn their page count, the order that actually builds on itself, and permission to skip the rest. Let's get into it.

Is this book for you?

The Thesis

The field of AI engineering is now distinct from ML engineering. This book gives you the mental models, decision frameworks, and architectural patterns to build production-ready AI applications on top of foundation models, without training anything from scratch.

Who should read it

Mid-to-senior engineers building AI-powered products. Engineering managers who need to make architectural decisions (RAG vs. finetuning, API vs. self-hosted). Technical PMs and founders who are past the demo phase and need to understand why their system fails in production. ML engineers transitioning into AI engineering roles.

Who should skip it

Researchers who want mathematical depth, there is no calculus here, and that’s intentional. Beginners who haven’t shipped anything with an LLM API yet, get your hands dirty first, then come back. Engineers who exclusively want code to run, this book has none. If you’re looking for a LangChain or LlamaIndex tutorial, this is not that book.

Prerequisites

Basic Python. A working mental model of how APIs work. Ideally, you’ve built at least one prototype with an LLM. Familiarity with concepts like embeddings and vectors helps but isn’t required, Huyen defines everything clearly.

Time Investment

2 hours for the 80/20 Fast Track. 8–10 hours for the full Practitioner’s Deep Dive. The first half of the book can be read at roughly twice the speed of the second half.

Return on Time Investment (ROTI)

If you put in the hours, here's what you walk out with:

Conceptual Upgrades:

• A clear mental model of when to use prompt engineering, RAG, or finetuning and why the answer is almost never “all three at once.”

• A framework for thinking about AI evaluation before you write a single line of application code. You’ll stop treating evaluation as an afterthought.

• A vocabulary for latency, cost, and quality trade-offs that lets you have honest conversations with your team about what a production AI system actually needs.

• A principled answer to the question: “Should we host our own model or use an API?”, based on concrete factors like goodput, KV cache utilization, and data privacy constraints, not gut feeling.

Architectural Deliverables:

• A reference architecture for an end-to-end AI engineering system: context enhancement → guardrails → model routing → caching → agents. Chapter 10 maps this out in one of the clearest system diagrams you’ll find in the field.

• A decision tree for the RAG-vs-finetuning tradeoff. Huyen’s framing here is sharp: finetuning is for form, RAG is for facts.

• A structured approach to designing AI evaluation pipelines, including how to use AI-as-a-judge without falling into the trap of the model grading its own homework.

The Non-Linear Reading Algorithm

Do not read this book cover-to-cover. The first four chapters are front-loaded with foundational context. Some of it is excellent; some of it is padding you do not need. Your time is better allocated elsewhere. Follow this execution path instead

The 80/20 Fast Track —> If you only have 2 hours

The unique value of this book lives in the second half. These three chapters contain the architectural insights that take engineers months of trial-and-error to learn on their own:

Read Chapter 5 (Prompt Engineering) analytically. Not for the individual tactics (you likely know most of them), but for Huyen's framing of context construction as the central discipline of AI engineering. This reframes prompting from a hack into an engineering practice. Pay attention to the section on structured outputs and the discussion of system prompts as contracts, not suggestions.

Read Chapter 6 (RAG and Agents) in full. This is the core of the book. The RAG architecture walkthrough is the clearest available treatment of the topic, from chunking strategies through hybrid retrieval through evaluation of the retriever itself. The Agents section is equally grounded. Huyen avoids the hype trap: she covers agent failure modes, planning limitations, and why most "autonomous" agents in production are closer to structured workflows with fallback logic. Read every word here.

Read Chapter 10 (AI Engineering Architecture and User Feedback) last, before anything else. Yes, out of order. Read it first as an inspectional pass to see where the whole book is going, the reference architecture maps everything together. Then read it again after Chapter 6. The section on user feedback and conversational feedback extraction is underappreciated; it's where Huyen discusses how to actually learn from your production system rather than just monitoring it.

The Practitioner's Deep Dive —> Where to slow down

These chapters require active engagement. Read them at a desk, with notes open, not on a phone.

• Chapter 3 and Chapter 4 (Evaluation). Arguably the most important and most underestimated chapters in the book. Huyen makes the case that evaluation is the hardest unsolved problem in AI engineering, not model selection or inference cost. The treatment of AI-as-a-judge is rigorous, she covers positional bias, verbosity bias, and self-enhancement bias in model judges, which are failure modes most teams discover the hard way. If you have an existing AI product in production with weak evaluation, read these chapters first, before anything else in the book.
  
  

• Chapter 7 (Finetuning). Slow down here. The section on when not to finetune is more valuable than the section on how to finetune. Huyen walks through memory math for LoRA vs. full finetuning in a way that makes hardware constraints concrete rather than abstract. Pay particular attention to the discussion of preference finetuning (RLHF/DPO), the nuances between supervised finetuning and preference alignment are frequently confused in practice.
  
  

• Chapter 9 (Inference Optimization). Dense but worth it. The framework for understanding inference bottlenecks, memory-bound vs. compute-bound regimes, KV cache behavior, quantization trade-offs, is the kind of mental model that separates engineers who can make infrastructure decisions from those who just follow benchmarks. Don’t try to memorize the numbers; focus on the reasoning structure.

The Skim/Skip List —> What you can safely deprioritize

• Chapter 1 (Introduction): Skim the section on the AI engineering stack (the three-layer diagram is genuinely useful) and the breakdown of AI engineering vs. ML engineering vs. full-stack engineering. Skip the use-case catalogue, it reads like a product brochure and adds little if you already work in the field. Read the intro paragraph and the summary, then move on.
  
  

• Chapter 2 (Understanding Foundation Models): This chapter is the most debated in reader reviews, and for good reason. The treatment of transformer architecture and training is broad but shallow. If you already understand what post-training, RLHF, and sampling strategies are, skim the section headers and skip to the Structured Outputs and Probabilistic Nature of AI subsections, those are genuinely useful framings. If you’re new to foundation models, read it analytically. If you’re experienced, you’ll lose an hour here you won’t get back.
  
  

• Chapter 8 (Dataset Engineering): This chapter is excellent if dataset curation and synthetic data generation are live problems for you right now. If they’re not, meaning you’re API-first and haven’t moved to finetuning yet, skim the introductory framing and the section on data synthesis. Return to this chapter when you actually need it.

  If you'd rather have this as a clean PDF you can annotate, comment "AI Engineering guide" below and I'll send you a copy, plus the supplementary resources I pulled together while writing it.

  Leave a comment

Terms to know before You Start

• Foundation model : a large model trained on broad data that can be adapted to many tasks (distinct from task-specific ML models)

• Context construction : Huyen’s term for the full discipline of deciding what to put in the prompt; treated as the central skill of AI engineering

• Goodput: useful throughput in inference serving; the fraction of total compute that produces valid, complete outputs

• KV cache: the key-value cache used during autoregressive decoding; understanding this is essential for Chapter 9

• PEFT (Parameter-Efficient Fine-Tuning) : finetuning techniques like LoRA that update a small fraction of model weights rather than all of them

• AI-as-a-judge: using a language model to evaluate the outputs of another language model; discussed at length in Chapter 3-4

• Preference finetuning: training a model using human or AI preference signals rather than direct supervision (RLHF, DPO, etc.)

The Execution Protocol

This is not a code book. There are no code blocks to run, no GitHub repos to clone, no environment to set up. That’s a deliberate choice and it’s both the book’s biggest strength and its most frequent criticism.

What this means for how you read it:

• The “Offline Read” method applies here more than anywhere. Because there’s no code pulling your attention to a terminal, the risk is passive reading. You need to compensate deliberately. Read with a document open. After every subsection, write one sentence in your own words that captures the core trade-off or decision. If you can’t, you didn’t actually absorb it.
  
  

• Build the decision tables yourself. Huyen gives you the factors; she often stops short of the decision matrix. As you read Chapters 5–7, build your own table mapping your current project to the framework she provides: Does your application need factual grounding (→ RAG)? Does it need a specific output style or format that prompting can’t achieve consistently (→ finetuning)? Making these concrete as you read is what separates reading from studying.
  
  

• GitHub Archaeology: The official companion repo is at github.com/chiphuyen/aie-book. It contains chapter summaries, errata, and supplementary resources. Worth bookmarking. For code that implements the concepts, use it alongside Huyen’s own Substack and the O’Reilly learning platform exercises, the book deliberately points outward to implementations rather than including them.
  
  

• The Evaluation Trap to avoid: A common mistake after reading Chapters 3-4 is trying to build a perfect evaluation framework before shipping anything. Don’t. Huyen is clear that evaluation is iterative. The value of those chapters is to know what you’re measuring and why, not to have a complete pipeline before you start.

Stop Rebuilding Integrations

Bring Your Claude Agents to Any Channel in Minutes

^{If your Claude agent is trapped inside your app, it’s time to move the conversation to where your customers actually live. Without the headache of maintaining custom infrastructure.}

^{Novu Connect is the new standard in Agent Communication Infrastructure (ACI). It bridges the gap between your AI agents and any messaging platform, including Slack, Teams, WhatsApp, and email. You don’t need to spend weeks building pipelines; just pick a template, connect your tools, and you’re live in under 2 minutes.}

^{No infrastructure to babysit, no custom plumbing to rebuild. Just immediate, two-way conversations with your customers.}

^{Join the challenge: deploy your agent in under 2 minutes and unlock a free month of our Pro tier.}

Join the Challenge NOW 👉

The Syntopical Map: Where it fits in the ecosystem

The Monday Morning Sprint

Passive reading decays within 48 hours without retrieval. Here’s how you lock this in before your next meeting.

Active Recall Check

Answer these without looking at the book. If you get stuck, you found your reread target.

1. Huyen argues there’s a specific ordering of techniques you should try before finetuning a model. What is that ordering, and what’s the engineering rationale for it? (Chapters 5–7)
   

2. What is the fundamental reason AI-as-a-judge evaluation can fail even when the judge model is strong? Name at least two specific biases she identifies, and describe how each one distorts evaluation results. (Chapters 3–4)
   

3. In Huyen’s reference architecture in Chapter 10, what role do caches play, and why does she treat them as a mandatory step rather than a performance optimization to add later? What types of caching does she distinguish between?
   

The Micro-Project: 60 minutes, one concrete output

Pick one AI application you’re currently building or have recently shipped, even a prototype counts.

Map it against Huyen’s five-step reference architecture from Chapter 10: context enhancement, guardrails, model routing and gateway, caching, and agent patterns. For each step, write one sentence on whether you’ve implemented it, skipped it intentionally, or skipped it by default (meaning you didn’t think about it).

Then identify the one gap in your current architecture that is most likely causing inconsistent output quality or latency spikes. Write a one-paragraph proposal for what you’d add or change, grounded in Huyen’s framework, not a tool recommendation, but a structural decision.

That paragraph is the deliverable. Share it in the comments if you want a gut-check from the community.

Build AI Agents That Reason Over Connected Knowledge

^{Production AI needs to connect evidence across sources, reason through relationships, and remember what it has already discovered.}

^{Join the live, hands-on Building Intelligent AI Agents with GraphRAG workshop led by David Knickerbocker, and learn how to build agents that run multi-step investigations, maintain investigation memory, answer follow-up questions, and use graph, timeline, sentiment, and geospatial tools for deeper insights.}

^{Move beyond basic retrieval and start building AI systems designed for complex, real-world questions, guided by an expert at the forefront of GraphRAG innovation.}

^{As an AI Agents Simplified subscriber, you can get 40% off with code AIAGENTS40.
Seats are limited. Secure yours before the offer ends.}

^{You’ll also receive:}

• ^{One complimentary Packt eBook worth $35}

• ^{A Packt Certificate}

• ^{Recording access}

^{Join us and learn how to build AI agents that do more than retrieve documents.}

Sign Up Now ➡️

Next Step

Have you read this one? Reply and tell me which section hit different or which part you think hasn’t aged well given how fast the field moves. The RAG chapter in particular is worth a conversation.

Let’s Collaborate

Hey there, I’m Hana, co-founder and technical writer at AI Agents Simplified. If you’re building in the AI space, have feedback on today’s post, or want to explore a collaboration, let’s chat! You can find me on LinkedIn or drop me an email. I read every message and would love to hear from you.

This issue is brought to you by HubSpot

I Thought This Was A Healthcare Paper. Then I Realized It Was About AI Agents.

Every once in a while, I read a research paper that changes the way I think about artificial intelligence, not because it introduces a new model or achieves a new benchmark, but because it challenges an assumption we rarely question.

This week, that paper was about something completely outside the world of AI agents: predicting six-month mortality in heart failure patients using machine learning. At first, it looked like a typical healthcare AI paper, where researchers train models, compare techniques, and report performance numbers.

But the more I read, the more I realized the interesting part was not the model itself. It was the way the researchers defined what “better” actually meant.

And that question applies to every AI system we are building today.

The Problem With How We Measure AI

Most AI projects begin with a similar question: how do we make the model better? Usually, that means improving measurable metrics such as accuracy, benchmark performance, speed, or cost. These measurements are useful because they help teams compare different approaches, but they can also hide a more important reality: not every mistake an AI system makes has the same consequence.

A recommendation engine showing the wrong movie is a small inconvenience, while a financial AI system producing incorrect information can create real damage. A medical AI system that fails to identify a high-risk patient is different because the cost of that mistake could mean losing the opportunity for early intervention.

The challenge, therefore, is not simply building an AI system that is correct more often. The challenge is designing a system that understands the consequences of being wrong.

The Question The Researchers Asked Was Different

The researchers used the MIMIC-III critical care database to build a machine learning system that predicted six-month mortality risk for heart failure patients. They tested different feature selection techniques with an XGBoost model to understand which information helped the system make better predictions.

But the most interesting decision was not the model choice.

It was the metric they prioritized.

In this type of healthcare problem, missing a high-risk patient is much worse than incorrectly flagging someone who is actually healthy. Because of that, the researchers prioritized recall, the ability to identify as many high-risk patients as possible, even if it created more false alarms.

They were not trying to build a model that was simply accurate.

They were building a model that made the less harmful mistake.

Demystify AI for Your Business in Just 4 Steps

<sup>Overwhelmed by AI? HubSpot's free guide cuts through the noise. Get the ultimate crash course for non-technical entrepreneurs who want to harness AI's power; without getting lost in the jargon.

"AI for Business Builders" delivers:</sup>

• ^{A 4-part roadmap to AI mastery}

• ^{Jargon-free explanations of large language models}

• ^{Practical prompt engineering tips you can use today}

• ^{Real-world examples of AI boosting businesses like yours}

^{Arm yourself with the knowledge to make informed AI investments and skyrocket your startup's growth.}

Download Your Free Guide Now 👉

Why This Matters For AI Agents

The same principle will define the next generation of AI agents.

As agents become more autonomous, the important question will not only be whether a system can complete a task successfully. The more important question is whether we understand what happens when that system makes a mistake and whether we have designed the right safeguards around those failures.

A coding agent that creates a minor bug is very different from one that introduces a security vulnerability into a production system. A customer support agent that escalates too many conversations is inconvenient, but an agent that provides incorrect financial advice creates a much bigger problem because the consequences extend beyond the immediate interaction.

The goal is not to create AI systems that never fail. That is impossible. The goal is to build systems that understand which failures are acceptable, which failures are dangerous, and when additional human oversight or verification is required.

My Take

The more I learn about AI, the more I believe the future will not belong only to the systems with the highest benchmark scores or the most impressive technical demonstrations.

The strongest AI systems will be the ones that understand context, uncertainty, and consequences. They will know not only what action to take, but also when they should slow down, ask for help, or recognize that they do not have enough confidence to proceed.

This paper reminded me of a simple idea:

The goal of AI should not only be to make fewer mistakes.

The goal should be to understand which mistakes matter most.

Because intelligence is not just about producing the right answer. It is about understanding what happens when the answer is wrong.

The paper that inspired this issue:

📄 Comparative Evaluation of Feature Selection Techniques for Six-Month Mortality Prediction in Heart Failure Patients
✍️ Authors: Parsa Haghighatgoo & Somayeh Afrasiabi
🔗 Read the original research paper
👉 Google Scholar link

7 Stocks Built for the Next Market Cycle

The Magnificent Seven reshaped the market, but leadership never stays concentrated
forever. As these companies mature, new contenders begin to emerge quietly, long
before they dominate headlines.

These 7 stocks could be the next wave of market leaders: 7 companies with growing
influence, strong fundamentals, and the potential to define the market’s next phase.

The full list is available here FREE

Let’s Collaborate

Hey, I’m Arian, Product Manager and Partnership Manager at AI Agents Simplified. If you’re building AI products, working on AI agents, or interested in collaborating with our community, I’d love to connect.

Feel free to reach out through my LinkedIn or email, I’m always happy to discuss partnerships, ideas, and the future of AI.

This issue is brought to you by HubSpot

Last week I got a bunch of replies to Part 1 that all said some version of the same thing: “okay, I get what loop engineering is now, but show me one.” Fair. A framework with no real example is just a nice diagram!

So that’s what today is.

Quick recap in case you’re just joining, or Part 1 already feels like a while ago. Loop engineering means building a system that prompts your agent for you, instead of you doing it by hand every time. We talked through the five moves every real loop makes, and the one mistake that ruins almost every first attempt: letting the agent decide for itself whether its own work is any good.

If any of that sounds unfamiliar, go read Part 1 first, this one builds directly on it and won’t make much sense without it.

If you’re caught up, here’s where we’re headed today:

• Two loops actually running right now → one built by a single developer before breakfast, one running inside a company shipping over a thousand pull requests a week

• What it actually costs you when a loop goes wrong → four specific costs, and none of them show up until they already have

• A five-step plan to build your first loop this weekend → smaller than you think, on purpose

Let’s get into it.

Two Loops That Are Actually Running Today

This isn’t theoretical. Two public examples show the range, from a single developer to a whole company.

Addy Osmani runs a personal loop every morning: it reads yesterday’s CI failures, open issues, and recent commits on its own, opens an isolated workspace for each thing worth fixing, has one agent draft a fix and a second agent review it, opens a pull request automatically when it passes, and drops anything uncertain into an inbox for him to look at. Nothing requires him to be awake for it to happen and nothing merges without a check.

At the other end of the scale, Stripe built an internal system nicknamed “Minions.” Engineer Steve Kaliski described it on the How I AI podcast: you tag the bot in Slack or react with an emoji, and Stripe’s agents were landing around 1,300 pull requests a week with no human writing the code, just humans reviewing it. The trick isn’t a smarter model. Before the agent even starts “thinking,” a separate, hard-coded system gathers the relevant tickets, docs, and code so the agent isn’t left guessing at its own context. Anything that can be handled by predictable, rule-based logic never gets handed to the probabilistic model. The humans didn’t disappear from the process, they moved from writing code to reviewing it.

Same five moves, wildly different scale. That’s the point! Loop engineering isn’t a specific tool, it’s a shape you can build small or big.

What It Costs You If You Get It Wrong

None of this is free, and the costs don’t show up while things are going well, that’s exactly what makes them dangerous.

Verification debt. Every PR the loop opens without a real check is a small loan against your future time. It looks fine today because the tests that exist are green. The problem lives in what the tests don’t cover, and it compounds quietly until it all surfaces at once.

Comprehension rot. The faster a loop ships code you didn’t write, the bigger the gap between what your codebase actually is and what you think it is. You stop reading line by line because the loop took over the writing, and your mental map goes stale while the code keeps moving.

Cognitive surrender. This is the psychological version of the first two. Once a loop runs reliably enough, it’s tempting to stop having an opinion about what it hands you and just click merge. The more you trust it, the less you look. The less you look, the less you’re able to judge and that’s a slope, not a step.

Token costs. Autonomous loops spawn their own sub-agents, retry on their own, and run on a timer whether you’re watching or not. One stuck loop, retrying all night, and you wake up to a bill instead of a fixed bug. Set a hard budget cap and a max-retry limit before you ever let a loop run unattended, don’t find out the ceiling exists by hitting it.

The uncomfortable truth underneath all four is that a loop doesn’t have opinions of its own. It amplifies whatever you bring to it. Bring good judgment and habits, and it scales your judgment. Bring the desire to never think about this again, and it scales that just as efficiently.

Unlock Your Next Income Stream: 100 Side Hustles for Ambitious Founders

^{In a world where financial freedom feels like a distant dream, smart women are building wealth on their own terms.}

• ^{Finally, a curated database of 100 proven side hustles (that actually work)}

• ^{Each idea comes with required startup costs, time investment, and potential earnings}

• ^{Exclusive insights from founders who've turned side gigs into 6-figure empires}

• ^{Detailed skill requirements so you can match your talents to the right opportunity}

• ^{Bonus: Priority scoring system to identify which hustles align with your lifestyle}

^{Don't let another month slip by watching others build their empire. Your next income stream is hiding in our database, waiting to be discovered.}

👉 Download the Side Hustle Database Now

Should You Actually Build One? Start Smaller Than You Think

You don’t need Stripe’s setup to get value from this. Start with something that barely looks like a “system”:

1. Pick one recurring, low-stakes check. Something like “did CI pass overnight” or “summarize new issues.” Not your production deploy pipeline.

2. Give it memory. A single markdown file the agent reads at the start and updates at the end is enough to make runs build on each other instead of starting from zero.

3. Add a second agent to check the first one’s work, before you add anything else. This is the step people skip, and it’s the one that matters most.

4. Only then, schedule it. Claude Code has /loop for time-based reruns and /goal for condition-based stopping; Codex has an equivalent Automations tab. Both platforms also support isolating parallel agents in separate git worktrees so they don’t overwrite each other’s changes, and both support MCP connectors to plug into tools like your issue tracker or Slack.

5. Set a spending cap and a human checkpoint, before you let it run while you sleep.

If you want it to run even with your laptop closed, you’ll need cloud-based scheduling (Claude Code’s Cloud Routines, or a GitHub Actions cron trigger) rather than a local scheduled task, local automations stop the second your machine sleeps.

The Real Skill Hasn't Changed

Here’s the thing worth sitting with. Generating code, plans, and pull requests has become nearly free. When something can be produced without limit, it stops being the scarce resource.

What’s still scarce is judgment, knowing which output is actually right, not just plausible-looking. A loop can generate a hundred options. It can’t tell you which one is correct; it can only tell you which one looks reasonable to it. That gap is exactly why you still need to be involved.

Two people can build the identical loop and end up in opposite places six months later. One person used it to move faster on work they already understood, kept reading the output, and got sharper. The other used it to avoid ever having to understand the system again, stopped checking, and quietly became a stranger to their own codebase. Same tool, same code, the difference was whether they stayed the engineer or just became the person who presses go.

Build the loop. Just build it like someone who still plans to know what’s happening inside it.

The Only Insurance That Can Make You Richer

^{Most insurance costs you money. But there’s a kind that can pay you when the stock market drops. One example turned $200 into $2,000 during a downturn. And you don’t even need to own stock to use it!
It protects your portfolio and can generate profits when stocks fall. You’ll find the step-by-step breakdown in this free guide. It's simple, fast to read, and made for regular, at-home investors…
And today, it’s totally free, but won’t be for long.}

Claim Your FREE Copy 👉

What’s Next

That’s Part 2. If Part 1 was about understanding the shape of a loop, this one was about watching two working examples, seeing what breaks when nobody’s checking, and having an actual plan to build one yourself.

Here’s the thing I want you to sit with more than any tactic in this post: the tools got faster, but the job didn’t get easier, it got narrower. Writing code was never really the scarce skill. Knowing which code is right was. Loop engineering doesn’t remove that skill, it just makes it more obvious when you don’t have it.

So build the loop. Give it memory. Make the evaluator genuinely skeptical before you make anything else fancier. And check on it, not because you don’t trust it, but because that’s the part of the job that’s actually still yours.

Before you go, I wanted to share a quick note about an event I’ll be attending at the end of July. The Packt team has been kind enough to offer AI Agents Simplified readers a 40% discount code, so if you’re interested, you can check it out too.

Build AI Agents That Reason Over Connected Knowledge

^{Production AI needs to connect evidence across sources, reason through relationships, and remember what it has already discovered.}

^{Join the live, hands-on Building Intelligent AI Agents with GraphRAG workshop led by David Knickerbocker, and learn how to build agents that run multi-step investigations, maintain investigation memory, answer follow-up questions, and use graph, timeline, sentiment, and geospatial tools for deeper insights.}

^{Move beyond basic retrieval and start building AI systems designed for complex, real-world questions, guided by an expert at the forefront of GraphRAG innovation.}

^{As an AI Agents Simplified subscriber, you can get 40% off with code AIAGENTS40.
Seats are limited. Secure yours before the offer ends.}

^{You’ll also receive:}

• ^{One complimentary Packt eBook worth $70}

• ^{A Packt Certificate}

• ^{Recording access}

^{Join us and learn how to build AI agents that do more than retrieve documents.}

Sign Up Now 👉

Let’s Connect

If you build one this weekend, I’d genuinely like to hear how it went, what broke, what surprised you, what you’d change. Find me on LinkedIn or reply to this post.

See you in the next one!

Leave a comment

Further reading:

• Addy Osmani’s original “Loop Engineering” essay

• Anthropic’s engineering write-up on generator/evaluator harness design

• Steve Kaliski on the How I AI podcast, on Stripe’s “Minions”

This issue is brought to you by Option Pit

Picture your last “productive” afternoon with an AI coding agent. You wrote a prompt. It did something. You read the output, wrote another prompt, waited again. Multiply that by twenty rounds and you basically became a very expensive keyboard for the model.

Loop engineering is the name for getting out of that seat.

It’s not another buzzword competing with prompt engineering or context engineering for your attention. It’s what happens after you’ve gotten good at both, and you notice the real bottleneck was never your wording. It was you, sitting there, being the only thing that tells the agent what to do next!

TL;DR

Loop engineering means designing a system that prompts your AI agent for you, instead of you prompting it by hand, one message at a time. This is Part 1 of a two-part series, and it covers the foundation:

• What loop engineering actually means

• How it’s different from prompt engineering and context engineering

• The five moves every working loop makes

• The one mistake almost everyone makes on their first attempt

Part 2, out next week, is the hands-on half: real loops running in the wild, what they cost you when they go wrong, and a five-step plan to build your own. More on that at the end.

What Loop Engineering Actually Means

The term comes from a June 2026 essay by Addy Osmani, an engineer on the Google Chrome team, who put it in one sentence:

loop engineering means replacing yourself as the person who prompts the agent, and designing a system that does that instead.

That same week, two other people said almost the identical thing without comparing notes. Peter Steinberger, creator of OpenClaw, posted that developers should stop prompting coding agents and start designing loops that prompt them for them. Boris Cherny, who leads Claude Code at Anthropic, said his job now is writing loops, he doesn’t prompt Claude directly anymore, the loops do that and figure out what needs doing.

Three people, one week, one idea. That’s usually a sign a term is describing something real, not something marketed.

Here’s the plain version: instead of you typing “fix this bug” every morning, you build a small system that checks for bugs every morning, decides which ones are worth fixing, hands them to an agent, checks the agent’s work, and remembers what it did, all without you touching a keyboard. You’re no longer inside that loop. You’re the person who built it and occasionally checks on it.

What happens at 3:50 PM

^{3 PM hits. Volume picks up. By 3:50, the market's a freight train.}

^{That's when my crew and I strike.}

^{A few wins from recent sessions:}

• ^{$790 in pure profit}

• ^{185% on a single position}

• ^{$1,500 winners closing the bell}

^{We're not predicting tomorrow's headlines. We're not reading tea leaves. We're watching where $55 billion flows in the final hour, and riding it.}

^{It happens today. And tomorrow. And every trading day after.}

Join us, your first week is FREE 👉

How This is Different From Prompt Engineering and Context Engineering

This is the part most explainers skip, and it’s the part that actually matters if you want to know when to use which skill.

Think of it as four layers stacked on top of each other, each one worrying about something bigger than the last:

• Prompt engineering worries about one sentence: what do I say to the model right now?

• Context engineering worries about one window: what information should be in front of the model so it can actually do this well?

• Harness engineering worries about one run: which tools can the agent use, what counts as “done,” how does it recover if something breaks?

• Loop engineering worries about the whole cycle: what makes this run again tomorrow, without me?

Let’s make that concrete. Say you want an agent to keep your test suite green.

Prompt engineering is you writing a clear instruction: “Run the test suite, if anything fails, fix it, and explain what you changed.”

Context engineering is making sure the agent actually sees the failing test output, the relevant file, and not forty irrelevant files that confuse it.

Harness engineering is deciding the agent can run pytest and edit files in /src, but can’t touch /prod, and defining what “the task is done” looks like.

Loop engineering is the layer where none of that requires you anymore. Something checks CI every morning, on its own, decides which failures are worth fixing, hands each one to an agent in an isolated workspace, has a second agent check the fix before it merges, and writes down what happened so tomorrow’s run knows where things stand.

Notice that loop engineering doesn’t replace the other three. A sloppy prompt inside a loop just produces sloppy output on a schedule, faster. The loop is the layer that decides when and whether the other three layers even get triggered and, crucially, whether anyone double-checked the result.

The IPO market ran a stress test

^{The 2026 pipeline looks very different from years past.}

^{Here’s what’s attached to some of the companies expected to headline the calendar:}

• ^{~$1.5 trillion target valuation.}

• ^{$20+ billion in annual revenue.}

• ^{55% year-over-year revenue growth.}

• ^{$1.4+ billion in pre-tax profit.}

• ^{240+ million monthly active users.}

• ^{Eight consecutive years of profitability.}

^{Unlike many IPOs, those aren’t projections ten years out - they’re current figures tied to a select set of private companies preparing for public markets.}

^{Our analysts break down seven of the most closely watched IPO prospects - including revenue, valuation range, and operating profile - in:}

^{The Seven Hottest IPOs On Wall Street’s 2026 Watchlist}

^{This report is available for free as a courtesy for a limited time only.}

Get your FREE copy ➡️

The Five Things a Working Loop Actually Does

Every turn of a working loop does five things, and skipping any one of them means it’s not really a loop, it’s just automation with an extra step.

1. Discovery —> it finds its own work. Reading yesterday’s CI failures, new tickets, or recent commits, rather than you telling it what to look at.

2. Handoff —> it hands the task to an agent, usually in its own isolated workspace (a git worktree, for example), so parallel agents don’t overwrite each other’s changes.

3. Verification —> a different agent checks the work. Not the one who did it.

4. Persistence —> it writes down what happened somewhere that survives the conversation: a markdown file, a ticket, a board.

5. Scheduling —> it does this again tomorrow, without a human pressing a button.

Drop discovery, and you’re back to manually assigning work. Drop verification, and you’ve built a machine that confidently ships whatever it produces. Drop persistence, and every morning starts from zero, with no memory of yesterday.

The One Part Everyone Gets Wrong: Letting The Agent Grade Itself

Here’s the uncomfortable finding that should shape how you build any loop: an AI agent is a bad judge of its own work.

Anthropic engineer Prithvi Rajasekaran documented this directly while building long-running coding agents. In Anthropic’s engineering write-up, he found that when an agent is asked to evaluate what it just built, it tends to confidently praise its own outputو even when a human looking at the same result can immediately tell it’s mediocre. It’s not a stupidity problem. The agent that wrote the code is still sitting inside all the reasoning that led it there. It doesn’t see the result objectively; it sees the story it told itself while building it.

His fix, borrowed from generative adversarial networks (the “GAN” architecture used in image generation, where one network builds and a separate network tries to catch fakes): split the builder and the judge into two different agents, running independently, with different instructions. Tuning a separate evaluator to be genuinely skeptical turned out to be far easier than trying to convince a generator to be hard on itself.

He took it one step further for frontend work: the evaluator didn’t just read the code, it opened the actual page using browser automation, clicked through it, took screenshots, and judged based on what actually happened, not what the code looked like it should do.

Claude Code has since turned this into an actual command, /goal, where you give the agent a condition (”all tests in test/auth pass and lint is clean”) and a separate, fresh model checks after every turn whether that condition is genuinely true, rather than trusting the agent’s own “looks done to me.”

This is the same principle banks use when a large transfer needs two different people to enter and approve it. The person who did the work will trust their own work. The check only means something if someone else, human or model, is doing it.

If you remember one thing from this whole piece, make it this:

the hard part of loop engineering was never getting the loop to run. It’s building in something that can tell it no.

Unmissable events in July:

If you could listen in on the architecture discussions happening inside Google, AWS, Salesforce, or DeepMind, what would you ask?

^{ARC 2026: Software Architecture in the Age of AI brings together architects and engineering leaders to discuss the engineering decisions behind building AI systems that actually work in production.}

^{Most AI conferences spend a lot of time talking about models and tools. This one is focused on architecture, governance, reliability, inference, and the challenges of operating AI systems at scale.}

^{Some of the sessions include:}

• ^{David Ping (AWS) on how solutions architecture is evolving in the age of AI.}

• ^{Dr. Ali Arsanjani and Juan Bustos (Google) on governance and engineering patterns.}

• ^{Rohit Bhardwaj (Salesforce) on AI inference at scale.}

• ^{Dr. Chi Wang (Google DeepMind) and Dr. Xiao Ma (Splunk) on multi-agent architectures.}

• ^{Imran Ahmad on designing reliable AI systems.}

• ^{Michelle Brenner (Netflix) on engineering leadership in the age of AI.}

^{📅 25th - 26th July
🎟️ Use code AGENT50 for 50% OFF the early bird price. First 10 sign-ups only!}

Sign Up NOW 👉

My Take, and What’s Next

Here’s where I land on all of this, for what it’s worth.

I don’t think loop engineering is hype dressed up in a new name. The reasoning behind it holds up. Once an agent can reliably do a bounded task, the next bottleneck really is you being the one who has to notice the task and type the prompt. Automating that part is a legitimate step up the stack, not a rebrand of something we already had.

But the generator/evaluator problem above is the part I’d pay closest attention to if I were trying this for the first time. It’s tempting to build the fun parts first, the scheduling, the automation, the “look, it runs by itself” moment and treat verification as something you’ll tighten up later. I think that’s backwards. A loop with no real evaluator isn’t a smaller version of a good loop. It’s a different, riskier thing: a system that ships its own mistakes on a schedule, confidently, while you’re not looking. Get the checking agent right before you get the scheduling right.

That’s the part I wanted to spend real time on this week, which is why I split this into two posts instead of cramming everything in.

Next week, Part 2 gets practical. I’ll walk through two loops that are actually running in production right now. Then we’ll get into what it actually costs you when a loop goes wrong and I’ll close with a five-step plan you can use to build your own first loop this weekend, without needing anything close to Stripe’s setup.

If this one was useful, Part 2 is where it gets hands-on. See you next week.

Subscribe now

Let’s Collaborate

Hey there, I’m Hana, co-founder and technical writer at AI Agents Simplified. If you’re building in the AI space, have feedback on today’s post, or want to explore a collaboration, let’s chat! You can find me on LinkedIn or drop me an email. I read every message and would love to hear from you.

This issue is brought to you by HubSpot

Before we get into today’s issue, I wanted to share a quick note about an event I’ll be attending at the end of July. The Packt team has been kind enough to offer AI Agents Simplified readers a 40% discount code, so if you’re interested, you can check it out too.

Beyond Prompts: Learn to Build AI Agents with OpenAI Codex

^{AI coding is evolving from code generation to agentic software development.}

^{OpenAI Codex can do far more than autocomplete code. It can inspect repositories, plan implementations, write tests, debug failures, review pull requests, and help developers complete complex engineering tasks. The key is knowing how to guide these AI agents with the right workflows, guardrails, and review practices.}

^{In this live, hands-on bootcamp, you’ll build practical AI-assisted development skills through 10 real-world engineering workflows. Working inside a prepared project, you’ll learn how to explore unfamiliar codebases, implement features safely, review AI-generated changes, refactor confidently, and ship production-ready code.}

^{The bootcamp is led by Chuck McCullough, a software architect, former IBM engineer, and AI engineering expert with more than 30 years of experience building enterprise software and training developers worldwide.}

^{Exclusive offer for AI Agents Simplified readers: Use code AISIM40 to get 40% off your registration.}

SIGN UP NOW 👉

Here's a question worth asking about any agent you've built: what can it actually do, versus what you think it can do?

Most of us connect an agent to a tool, test it a few times, and move on. The agent answers questions correctly, so we assume it's safe. But "answers correctly" and "can't be talked into doing something bad" are two completely different things. And right now, most agents in production have never been checked for the second one.

That gap is the subject of this issue. It's also one of the best sections in Agentic AI with Microsoft Foundry, which spends real time on exactly this problem:

• what your agent's tools can do?

• who's watching when it uses them?

• and how to test it before an attacker does?

The Question Changed, and Most People Didn't Notice!

For a while, building an agent just meant getting good answers out of a model. Now agents call tools. They read your database, open tickets, send emails, touch your codebase. Once an agent can act, a bad answer isn’t just embarrassing. It’s a bad action, taken on your behalf!

This shift is why security researchers created an entirely new list of risks just for agents. In December 2025, OWASP published its first Top 10 for Agentic Applications. It’s different from the older list made for chatbots. It adds things like “agent goal hijack” and “tool misuse”, problems that only exist once an agent has real access to real systems.

The numbers back this up. HackerOne, the platform companies use to report security bugs, found that AI-related vulnerability reports jumped 210% in a year. Reports specifically about prompt injection, tricking a model into ignoring its instructions, jumped 540%.

Agentic AI with Microsoft Foundry covers this exact risk in its chapter on agent tools. The authors point out something simple but easy to miss: if you connect an agent to an external tool server and don’t explicitly limit what it can access, the agent inherits everything that server can do. For something like GitHub, that can include deleting a repository or force-pushing to a protected branch. Nobody asked for that. It just comes with the connection, by default.

The Fix Is Small. That’s Why People Skip It.

Here’s the part that’s easy to fix and easy to forget: give your agent a list of exactly which tools it’s allowed to use, instead of handing it everything.

The book walks through this using Microsoft’s Agent Framework, where you pass an allowed_tools list when you set up the connection. Want your agent to read issues and pull requests? Give it exactly that, and nothing else. No delete. No force-push. No access to anything you didn’t explicitly approve.

The authors put it in terms that make it click: treat this list the way you’d treat a permissions policy for an employee. Review it before you launch. Only add new tools after testing them somewhere that isn’t your live environment. It’s not something you set once, but it’s something you keep checking as your agent grows.

This one idea, on its own, is worth taking a look at the book. It’s the difference between an agent that can only do what you meant, and one that can do whatever the tool server happens to allow.

100+ ChatGPT Prompts to Revolutionize Your Day

^{Supercharge your productivity with HubSpot's comprehensive guide. This free resource is your fast track to AI mastery:}

• ^{Industry-Specific Use Cases: 15+ real-world applications across various sectors}

• ^{Productivity Guide: 21 best practices to 10x your efficiency with AI}

• ^{Prompt Powerhouse: 100+ ready-to-use prompts for immediate implementation}

• ^{Challenge Buster: Overcome common AI hurdles with expert strategies}

^{Plus, in-depth sections on email composition, content creation, customer support, and data analysis.}

Find Your Guide Here 👉

Reading Isn't the Risk, Writing Is.

Limiting tool access handles part of the problem. The other part is what happens the moment your agent actually decides to use one of those tools.

Agentic AI with Microsoft Foundry explains how Microsoft Foundry handles this. By default, any tool call needs a yes before it runs. The agent pauses, someone (or some system) approves or rejects it, and only then does it continue. The book shows the exact code for this approval step, including how to tell the difference between a “read” action and a “write” action.

That distinction matters more than it sounds like it should. An agent that only looks things up is low risk. An agent that can close a ticket, send an email, or delete something is not. The book’s advice:

Auto-approve the reads, and require a human or a policy check for anything that writes. You get a record of every action too, which matters a lot if you’re in healthcare, finance, or anything with rules attached.

Test Your Agent Like Someone's Trying to Break It

Even with a short tool list and an approval step, you still don’t know how your specific agent holds up against someone actually trying to trick it. That’s what red-teaming is for, and it’s stopped being something only security teams do.

Agentic AI with Microsoft Foundry dedicates a full section to this, using Microsoft Foundry’s built-in Red Team agent. You pick which risks to test for, choose the kinds of attacks to try, and it runs them against your agent automatically. The book walks through the entire setup, screen by screen, including how many attempts to run per risk category (they recommend 5 for a real deployment, not 1).

The book also makes a point that’s easy to miss:

This isn’t a one-time check before launch. Every time you change a prompt, add a tool, or switch models, the risk changes with it. The teams doing this well run these tests every time they release a change, the same way you’d run any other test before shipping code.

90% of AI Runs Through This Company

^{The biggest AI wins often come from companies you don’t hear about every day.
Case in point:
The database provider now embedded into the big three cloud platforms - with access to 90% of the market.
You’ll find the name and ticker of this newly-minted giant in our 10 Best AI Stocks to Own in 2026 report, along with:}

• ^{The chip giant holding 80% of the AI data center market.}

• ^{A plucky challenger with 28% revenue growth forecasts.}

• ^{A multi-cloud operator with high-end analyst targets near $440.}

^{Plus 6 other AI stocks set to take off.}

Get the full list while it’s still FREE

The Next Step

If your agent touches anything real, a database, an inbox, a repository, anything that writes, its tool permissions deserve the same attention you’d give a production password. Most teams haven’t gotten there yet.

Agentic AI with Microsoft Foundry is the clearest walkthrough I’ve found for actually doing this. The tool permission pattern, the approval step, and the red-team setup, all with real code and real screenshots from Microsoft Foundry. If you’re building agents that touch anything important, it’s worth having next to you.

Let’s Collaborate

Hey there, I’m Hana, co-founder and technical writer at AI Agents Simplified. If you’re building in the AI space, have feedback on today’s post, or want to explore a collaboration, let’s chat! You can find me on LinkedIn or drop me an email. I read every message and would love to hear from you.

References

• Agentic AI with Microsoft Foundry: Design and develop intelligent AI solutions and autonomous agents with Microsoft’s Agent Framework

• OWASP Top 10 for Agentic Applications for 2026

• When AI becomes the attack surface

This issue is brought to you by HubSpot

Before we get into today’s issue, I wanted to share a quick note about an event I’ll be attending at the end of July. The Packt team has been kind enough to offer AI Agents Simplified readers a discount code, so if you’re interested, you can check it out too. It’s a rare chance to be part of an event with some genuinely big names, and I’m looking forward to it.

The Next Challenge for AI Builders: Software Architecture

Join ARC 2026, Packt’s flagship 2-day virtual summit, bringing together software architects, CTOs, engineering leaders, and AI practitioners to explore how AI is transforming modern software systems.

Hear from industry leaders including Dr. Ali Arsanjani (Google Applied AI), David Ping (AWS), Juan Bustos (Google), Dr. Chi Wang (Google DeepMind), and more as they cover AI governance, agentic systems, reliable AI architectures, engineering leadership, and AI inference at scale.

📅 25th - 26th July
🎟️ Use code ARCH50 for 50% off the early bird price. First 10 sign-ups only!

Sign up NOW 👉

Last December, in Issue #31, we laid the groundwork for the autonomous future. We broke down how AI was shifting from strict, step-by-step instructions to mission-driven, goal-oriented agents. We introduced you to the anatomy of an agent, the "Model, Tools, and Orchestration" triad, using our Gourmet Chef analogy, and explored the 5-step "Think, Act, Observe" problem-solving loop.

Well, the landscape has moved incredibly fast since then. Google and Kaggle have just launched the fourth iteration of their Intensive AI Agents Course, and the focus has entirely shifted from "can we build an agent?" to "how do we trust and scale agents in production?"

Let’s get into what’s new in this updated curriculum and go a bit deeper into the cutting-edge concepts driving the next wave of agentic engineering.

1. From "Vibe Coding" to Spec-Driven Development

Previously, we discussed how the agentic era demands a shift from verification to validation. Asking “Did we build the right product?” instead of “Did we build the product right?”.

The new course takes this a massive step forward by completely redefining the Software Development Lifecycle (SDLC). We are moving away from casual “vibe coding” (where you just prompt an AI and copy-paste errors back to iterate) into disciplined Agentic Engineering.

The core formula driving this is Agent = Model + Harness. The model itself is only about 10% of the equation; nearly 90% is the “harness”. The sandboxes, tools, orchestration, and guardrails that make the system reliable.

Most importantly, code is now considered entirely disposable. Developers no longer need to form an emotional attachment to their codebase. Instead, we are entering the era of Spec-Driven Development. The behavioral specification - often written in BDD (Behavior-Driven Development) or Gherkin formats - is now the durable, version-controlled source of truth, while the code itself is just a temporary implementation that can be cleanly regenerated by an agent in minutes.

2. Solving “Context Rot” with Agent Skills

Last December, we looked at how an agent uses its orchestration layer to dynamically think and act. But as developers started giving agents more tools and massive system prompts, a new problem emerged: Context Rot. If you dump too many instructions into a prompt, the agent gets distracted, picks the wrong tools, and forgets its rules.

To solve this, Google introduced Agent Skills. Think of skills as highly encapsulated playbooks for your agent. Instead of bloating the system prompt, a skill is a simple folder containing a skill.md file, alongside specific scripts and assets.

This architecture leverages a brilliant concept called progressive disclosure. At startup, the agent only loads a tiny metadata footprint into its context window. The detailed execution guidelines and scripts are only fetched dynamically when the specific task demands it. This allows your agent to hold dozens of specialized capabilities without triggering context rot or blowing through your token budget.

Demystify AI for Your Business in Just 4 Steps

Overwhelmed by AI? HubSpot's FREE guide cuts through the noise. Get the ultimate crash course for non-technical entrepreneurs who want to harness AI's power without getting lost in the jargon.

"AI for Business Builders" delivers:

• A 4-part roadmap to AI mastery

• Jargon-free explanations of large language models

• Practical prompt engineering tips you can use today

• Real-world examples of AI boosting businesses like yours

Arm yourself with the knowledge to make informed AI investments and skyrocket your startup's growth.

Download Your Free Guide Now

❤️ The best way to keep our mission going - at zero cost to you - is by checking out this free guide from our sponsor.

3. Open Protocols: The “USB-C” for Agents

In Issue #31, we compared an agent’s tools to a chef’s physical kitchen - ovens, knives, and ingredients. But wiring up that kitchen has become a technical debt nightmare. If you have 5 models and 10 tools, building custom connections means writing and maintaining 50 fragile integrations. The classic “N to M complexity crisis”.

To fix this, the industry is rallying behind standardized open protocols. The Model Context Protocol (MCP) has emerged as the universal “USB-C” for agents, allowing them to connect to external tools, databases, and APIs with linear scalability.

Furthermore, we are shifting away from massive “single-agent monoliths” toward decentralized networks of micro-agents. This is powered by the Agent-to-Agent (A2A) protocol, a lingua franca that allows specialized agents to discover each other, negotiate, and delegate tasks autonomously. Need an agent to output a dynamic interface for the user? There’s even an Agent to UI (A2UI) protocol for rendering trusted interface components on the fly.

4. The New Trust Paradigm: Trajectory-Aware Evaluation

If code is disposable and agents are acting autonomously, how do you actually trust the system? Traditional software security relies on binary gates. If the code compiles and credentials pass, you’re good. But an agent can have perfectly valid access tokens and still execute misaligned intent.

The updated course introduces Effective Trust, a continuous, dynamic metric evaluated across supply chain, identity, and runtime behavior. We also learned about a dangerous phenomenon called “fragile success traps”. For example, an agent tasked with optimizing database latency might just download 100,000 rows into local memory. It passes the final output test, but its reasoning is dangerously flawed.

Because of this, evaluation can no longer be a black box. It must be trajectory-aware. Using tools like OpenTelemetry, developers must capture every intermediate reasoning step and API call to evaluate the path the agent took, not just the final output. To secure this, organizations are adopting a triad of autonomous defense teams: Red teams to inject adversarial prompts, Blue teams to monitor the runtime bill of materials, and Green teams to automatically refactor and quarantine anomalies

Take the FREE course 👉

2026’s Hidden Breakout Stocks

Our analysts just went through every sector, chart, and earnings trend to find the 10 stocks most likely to dominate 2025 - and they compiled them all in the Top 10 Best Stocks to Own in 2026.

In this free report, you’ll discover companies primed for a Fed-fueled rally - from AI powerhouses to dividend machines. These names are already attracting billions in institutional inflows, so this is your chance to position early.

Get the Top 10 Best Stocks to Own in 2026 now, before it’s gone for good.

Get the FREE report 👉

❤️ The best way to keep our mission going - at zero cost to you - is by checking out this free guide from our sponsor.

We’ve officially moved past the honeymoon phase of prompt engineering. The tools discussed in this course; spec-driven generation, agent skills, open protocols, and continuous trajectory evaluation; are what will actually put AI agents into enterprise production environments.

Until next time, keep building and keep validating!

Want to test your new skills? The Kaggle course culminates in a Capstone project where you can build agents for business, concierge tasks, or social good. Get out there and start Agentic Engineering!

Take the FREE course 👉

Essential Watch

Before you go, if you want to see these concepts in action and go even deeper down the rabbit hole, I highly encourage you to watch this closely related video:

Drop a comment if you liked this issue or shoot me a message on LinkedIn! I would love to hear from you (If you’re preparing for a job interview as AI Engineer, let’s study together 😁)

Leave a comment

Until next time, keep building and keep validating 👋

This issue is brought to you by MarketBeat

Three phrases showed up in AI conversations recently and spread fast: harness engineering, loop engineering, and Hermes Agent. They’re not branding. They’re not hype. They describe real shifts in how developers build and run AI agents, and they’re related to each other in a specific order.

In this post, I explain each one clearly, then show you how they fit together.

Why these terms exist at all

To understand them, you need one piece of background.

For a while, the main skill for working with AI was prompt engineering, writing good instructions to get good outputs. One message in, one answer out. That worked well for simple tasks.

Then in 2025, context engineering became the bigger concern. The question shifted from “how do I phrase this?” to “what information does the model need to solve this?” You’re now thinking about what documents, history, and data to put in front of the model.

By 2026, both of those were table stakes. Agents were running for hours, making dozens of decisions in a row, touching real files and real systems, without a human watching every step. That’s when three new problems surfaced:

• what environment do you put the agent in

• how do you keep it running reliably without you

• what tool actually implements all of this?

Those problems got names!

What Is Harness Engineering

Harness engineering is the discipline of designing the environment an AI agent runs inside. Not the model. Not the prompt. The environment.

Specifically, which tools the agent can call, where it gets its information, what validation logic checks its work, and when it should stop.

In February 2026, Mitchell Hashimoto, the person who built HashiCorp and co-created Terraform, published a blog post describing a habit he’d developed while working with AI agents. Every time an agent made a mistake, instead of just correcting it in chat, he built a permanent fix into the agent’s environment so the mistake couldn’t happen again. He called it “engineering the harness.” OpenAI and Anthropic both published follow-up articles within weeks. The term stuck!

Why It Matters

Without a harness, an agent is only reliable in demos.

Here’s a concrete example. OpenAI ran an internal experiment in late 2025 where a three-person team wrote zero code themselves for five months, everything was written by their coding agent, Codex. The result was one million lines of code and 1,500 merged pull requests.

But to get there, they had to solve four real problems that prompt engineering couldn’t fix:

No shared understanding: The agent kept guessing at naming conventions and architectural patterns because nothing told it what the project’s rules were. The fix wasn’t a longer prompt, it was a structured docs/ directory that the agent navigated to find exactly what it needed at runtime.

Human review was the bottleneck: The agent was generating code faster than humans could check it. The fix was wiring the agent to run its own tests, screenshot its own UI paths, and meet a concrete standard (a service had to start in under 800 milliseconds) before marking a task done.

Architectural drift: Without constraints, the agent repeated whatever patterns it found in the codebase, including bad ones. The fix was a strict dependency structure enforced by linters that blocked non-compliant code automatically.

Silent technical debt: Problems accumulated silently over weeks. The fix was scheduled background agents that scanned for deviations and opened automatic refactoring pull requests.

None of those fixes touched the prompt. All of them touched the environment.

The short version…

Harness engineering is what you build when a single good prompt isn’t enough. It’s the layer that makes an agent reliable at scale, tools, constraints, feedback loops, and validation logic, all designed by a human so the agent doesn’t have to guess.

This Market Shift Makes The Mag 7 Look Outdated

The Magnificent Seven won’t lead the market forever.

Our analysts believe that shift is already underway.

See the 7 stocks they think could lead by 2026.

Send My Free Report ➡️

❤️ The best way to keep our mission going - at zero cost to you - is by checking out this free guide from our sponsor.

What Is Loop Engineering

Loop engineering is the practice of designing the system that prompts your agent, instead of typing each prompt yourself.

The term was popularized on June 7, 2026, when Addy Osmani, an engineering lead at Google Chrome, published an essay that named and structured a practice people had been doing in pieces. The post built on two observations that had already spread fast:

Peter Steinberger, the developer behind the OpenClaw agent project, had posted: “You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.” That post reportedly reached 6.5 million views in days.

Boris Cherny, the head of Claude Code at Anthropic, was putting it even more directly: “I don’t prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.”

How it works

A loop is a repeating cycle. The agent takes an action, gets real feedback from its environment, test results, linter output, error messages, uses that feedback to decide what to do next, and keeps going until a goal condition is met. You define the goal once. The loop runs until it’s done.

The difference from a one-shot prompt is significant. A prompt asks the model for an answer. A loop puts the model inside a system that keeps working toward a real outcome. The model writes prompts, runs checks, and iterates. You design the system; the system does the work.

Osmani’s essay gave the loop a specific anatomy, six parts that a well-functioning loop needs:

• Automations —> scheduled triggers that kick off the loop on a timer or event, not because you typed something

• Worktrees —> isolated working directories so parallel agents don’t overwrite each other’s files

• Skills —> reusable instruction files that package what the agent should know about a project, so it doesn’t guess every run

• Connectors —> links to external tools (GitHub, Linear, Slack) so the agent can take real actions, not just suggest them

• Sub-agents —> a second agent that checks the first one’s work; the same model shouldn’t grade its own output

• Memory —> a file or board outside the conversation that holds what’s been done, what’s open, and what failed, so the next run doesn’t start from zero

The Relationship to Harness Engineering

Loop engineering sits one layer above harness engineering. The harness is the environment. The loop is what drives the agent through that environment, repeatedly, with verification.

You can have a harness without a loop, a single well-equipped agent run. But a loop without a harness is unstable: no constraints, no feedback, no memory. They work together.

Addy Osmani said it directly:

loop engineering is one level above harness engineering. The harness makes an agent capable. The loop makes it autonomous.

What Is Hermes Agent

Hermes Agent is an open-source autonomous AI agent built by Nous Research. It was released on February 25, 2026, under an MIT license. It lives on your own server, not a cloud service someone else controls and it works with any language model, Claude, GPT-4o, Gemini, local models via Ollama, whatever you choose.

By June 2026, it had crossed 175,000 GitHub stars!

What makes it different

Most AI agents are stateless. You close the session, the agent forgets everything. Your project context, your preferences, what worked last time, what failed, gone. Next session starts from scratch.

Hermes doesn’t work that way.

When Hermes completes a task, it writes a reusable skill file, a structured record of what it did and how. It stores the outcome in persistent memory. Next time a similar task comes up, it loads that skill and applies it. The longer it runs on a given set of tasks, the better it gets at them.

Nous Research calls this a closed learning loop. The agent doesn’t just execute, it learns from execution and adjusts.

Other practical things it can do: run scheduled cron jobs while you’re not at your computer, connect to 16+ messaging platforms, and use MCP (Model Context Protocol) to hook into external services. There’s no telemetry, no cloud dependency, and no vendor lock-in.

What it isn't

It’s not a coding assistant tied to an IDE. It’s not a chatbot wrapper. It’s closer to a background process that runs on your infrastructure, accumulates knowledge over time, and gets better as it works.

If your main need is coding help within a single project session, Claude Code is still better at that specific job. Hermes is the right choice when you work across multiple projects, want persistent memory, and want an agent running on your own infrastructure.

Turn AI into Your Income Engine

Ready to transform artificial intelligence from a buzzword into your personal revenue generator? Our groundbreaking guide "200+ AI-Powered Income Ideas" is your gateway to financial innovation in the digital age.

Inside you'll discover:

• A curated collection of 200+ profitable opportunities spanning content creation, e-commerce, gaming, and emerging digital markets—each vetted for real-world potential

• Step-by-step implementation guides designed for beginners, making AI accessible regardless of your technical background

• Cutting-edge strategies aligned with current market trends, ensuring your ventures stay ahead of the curve

Download your guide today and unlock a future where artificial intelligence powers your success. Your next income stream is waiting.

Get Your Guide 👉

❤️ The best way to keep our mission going - at zero cost to you - is by checking out this free guide from our sponsor.

Which one should you care about?

If you’re using AI for one-off tasks, none of these terms are urgent. A good prompt with good context still handles most individual requests.

If you’re building AI agents that run for more than a few minutes, touch real systems, or need to run reliably without you watching, you need a harness. No amount of prompting replaces it.

If you want those agents to run on a schedule, overnight, or in parallel, you’re building loops. The six components Osmani listed are a practical checklist.

If you want all of that in an open-source, self-hosted package that works with any model and remembers what it learns, Hermes Agent is worth looking at.

The progression is prompt → context → harness → loop. We’re currently at the loop layer. The previous three didn’t disappear; they’re just not the bottleneck anymore.

Let’s Collaborate

Hey there, I’m Hana, co-founder and technical writer at AI Agents Simplified. If you’re building in the AI space, have feedback on today’s post, or want to explore a collaboration, let’s chat! You can find me on LinkedIn or drop me an email. I read every message and would love to hear from you.

This issue is brought to you by MarketBeat

There's a pattern I keep seeing in how people approach agent development. They reach for a framework first and reverse-engineer the concepts later, if ever. It works, until it doesn't! When something breaks or you're making a non-trivial architectural decision, you realize the abstraction was hiding more than you thought. What exactly happens when an LLM "calls a tool"? How does memory actually persist? Why does the ReAct loop work?

ai-agents-from-scratch by pguso is a GitHub repo that answers those questions directly. It has 3.5k stars and 530 forks, which is a decent signal, but what makes it genuinely useful is the approach: 14 self-contained examples, running locally using node-llama-cpp, with no framework abstractions in the way.

The repo's philosophy is simple: learn by building, understand deeply, then use frameworks wisely. That order matters.

What The Repo Covers

The learning path runs through 14 numbered examples, each one building on the last. It starts with basic LLM interaction and ends with advanced reasoning patterns like Tree of Thought, Graph of Thought, and Chain of Thought.

Examples 1–6 cover the fundamentals. You'll work with system prompts, test reasoning on quantitative problems, process requests in parallel, and stream responses. These aren't flashy, but they're where most practitioners have shaky understanding. Knowing why batch processing works the way it does, or what token budgets actually control, changes how you design real systems.

Example 7 is the inflection point. This is where function calling is introduced, and the repo labels it correctly: “this is where text generation becomes agency.” You define tools, specify their parameters in JSON Schema, and watch the LLM decide when and how to invoke them. If you’ve used agents without building this from scratch, you probably have an incomplete mental model of this step. It’s worth doing once.

Example 8 adds memory. Specifically, persistent memory across sessions: facts, preferences, retrieval strategies. Most agent tutorials treat memory as a given, but the implementation details matter. How do you store state? When do you retrieve it? This example makes those decisions explicit.

Example 9 introduces the ReAct pattern: Reason → Act → Observe, repeated until the problem is solved. This is the foundation of how almost every modern agent framework operates under the hood. Working through it manually, without a framework, is clarifying in a way that reading about it isn’t.

Examples 10–14 go into more advanced territory: Atom of Thought planning, error handling with retry policies and fallback strategies, Tree of Thought for searching competing reasoning branches, Graph of Thought for merging multiple sources into a consistent output, and Chain of Thought for auditable step-by-step decision making. Each one has a working implementation and a decision guide explaining when to use it over the alternatives.

MarketBeat releases “Top 10 Stocks” to own report

While the crowd’s chasing yesterday’s headlines, the real money’s brewing in the shadows.

2026’s megatrends - AI’s takeover, consumer empires doubling down, aerial taxis rewriting travel - are already here.

And Wall Street’s too busy navel-gazing to notice.

Our 10 Stocks Set to Soar in 2026 report cracks the code on those megatrends, giving you the name and ticker of the companies at the forefront of each one.

MarketBeat’s analysts sifted the chaff to deliver these 10 picks…

And they could very well be your ticket to profits the masses will miss.

Free today, after that, it’s strictly for paid members.

Act now or watch from the sidelines later!

Get your report here 👉

❤️ The best way to keep our mission going - at zero cost to you - is by checking out this free guide from our sponsor.

How To Setup

You’ll need Node.js 18+ and at least 8GB of RAM (16GB recommended). The examples run on local GGUF models.

• You download the model

• drop it in a ./models/ folder

• and run npm install

There’s also an optional OpenAI path (Example 2) if you want to compare local vs. hosted inference. Useful for internalizing the tradeoffs around latency, cost, and data privacy in a concrete way.

What happens at 3:50 PM

3 PM hits. Volume picks up. By 3:50, the market's a freight train.

That's when my crew and I strike.

A few wins from recent sessions:

• $790 in pure profit

• 185% on a single position

• $1,500 winners closing the bell

We're not predicting tomorrow's headlines. We're not reading tea leaves. We're watching where $55 billion flows in the final hour and riding it.

It happens today. And tomorrow. And every trading day after.

Your first week is FREE

❤️ The best way to keep our mission going - at zero cost to you - is by checking out this free guide from our sponsor.

Why this is worth your time

Frameworks hide complexity intentionally. That’s the point of them. You don’t have to think about error handling, retry logic, or tool parsing formats every time you build something. But that abstraction has a cost. When something breaks, or when you’re designing under real constraints, the gap in your mental model shows.

This repo is not a replacement for frameworks. The README is explicit about that, and I’d say the same thing. It’s a foundation. Once you’ve built a ReAct loop from scratch, you’ll understand what LangGraph is doing when you use it. Once you’ve implemented memory manually, you’ll make better decisions about when to use a vector store vs. simple key-value state.

The 14-example structure is well-paced. Each example is self-contained, the docs are clear, and the progression is logical. You can work through the whole thing in a focused weekend, or dip into specific sections to close a particular gap.

It’s built for people who want to actually understand AI agents, not just use them. If that’s you, it’s worth cloning.

Let’s Collaborate

Hey there, I’m Hana, co-founder and technical writer at AI Agents Simplified. If you’re building in the AI space, have feedback on today's post, or want to explore a collaboration, let’s chat! You can find me on LinkedIn or drop me an email. I read every message and would love to hear from you.

This issue is brought to you by MarketBeat

Are you flying blind when launching early-stage products or new AI features?

Traditional scoreboards like the RFM model fall flat here. Because RFM is strictly retrospective, it leaves you completely in the dark regarding early churn risks. The real intelligence layer sits unparsed and ignored in unstructured text reviews and daily user feedback.

A foundational 2026 study published in the Journal of Computing and Security solves this infrastructure gap. Titled “Behavioral Loyalty Prediction from Customer Reviews in E-Commerce: A Deep Learning and Explainable AI Approach”, authored by Pedram Kazemi Esfe and Fakhroddin Noorbehbahani, this work completely transforms messy, multi-modal unstructured data into highly interpretable operational intelligence.

Problem

Every business wants to know if their users are actually loyal or just passing through. Traditionally, companies look at purchase history using methods like the RFM model, which checks how recently, how often, and how much a customer has bought.

• The big problem with this approach is that it is strictly retrospective.

• It requires a solid foundation of past purchases to calculate a score, meaning it is useless for net-new customers or modern community platforms lacking strict transaction logs.

• If you are launching a new AI agent feature, standing up an early-stage MVP, or trying to figure out why users are churning before their second purchase, historical purchase data leaves you completely in the dark.

What We Did Previously

In the early days of analytics, product and marketing teams tried to solve this blindspot with basic machine learning models (like Artificial Neural Networks or Decision Trees) applied to simple spreadsheets or rigid surveys.

• When analysts attempted to use natural language customer reviews, they usually oversimplified the data.

• They focused strictly on simple positive or negative sentiment labels (polarity rules), entirely missing the rich behavioral nuances of the customer voice.

• These old methods created circular logic where the data you put in ended up artificially dictating the score you got out.

• They completely lacked the predictive depth needed for real-time, proactive churn intervention.

  ---

Why We Want Change in Our Technical Pipelines

To move past these shallow analytics, the new research introduces an advanced deep learning architecture that reads the actual natural language text your customers leave in their feedback. Instead of waiting for lagging financial reports, the model converts unstructured text into actionable intelligence through a multi-stage pipeline:

• Transformer Embedding Branches: The pipeline processes text using state-of-the-art Large Language Models, specifically BERT, RoBERTa, ALBERT, GPT-2, and Qwen 1.5-0.5B—to extract deep semantic intent and convert natural language into dense spatial vectors.

• Parallel Structured Processing: It provisions an isolated branch to process structured categorical metadata simultaneously, specifically handling Review Scores and a binary flag tracking whether the user left a written title.

• Intelligent Data Fusion with TabTransformer: The extracted text token embeddings and tabular metadata are fused using a TabTransformer module coupled with Convolutional Neural Networks (CNNs). This ensures massive, high-dimensional text vectors do not completely eclipse critical, small structured metrics (like title presence).

• Evolutionary Calibration (Genetic Algorithm): Rather than performing an arbitrary hyperparameter search, the authors route the entire network topology through a Genetic Algorithm (GA). Operating over 50 generations with a population of chromosomes, the GA iteratively breeds configurations, exploring a search space of 19,440 possible combinations automatically.

To see if this deep learning approach was actually worth the engineering effort, the researchers ran an ablation study to see what happens when you strip the AI away. Here is what they found out:

10 AI Stocks to Lead the Next Decade

AI is fueling the Fourth Industrial Revolution – and these 10 stocks are front and center.

One of them makes $40K accelerator chips with a full-stack platform that all but guarantees wide adoption.

Another leads warehouse automation, with a $23B backlog – including all 47 distribution centers of a top U.S. retailer – plus a JV to lease robots to mid-market operators.

From core infrastructure to automation leaders, these companies and other leaders are all in The 10 Best AI Stocks to Own in 2026.

Free today. Not forever!

Grab it before the paywall locks 👉

❤️ The best way to keep our mission going - at zero cost to you - is by checking out this free guide from our sponsor.

What the Results Teach Us

The optimized AI model proved incredibly accurate, correctly predicting customer loyalty over 92% of the time. But the real gold for product builders lies in understanding what data actually moves the needle:

• Words Speak Louder Than Stars: When the system is forced to evaluate customer loyalty without reading the actual written review text, predictive accuracy collapses by nearly 37%. This proves that simple numerical ratings hide the true qualitative health of the user experience.

• The “Subject Line” Clue: Simply checking whether a customer bothered to leave a written title or subject line provides a massive intent signal. Highly retained, loyal users are over 11 times more likely to include a written review title compared to churning or disengaged users.

• Skipping the Star Rating: Remarkably, the AI system worked just as well when it had to “guess” the sentiment from open-ended natural language text as it did when given explicit, numerical star ratings. This is a game-changer for community forums, social media comments, or early MVPs where users do not leave formal ratings.

Stripping the Black Box with Explainable AI (XAI)

Deep learning models are notoriously difficult to trust in production due to their opaque, black-box nature. If an automated system flags a user as an attrition risk, product and engineering teams need to know exactly why.

To resolve this, the authors integrated SHAP values (SHapley Additive exPlanations), a game-theoretic approach developed by authors such as Mosca et al. (2022) that assigns an explicit importance attribution to every single token (word) within a raw review:

• Token-Level Attribution: Local explanations generate force plots indicating which specific words push an agent’s prediction toward retention (e.g., “excellent”, “fast” visualized with positive force) versus words driving the prediction toward churn (e.g., “delay”, “waiting” visualized with negative force).

• Global Vocabulary Mapping: Aggregating SHAP values across the entire 58,000+ user dataset maps overarching vocabulary triggers, showing that terms like “reliable” strictly shape positive boundaries, while terms like “unfortunately” aggressively drive negative boundaries.

If your technical pipeline relies only on lagging financial numbers, you only find out your AI agent has a bad UX when it is too late to save the user. Integrating an NLP-driven intent loop directly into your backend architecture changes the paradigm entirely, giving you the power to pick up on micro-signals of churn and intervene proactively.

Let’s Collaborate

As for myself, I’m Arian, Product Manager and writer at AI Agents Simplified. I absolutely love geeking out over the intersection of product management and e-commerce, supercharged by deep learning and AI.

If you’re an engineer, founder, or growth operator working on similar projects and want to bounce ideas around, or if you are interested in collaborating on future deep dives, let’s connect. Shoot us a message or email, I read and reply to every single one.

Resources

• Authors: Pedram Kazemi Esfe, Fakhroddin Noorbehbahani

• Title: Behavioral Loyalty Prediction from Customer Reviews in E-Commerce: A Deep Learning and Explainable AI Approach

• Link: Behavioral Loyalty Prediction from Customer Reviews in E-Commerce

• Journal: Journal of Computing and Security (JCS), http://www.jcomsec.org

• Publication Details: Online published 21 June 2026; Volume 13, Number 1, Spring 2026, pp. 35-57

This issue is brought to you by Piere

I spent a good chunk of last week trying to debug an AI agent that was supposed to handle a fairly standard customer support workflow. I gave it a detailed system prompt, hooked up a few basic tools to query an internal database, and let it run.

During local testing, it ran fine. It answered basic questions, fetched the right account details, and seemed perfectly stable. But the moment I pushed it to a staging environment with real-world, messy user queries, the whole thing broke down. The agent started hallucinating arguments for tool calls. It got stuck in infinite loops trying to correct a minor API timeout. When a user asked a multi-part question, it completely forgot the initial constraints halfway through generating the response.

The problem I ran into was not an issue with the underlying language model. The problem was that I was falling into the trap of asking one single agent to handle every step of the process at once.

Why “Bigger Prompts” Are Destroying Your Accuracy

Building your first agent is deceptively easy, which is exactly why it is so dangerous. We tend to write a massive system prompt, attach half a dozen tools, and ask a single agent to execute a highly complex task.

When you force a single agent to handle intent parsing, planning, tool execution, and self-correction all at once, you overwhelm its cognitive capacity. Every time the agent makes a tool call, the result gets appended to its context window. After a few turns, that window is bloated with JSON responses, error messages, and intermediate thoughts. The agent loses track of the original goal because the signal-to-noise ratio has completely degraded.

I was reading 30 Agents Every AI Engineer Must Build by Imran Ahmad recently, and he hits the nail on the head regarding this exact bottleneck. He breaks down why these overloaded, single-agent loops inevitably fracture under production loads. What makes his explanation so useful is that he doesn’t just point out the flaw; he maps out the exact architectural shift required to fix it.

The path to production reliability requires abandoning this do-it-all approach and adopting distributed, multi-agent orchestration.

Stop Making Your Agent Do Everything (Do This Instead)

Instead of one agent trying to do everything, you have to separate the cognitive load into specialized roles.

In a multi-agent architecture, you might introduce a “Router” agent whose only job is to look at the user’s initial input and classify the intent. That router doesn’t have access to any external databases. It just delegates the task to a specific “Worker” agent. That worker is equipped with only the one or two tools necessary for that exact job, keeping its context clean and focused. Finally, the worker passes its output to a “Critic” agent, which evaluates the result against the initial constraints before anything is ever returned to the user.

Ahmad dedicates a massive section of his book to this progression. He provides the actual blueprints for moving from simple reactive scripts to what he calls chain-of-agents orchestrators. I found his breakdown of tool invocation patterns particularly helpful. He shows exactly how to restrict an agent’s toolset so it doesn’t get confused, and how to write explicit schemas that force the agent to format its output correctly before passing it down the chain.

Get your copy of his book here.

The Missing Link: Getting Your Agents to Communicate

Moving from a single agent to a team of specialized agents makes logical sense, but it introduces a completely new set of hard engineering challenges. You no longer have one brain holding all the information; you have to manage distributed state.

If your worker agent finds a crucial piece of data, how does the critic agent know about it without having to re-read the entire interaction history? You need a formal communication protocol. Agents have to pass payloads to one another without losing the overarching context of the user’s request.

This is another area where Ahmad’s book serves as a phenomenal desk reference. He goes deep into the mechanics of memory-augmented multi-agent systems. He explains how to separate short-term working memory, the stuff the agents are currently passing back and forth, from long-term semantic memory stored in vector databases. It is a highly pragmatic guide to building out the shared state required for frameworks like LangGraph and CrewAI to actually function at scale.

What if your money could drive itself to your goals?

Any bank, any account, Piere makes it possible. In seconds, Piere analyzes your spending, income, wants, and goals, then creates fully automated plans for your money to follow.

• Save money automatically when you get paid, your money moves itself to the right account at the right interest rate

• Repay debt and stay debt free - Piere smartly determines which accounts to pay and when for the biggest impact

• Spend smarter, Piere keeps only the money you need for monthly expenses in your checking, moving the rest to high-yield accounts for safekeeping (and less temptation)

Get started in just seconds, and if you don’t grow by at least $120 in your first year, we’ll give you back the difference.

Learn More 👉

How to Stop Endless Execution Loops Forever

The hardest part of orchestrating multiple agents isn’t getting them to talk to each other; it is figuring out what to do when they disagree.

If you build a workflow where a research agent pulls data and a compliance agent reviews it, you will eventually hit a wall where the compliance agent rejects the work. If you haven’t engineered a fallback path, the system will either fail silently or get trapped in an endless loop of rejection and regeneration.

You have to build consensus mechanisms. 30 Agents Every AI Engineer Must Build does an excellent job of outlining how to handle these conflicts. It walks through building arbitration workflows where an orchestrator agent evaluates the competing outputs, adjusts the constraints, and forces the system to refine the answer rather than crashing. It shows you how to design these systems with human-in-the-loop checkpoints, ensuring that when the agents genuinely cannot reach a safe consensus, the process pauses and waits for your input.

The Next Step

If you are currently struggling to transition brittle, single-agent prototypes into stable workflows that you can actually trust in production, you need to understand these multi-agent architectures.

Ahmad’s book is dense, practical, and heavily focused on structural engineering over vague AI theory. It maps out the exact progression you need to take to build resilient systems.

I highly recommend keeping a copy on hand as you build. You can grab your copy through the link below.

Get your copy of his book here.

P.S. To save you time, I’ve also put together a short reading roadmap for the text. It breaks down exactly which chapters you should focus on depending on what you are actively building right now.

If you want a copy, drop a comment below and I’ll send it directly to you.

Leave a comment

This issue is brought to you by Novu Connect

AI agents are having their definitive “demo magic” moment. You open a browser, connect a model to a handful of tools, write a clean system prompt, and suddenly it feels like you have engineered a fully autonomous digital employee. In a controlled environment, it looks alive. It reads documents, summarizes email threads, searches a database, creates engineering tickets, and orchestrates API calls seamlessly. Everyone in the room smiles, the investors are sold, and the immediate conclusion is that half the company’s workflows can be automated overnight.

However, the moment you put that agent in front of real users, the illusion cracks. The agent begins to lose track of critical constraints, calls entirely wrong tools, updates incorrect database records, and confidently reports that an action succeeded when the backend actually rejected it. It loops endlessly on failed operations and leaks data across user sessions. This exposes an uncomfortable reality in contemporary engineering: agents are easy to demo because underlying large language models are highly impressive, but they are incredibly hard to ship because production environments are entirely unforgiving. The core challenge is not getting an LLM to talk; the real challenge is architecting the controlled backend environment that surrounds it.

The Reality Engine vs. The Reasoning Engine

To bridge the gap between a fragile prototype and a robust product, we must establish context discipline. A production-ready AI agent is not a standalone brain; it is an actor inside a heavily restricted ecosystem. While the model serves exclusively as the reasoning engine capable of planning, classifying, and summarizing, the backend serves as the reality engine. The model itself possesses no inherent knowledge of your live database, tenant-level permissions, concurrency locks, or compliance status. It only knows what you deliberately inject into its context window.

When engineering teams treat the context window like an unstructured data dump, throwing in raw chat logs, massive documentation files, and unvalidated tool outputs, they rely on hope rather than architecture. A reliable backend must systematically enforce restrictions before the model ever reasons. The system must algorithmically determine user roles, enforce workspace isolation, slice data down to the bare minimum required for the task, and aggressively hide parameters that the model should never see. A more capable model cannot fix a messy environment; a stronger model inside an undisciplined context window simply generates more expensive, complex errors.

The Golden Rule: Propose and Validate

The single most critical architectural pattern for reliable agents dictates that the model must never directly mutate business state. The agent should not directly execute an API call to update a database, refund a transaction, dispatch an email, or alter an enterprise workflow status. Instead, the model proposes an action, a strict backend validation layer audits the proposal, and only then does a boring, predictable execution system run it.

Consider an agent operating within a CRM where a user commands it to follow up with everyone from a recent demo. The model generates proposed actions, such as drafting specific emails, setting individual tasks, and moving deal stages. Before any packets are sent, the backend adult in the room checks for contact ownership, verification records, marketing opt-out status, duplication risks, and whether the operating user holds the necessary authorization. The agent provides the flexible, creative interface, but the backend must remain strictly unyielding.

To achieve this, tool calling must be fundamentally decoupled from direct execution. Tool calling provides a structured schema, but it offers zero guarantees of factual or operational correctness. A model can easily hallucinate IDs, pass incomplete arguments, choose the wrong tool entirely, or repeat a failing operation in an infinite loop. Therefore, the pipeline must transition sequentially from the Model to a Proposed Action, through a dedicated Validator, into the Executor, across the Result layer, through an Agent Feedback mechanism, and finally to the Responded State. The middle validation layer acts as a classic software guard, evaluating strict state machines, rate limits, input formatting, and risk profiles. AI has not removed the need for traditional backend engineering rules; it has made them vastly more important.

Stop Rebuilding Integrations

Bring Your Claude Agents to Any Channel in Minutes

If your Claude agent is trapped inside your app, it’s time to move the conversation to where your customers actually live. Without the headache of maintaining custom infrastructure.

Novu Connect is the new standard in Agent Communication Infrastructure (ACI). It bridges the gap between your AI agents and any messaging platform, including Slack, Teams, WhatsApp, and email. You don’t need to spend weeks building pipelines; just pick a template, connect your tools, and you’re live in under 2 minutes.

No infrastructure to babysit, no custom plumbing to rebuild. Just immediate, two-way conversations with your customers.

Join the challenge: deploy your agent in under 2 minutes and unlock a free month of our Pro tier.

Join the Challenge NOW 👉

❤️ The best way to keep our mission going - at zero cost to you - is by checking out this free guide from our sponsor.

Engineering the Repair Loop and Restructuring Memory

When errors inevitably occur, traditional software fails loudly by returning explicit exception codes, while agents tend to fail silently by inventing answers or pretending an action succeeded. Brittle systems halt completely when a tool returns an error, but a production-grade agent relies on a continuous repair loop where failures are converted into semantic feedback. If the backend safely blocks an invalid action, it should pass a structured explanation back into the model’s context. By informing the agent that a specific invoice is already locked or a chosen engineer is assigned to another workspace, the model can dynamically recover, apologize, adjust its parameters, or ask the user for clarification.

This disciplined approach must extend to agent memory, which is frequently misunderstood as a magical, infinite cache. Storing every conversational turn and historical variable indefinitely introduces stale context, data privacy violations, and severe latency issues. For business workflows, the relational database or enterprise CRM must remain the immutable source of truth. The agent should possess short-term working memory to maintain current task continuity and high-level summaries for past interactions, but it should never memorize static states. The agent does not need to remember if an invoice was settled or if a user is a workspace administrator; it must explicitly query the backend for those facts on every relevant turn.

The Architecture of a Trustworthy Agent

Behind a clean, simple user interface, a dependable agent infrastructure demands eight distinct, decoupled operational layers working synchronously:

1. The Identity Layer: Establishes precise user authentication, workspace boundaries, role-based access control, and strict data visibility limits.

2. The Context Builder: Curates a highly selective, relevant, and secure slice of information to feed into the model’s immediate reasoning window.

3. The Tool Registry: Maintains a strict directory of valid schemas, input expectations, clear descriptions, and pre-calculated risk levels for every accessible action.

4. The Policy and Permission Engine: Segregates operations by risk, determining which low-impact tasks can run autonomously and which high-impact workflows require multi-party or human approval.

5. The State Validator: Audits the model’s logical proposals against current business data to ensure compliance with real-world state machines.

6. The Execution Layer: A heavily logged, entirely predictable system that communicates directly with external APIs, databases, and core infrastructure.

7. The Feedback Loop: Translates the real-world success, partial failure, or execution constraints back into clear inputs the model can use to plan its final output.

8. The Observability Layer: Captures deep, end-to-end trace chains tracking the exact user prompt, the injected context, the model’s internal decisions, and the validation logs.

Without comprehensive decision tracing, debugging an agent becomes complete guesswork, and guesswork does not scale in enterprise software. Human approval flows are not a programmatic bottleneck; they are a prerequisite for utility. By separating low-risk actions like drafting and summarizing from high-risk mutations like data deletion and billing updates, you establish controlled autonomy. This allows organizations to gradually earn trust, moving deliberately from supervised assistance to full automation only after verified testing, evaluation runs, and reliable rollback strategies are safely in place. Ultimate industry adoption will not belong to the teams building the most dramatic, conversational personalities, but to the engineers who quietly build the most dependable operating environments around the model.

What happens at 3:50 PM

3 PM hits. Volume picks up. By 3:50, the market's a freight train.

That's when my crew and I strike.

A few wins from recent sessions:

• $790 in pure profit

• 185% on a single position

• $1,500 winners closing the bell

We're not predicting tomorrow's headlines. We're not reading tea leaves. We're watching where $55 billion flows in the final hour, and riding it.

It happens today. And tomorrow. And every trading day after.

Tap here to join us. First week is free.

❤️ The best way to keep our mission going - at zero cost to you - is by checking out this free guide from our sponsor.

What is your take?

When engineering agentic pipelines inside your organization, where are you currently facing the steepest bottleneck: getting the model to accurately reason through technical dependencies, or building the backend validation infrastructure necessary to trust it with live operations? Let us know in the comments below!