<![CDATA[ ML - freeCodeCamp.org ]]> https://www.freecodecamp.org/news/ https://cdn.freecodecamp.org/universal/favicons/favicon.png <![CDATA[ ML - freeCodeCamp.org ]]> https://www.freecodecamp.org/news/ Eleventy Sun, 04 Oct 2026 06:06:23 +0000 60 <![CDATA[ What a Machine Learning Model is and How to Make One ]]> https://www.freecodecamp.org/news/what-a-machine-learning-model-is-and-how-to-make-one/ 6aa1b782434f42bd4da9b37c Wed, 09 Sep 2026 19:46:10 +0000 Machine learning can sound much more complicated than it actually is. You hear words like models, training, features, datasets, predictions, and algorithms, and it can feel like you need a PhD in mathematics before you're allowed to write your first machine learning program.

But at its core, machine learning is about getting a computer to learn patterns from examples and then use those patterns to make predictions about new examples. If you've ever learned to recognize a cat after seeing lots of cats, you already understand the basic idea.

In this tutorial, we're going to build a real machine learning model in Python. We'll start with a tiny dataset, train a model to predict whether a student might pass an exam based on the number of hours they studied, and then use the trained model to make predictions about new students.

Prerequisites

You don't need any previous machine learning experience to follow this tutorial. We'll introduce each machine learning concept as we go.

But having a basic understanding of Python will make the tutorial easier to follow. You should be comfortable with:

  • Creating and using variables

  • Working with Python lists

  • Writing basic if/else statements

  • Calling functions

  • Reading and running a Python program

  • Using a terminal or command prompt to run commands

You should also have:

  • Python installed on your computer

  • A text editor or code editor, such as VS Code

  • A terminal or command prompt

  • An internet connection to install the required Python library

You do not need prior knowledge of machine learning, scikit-learn, statistics, or advanced mathematics. I'll explain the machine learning concepts and code step by step.

What You Will Learn

The goal isn't just to get the code working. We're going to understand what each important line does, why we need it, and what's actually happening behind the scenes.

By the end, you'll have a much clearer mental model of what machine learning actually is and how you can start building models yourself.

What Is a Machine Learning Model?

A machine learning model is a program that has learned a pattern from data.

That definition is intentionally simple.

Suppose you show a child several animals and tell them which ones are cats. After seeing enough examples, the child might notice that cats usually have certain characteristics: whiskers, four legs, fur, a particular face shape, and so on. When they see a new animal, they can use what they learned to make a guess about whether it is a cat.

A machine learning model works in a similar way, except instead of looking at animals, it works with numbers and data.

For example, suppose we give a model information about students:

Hours Studied Exam Result
1 Fail
2 Fail
3 Fail
4 Pass
5 Pass
6 Pass

The model can look at these examples and discover a relationship between studying time and exam results. It might learn that students who study more tend to have a higher chance of passing.

We aren't explicitly writing that rule into the program. The model learns the relationship from the examples.

That's the key idea behind machine learning.

Machine Learning vs Traditional Programming

This becomes much clearer when you compare machine learning with traditional programming.

In traditional programming, you give the computer rules and data, and it produces an answer.

For example:

Data + Rules → Answer

You might write:

hours = 5

if hours >= 4:
    print("Likely to pass")
else:
    print("Likely to fail")

Here, you explicitly created the rule:

hours >= 4

The computer isn't learning anything. You told it exactly what to do.

Machine learning flips this around. Instead of manually writing the rule, you give the computer examples:

Examples + Correct Answers → Machine Learning Model

The model figures out a useful pattern from those examples.

Then you can give the trained model new data:

New Data + Trained Model → Prediction

That difference is one of the most important concepts to understand.

What Does "Training" Mean?

Training is simply the process of teaching a machine learning model using examples.

Imagine that you're teaching someone to recognize whether a student is likely to pass an exam.

You give them examples:

1 hour → Fail
2 hours → Fail
3 hours → Fail
5 hours → Pass
6 hours → Pass

After looking at enough examples, they start noticing a pattern.

Machine learning training works similarly.

We give the algorithm data, and the algorithm adjusts the model so that its predictions become better at matching the examples it's been given.

The word training sounds fancy, but the basic idea is just to give the model examples and let it learn a useful pattern.

What Is a Dataset?

A dataset is simply a collection of data.

For our project, we can represent our dataset using Python lists.

Suppose we have:

hours = [1, 2, 3, 4, 5, 6, 7, 8]

and:

results = [0, 0, 0, 1, 1, 1, 1, 1]

Here, we're using numbers to represent the exam results.

We'll use:

0 = Fail
1 = Pass

So our data means:

1 hour → Fail
2 hours → Fail
3 hours → Fail
4 hours → Pass
5 hours → Pass
6 hours → Pass
7 hours → Pass
8 hours → Pass

The first list contains our input information. The second list contains the answers we want the model to learn from.

What Are Features and Labels?

Machine learning uses a few words that sound more complicated than they really are.

A feature is information that we use to make a prediction.

A label is the answer we want the model to predict.

In our example:

Hours studied → Feature
Pass/fail → Label

If we had more information about each student, we could have multiple features, such as:

Hours studied
Previous exam score
Homework completion rate
Attendance

Then the model could use all of those features to predict:

Pass or fail

So you can think of it like this: Features are the clues. The label is the answer.

What Kind of Machine Learning Are We Using?

Our example uses supervised learning. Supervised learning means we train the model using examples where we already know the correct answer.

For example:

Hours studied: 2
Correct answer: Fail

and:

Hours studied: 6
Correct answer: Pass

The model sees both the input and the correct output during training.

This is different from unsupervised learning, where the model receives data without being given the correct answers and tries to find patterns or groups on its own.

There are other types of machine learning too, including reinforcement learning, but supervised learning is a great place to start because the basic workflow is easy to understand.

What Are We Actually Going to Build?

We're going to create a Python program that:

  1. Creates a small dataset.

  2. Separates the inputs from the answers.

  3. Splits the data into training and testing data.

  4. Creates a machine learning model.

  5. Trains the model.

  6. Tests how well it performs.

  7. Gives the model new information.

  8. Uses the model to make a prediction.

Our final program will use a decision tree classifier from the scikit-learn library.

A decision tree is a machine learning algorithm that makes decisions by asking a series of questions about the data.

For our simple example, the model might learn a pattern similar to:

Did the student study enough hours?
        ↓
      Yes → Pass
      No  → Fail

Real decision trees can become much more complicated, but this gives you the basic idea.

Now let's get started building!

Step 1: Install Python

To follow along here, you'll need Python installed on your computer.

You can check whether Python is already installed by running:

python --version

You should see something similar to:

Python 3.12.0

The exact version doesn't have to match that example.

Step 2: Create a Project Folder

Create a folder called:

machine-learning-model

Inside that folder, create a file called:

model.py

Our project will eventually look like:

machine-learning-model/
└── model.py

Step 3: Install scikit-learn

We're going to use a Python library called scikit-learn.

scikit-learn provides many machine learning algorithms and tools, so we don't have to implement everything from mathematical equations ourselves.

Install it with:

pip install scikit-learn

We could technically build a simple machine learning algorithm ourselves, and doing that can be useful for learning the mathematics later. For our first practical model, however, using a machine learning library lets us focus on understanding the workflow.

Step 4: Import the Model

Open model.py and write:

from sklearn.tree import DecisionTreeClassifier

This line imports the DecisionTreeClassifier class from scikit-learn.

This structure:

from sklearn.tree

means we're getting something from scikit-learn's tree module.

Then:

import DecisionTreeClassifier

means we want to use the decision tree classifier.

After importing it, we can create a machine learning model with:

model = DecisionTreeClassifier()

The variable:

model

will represent our machine learning model.

At this point, the model hasn't learned anything. It's basically an empty model waiting for training data.

Step 5: Create Our Dataset

Now let's create the examples our model will learn from.

Add:

hours = [1, 2, 3, 4, 5, 6, 7, 8]

This list represents how many hours each student studied.

Then:

results = [0, 0, 0, 1, 1, 1, 1, 1]

This list represents whether each student passed.

Remember:

0 = Fail
1 = Pass

So the first student studied for one hour and failed.

The fourth student studied for four hours and passed.

The eighth student studied for eight hours and passed.

We now have examples that the model can learn from.

Step 6: Understand Why the Data Structure Matters

There's an important detail here. Machine learning libraries usually expect the input data to be structured in a particular way.

Our hours list looks like this:

[1, 2, 3, 4, 5, 6, 7, 8]

But scikit-learn expects features to be represented as a two-dimensional structure.

Why?

Because a machine learning dataset can contain multiple features.

Imagine this dataset:

Hours Studied | Attendance | Previous Score
2             | 80%        | 65
5             | 95%        | 82
7             | 98%        | 91

Each row represents one example.

Each column represents one feature.

So even though our current model only has one feature, we still need to represent it as a two-dimensional dataset.

We can do this using nested lists:

X = [
    [1],
    [2],
    [3],
    [4],
    [5],
    [6],
    [7],
    [8]
]

Each inner list represents one student.

The first student has:

[1]

meaning they studied one hour.

The second has:

[2]

and so on.

The uppercase X is a common convention for the feature data.

Now create the labels:

y = [0, 0, 0, 1, 1, 1, 1, 1]

The lowercase y is commonly used for the target or label values.

So we now have:

X = [
    [1],
    [2],
    [3],
    [4],
    [5],
    [6],
    [7],
    [8]
]

y = [0, 0, 0, 1, 1, 1, 1, 1]

You can think of X as:

Here are the clues.

And y as:

Here are the correct answers.

Step 7: Split the Data

We don't want to train and test the model using exactly the same examples.

That would be a bit like giving a student the exact questions they'll see on an exam and then saying:

