Agentic AI DevOps: Session 2 – Introduction to AI & ML

Agentic AI DevOps Bootcamp · Session 2 · Summary Notes

The story in one line: a machine learns the way a new hire does. It studies lots of examples with the answers shown, finds the pattern, and then handles new cases on its own.

Where we are heading

Our goal in this bootcamp is to build agentic AI for DevOps use cases. To get there with confidence, we need strong basics first. The path looks like this:

AI & ML foundations → Embeddings & transformers → LLMs & prompt engineering → Generative AI & RAG → AIOps use cases → Agentic architecture (MCP & harness engineering) → DevOps agents

MLOps is a separate track, not tied to the agentic flow, so we cover it at the end. Whenever we integrate a DevOps tool into an AI system, we will first do a quick refresher on that tool.

Why start with basics? You could jump straight into an LLM, wire it up and build an agent. But you would miss what is happening under the hood: how these models “think” like a human. The basics are foundations for any AI role, whether you build DevOps agents tomorrow or become an AI or ML engineer. It takes only two or three sessions, and they become your building blocks.

Chapter 1: What is Artificial Intelligence?

Artificial Intelligence (AI) is the broad umbrella: anything where we bring human-like intelligence into machines.

Four major areas sit under that umbrella:

A quick picture: a self-driving car captures the lane as an image, understands it, and adjusts the steering, just as you would with your eyes and hands. That’s AI at work.

Where do we focus?

As IT professionals, most of us deal with data. Customers use applications, data lands in databases, and that’s our world. That’s why ML and NLP are where most of our use cases live:

• ML → learn from historical data, predict, recommend.
• NLP → chatbots, and DevOps assistants where engineers chat with an agent about infrastructure, logs and root-cause analysis.

So we will go deep on these two. ML first, then NLP.

Chapter 2: How can a machine “predict”? Let’s play a game

Machine learning means machines learn from historical data and predict what comes next. But how? Let’s do it ourselves.

Game 1: What comes after 2, 4, 6, … ?

You instinctively do three things:

1. Look at the data you have: 2, 4, 6.
2. Find the pattern: each number is the previous one + 2.
3. Apply it: 6 + 2 = 8.

You didn’t guess. The pattern gave you an algorithm (the math to apply), and the algorithm gave you the answer.

Try 1, 3, 5, 7, … The same method works: find the pattern first, then apply the math. Or go, stop, go, stop, … The pattern is alternation, so the next is go.

The big lesson: the machine’s prediction is only as good as the pattern it finds. Find the right pattern → right algorithm → correct predictions. Find the wrong pattern → wrong math → wrong predictions.

Game 2: milk, bread, butter, … ?

This one is different. There is no single exact formula. The pattern is similarity: they are all milk-related products. Next could be cheese, but milk bread or other dairy items could also be valid. Cheese is directly derived from milk, so it carries the highest weight (probability). When several answers are possible, we score each option and pick the highest.

Prediction vs. recommendation

In the loan case, the agent isn’t recommending. It is predicting one outcome from the application details. In the checkout case, there could be n products to suggest, so the system scores them all and shows the top pick, which keeps changing with the factors involved.

Where ML is mainly used today: prediction and recommendation systems, always learning from data, finding the pattern, identifying the algorithm and applying the numbers.

A note on LLMs and agents: ChatGPT, Claude and the agents you’ll build are not “classic” ML prediction systems like the ones above. You don’t need to train a model to use them. But an LLM is itself a model built with ML techniques, and understanding these basics tells you how it works inside. That’s why we start here.

Chapter 3: What does the data look like? Structured vs. unstructured

Structured data: neatly arranged in rows and columns. Each column is a feature (a specification, in plain language).

Other examples: a loan application (credit score, loan amount, term, asset value) and credit-card transactions (time, place, amount → is it fraud?).

Unstructured data: no rows, no columns, no tidy features. Examples: images, audio, video, articles, social-media comments. Show a machine a photo and ask “car or bus?” That’s unstructured data.

