I Thought Agentic AI and AI Agents Were the Same Thing. They Are Not

Sristi Acharya — Sat, 01 Aug 2026 14:15:15 +0000

People use these two terms like they mean the same thing. They don't. And once you see the difference, it's hard to unsee it.

Here's the simplest way to think about it. Agentic AI is a skill, the ability to act on its own. An AI Agent is a worker, a system built with that skill and given a specific job. That's really the whole thing, but let's go a bit deeper.

What Is Agentic AI?

Normal AI waits for you. You ask, it answers, done. You ask again, it answers again. Every interaction is separate.

Agentic AI doesn't work that way. You give it a goal and it figures out the steps, takes action, checks if it worked, and keeps going until it's done. No hand holding required.

Think of it like asking a colleague to handle onboarding for a new hire. You don't walk them through every single step. You just say "handle it" and they do.

Real example: GitHub Copilot Workspace

You tell it to add a login feature to your app. It reads your entire codebase, writes the code across multiple files, runs the tests, sees what broke, and fixes it. You didn't do anything in between. That's agentic behaviour.

What Is an AI Agent?

An AI Agent is an actual deployed system. Something with a name, a job, and tools to do that job. It's not just a behaviour, it's a thing you can point to and say "that's our support agent" or "that's our research agent."

Every AI Agent is agentic. But not everything agentic is an agent. The difference is whether there's a specific, deployed system doing the work.

Real example: Klarna's Customer Support Agent

Klarna built an AI agent whose whole job is handling customer support. It can look up your order, process a refund, update your address, all in one conversation. It has a defined role and real access to Klarna's systems. That's an agent.

One More Example of Each

Agentic AI: Salesforce Einstein

Einstein watches your sales pipeline, spots deals that look risky, writes follow up emails, and schedules them. Nobody tells it to write the email. It just does the whole thing start to finish. That's agentic behaviour baked into a product.

AI Agent: Amazon Rufus

Rufus is Amazon's shopping agent. Ask it what's a good camera for travel and it checks your past purchases, compares current listings, looks at availability, and gives you a personalised answer. It has one job: help you shop.

The Simple Version

	Agentic AI	AI Agent
What it is	A behaviour or capability	A deployed system with a job
Think of it as	How something acts	What something is
Example	Copilot fixing code on its own	Klarna's support bot

When to Use Which Term

Say "Agentic AI" when you're describing how a system behaves, that it can plan, act, and correct itself without someone guiding every step.

Say "AI Agent" when you're talking about a specific system that has a role, tools, and a scope, like a support agent, a coding agent, or a research agent.

Why Does This Matter?

Because when you're building with AI, these two things lead to very different questions.

Agentic AI makes you ask how much autonomy you want to give the system.

An AI Agent makes you ask what it can access, what actions it can take, and who's responsible if it gets something wrong.

An agent that processes real refunds or pushes code to production is operating in the real world. That's a bigger deal than smart autocomplete.

Get these concepts right early and a lot of other things about how AI systems are designed start to make sense pretty quickly.

Managing Permissions with AWS IAM. Here's What I Learnt

Sristi Acharya — Fri, 05 Jun 2026 09:31:54 +0000

So I recently worked on a project where I had to set up and manage permissions using AWS IAM, and honestly? It was one of those things that sounds intimidating at first but starts to click once you actually get your hands dirty with it.

In this post, I'll walk you through exactly what I did, setting up policies, creating users and groups, tagging EC2 instances, and testing whether the permissions actually worked. Let's get into it.

First Things First, What Even Is AWS IAM?

IAM stands for Identity and Access Management. It's a web service from AWS that lets you control who can access what in your AWS account.

Think of it like this: you're the admin of an office building. Some people should be able to enter every room, some only specific ones, and some shouldn't get past the lobby. IAM is basically your access-card system; you decide who gets in and where, and you can change that at any time.

For this project, I used IAM to:

Create EC2 instances
Manage users and groups
Assign permissions to allow or deny access to resources

Setting Up EC2 Instances with Tags

Before touching IAM, I spun up two EC2 instances to use as test subjects. One for production, one for development.

To tell them apart (and to make the IAM policy work properly), I tagged them. Tags in AWS are key-value labels you attach to resources. They're useful for organising things, tracking costs, and, in our case, building conditions into policies.

The tag I used was Env, and I gave each instance a different value:

Instance	Tag Key	Tag Value
project-production-sristi	Env	production
project-development-sristi	Env	development

Simple, but this small detail becomes really important when we write the policy.