“Wow, you got 100%. Great job.”

We haven't really tested whether they learned anything.

Instead, we'll separate our dataset into:

  • Training data

  • Testing data

The training data teaches the model, while the testing data checks whether the model can make predictions on examples it wasn't trained on.

Import the splitting function:

from sklearn.model_selection import train_test_split

Now we can write:

X_train, X_test, y_train, y_test = train_test_split(
    X,
    y,
    test_size=0.25,
    random_state=42
)

There is a lot happening in this one line, so let's unpack it.

train_test_split()

This function randomly divides our data into training and testing portions.

We pass it:

X

which contains our features.

Then:

y

which contains our labels.

The argument:

test_size=0.25

means we want approximately 25% of our data for testing.

The remaining 75% is used for training.

random_state=42

The data is randomly split.

If you run the program multiple times without controlling the randomness, you might get a different split each time.

Setting:

random_state=42

makes the random split reproducible.

The number 42 isn't magical. You could use another integer.

For example:

random_state=10

would also work.

We use 42 simply because it's a common example value.

The Four Variables

The function returns four pieces of data:

X_train
X_test
y_train
y_test

X_train contains the features used to train the model.

y_train contains the correct answers for those training examples.

X_test contains the features used to test the model.

y_test contains the correct answers so we can compare them with the model's predictions.

Step 8: Create the Model

Now create our decision tree:

model = DecisionTreeClassifier()

This creates the model object.

Again, nothing has been learned yet. Think of it like buying a blank notebook: the notebook exists, but it doesn't contain your notes yet.

Step 9: Train the Model

Now we get to the line that actually teaches the model:

model.fit(X_train, y_train)

This is one of the most important lines in machine learning.

The .fit() method trains the model using the data we provide.

We give it:

X_train

which contains the examples.

Then:

y_train

which contains the correct answers.

The model looks for patterns connecting the features to the labels.

In our case, it's trying to discover a relationship between:

Hours studied

and:

Pass/fail

The exact internal process depends on the algorithm. A decision tree learns decision rules that split the training data into groups that become increasingly useful for predicting the target.

The important thing to understand right now is:

model.fit(X_train, y_train)

means:

Learn from these examples and their correct answers.

Step 10: Make Predictions

After training, we can give the model new data.

Suppose a student studied for five hours.

We can write:

prediction = model.predict([[5]])

Notice that we used:

[[5]]

instead of:

[5]

The outer list represents the collection of examples. The inner list represents the features for one example.

Since our model has one feature, that example contains one value:

[5]

So:

[[5]]

means:

Predict the result for one student whose feature value is five hours.

The model returns a prediction.

We can print it:

print(prediction)

You might see:

[1]

Remember:

1 = Pass
0 = Fail

So the model predicted that the student would pass.

Step 11: Convert the Prediction Into Human-Friendly Text

A prediction of:

1

isn't particularly friendly.

We can write:

if prediction[0] == 1:
    print("The model predicts: Pass")
else:
    print("The model predicts: Fail")

Let's look at:

prediction[0]

The model returns a list containing the prediction:

[1]

The [0] gets the first item.

Python starts counting list positions at zero.

So:

prediction[0]

means:

Give me the first prediction.

Then:

if prediction[0] == 1:

checks whether the model predicted 1.

If it did, we print:

The model predicts: Pass

Otherwise, we print:

The model predicts: Fail

Step 12: Test the Model

We shouldn't just make one prediction and assume the model is good.

We need to evaluate it.

First, make predictions for the test dataset:

predictions = model.predict(X_test)

Now:

predictions

contains the model's predictions for the examples it didn't see during training.

We can compare these predictions with:

y_test

which contains the actual answers.

scikit-learn provides an accuracy function:

from sklearn.metrics import accuracy_score

Then:

accuracy = accuracy_score(y_test, predictions)

The function compares the correct answers with the model's predictions.

If the model gets:

8 out of 10

correct, the accuracy would be:

0.8

We can turn that into a percentage:

print(f"Model accuracy: {accuracy * 100:.2f}%")

The * 100 converts:

0.8

into:

80

The:

:.2f

means we want two decimal places.

So the output could look like:

Model accuracy: 80.00%

A Very Important Warning About Accuracy

Accuracy is useful, but it doesn't tell you everything about a model.

Imagine you're trying to detect a rare disease.

Suppose:

99 people are healthy
1 person is sick

A terrible model could simply predict:

Everyone is healthy.

It would be 99% accurate.

But it completely failed at the thing we actually care about: identifying the sick person.

This is why machine learning developers use other evaluation metrics depending on the problem, including precision, recall, F1 score, mean squared error, and others.

For our beginner example, accuracy is enough to understand the basic workflow.

Step 13: Put Everything Together

Our complete beginner machine learning program looks like this:

from sklearn.tree import DecisionTreeClassifier
from sklearn.model_selection import train_test_split
from sklearn.metrics import accuracy_score


# Dataset
X = [
    [1],
    [2],
    [3],
    [4],
    [5],
    [6],
    [7],
    [8]
]

y = [
    0,
    0,
    0,
    1,
    1,
    1,
    1,
    1
]


# Split the data into training and testing sets
X_train, X_test, y_train, y_test = train_test_split(
    X,
    y,
    test_size=0.25,
    random_state=42
)


# Create the machine learning model
model = DecisionTreeClassifier()


# Train the model
model.fit(X_train, y_train)


# Make predictions on the test data
predictions = model.predict(X_test)


# Calculate accuracy
accuracy = accuracy_score(y_test, predictions)


print(f"Model accuracy: {accuracy * 100:.2f}%")


# Make a prediction for a new student
hours_studied = [[5]]

prediction = model.predict(hours_studied)


# Display the prediction
if prediction[0] == 1:
    print("The model predicts: Pass")
else:
    print("The model predicts: Fail")

Reading the Complete Code From Top to Bottom

The first three lines:

from sklearn.tree import DecisionTreeClassifier
from sklearn.model_selection import train_test_split
from sklearn.metrics import accuracy_score

import the tools we need.

Then:

X = [
    [1],
    [2],
    [3],
    [4],
    [5],
    [6],
    [7],
    [8]
]

creates the feature data.

Then:

y = [
    0,
    0,
    0,
    1,
    1,
    1,
    1,
    1
]

creates the labels.

Next:

X_train, X_test, y_train, y_test = train_test_split(...)

divides the dataset into training and testing data.

Then:

model = DecisionTreeClassifier()

creates the model.

Next:

model.fit(X_train, y_train)

trains it.

Then:

predictions = model.predict(X_test)

asks the trained model to make predictions about the testing examples.

Next:

accuracy = accuracy_score(y_test, predictions)

measures how many of those predictions were correct.

Finally:

prediction = model.predict([[5]])

asks the model to predict the result for a new student who studied for five hours.

That's the entire machine learning workflow.

What Is Actually Happening Inside the Model?

This is where machine learning gets more interesting.

When we run:

model.fit(X_train, y_train)

the decision tree doesn't simply memorize the phrase:

4 hours = Pass

It analyzes the training examples and looks for useful ways to split them.

For example, it might discover a rule similar to:

Is hours studied <= 3.5?

If yes:

Predict Fail

If no:

Predict Pass

The exact tree depends on the training data and algorithm settings.

If we added more features, the tree could make decisions using several pieces of information.

For example:

Is study time <= 3.5?

       Yes
        ↓
    Predict Fail

       No
        ↓
Is attendance <= 80%?

       Yes
        ↓
    Predict Fail

       No
        ↓
    Predict Pass

Again, our actual code doesn't manually create these rules.

The algorithm learns them from the training data.

What Does "Learning" Actually Mean?

This is one of the most misunderstood parts of machine learning.

The computer isn't learning in exactly the same way a human does. A machine learning algorithm uses mathematical procedures to adjust a model based on data.

Different algorithms learn in different ways. A decision tree searches for useful splits. A linear regression model learns numerical parameters that describe a relationship. A neural network adjusts many parameters using optimization algorithms. And da clustering algorithm groups similar examples together.

So "learning" is a convenient word for:

Using an algorithm to adjust a model so that it captures useful patterns in data.

What Is a Parameter?

A parameter is a value inside a machine learning model that is learned from data.

For example, in a simple linear model:

y = mx + b

the model might learn values for:

m
b

Those values determine the relationship between the input and output.

Neural networks can have millions or billions of learned parameters.

The important idea is that the model's behavior is controlled by values that are learned or adjusted during training.

Parameters vs Hyperparameters

These two terms are easy to confuse.

A parameter is generally learned from the training data, while a hyperparameter is something you configure before or during training.

For our decision tree, we could specify:

model = DecisionTreeClassifier(
    max_depth=3
)

Here:

max_depth=3

is a hyperparameter.

We're telling the algorithm:

Don't allow the decision tree to grow beyond a depth of three.

The model learns its internal decision rules from the data, while we choose the hyperparameter.

This distinction becomes increasingly important as you build more advanced models.

Why Do We Need Training and Testing Data?

Imagine you're studying for a math exam.

Your teacher gives you ten practice questions, and you memorize all ten answers.

Then the exam contains those exact ten questions, so you get everything correct.

Does that prove you understand mathematics? Not really. You might simply have memorized the examples.

Machine learning has a similar problem called overfitting. A model can become extremely good at the training data without becoming good at handling new data.

That's why we keep some examples separate. The model doesn't see the test examples during training. Then we can ask:

Can the model generalize what it learned to examples it hasn't seen before?

That ability to work on new data is one of the most important goals of machine learning.

What Is Overfitting?

Overfitting happens when a model learns the training data too specifically.

Imagine we give the model a very small dataset. Instead of learning the general pattern:

More studying tends to increase the chance of passing.