Why does it matter?

Machines handle the two types differently:

Both are machine learning. To cover everything, we need to understand statistical ML and deep learning, and we will do both in this course.

Chapter 4: The new engineer story: Training and inference

This is the core story of today. Requirement: classify incoming emails as Spam or Not Spam.

Forget machines for a moment. Imagine you hire an engineer for this job. He has no prior knowledge. How will he know what is spam?

Stage 1: Training

You collect thousands of emails: some spam, some not spam. You give them to him with both parts:

• Input (feature): the email body.
• Output (label): Spam or Not spam, the correct answer.

He studies why each email was labelled the way it was and learns the patterns: what spam usually looks like, what legitimate mail looks like.

The label in the training data is called the truth (the actual value). It’s there for learning. Later, in real life, nobody will hand him the answer. He must predict it.

Stage 2: Testing: the exam

Before putting him on the real job, you test him. You hand over a brand-new email he has never seen and ask: spam or not? He uses what he learned. His answer may be right or wrong.

Stage 3: Inference

Once he’s on the real job, classifying live emails, that is called inference.

Training = learning from data where the answers are known.
Inference = using what was learned to predict on new, real data.

Now replace the engineer with a machine

The process is identical. You give training data to the machine, it finds the patterns using the labels as the truth, and training is complete. In practice, training is just a program, typically Python code, that you run on your data.

The outcome of training is called the machine learning model (ML model).

ML model = the trained machine learning algorithm, with the patterns it learned already loaded in it.

When you send data to a model for inference, it doesn’t learn anything new. It simply applies what it already has, the equation built from the patterns, and gives you a prediction.

Chapter 5: What decides how accurate the predictions are?

Two things:

1. Quality of the training: how well the learning was done.
2. Quality of the data: if the training data has wrong labels, the engineer (or machine) learns the wrong patterns, so garbage in, garbage out.

“How much data do I need?”

There’s no ground rule. Think of the engineer again:

• Train him on 100 emails → he makes mistakes in production.
• Retrain on 1,000 → better than before, but still some mistakes.
• Add better quality data or change the training approach → keep improving.

Start with a sensible baseline, then iterate. Common sense applies: you can’t train on a single email. Maybe start with thousands, not one. In real projects, models go through multiple rounds of retraining until they reach the accuracy you expect.

Also remember that every training run costs compute and money, so we can’t retrain endlessly without thinking.

Where does data science fit in?

Suppose you train a model 100 times and it’s wrong every time. Is it your fault? Often it’s the data quality or the training approach. That’s where the data science team comes in. They analyze and pre-process the data, maintain its quality, run their own experiments, and hand you recommendations and baselines. By the time it reaches you, the data is in better shape and you follow their guidance. You’re not reinventing the wheel. As an ML or AI engineer, or an engineer building AI applications, you carry that work forward.

Key terms cheat sheet

Quick recap

1. AI is the umbrella. ML (learn from data) and NLP (human language) are the two areas we focus on.
2. Machines predict by finding the pattern → deriving the algorithm → applying the math, not by guessing.
3. Prediction = one definite answer. Recommendation = score the options and pick the best.
4. Structured data (tables) → statistical ML. Unstructured data (images, audio, text) → deep learning.
5. Training teaches with known answers; inference uses what was learned on new data.
6. The output of training is the ML model.
7. Accuracy depends on data quality and training quality; expect to retrain and iterate.

Check yourself

1. In the sequence 5, 10, 15, … what are the pattern, the algorithm and the prediction?
2. Is “approve or reject this loan” a prediction or a recommendation system? What about “customers also bought…”?
3. A photo is uploaded and the model must say “car or bus”. Is that structured or unstructured data? Which approach fits?
4. During training, what is the label? Will it be available during inference?
5. Your model keeps making mistakes in production. Name two things to check.

Up next

Session 3: ML basics in depth. Classification vs. regression, how a model actually finds its pattern, and the math behind it. After that, we move into practical Python.