Writing the IAM Policy

This is where things get interesting. An IAM Policy is a set of rules written in JSON that tells AWS what actions are allowed or denied, on which resources, and under what conditions.

Here's the policy I wrote:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2:*",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "ec2:ResourceTag/Env": "development"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": "ec2:Describe*",
      "Resource": "*"
    },
    {
      "Effect": "Deny",
      "Action": [
        "ec2:DeleteTags",
        "ec2:CreateTags"
      ],
      "Resource": "*"
    }
  ]
}

Let me break down what each part does:

Statement 1 — Allows all EC2 actions (ec2:*), but only on instances where the Env tag equals development. So anything tagged as production? Off limits.
Statement 2 — Allows the user to describe (basically, view) EC2 resources. Without this, the user wouldn't even be able to see what instances exist.
Statement 3 — Explicitly denies the ability to create or delete tags. This is important — you don't want users messing with the very tags that control their own permissions. That would be a bit of a security hole.

Three key things you always define in a policy statement:

Effect — Allow or Deny
Action — What operation you're allowing/denying (like stopping an instance, describing resources, etc.)
Resource — Which AWS resource this applies to (* means all)

Creating an Account Alias

Small but useful thing, I set up an AWS Account Alias. Instead of sharing a URL with a long numeric account ID, you can create a friendly name for your account.

My sign-in URL went from something like 738565xxxxx.signin.aws.amazon.com/console to:

https://project-alias-sristi.signin.aws.amazon.com/console

Much cleaner to share with new users. And don't worry, IAM users can still use the original account ID URL if needed.

Creating a User Group + IAM User

Next up, creating a User Group and adding a user to it.

Why use groups instead of attaching policies directly to users?

Imagine you have 20 developers. If you attach permissions to each user individually, managing that becomes a nightmare, especially when something changes. With a group, you set the policy once, and every user in that group inherits it automatically. Way more scalable.

Here's what I set up:

User Group: dev-group — I attached the policy I created to this group
IAM User: dev-sristi — Added to dev-group

When creating the user, I ticked the option to allow console access. Once the user was created, AWS gave me two ways to share the credentials:

Email the sign-in instructions directly
Download a .csv file with the username and password

My Sign In user credentials

Testing It Out: IAM Policies in Action

This is the fun part. I logged into the AWS console as the new IAM user (dev-sristi) and immediately noticed the difference. The dashboard looked different from the root account, with lots of "Access Denied" errors across various panels like cost, security, and applications. That's expected. The user only has EC2-related permissions, nothing else.

Then I tested the actual policy by trying to stop both instances:

Stopping the Production Instance

Got a big red error banner. The user wasn't authorised to perform ec2:StopInstances on the production instance. The policy blocked it because the Env tag on that instance was production, not development.

Stopping the Development Instance

Green banner. "Successfully initiated stopping." The policy allowed it because the instance had Env: development exactly what the condition in the policy was looking for.

" width="800" height="144">

It worked exactly as intended. Honestly, pretty satisfying to see it play out in real time.

Summary: What I Built

Here's a quick recap of everything that was set up:

Component	Name	Purpose
IAM User Group	`dev-group`	Holds the permissions policy
IAM User	`dev-sristi`	Member of `dev-group`
EC2 Instance	`project-development-sristi`	Tag: `Env=development`
EC2 Instance	`project-production-sristi`	Tag: `Env=production`
IAM Policy	`SristiDevEnvironmentPolicy`	Allow dev access, deny prod

Key Takeaways

A few things I came away from this project understanding a lot better:

IAM Policies are how you define rules for what's allowed, what's denied, and on what resources. Writing them in JSON gives you a lot of flexibility, especially when you add conditions like tag-based access.

Account Aliases are a small quality-of-life thing but are really useful when onboarding new users. Nobody wants to memorise a 12-digit account ID.

IAM Users vs User Groups — attaching policies directly to users works, but using groups is the better practice. It's cleaner and much easier to manage at scale.

Tags aren't just for organisation — they can actually drive your security policies. That Env tag was the entire reason the permission logic worked. One tag value meant full access, another meant denied.

Testing is everything. Writing the policy is one thing; actually logging in as the user and seeing what they can and can't do is how you know it works.

If you're just getting started with AWS, IAM is one of the first things worth learning properly. Messing up permissions is one of the most common ways things go wrong in cloud environments, and understanding IAM gives you real control over who can do what in your account.

Give it a try, break things in a dev environment, and see what happens. That's honestly the best way to learn it.

DEV Community: Sristi Acharya