it might effectively memorize the specific examples.

That can make training performance look excellent while performance on new data is poor.

A model that performs well on training data but poorly on unseen data is often overfitting.

What Is Underfitting?

Underfitting is basically the opposite. The model is too simple to capture the important patterns in the data.

Imagine trying to predict someone's exam result using only one or two results.

That doesn't give the model enough useful information, and it might perform poorly on both training and testing data.

Good machine learning involves finding a model that's complex enough to learn useful patterns but not so complex that it simply memorizes the training examples.

Why Our Dataset Is Not a Real Machine Learning Dataset

Our eight examples are intentionally tiny.

A real machine learning project would usually use much more data.

For example, you might collect:

10,000 students

with features such as:

Hours studied
Attendance
Homework completion
Previous scores
Sleep duration

and a label such as:

Passed

Then the model could learn from thousands of examples.

Our tiny dataset is useful because we can understand every part of the process.

Step 14: Add More Features

Let's make our example slightly more realistic.

Instead of only using hours studied, suppose we have:

Hours studied
Attendance

We can represent each student like this:

X = [
    [2, 70],
    [3, 75],
    [4, 80],
    [5, 85],
    [6, 90],
    [7, 95]
]

Now each row contains two features.

For example:

[5, 85]

means:

5 hours studied
85% attendance

Our labels could still be:

y = [0, 0, 1, 1, 1, 1]

Now the model has more information to work with.

We could train it exactly the same way:

model.fit(X_train, y_train)

The difference is that the model now has two features instead of one.

Step 15: Make a Prediction With Multiple Features

Suppose we want to predict the result of a student who:

Studied for 5 hours
Had 90% attendance

We represent that as:

new_student = [[5, 90]]

Then:

prediction = model.predict(new_student)

The model uses both features to make the prediction.

This is how machine learning scales from simple examples to datasets with many columns.

What Happens When You Have Hundreds of Features?

The exact same basic concept applies.

Imagine predicting house prices using:

Number of bedrooms
Square footage
Number of bathrooms
Location
Age of house
Garage size
Lot size
Distance to school

Each one can become a feature. Then the model uses those features to predict a target:

House price

The basic structure remains:

Features → Model → Prediction

The difficult part becomes choosing useful data, selecting an appropriate algorithm, cleaning the data, evaluating the model, and making sure the model works well outside the training dataset.

What Is Regression?

So far, our model predicts categories:

Pass
Fail

This is a classification problem. Classification means predicting a category.

Examples include:

Spam / Not Spam
Cat / Dog
Fraud / Not Fraud
Pass / Fail

Regression is different. It predicts a numerical value.

For example:

House price = $425,000

or:

Temperature = 82.4°F

or:

Sales = $17,500

So a useful distinction is:

Classification → Predict a category

Regression → Predict a number

A Simple Regression Example

scikit-learn provides a model called LinearRegression.

Import it:

from sklearn.linear_model import LinearRegression

Create the model:

model = LinearRegression()

Then train it:

model.fit(X_train, y_train)

And make a prediction:

prediction = model.predict([[5]])

The workflow is almost identical.

That's one reason machine learning libraries are useful: once you understand the general workflow, learning new algorithms becomes much easier.

The General Machine Learning Workflow

Most beginner machine learning projects can be thought about using this sequence:

1. Collect Data

Get examples related to the problem you want to solve.

2. Clean the Data

Fix missing, incorrect, duplicated, or inconsistent information.

3. Select Features

Choose the information you want the model to use.

4. Choose a Model

Select an algorithm appropriate for the problem.

5. Split the Data

Separate training and testing examples.

6. Train

Use the training data to fit the model.

7. Evaluate

Measure how well the model performs.

8. Improve

Change the data, features, model, or hyperparameters.

9. Make Predictions

Use the trained model on new data.

10. Deploy

If the model is useful, integrate it into an application.

This workflow is much more important than memorizing the name of a particular algorithm.

How Machine Learning Fits Into Real Applications

A trained model is usually not the entire application.

Imagine you build a model that predicts whether an email is spam. You might eventually create:

Email
 ↓
Backend
 ↓
Machine Learning Model
 ↓
Prediction
 ↓
User Interface

The model is one component inside a larger software system.

The same idea applies to:

Recommendation systems
Fraud detection
Search engines
AI assistants
Image classification
Demand forecasting
Customer analytics

This is important for developers because machine learning engineering isn't only about training models. You also need to know how to build software around those models.

What Should You Learn After This?

Once you understand this basic project, there are several useful directions to explore.

Learn NumPy

NumPy is one of the fundamental Python libraries for numerical computing. You'll encounter arrays everywhere in machine learning.

Learn pandas

pandas is extremely useful for working with datasets.

For example:

import pandas as pd

You can load a CSV file:

data = pd.read_csv("students.csv")

and inspect it:

print(data.head())

This becomes much more useful once you start working with real datasets.

Learn Data Visualization

Libraries such as Matplotlib can help you visualize your data. For example, you might want to see whether exam scores increase as study hours increase.

Visualizing data can help you understand patterns before you even train a model.

Learn More Algorithms

Once decision trees make sense, explore:

Linear Regression
Logistic Regression
Random Forests
K-Nearest Neighbors
Support Vector Machines
Gradient Boosting
Neural Networks

You don't need to memorize all of them.

Focus on understanding what kind of problem each algorithm is designed to solve and what assumptions or tradeoffs come with it.

Learn the Mathematics

You can build useful machine learning applications without deriving every equation from scratch.

But if you want to understand machine learning deeply, mathematics becomes increasingly valuable.

Start with:

Algebra
Functions
Probability
Statistics
Linear Algebra
Calculus

Concepts such as derivatives and gradients become especially important when you start learning how neural networks train.

Here's a calculus course and a statistics handbook as well to get you started.

The Mental Model to Keep

When you're learning machine learning, don't let the terminology make everything feel more complicated than it is.

At the simplest level, think about machine learning like this:

You have examples, and each example contains information called features. Some examples also have known answers called labels.

You give those examples to a learning algorithm. The algorithm creates a model that captures patterns in the examples.

Then you give the trained model new information. The model uses the patterns it learned to make a prediction.

In code, the basic workflow looks like:

model = SomeMachineLearningModel()

model.fit(X_train, y_train)

predictions = model.predict(X_test)

That three-part structure is worth remembering.

model = ...

creates the model.

model.fit(...)

trains the model.

model.predict(...)

uses the trained model.

Everything else you learn about machine learning builds on this foundation.

Final Thoughts

A machine learning model isn't a magical brain sitting inside your computer. It's a mathematical model created by an algorithm that has learned patterns from data.

The most important shift in thinking is understanding that you don't always need to program every rule yourself.

With traditional programming, you might explicitly write:

if hours >= 4:
    result = "Pass"

With machine learning, you provide examples:

1 hour → Fail
2 hours → Fail
3 hours → Fail
4 hours → Pass
5 hours → Pass

and let the learning algorithm find a useful pattern.

Our project was intentionally small, but the same basic ideas appear in much larger systems. A recommendation engine, fraud detector, image classifier, and many other machine learning applications still have to deal with data, features, training, evaluation, and predictions.

Once you understand those fundamentals, terms like training, features, labels, classification, regression, overfitting, and models stop sounding like a collection of random AI vocabulary and start fitting into one connected idea.

You don't need to start by building the next giant AI system. Start with a tiny dataset, train one model, inspect its predictions, change something, and see what happens. That hands-on process is where machine learning starts becoming much easier to understand.

Happy coding!

]]> <![CDATA[ Model Packaging Tools Every MLOps Engineer Should Know ]]> https://www.freecodecamp.org/news/model-packaging-tools-every-mlops-engineer-should-know/ 69d3ca7840c9cabf443c9ce3 Mon, 06 Apr 2026 15:00:08 +0000 Most machine learning deployments don’t fail because the model is bad. They fail because of packaging.

Teams often spend months fine-tuning models (adjusting hyperparameters and improving architectures) only to hit a wall when it’s time to deploy. Suddenly, the production system can’t even read the model file. Everything breaks at the handoff between research and production.

The good news? If you think about packaging from the start, you can save up to 60% of the time usually spent during deployment. That’s because you avoid the common friction between the experimental environment and the production system.

In this guide, we’ll walk through eleven essential tools every MLOps engineer should know. To keep things clear, we’ll group them into three stages of a model’s lifecycle:

  • Serialization: how models are stored and transferred

  • Bundling & Serving: how models are deployed and run

  • Registry: how models are tracked and versioned

Table Of Contents

Model Serialization Formats

Serialization is simply the process of turning a trained model into a file that can be stored and moved around. It’s the first step in the pipeline, and it matters more than people think. The format you choose determines how your model will be loaded later in production.

So, you want something that either works across different frameworks or is optimized for the environment where your model will eventually run.

Below are some of the most common tools in this space:

1. ONNX (Open Neural Network Exchange)

ONNX is basically the common language for model serialization. It lets you train a model in one framework, like PyTorch, and then deploy it somewhere else without running into compatibility issues. It also performs well across different types of hardware.

ONNX separates your training framework from your inference runtime and allows hardware-level optimizations like quantization and graph fusion. It’s also widely supported across cloud platforms and edge devices.

Key considerations: This format makes it possible to decouple training from deployment, while still enabling performance optimizations across different hardware setups.

When to use it: Use ONNX when you need portability – especially if different teams or environments are involved.

2. TorchScript

TorchScript lets you compile PyTorch models into a format that can run without Python. That means you can deploy it in environments like C++ or mobile without carrying the full Python runtime.

It supports two approaches: tracing (recording execution with sample inputs) and scripting (capturing full control flow).

Key considerations: Its biggest advantage is removing the Python dependency, which helps reduce latency and makes it suitable for more constrained environments.

When to use it: Best for high-performance systems where Python would be too heavy or introduce security concerns.

3. TensorFlow SavedModel

SavedModel is TensorFlow’s native format. It stores everything – the computation graph, weights, and serving logic – in a single directory.

It’s also the standard input format for TensorFlow Serving, TFLite, and Google Cloud AI Platform.

Key considerations: It keeps everything within the TensorFlow ecosystem intact, so you don’t lose any part of the model when moving to production.

When to use it: If your project is built on TensorFlow, this is the default and safest choice.

4.  Pickle and Joblib

Pickle is Python’s built-in way of saving objects, and Joblib builds on top of it to better handle large arrays and models.

These are commonly used for scikit-learn pipelines, XGBoost models, and other traditional ML setups.

Key considerations: They’re simple and convenient, but come with real trade-offs. Pickle can execute arbitrary code when loading, which makes it unsafe in untrusted environments. It’s also tightly coupled to Python versions and library dependencies, so models can break when moved across environments.

When to use it: Best suited for controlled environments where everything runs in the same Python stack, such as internal tools, quick prototypes, or batch jobs.

It’s especially practical when you’re working with classical ML models and don’t need cross-language support or long-term portability. Avoid it for production systems that require security, reproducibility, or deployment across different environments.

5. Safetensors

Safetensors is a newer format developed by Hugging Face. It’s designed to be safe, fast, and straightforward.

It avoids arbitrary code execution and allows efficient loading directly from disk.

Key considerations: It’s both memory-efficient and secure, which makes it a strong alternative to older formats like Pickle.

When to use it: Ideal for modern workflows where speed and safety are important.

Model Bundling and Serving Tools

Once your model is saved, the next step is making it usable in production. That means wrapping it in a way that can handle requests and connect it to the rest of your system.

1. BentoML

BentoML allows you to define your model service in Python – including preprocessing, inference, and postprocessing – and package everything into a single unit called a “Bento.”

This bundle includes the model, code, dependencies, and even Docker configuration.

Key considerations: It simplifies deployment by packaging everything into one consistent artifact that can run anywhere.

When to use it: Great when you want to ship your model and all its logic together as one deployable unit.

2. NVIDIA Triton Inference Server

Triton is NVIDIA’s production-grade inference server. It supports multiple model formats like ONNX, TorchScript, TensorFlow, and more.

It’s built for performance, using features like dynamic batching and concurrent execution to fully utilize GPUs.

Key considerations: It delivers high throughput and efficiently uses hardware, especially GPUs, while supporting models from different frameworks.

When to use it: Best for large-scale deployments where performance, low latency, and GPU usage are critical.

3. TorchServe

TorchServe is the official serving tool for PyTorch, developed with AWS.

It packages models into a MAR file, which includes weights, code, and dependencies, and provides APIs for managing models in production.

Key considerations: It offers built-in features for versioning, batching, and management without needing to build everything from scratch.

When to use it: A solid choice for deploying PyTorch models in a standard production setup.

Model Registries

A model registry is essentially your source of truth. It stores your models, tracks versions, and manages their lifecycle from experimentation to production.

Without one, things quickly become messy and hard to track.

1. MLflow Model Registry

MLflow is one of the most widely used MLOps platforms. Its registry helps manage model versions and track their progression through stages like Staging and Production.

It also links models back to the experiments that created them.

Key considerations: It provides strong lifecycle management and makes it easier to track and audit models.

When to use it: Ideal for teams that need structured workflows and clear governance.

2. Hugging Face Hub

The Hugging Face Hub is one of the largest platforms for sharing and managing models.

It supports both public and private repositories, along with dataset versioning and interactive demos.

Key considerations: It offers a huge library of models and makes collaboration very easy.

When to use it: Perfect for projects involving transformers, generative AI, or anything that benefits from sharing and discovery.

3. Weights and Biases

Weights & Biases combines experiment tracking with a model registry.

It connects each model directly to the training run that produced it.

Key considerations: It gives you full traceability, so you always know how a model was created.

When to use it: Best when you want a strong link between experimentation and production artifacts.

Conclusion

Machine learning systems rarely fail because the models are bad. They fail because the path to production is fragile.

Packaging is what connects research to production. If that connection is weak, even great models won’t make it into real use.

Choosing the right tools across serialization, serving, and registry layers makes systems easier to deploy and maintain. Formats like ONNX and Safetensors improve portability and safety. Tools like Triton and BentoML help with reliable serving. Registries like MLflow and Hugging Face Hub keep everything organized.

The main idea is simple: don’t leave deployment as something to figure out later.

When packaging is planned early, teams move faster and avoid a lot of unnecessary problems.

In practice, success in MLOps isn’t just about building models. It’s about making sure they actually run in the real world.

]]> <![CDATA[ How to Build an MCP Server with Python, Docker, and Claude Code ]]> https://www.freecodecamp.org/news/how-to-build-an-mcp-server-with-python-docker-and-claude-code/ 69b09018abc0d95001a8f07f Tue, 10 Mar 2026 21:41:44 +0000 Every MCP tutorial I've found so far has followed the same basic script: build a server, point Claude Desktop at it, screenshot the chat window, done.

This is fine if you want a demo. But it's not fine if you want something you can ship, defend in an interview, or hand to another developer without a README that starts with "first, install this Electron app."

So I built an MCP server in Python, containerized it with Docker, and wired it into Claude Code – all from the terminal, no GUI required.

This article walks through the full loop in one afternoon: what MCP actually is, why it matters now that OpenAI and Google have adopted it, the real security problems nobody puts in their tutorial (complete with CVEs), and every command you need to go from an empty directory to a working tool.

If you're between jobs and need a portfolio project that shows you understand how AI tooling actually works under the hood, this is the one.

Table of Contents

What You Will Build

By the end of this tutorial, you will have:

  • A Python MCP server that exposes custom tools to any MCP-compatible AI client

  • A Docker container that packages the server for reproducible deployment

  • A working connection between that container and Claude Code in your terminal

  • An understanding of the security risks involved and how to mitigate the worst of them

The server we are building is a project scaffolder. You give it a project name and a language, and it generates a starter directory structure with the right files. It's simple enough to build in an afternoon, but useful enough to actually put on your résumé.

Prerequisites

You will need the following installed on your machine:

  • Python 3.10+ (check with python3 --version)

  • Docker (check with docker --version)

  • Claude Code with an active Claude Pro, Max, or API plan (check with claude --version)

  • Node.js 20+ (required by Claude Code – check with node --version)

  • A terminal you are comfortable in

If you don't have Claude Code installed yet, follow the official installation instructions. The npm installation method is deprecated, so make sure you use the native binary installer instead.

What is MCP (and Why Should You Care)?

The Model Context Protocol (MCP) is an open standard that lets AI models connect to external tools and data sources. Anthropic released it in November 2024, and within a year it became the default way to extend what an LLM can do. OpenAI adopted it in March 2025. Google DeepMind followed in April. The protocol now has over 97 million monthly SDK downloads and more than 10,000 active servers.

The easiest way to think about MCP is as a USB-C port for AI. Before MCP, every AI provider had its own way of calling tools. OpenAI had function calling. Google had their own format. If you wanted your tool to work with multiple models, you had to implement it multiple times. MCP gives you one interface that works everywhere.

Here is how the pieces fit together:

  • An MCP server exposes tools, resources, and prompts. It is your code.

  • An MCP client (like Claude Code, Claude Desktop, or Cursor) discovers those tools and calls them on behalf of the LLM.

  • The transport is how they communicate. For local servers, that's usually stdio (standard input/output). For remote servers, it's HTTP.

When you type a message in Claude Code and it decides to use one of your tools, here is what happens: Claude Code sends a JSON-RPC 2.0 message to your server over stdin, your server executes the tool and writes the result to stdout, and Claude Code reads it back. The LLM never talks to your server directly. The client is always in the middle.

If you want the deeper architecture breakdown, freeCodeCamp already has a solid explainer on how MCP works under the hood. Here, I will focus on building.

Why Claude Code Instead of Claude Desktop?

Most MCP tutorials use Claude Desktop as the client. That works, but Claude Code has a few advantages for developers:

  1. It lives in your terminal. No GUI to configure. No JSON files to hand-edit in hidden config directories. You add an MCP server with one command and you are done.

  2. It's already where you code. If you're writing the server, testing it, and connecting it, doing all of that in the same terminal session cuts the context switching.

  3. It works on headless machines. If you're SSHing into a dev box or running in CI, Claude Desktop isn't an option. Claude Code is.

  4. It's also an MCP server itself. Claude Code can expose its own tools (file reading, writing, shell commands) to other MCP clients via claude mcp serve. That's a neat trick we won't use today, but it's worth knowing about.

The relevant commands:

# Add an MCP server
claude mcp add <name> -- <command>

# List configured servers
claude mcp list

# Remove a server
claude mcp remove <name>

# Check MCP status inside Claude Code
/mcp

Step 1: Build the MCP Server

We're using FastMCP, a Python framework that handles all the protocol plumbing so you can focus on your tools. Create a new project directory and set it up:

mkdir mcp-scaffolder && cd mcp-scaffolder
python3 -m venv .venv
source .venv/bin/activate
pip install "mcp[cli]>=1.25,<2"

Why pin the version? The MCP Python SDK v2.0 is in development and will change the transport layer significantly. Pinning to >=1.25,<2 keeps your server working until you're ready to migrate.

Now create server.py:

# server.py
from mcp.server.fastmcp import FastMCP
import os
import json

mcp = FastMCP("project-scaffolder")

# Templates for different languages
TEMPLATES = {
    "python": {
        "files": {
            "main.py": '"""Entry point."""\n\n\ndef main():\n    print("Hello, world!")\n\n\nif __name__ == "__main__":\n    main()\n',
            "requirements.txt": "",
            "README.md": "# {name}\n\nA Python project.\n\n## Setup\n\n```bash\npip install -r requirements.txt\npython main.py\n```\n",
            ".gitignore": "__pycache__/\n*.pyc\n.venv/\n",
        },
        "dirs": ["tests"],
    },
    "node": {
        "files": {
            "index.js": 'console.log("Hello, world!");\n',
            "package.json": '{{\n  "name": "{name}",\n  "version": "1.0.0",\n  "main": "index.js"\n}}\n',
            "README.md": "# {name}\n\nA Node.js project.\n\n## Setup\n\n```bash\nnpm install\nnode index.js\n```\n",
            ".gitignore": "node_modules/\n",
        },
        "dirs": [],
    },
    "go": {
        "files": {
            "main.go": 'package main\n\nimport "fmt"\n\nfunc main() {{\n\tfmt.Println("Hello, world!")\n}}\n',
            "go.mod": "module {name}\n\ngo 1.21\n",
            "README.md": "# {name}\n\nA Go project.\n\n## Setup\n\n```bash\ngo run main.go\n```\n",
            ".gitignore": "bin/\n",
        },
        "dirs": ["cmd", "internal"],
    },
}


@mcp.tool()
def scaffold_project(name: str, language: str) -> str:
    """Create a new project directory structure.

    Args:
        name: The project name (used as the directory name)
        language: The programming language - one of: python, node, go
    """
    language = language.lower().strip()

    if language not in TEMPLATES:
        return json.dumps({
            "error": f"Unsupported language: {language}",
            "supported": list(TEMPLATES.keys()),
        })

    template = TEMPLATES[language]
    base_path = os.path.join(os.getcwd(), name)

    if os.path.exists(base_path):
        return json.dumps({
            "error": f"Directory already exists: {name}",
        })

    # Create the project directory
    os.makedirs(base_path, exist_ok=True)

    # Create subdirectories
    for dir_name in template["dirs"]:
        os.makedirs(os.path.join(base_path, dir_name), exist_ok=True)

    # Create files
    created_files = []
    for filename, content in template["files"].items():
        filepath = os.path.join(base_path, filename)
        formatted_content = content.replace("{name}", name)
        with open(filepath, "w") as f:
            f.write(formatted_content)
        created_files.append(filename)

    return json.dumps({
        "status": "created",
        "path": base_path,
        "language": language,
        "files": created_files,
        "directories": template["dirs"],
    })


@mcp.tool()
def list_templates() -> str:
    """List all available project templates and their contents."""
    result = {}
    for lang, template in TEMPLATES.items():
        result[lang] = {
            "files": list(template["files"].keys()),
            "directories": template["dirs"],
        }
    return json.dumps(result, indent=2)


if __name__ == "__main__":
    mcp.run(transport="stdio")

A few things to notice about this code:

Tools return strings. MCP tools communicate through text. I'm returning JSON strings so the LLM can parse the results reliably. You could return plain text, but structured data gives the model more to work with.

The @mcp.tool() decorator does the heavy lifting. FastMCP reads your function signature and docstring to generate the JSON schema that tells the LLM what this tool does, what arguments it takes, and what types they are. Good docstrings aren't optional here – they're how the LLM decides whether to call your tool.

transport="stdio" is the key line. This tells FastMCP to communicate over standard input/output, which is what Claude Code expects for local servers.

Step 2: Test It Locally

Before we Dockerize anything, make sure the server actually works:

# Quick smoke test - the server should start without errors
python server.py

You should see... nothing. That is correct. An MCP server over stdio just sits there waiting for JSON-RPC messages on stdin. Press Ctrl+C to stop it.

For a proper test, use the MCP Inspector (Anthropic's debugging tool):

# Install and run the inspector
npx @modelcontextprotocol/inspector python server.py

This opens a web interface where you can see your tools, call them manually, and inspect the JSON-RPC messages going back and forth. Verify that both scaffold_project and list_templates show up and return sensible results.

Here's a debugging tip that will save you time: If your MCP server logs anything to stdout, it will corrupt the JSON-RPC stream and the client will disconnect. Use stderr for all logging: print("debug info", file=sys.stderr). This is the single most common source of "my server connects but then immediately fails" bugs. The New Stack called stdio transport "incredibly fragile" for exactly this reason.

Step 3: Dockerize It

Create a Dockerfile in your project root:

FROM python:3.12-slim

WORKDIR /app

# Install dependencies
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Copy server code
COPY server.py .

# MCP servers over stdio need unbuffered output
ENV PYTHONUNBUFFERED=1

# The server reads from stdin and writes to stdout
CMD ["python", "server.py"]

Create requirements.txt:

mcp[cli]>=1.25,<2

Build and verify:

docker build -t mcp-scaffolder .

# Quick test - should start without errors
docker run -i mcp-scaffolder

Again, you'll see nothing because the server is waiting for input. Ctrl+C to stop.

Two things matter in this Dockerfile:

  1. PYTHONUNBUFFERED=1 is critical. Without it, Python buffers stdout, and the MCP client may hang waiting for responses that are sitting in a buffer. This is one of those bugs that works fine in local testing and breaks in Docker.

  2. docker run -i (interactive mode) is required. The -i flag keeps stdin open so the MCP client can send messages to the container. Without it, the server gets an immediate EOF and exits.

Step 4: Wire It Into Claude Code

Now connect your Docker container to Claude Code:

claude mcp add scaffolder -- docker run -i --rm mcp-scaffolder

That's the whole command. Let me break it down:

  • claude mcp add registers a new MCP server

  • scaffolder is the name you will reference it by

  • Everything after -- is the command Claude Code runs to start the server

  • docker run -i --rm mcp-scaffolder starts the container with interactive stdin and removes it when done

Verify that it registered:

claude mcp list

You should see scaffolder in the output with a stdio transport type.

Now launch Claude Code and check the connection:

claude

Once inside Claude Code, type /mcp to see the status of your MCP servers. You should see scaffolder listed as connected with two tools available.

Step 5: Use It

Still inside Claude Code, try it out:

Create a new Python project called "weather-api"

Claude Code should discover your scaffold_project tool, call it with name="weather-api" and language="python", and report back what it created. Check your filesystem and you should see the full project structure.

Try a few more:

What project templates are available?

Scaffold a Go project called "url-shortener"

If Claude Code doesn't pick up your tools, run /mcp to check the connection status. If it shows as disconnected, the most common causes are that the Docker image failed to build, stdout is being polluted (check for stray print statements), or the Docker daemon is not running.

Security: What the Other Tutorials Leave Out

This is the section most MCP tutorials skip. They should not. MCP has had real security incidents, not theoretical ones, and understanding them makes you a better developer.

The Prompt Injection Problem

MCP servers execute code on your machine based on what an LLM decides to do. If an attacker can influence what the LLM sees, they can influence what your server does. This is called prompt injection, and it is the number one unsolved security problem in the MCP ecosystem.

In May 2025, researchers at Invariant Labs demonstrated this against the official GitHub MCP server. They created a malicious GitHub issue that, when read by an AI agent, hijacked the agent into leaking private repository data (including salary information) into a public pull request. The root cause was an overly broad Personal Access Token combined with untrusted content landing in the LLM's context window.

This was not a contrived lab demo. It used the official GitHub MCP server, the kind of thing people install from the MCP server directory without a second thought.

Real CVEs, Not Theory

The ecosystem has accumulated real vulnerability reports:

  • CVE-2025-6514: A critical command-injection bug in mcp-remote, a popular OAuth proxy that 437,000+ environments used. An attacker could execute arbitrary OS commands through crafted OAuth redirect URIs.

  • CVE-2025-6515: Session hijacking in oatpp-mcp through predictable session IDs, letting attackers inject prompts into other users' sessions.

  • MCP Inspector RCE: Anthropic's own debugging tool allowed unauthenticated remote code execution. Inspecting a malicious server meant giving the attacker a shell on your machine.

An Equixly security assessment found command injection in 43% of tested MCP server implementations. Nearly a third were vulnerable to server-side request forgery.

What You Should Actually Do

For the server we built today, here is what matters:

Limit file system access

Our Docker container doesn't mount your home directory. That's intentional. If you need the server to write files to your host, mount only the specific directory you need: docker run -i --rm -v $(pwd)/projects:/app/projects mcp-scaffolder. Never mount / or ~.

Validate all inputs

Our scaffold_project tool checks that the language is in a known list and that the directory does not already exist. But think about what happens if someone passes name="../../etc/passwd" as the project name. Path traversal is the kind of thing you need to catch. Add this to the tool:

# Add this validation at the top of scaffold_project
if ".." in name or "/" in name or "\\" in name:
    return json.dumps({"error": "Invalid project name"})

Use least-privilege tokens

If your MCP server connects to an API, give it the minimum permissions it needs. The GitHub MCP incident happened because the PAT had access to every private repo. A read-only token scoped to one repo would have contained the blast radius.

Do not install MCP servers from untrusted sources

A malicious npm package posing as a "Postmark MCP Server" was caught silently BCC'ing all emails to an attacker's address. Treat MCP server packages with the same caution you would give any code that runs on your machine with your permissions.

What to Do Next

You have a working MCP server in a Docker container, connected to Claude Code. Here is how to make it portfolio-ready:

  1. Add more tools: The scaffolder is a starting point. Add a tool that reads a project's dependency file and lists outdated packages. Add one that generates a Dockerfile for an existing project. Each tool is a function with a decorator – the pattern is the same every time.

  2. Add tests: Write pytest tests that call your tool functions directly and verify the output. MCP tools are just Python functions. Test them like Python functions.

  3. Push the Docker image: Tag it and push to Docker Hub or GitHub Container Registry. Then your claude mcp add command becomes claude mcp add scaffolder -- docker run -i --rm yourusername/mcp-scaffolder:latest and anyone can use it.

  4. Write a README that explains the security model: What permissions does your server need? What file system access? What happens if inputs are malicious? Answering these questions in your README signals that you think about security, which is exactly what hiring managers are looking for right now.

Wrapping Up

We built a Python MCP server with FastMCP, containerized it with Docker, and connected it to Claude Code. The whole thing fits in about 100 lines of Python, a six-line Dockerfile, and one claude mcp add command.

The MCP ecosystem is real and growing fast. The protocol has the backing of Anthropic, OpenAI, and Google. It's now governed by the Linux Foundation. But it's also young, and the security story is still being written. Build with it, but build with your eyes open.

If you want to go deeper, here are the resources I found most useful:

The complete source code for this tutorial is on GitHub.

]]> <![CDATA[ The Open Source LLM Agent Handbook: How to Automate Complex Tasks with LangGraph and CrewAI ]]> https://www.freecodecamp.org/news/the-open-source-llm-agent-handbook/ 683f04aedfb685791a4e8dd2 Tue, 03 Jun 2025 14:20:30 +0000 Ever feel like your AI tools are a bit...well, passive? Like they just sit there, waiting for your next command? Imagine if they could take initiative, break down big problems, and even work together to get things done.

That's exactly what LLM agents bring to the table. They're changing how we automate complex tasks, and they can help bring our AI ideas to life in a whole new way.

In this article, we'll explore what LLM agents are, how they work, and how you can build your very own using awesome open-source frameworks.

What we’ll cover:

  1. The Current State of LLM Agents

  2. What Are LLM Agents and Why Are They a Big Deal?

  3. The Rise of Open-Source Agent Frameworks

  4. Core Concepts Behind Agent Design

  5. Project: Automate Your Daily Schedule from Emails

  6. Multi-Agent Collaboration with CrewAI

  7. What Actually Happens During Execution?

  8. Are LLM Agents Safe? What to Know About Security and Privacy

  9. Troubleshooting & Tips

  10. Explore More Daily Automations

  11. What’s Next in Agent Technology?

  12. Final Summary

The Current State of LLM Agents

LLM agents are one of the most exciting developments in AI right now. They’re already helping automate real tasks but they’re also still evolving. So where are we today?

From Chatbots to Autonomous Agents

Large Language Models (LLMs) like GPT-4, Claude, Gemini, and LLaMA have evolved from simple chatbots into surprisingly capable reasoning engines. They've gone from answering trivia questions and generating essays to performing complex reasoning, following multi-step instructions, and interacting with tools like web search and code interpreters.

But here’s the catch: these models are reactive. They wait for input and give output. They don't retain memory between tasks, plan ahead, or pursue goals on their own. That’s where LLM agents come in – they bridge this gap by adding structure, memory, and autonomy.

What Can Agents Do Today?

Right now, LLM agents are already being used for:

  • Summarizing emails or documents

  • Planning daily schedules

  • Running DevOps scripts

  • Searching APIs or tools for answers

  • Collaborating in small “teams” to complete complex tasks

But they’re not perfect yet. Agents can still:

  • Get stuck in loops

  • Misunderstand goals

  • Require detailed prompts and guardrails

That’s because this technology is still early-stage. Frameworks are getting better fast, but reliability and memory are still works in progress. So just keep that in mind as you experiment.

Why Now Is the Best Time to Learn

The truth is: we’re still early. But not too early.

This is the perfect time to start experimenting with agents:

  • The tooling is mature enough to build real projects

  • The community is growing rapidly

  • And you don’t need to be an AI expert just comfortable with Python

What Are LLM Agents and Why Are They a Big Deal?

Before we dive into the exciting world of agents, let's quickly chat a bit more about the basics.

What Is an LLM?

An LLM, or Large Language Model, is basically an AI that's learned from a massive amount of text from the internet – think books, articles, code, and tons more. You can picture it as a super-smart autocomplete engine. But it does way more than just finish your sentences. It can also:

  • Answer tricky questions

  • Summarize long articles or documents

  • Write code, emails, or creative stories

  • Translate languages instantly

  • Even solve logic puzzles and have engaging conversations

Chances are you've heard of ChatGPT, which is powered by OpenAI's GPT models. Other popular LLMs you might come across include Claude (from Anthropic), LLaMA (by Meta), Mistral, and Gemini (from Google).

These models work by simply predicting the next word in a sentence based on the context. While that sounds straightforward, when trained on billions of words, LLMs become capable of surprisingly intelligent behavior, understanding your instructions, following step-by-step reasoning, and producing coherent responses across almost any topic you can imagine.

So, What’s an LLM Agent?

While LLMs are super powerful, they usually just react – they only respond when you ask them something. An LLM agent, on the other hand, is proactive.

LLM agents can:

  • Break down big, complex tasks into smaller, manageable steps

  • Make smart decisions and figure out what to do next

  • Use "tools" like web search, calculators, or even other apps

  • Work towards a goal, even if it takes multiple steps or tries

  • Team up with other agents to accomplish shared objectives

In short, LLM agents can think, plan, act, and adapt.

Think of an LLM agent like your super-efficient new assistant: you give it a goal, and it figures out how to achieve it all on its own.

Why Does This Matter?

This shift from just responding to actively pursuing goals opens a ton of exciting possibilities:

  • Automating boring IT or DevOps tasks

  • Generating detailed reports from raw data

  • Helping you with multi-step research projects

  • Reading through your daily emails and highlighting key info

  • Running your internal tools to take real-world actions

Unlike older, rule-based bots, LLM agents can reason, reflect, and learn from their attempts. This makes them a much better fit for real-world tasks that are messy, require flexibility, and depend on understanding context.

The Rise of Open-Source Agent Frameworks

Not too long ago, if you wanted to build an AI system that could act autonomously, it meant writing a ton of custom code, painstakingly managing memory, and trying to stitch together dozens of components. It was a complex, delicate, and highly specialized job.

But guess what? That's not the case anymore.

In 2024, a wave of fantastic open-source frameworks hit the scene. These tools have made it dramatically easier to build powerful LLM agents without you having to reinvent the wheel every time.

FrameworkDescriptionMaintainer
LangGraphGraph-based framework for agent state and memoryLangChain
CrewAI"Role-based, multi-agent collaboration engine"Community (CrewAI)
AutoGenCustomizable multi-agent chat orchestrationMicrosoft
AgentVerseModular framework for agent simulation and testingOpen-source project

What These Tools Enable

These frameworks give you ready-made building blocks to handle the trickier parts of creating agents:

  • Planning – Letting agents decide their next move

  • Tool Use – Easily connecting agents to things like file systems, web browsers, APIs, or databases

  • Memory – Storing and retrieving past information or intermediate results for long-term context

  • Multi-Agent Collaboration – Setting up teams of agents that work together on shared goals

Why Use a Framework Instead of Building from Scratch?

While you could build a custom agent from the ground up, using a framework will save you a huge amount of time and effort. Open-source agent libraries come packed with:

  • Built-in support for orchestrating LLMs

  • Proven patterns for task planning, keeping track of where you are, and getting feedback

  • Easy integration with popular models like OpenAI, or even models you run locally

  • The flexibility to grow from a single helpful agent to entire teams of agents

Basically, these frameworks let you focus on what your agent should do, rather than getting bogged down in how to build all the internal workings. Plus, choosing open source means you benefit from community contributions, transparency in how they work, and the freedom to tweak them to your exact needs, without getting locked into a single vendor.

Core Concepts Behind Agent Design

To really grasp how LLM agents operate, it helps to think of them as goal-driven systems that constantly cycle through observing, reasoning, and acting. This continuous loop allows them to tackle tasks that go beyond simple questions and answers, moving into true automation, tool usage, and adapting on the fly.

The Agent Loop

Most LLM agents function based on a mental model called the Agent Loop a step-by-step cycle that repeats until the job is done. Here’s how it typically works:

  • Perceive: The agent starts by noticing something in its environment or receiving new information. This could be your prompt, a piece of data, or the current state of a system.

  • Plan: Based on what it perceives and its overall goal, the agent decides what to do next. It might break the task into smaller sub-goals or figure out the best tool for the job.

  • Act: The agent then acts. This could mean running a function, calling an API, searching the web, interacting with a database, or even asking another agent for help.

  • Reflect: After acting, the agent looks at the outcome: Did it work? Was the result useful? Should it try a different approach? Based on this, it updates its plan and keeps going until the task is complete.

This loop is what makes agents so dynamic. It allows them to handle ever-changing tasks, learn from partial results, and correct their course qualities that are vital for building truly useful AI assistants.

Key Components of an Agent

To do their job effectively, agents are built around several crucial parts:

  • Tools are how an agent interacts with the real (or digital) world. These can be anything from search engines, code execution environments, file readers, or API clients, to simple calculators or command-line scripts.

  • Memory lets agents remember what they've done or seen across different steps. This might include previous things you've said, temporary results, or key decisions. Some frameworks offer short-term memory (just for one session), while others support long-term memory that can span multiple sessions or goals.

  • Environment refers to the external data or system context the agent operates within think APIs, documents, databases, files, or sensor inputs. The more information and access an agent have to its environment, the more meaningful actions it can take.

  • Goal is the agent's ultimate objective: what it's trying to achieve. Goals should be specific and clear for instance, “generate a daily schedule,” “summarize this document,” or “extract tasks from emails.”

Multi-Agent Collaboration

For more advanced systems, you can even have multiple agents working together to hit a shared target. Each agent can be given a specific role that highlights its specialty just like people working on a team.

For example:

  • A researcher agent might be tasked with gathering information.

  • A coder agent could write Python scripts or automation routines.

  • A reviewer agent might check the results and ensure everything is up to snuff.

These agents can chat with each other, share information, and even debate or vote on decisions. This kind of teamwork allows AI systems to tackle bigger, more complex tasks while keeping things organized and modular.

Project: Automate Your Daily Schedule from Emails

What We’re Automating

Think about your typical morning routine:

  • You open your inbox.

  • You quickly scan through a bunch of emails.

  • You try to spot meetings, tasks, and important reminders.

  • Then, you manually write a to-do list or add things to your calendar.

Let's use an LLM agent to make that process effortless. Our agent will:

  • Read a list of your email messages

  • Pull out time-sensitive items like meetings or deadlines

  • Summarize everything into a nice, clean daily schedule

Step 1: Install the Required Tools

To get started, you'll need three main tools: Python, VSCode, and an OpenAI API key.

1. Install Python 3.9 or Higher

Grab the latest version of Python 3.9+ from the official website: https://www.python.org/downloads/

Once it's installed, double-check it by running python --version in your terminal.

This command simply asks your system to report the Python version currently installed. You'll want to see Python 3.9.x or something higher to ensure compatibility with our project.

VSCode is a fantastic, user-friendly code editor that works perfectly with Python. You can download it right here: https://code.visualstudio.com/.

3. Get Your OpenAI API Key

Head over to: https://platform.openai.com

Sign in or create a new account. Navigate to your API Keys page. Click “Create new secret key” and make sure to copy that key somewhere safe for later.

4. Install Python Libraries

Open your terminal or command prompt and install these essential packages:

pip install langgraph langchain openai

This command uses pip, Python's package manager, to download and install three crucial libraries for our agent:

  • langgraph: The core framework we'll use to build our agent's workflow.

  • langchain: A foundational library for working with large language models, upon which LangGraph is built.

  • openai: The official Python library for connecting to OpenAI's powerful AI models.

If you're excited to try out multi-agent setups (which we'll cover in Step 5), also install CrewAI:

pip install crewai

This command installs CrewAI, a specialized framework that makes it easy to orchestrate multiple AI agents working together as a team.

5. Set Your OpenAI API Key

You need to make sure your Python code can find and use your OpenAI API key. This is typically done by setting it as an environment variable.

On macOS/Linux, run this in your terminal (replace "your-api-key" with your actual key):

export OPENAI_API_KEY="your-api-key"

This command sets an environment variable named OPENAI_API_KEY. Environment variables are a secure way for applications (like your Python script) to access sensitive information without hardcoding it directly into the code itself.

On Windows (using Command Prompt), do this:

set OPENAI_API_KEY="your-api-key"

This is the Windows equivalent command to set the OPENAI_API_KEY environment variable.

Now, your Python code will be all set to talk to the OpenAI model!

Step 2: Define the Task

We discussed this briefly in the beginning of this section. But to reiterate, this is what we’ll want our agent to do:

  • Scan for meetings, events, and important tasks.

  • Jot them down quickly in a notebook or an app.

  • Create a rough mental plan for your day.

This routine takes time and mental energy. So having an agent do it for us will be super helpful.

Step 3: Build the Workflow with LangGraph

What Is LangGraph?

LangGraph is a cool framework that helps you build agents using a "graph-based" workflow, kind of like drawing a flowchart. It's powered by LangChain and gives you a lot more control over exactly how each step in your agent's process unfolds.

Each "node" in this graph represents a decision point or a function that:

  • Takes some input (its current "state").

  • Does some reasoning or takes an action (often involving the LLM and its tools).

  • Returns an updated output (a new "state").

You draw the connections between these nodes, and LangGraph then executes it like a smart, automated state machine.

Why Use LangGraph?

  • You get to control the precise order of execution.

  • It's fantastic for building workflows that have multiple steps or even branch off into different paths.

  • It plays nicely with both cloud-based models (like OpenAI) and models you run locally.

Alright – now let’s write the code.

1. Simulate Email Input

In a real application, your agent would probably connect to Gmail or Outlook to fetch your actual emails. For this example, though, we’ll just hardcode some sample messages to keep things simple:

Python

emails = """
1. Subject: Standup Call at 10 AM
2. Subject: Client Review due by 5 PM
3. Subject: Lunch with Sarah at noon
4. Subject: AWS Budget Warning – 80% usage
5. Subject: Dentist Appointment - 4 PM
"""

This multiline Python string, emails, acts as our stand-in for real email content. We're providing a simple, structured list of email subjects to demonstrate how the agent will process text.

2. Define the Agent Logic

Now, we'll tell OpenAI’s GPT model how to process this email text and turn it into a summary.

from langchain_openai import ChatOpenAI
from langgraph.graph import StateGraph, END
from typing import TypedDict, Annotated, List
import operator

# Define the state for our graph
class AgentState(TypedDict):
    emails: str
    result: str

llm = ChatOpenAI(temperature=0, model="gpt-4o") # Using gpt-4o for better performance

def calendar_summary_agent(state: AgentState) -> AgentState:
    emails = state["emails"]
    prompt = f"Summarize today's schedule based on these emails, listing time-sensitive items first and then other important notes. Be concise and use bullet points:\n{emails}"
    summary = llm.invoke(prompt).content
    return {"result": summary, "emails": emails} # Ensure emails is also returned

Here’s what’s going on:

  • Imports: We bring in necessary components:

    • ChatOpenAI to connect to the LLM,

    • StateGraph and END from langgraph.graph to build our agent workflow,

    • TypedDict, Annotated, and List from typing for type checking and structure,

    • operator (though not used in this snippet, it can help with comparisons or logic).

  • AgentState: This TypedDict defines the shape of the data our agent will work with. It includes:

    • emails: the raw input messages.

    • result: the final output (the daily summary).

  • llm = ChatOpenAI(...): Initializes the language model. We're using GPT-4o with temperature=0 to ensure consistent, predictable output perfect for structured summarization tasks.

  • calendar_summary_agent(state: AgentState): This function is the "brain" of our agent. It:

    • Takes in the current state, which includes a list of emails.

    • Extracts the emails from that state.

    • Constructs a prompt that tells the model to generate a concise daily schedule summary using bullet points, prioritizing time-sensitive items.

    • Sends this prompt to the model with llm.invoke(prompt).content, which returns the LLM’s response as plain text.

    • Returns a new AgentState dictionary containing:

      • result: the generated summary,

      • emails: preserved in case we need it downstream.

3. Build and Run the Graph

Now, let's use LangGraph to map out the flow of our single-agent task and then run it.

builder = StateGraph(AgentState)
builder.add_node("calendar", calendar_summary_agent)
builder.set_entry_point("calendar")
builder.set_finish_point("calendar") # END is implicit if not set explicitly

graph = builder.compile()

# Run the graph using your simulated email data
result = graph.invoke({"emails": emails})
print(result["result"])

Here’s what’s going on:

  • builder = StateGraph(AgentState): We're initiating a StateGraph object. By passing AgentState, we're telling LangGraph the expected data structure for its internal state.

  • builder.add_node("calendar", calendar_summary_agent): This line adds a named "node" to our graph. We're calling it "calendar", and we're linking it to our calendar_summary_agent function, meaning that function will be executed when this node is active.

  • builder.set_entry_point("calendar"): This sets "calendar" as the very first step in our workflow. When we start the graph, execution will begin here.

  • builder.set_finish_point("calendar"): This tells LangGraph that once the "calendar" node finishes its job, the entire graph process is complete.

  • graph = builder.compile(): This command takes our defined graph blueprint and "compiles" it into an executable workflow.

  • result = graph.invoke({"emails": emails}): This is where the magic happens! We're telling our graph to start running. We pass it an initial state that contains our emails data. The graph will then process this data through its nodes until it reaches an end point, returning the final state.

  • print(result["result"]): Finally, we grab the summarized schedule from the result (the final state of our graph) and print it to the console.

Example Output

Your Schedule:
- 10:00 AM – Standup Call
- 12:00 PM – Lunch with Sarah
- 4:00 PM – Dentist Appointment
- Submit client report by 5:00 PM
- AWS Budget Warning – check usage

Boom! You've just built an AI agent that can read your emails and whip up your daily schedule. Pretty cool, right? This is a simple yet powerful peek into what LLM agents can do with just a few lines of code.

Multi-Agent Collaboration with CrewAI

What Is CrewAI?

CrewAI is an exciting open-source framework that lets you build teams of agents that work together seamlessly just like a real-world project team! Each agent in a CrewAI setup:

  • Has a specific, specialized role.

  • Can communicate and share information with its teammates.

  • Collaborates to achieve a shared goal.

This multi-agent approach is super useful when your task is too big or too complex for just one agent, or when breaking it down into specialized parts makes it clearer and more efficient.

Sample Roles for the Email Summary Task

Let's imagine our email summary task being handled by a small team of agents:

Agent NameRoleResponsibility
ExtractorEmail Scanner"Find meetings, reminders, and tasks from emails"
PrioritizerSchedule OptimizerSort items by urgency and time
FormatterOutput Generator"Write a clean, polished daily agenda"

Sample CrewAI Code

from crewai import Agent, Crew, Task, Process
from langchain_openai import ChatOpenAI
import os

# Set your OpenAI API key from environment variables
# os.environ["OPENAI_API_KEY"] = "YOUR_API_KEY" # Make sure this is set, or defined directly

# Initialize the LLM (using gpt-4o for better performance)
llm = ChatOpenAI(temperature=0, model="gpt-4o")

# Define the agents with specific roles and goals
extractor = Agent(
    role="Email Scanner",
    goal="Find all meetings, reminders, and tasks from the given emails, accurately extracting details like time, date, and subject.",
    backstory="You are an expert at scanning emails for key information. You meticulously extract every relevant detail.",
    verbose=True,
    allow_delegation=False,
    llm=llm
)

prioritizer = Agent(
    role="Schedule Optimizer",
    goal="Sort extracted items by urgency and time, preparing them for a daily agenda.",
    backstory="You are a master of time management, always knowing what needs to be done first. You organize tasks logically.",
    verbose=True,
    allow_delegation=False,
    llm=llm
)

formatter = Agent(
    role="Output Generator",
    goal="Generate a clean, polished, and concise daily agenda in bullet-point format, clearly listing all schedule items.",
    backstory="You are a professional secretary, ensuring all outputs are perfectly formatted and easy to read. You prioritize clarity.",
    verbose=True,
    allow_delegation=False,
    llm=llm
)

# Simulate email input
emails = """
1. Subject: Standup Call at 10 AM
2. Subject: Client Review due by 5 PM
3. Subject: Lunch with Sarah at noon
4. Subject: AWS Budget Warning – 80% usage
5. Subject: Dentist Appointment - 4 PM
"""

# Define the tasks for each agent
extract_task = Task(
    description=f"Extract all relevant events, meetings, and tasks from these emails: {emails}. Focus on precise details.",
    agent=extractor,
    expected_output="A list of extracted items with their details (e.g., '- Standup Call at 10 AM', '- Client Review due by 5 PM')."
)

prioritize_task = Task(
    description="Prioritize the extracted items by time and urgency. Meetings first, then deadlines, then other notes.",
    agent=prioritizer,
    context=[extract_task], # The output of extract_task is the input here
    expected_output="A prioritized list of schedule items."
)

format_task = Task(
    description="Format the prioritized schedule into a clean, easy-to-read daily agenda using bullet points. Ensure concise language.",
    agent=formatter,
    context=[prioritize_task], # The output of prioritize_task is the input here
    expected_output="A well-formatted daily agenda with bullet points."
)

# Instantiate the crew
crew = Crew(
    agents=[extractor, prioritizer, formatter],
    tasks=[extract_task, prioritize_task, format_task],
    process=Process.sequential, # Tasks are executed sequentially
    verbose=2 # Outputs more details during execution
)

# Run the crew
result = crew.kickoff()
print("\n########################")
print("## Final Daily Agenda ##")
print("########################\n")
print(result)

Here’s what’s going on:

  • Imports: We bring in key classes from CrewAI: Agent, Crew, Task, and Process. We also import ChatOpenAI for our language model and os to handle environment variables.

  • llm = ChatOpenAI(...): Just like in the LangGraph example, this sets up our OpenAI language model, making sure its responses are direct (temperature=0) and using the gpt-4o model.

  • Agent Definitions (extractor, prioritizer, formatter):

    • Each of these variables creates an Agent instance. An agent is defined by its role (what it does), a specific goal it's trying to achieve, and a backstory (a sort of personality or expertise that helps the LLM understand its purpose better).

    • verbose=True is super helpful for debugging, as it makes the agents print out their "thoughts" as they work.

    • allow_delegation=False means these agents won't pass their assigned tasks to other agents (though this can be set to True for more complex delegation scenarios).

    • llm=llm connects each agent to our OpenAI language model.

  • Simulated emails: We reuse the same sample email data for this example.

  • Task Definitions (extract_task, prioritize_task, format_task):

    • Each Task defines a specific piece of work that an agent needs to perform.

    • description clearly tells the agent what the task involves.

    • agent assigns this task to one of our defined agents (e.g., extractor for extract_task).

    • context=[...] is a critical part of CrewAI's collaboration. It tells a task to use the output of a previous task as its input. For instance, prioritize_task takes the extract_task's output as its context.

    • expected_output gives the agent an idea of what its result should look like, helping guide the LLM.

  • crew = Crew(...):

    • This is where we assemble our team! We create a Crew instance, giving it our list of agents and tasks.

    • process=Process.sequential tells the crew to execute tasks one after another in the order they're defined in the tasks list. CrewAI also supports more advanced processes like hierarchical ones.

    • verbose=2 will show you a very detailed log of the crew's internal workings and communication.

  • result = crew.kickoff(): This command officially starts the entire multi-agent workflow. The agents will begin collaborating, passing information, and working through their assigned tasks in sequence.

  • fprint(result): Finally, the consolidated output from the entire crew's collaborative effort is printed to your console.

CrewAI cleverly handles all the communication between agents, figures out who needs to work on what and when, and passes the output smoothly from one agent to the next it's like having a mini AI assembly line!

What Actually Happens During Execution?

So, whether you're using LangGraph or CrewAI, what's really going on behind the scenes when an agent runs? Let's break down the execution process:

  • The system gets an input state (for example, your emails).

  • The first agent or graph node reads this input and uses a Large Language Model (LLM) to make sense of it.

  • Based on its understanding, the agent decides on an action like pulling out key events or calling a specific tool.

  • If needed, the agent might invoke tools (like a web search or a file reader) to get more context or perform external operations.

  • The result of that action is then passed to the next agent in the team (if it's a multi-agent setup) or returned directly to you.

Execution keeps going until:

  • The task is fully completed.

  • All agents have finished their assigned roles.

  • A stopping condition or a designated "END" point in the workflow is reached.

Think of this as a super-smart workflow engine where every single step involves reasoning, making decisions, and remembering previous interactions.

Are LLM Agents Safe? What to Know About Security and Privacy

As cool as LLM agents are, they raise an important question: can you really trust an AI to run parts of your workflow or interact with your data? It depends. If you’re using services like OpenAI or Anthropic, your data is encrypted in transit and (as of now) isn’t used for training.

But some data might still be temporarily logged to prevent abuse. That’s usually fine for testing and personal projects, but if you’re working with sensitive business info, customer data, or anything private, you’ll want to be careful.

Use anonymized inputs, avoid exposing full datasets, and consider running agents locally using open-source models like LLaMA or Mistral if full control matters to you.

You can also set clear boundaries for your agents so they don’t overstep. Think of it like onboarding a new intern: you wouldn’t give them access to everything on day one.

Give agents only the tools and files they need, keep logs of what they do, and always review the results before letting them make real changes.

As this tech grows, more safety features are coming like better sandboxing, memory limits, and role-based access. But for now, it’s smart to treat your agents like powerful helpers that still need some human supervision.

Troubleshooting & Tips

Sometimes, agents can be a bit quirky! Here are some common issues you might run into and how to fix them:

IssueSuggested Fix
Agent seems to loop foreverSet a maximum number of iterations or define a clearer stopping point.
Output is too chatty or verboseUse more specific prompts (for example, “Respond in bullet points only”).
Input is too long or gets cut offBreak down large pieces of content into smaller chunks and summarize them individually.
Agent runs too slowlyTry using a faster LLM model like gpt-3.5 or consider running a local model.

A handy tip: You can also add print() statements or logging messages inside your agent functions to see what's happening at each stage and debug state transitions.

Explore More Daily Automations

Once you've built one agent-based task, you'll find it incredibly easy to adapt the pattern for other automations. Here are some cool ideas to get your creative juices flowing:

Task TypeExample Automation
DevOps Assistant"Read system logs, detect potential issues, and suggest solutions."
Finance TrackerRead bank statements or CSV files and summarize your spending habits/budgets.
Meeting OrganizerAfter a meeting, automatically extract action items and assign owners.
Inbox Cleaner"Automatically label, archive, and delete non-urgent emails."
Note SummarizerConvert your daily notes into a neatly formatted to-do list or summary.
Link CheckerExtract URLs from documents and automatically test if they're still valid.
Resume FormatterScore resumes against job descriptions and format them automatically.

Each of these can be built using the very same principles and frameworks we discussed whether that's LangGraph or CrewAI.

What’s Next in Agent Technology?

LLM agents are evolving at lightning speed, and the next wave of innovation is already here:

  • Smarter memory systems: Expect agents to have better long-term memory, allowing them to learn over extended periods and remember past conversations and actions.

  • Multi-modal agents: Agents won't just handle text anymore! They'll be able to process and understand images, audio, and video, making them much more versatile.

  • Advanced planning frameworks: Techniques like ReAct, Toolformer, and AutoGen are constantly improving agents' ability to reason, plan, and reduce those pesky "hallucinations."

  • Edge deployment: Imagine agents running entirely offline on your local computer or device using lightweight models like LLaMA 3 or Mistral.

In the very near future, you'll see agents seamlessly integrated into:

  • Your DevOps pipelines

  • Big enterprise workflows

  • Everyday productivity tools

  • Mobile apps and smart devices

  • Games, simulations, and educational platforms

Final Summary

Alright, let's quickly recap all the cool stuff you've just learned and accomplished:

  • You've gotten a solid grasp of what LLM agents are and why they're so powerful.

  • You've seen how open-source frameworks like LangGraph and CrewAI make building agents much easier.

  • You've built a real LLM agent using LangGraph to automate a common daily task: summarizing your inbox!

  • You've explored the world of multi-agent collaboration with CrewAI, understanding how teams of AIs can work together.

  • You've learned how to take these principles and scale them to automate countless other tasks.

So, next time you find yourself stuck doing something repetitive, just ask yourself: "Hey, can I build an agent for that?" The answer is probably yes!

Resources Recap

Here are some helpful resources if you want to dive deeper into building LLM agents:

ResourceLink
LangGraph Docshttps://docs.langgraph.dev/
CrewAI GitHubhttps://github.com/joaomdmoura/crewAI
LangChain Docshttps://docs.langchain.com/docs/
OpenAI API Docshttps://platform.openai.com/docs
Python 3.9+https://www.python.org/downloads/
VSCodehttps://code.visualstudio.com/
]]>