👋 Hey there, tech enthusiasts!

I'm Sarvar, a Cloud Architect who loves turning complex tech problems into simple solutions. I've worked with AWS, Azure, DevOps, Data, Analytics, Generative-AI and Agentic-AI building real systems for real companies. In this article series, I'll share what I've learned in a way that's easy to follow, whether you're experienced or just getting started.

Let's get into it! 🚀

This article is for beginners who've heard about AI agents but haven't built one yet.

The Problem That Started It All

You're looking for a job. You open LinkedIn, Naukri, Indeed search "Senior Python Developer." Hundreds of results pop up. Every company wants something slightly different. One wants AWS + Django. Another wants FastAPI + Kubernetes. The third one wants Flask + microservices.

You have all these skills. That's not the problem.

The problem is time. To stand out, you need to customize your resume for each role. Read the job description carefully. Figure out what they care about. Rewrite your summary. Reorder skills. Tweak bullet points. Write a cover letter. Hit submit.

That's ONE application. Now do that 10 more times.

It's not a skill problem. It's a time problem. You're doing the same thing over and over read, match, rewrite, submit.

What if you could build something that handles all of this for you?

You give it your resume and say "Find Senior Python roles in Bangalore, 20-35 LPA (Lakhs Per Annum ₹20-35 lakh salary), remote-friendly" and it goes to work. It reads job descriptions, matches your skills, finds gaps, rewrites your resume for each role, writes cover letters, and ranks everything by how well you fit.

Same you. Same resume. Same job market. But the boring repetitive part? Done automatically.

That's what got me into agentic AI. Not the hype. The simple thought: "I can automate this annoying thing."

ChatGPT vs AI Agents What's the Difference?

People ask me this all the time. "Isn't ChatGPT already an agent?"

Not really. Here's the simple difference.

ChatGPT - you ask a question, you get text back. Yes, it can browse the web and run code now. But YOU are still driving. You ask, it responds. You ask again, it responds again. It waits for you at every step.

An AI Agent - you give it a goal and it goes and does the work. Multiple steps. Multiple tools. Without you guiding each step. It decides what to do next on its own.

Here's a simple comparison:

One waits for you. The other goes and does the work. That's the whole difference.

How Agents Think?

Every agent follows the same basic pattern:

Think → Do → Check → Repeat

Here's what that looks like:

┌─────────┐     ┌─────────┐     ┌─────────┐
│  THINK  │───▶│   DO    │────▶│  CHECK  │
│ What's  │     │ Take    │     │ Did it  │
│ next?   │     │ action  │     │ work?   │
└─────────┘     └─────────┘     └─────┬───┘
     ▲                                │
     │          Not done yet          │
     └────────────────────────────────┘
              ✅ Done? → Stop

That's it. The agent looks at the goal, figures out the next step, does it, checks if it worked, and keeps going until the job is done.

(You might hear people call this "ReAct" which stands for Reason + Act. It's a formal way of saying the agent thinks about what to do, then does it, then thinks again. But at its core, it's just the loop above.)

Let me show you how this works with the resume example:

Goal: "Tailor this resume for an Amazon SDE role."

1. Agent reads the job description. Amazon wants Python, AWS, and distributed systems.
2. Agent reads your resume. Python and AWS are there. But distributed systems? It's buried in one bullet point that nobody would notice.
3. Agent rewrites that bullet point to make distributed systems stand out.
4. Agent checks again are all the important keywords from the job description covered? Not yet. Kafka is missing.
5. Agent looks at your experience. You actually used Kafka at your last job but never put it on the resume. (We all do this.)
6. Agent adds Kafka to the relevant section.
7. Final check. Everything important is covered. Done.

Seven steps. No human needed. The agent figured out what was missing, fixed it, checked its work, and moved on.

This is how every agent works whether it's tailoring resumes, monitoring servers, or analyzing data. Same loop, different tasks. (Okay, I'm oversimplifying a bit real agents sometimes have more complex decision trees. But this mental model will get you through 90% of what you'll build.)

The Autonomy Spectrum How Much Freedom Should an Agent Have?

Before we look at how to build an agent, let's understand how much freedom you can give one. "Agent" isn't all-or-nothing. It's a range.

Most real-world agents today are in the middle some human control, some agent freedom.

My advice: Start with orchestrated you define the workflow, the agent executes it. Once you trust it, give it more freedom gradually. Add human checkpoints for important steps. Fully autonomous? Maybe someday. Not yet for anything that matters.

The resume tailor agent we're building in this series? Semi-autonomous. It figures out what to fix and does the work, but shows you the result before anything gets submitted.

The Building Blocks of Every Agent

Now that you know how much freedom an agent can have, let's look at what you actually configure to make one work. Most frameworks I've used have these same pieces. Let's group them by what they do.

The Core: Who does what?

LLM (The Brain) - The AI model that does the thinking. GPT-4, Claude, Amazon Nova, Llama. Don't always use the most expensive model. Use cheap models for easy tasks, powerful models for hard tasks.

Role (The Identity) - Tell the agent WHO it is. Example: "You are a Senior Tech Recruiter with 15 years of experience." The more specific the role, the better the output. Vague roles give vague results.

Goal (The Finish Line) - When should the agent stop?

• ❌ Bad: "Help with job search"
• ✅ Good: "Find 5 Senior Python roles in Bangalore, 20-35 LPA, remote-friendly, from companies older than 3 years"

Task (The Instruction) - The specific work to do right now. "Read this job description. Compare it against the resume. List the top 5 skill gaps." Be as specific as possible the more you leave unclear, the more the agent makes up.

The Context: What does the agent know?

Backstory (The Personality) - Shapes HOW the agent approaches work. Same task, different backstory, different style:

• "Seasoned recruiter" → practical, beats resume-scanning software
• "Career coach" → encouraging, focused on growth
• "Brutally honest reviewer" → tears your resume apart (but you learn the most)

Knowledge Base (The Facts) - Information you hand the agent upfront. "The candidate is a Senior Python Developer. Based in Bangalore. Prefers remote. Salary: 20-35 LPA." Without this, the agent guesses. And it guesses wrong.

Memory (What It Remembers) - Two types:

• Short-term: Remembers what happened earlier in the current task. "I already found Python listed in the resume."
• Long-term: Remembers across sessions. Run it next week, it knows what worked last time.

The Safety Net: What keeps it under control?

Tools (The Hands) - What the agent can actually DO beyond generating text: search the web, read files, call APIs, run code. Without tools, it just writes. With tools, it takes action. Not every agent needs tools a resume rewriter just processes text, but a job searcher needs API access.

Guardrails (The Limits) - Rules that keep the agent in check:

• Max attempts → stop after X tries (otherwise it loops forever and burns your budget)
• Allowed actions → limit which tools it can use
• Output checks → verify the result makes sense

I always set guardrails. Always. I learned this at 2 AM watching my bill climb because an agent got stuck in a loop.

Human-in-the-Loop (The Pause Button) - For important decisions, make the agent stop and ask. The agent tailored your resume and is about to submit it. Instead of auto-submitting, it shows you the final version. "Should I submit this?" You review, approve, it continues.

Automate the boring parts. Keep human judgment for the important decisions.

Quick Reference

Ten pieces, three groups. Now let's see how multiple agents work together.

Multiple Agents Working Together

One agent is useful. But what if the job is too big for one?

You split the work. Just like a real team each person handles what they're best at.

Think of it like a restaurant:

• One chef doesn't do everything. There's someone who preps ingredients, someone who cooks, and someone who plates the dish.
• Each person does one thing well. Together, they serve a full meal.

Agents work the same way.

Our resume example with 3 agents:

Each agent does one thing. Together, they handle the full workflow.

How Do They Pass Work to Each Other?

Three patterns. You only need to know the first one for now.

1. Sequential - Like a relay race A→B→C

Agent 1 finishes → hands output to Agent 2 → hands to Agent 3.

This is what we'll use. It's the simplest. Easy to understand, easy to fix when something breaks you know exactly which agent caused the problem.

2. Hierarchical - Like a manager assigning tasks

One "boss" agent gives work to others and collects results. Useful when you need coordination, but more complex to set up.

3. Parallel - Everyone works at the same time

Multiple agents work on independent tasks simultaneously. Faster, but the tasks can't depend on each other. Example: three agents searching three different job boards at the same time.

For this series, we're using sequential. Agent 1 passes to Agent 2 passes to Agent 3. Simple, predictable, easy to debug. You can explore the other patterns later once you're comfortable.

Here's how our 3 agents work together:

┌──────────────┐       ┌───────────────┐       ┌─────────────────────┐
│ Job Analyzer │──────▶│ Resume Writer │──────▶│ Cover Letter Writer │
│              │       │               │       │                     │
│ "They want   │       │ Rewrites your │       │ Writes a letter     │
│  Python, AWS,│       │ resume to     │       │ connecting your     │
│  distributed │       │ highlight     │       │ experience to       │
│  systems"    │       │ those skills  │       │ their needs         │
└──────────────┘       └───────────────┘       └─────────────────────┘

CrewAI - The Framework We'll Use

I tried several agent frameworks. I picked CrewAI because it's simple and respects your time.

Why CrewAI?

• Free and open source - active community, regular updates
• Ready-made templates - gives you a working project structure immediately
• Plain English configuration - define agents and tasks in YAML (simple text files), not complex code
• Fast to start - first working agent in about 10 minutes once your environment is set up

Project Structure

When you create a CrewAI project, you get this folder structure:

my-agent-project/
├── src/
│   └── my_agent_project/
│       ├── config/
│       │   ├── agents.yaml      ← WHO: define your agents here
│       │   └── tasks.yaml       ← WHAT: define tasks here
│       ├── tools/
│       │   └── custom_tool.py   ← HOW: custom tools agents can use
│       ├── crew.py              ← WIRING: connects agents to tasks
│       └── main.py              ← START: entry point, kicks everything off
├── knowledge/                   ← FACTS: static files agents can read
├── .env                         ← SECRETS: API keys, model settings
└── pyproject.toml               ← DEPENDENCIES: Python packages needed

You only need to write three things: agent definitions, task definitions, and the wiring between them. Everything else is scaffolding that CrewAI handles.

CrewAI vs LangChain - When to Use Which

Use CrewAI when you know your agents and the flow is straightforward. Agent A does X, passes to Agent B which does Y. Done.

Use LangChain/LangGraph when you need complex logic like "if confidence is above 80% go to Agent A, otherwise retry with Agent B, and if that fails ask a human."

My take: Start with CrewAI. You can always add complexity later. Removing complexity? That's painful.

MCP - How Agents Talk to the Outside World

Your agent can think. But can it actually reach out and grab information from somewhere else? Like a database full of job listings? Or a file stored in the cloud?

That's what MCP does. It gives your agent a way to connect to outside services.

The Simplest Way to Understand MCP

Imagine you buy a new phone. You need to charge it. Now imagine every phone brand had a completely different charger one for Samsung, one for Apple, one for OnePlus, all different shapes.

That's what life was like before USB-C. Now? One cable works for almost everything.

MCP is the USB-C of AI agents. One standard way to connect to any service databases, file storage, APIs, messaging apps. You don't write different connection code for each one.

Back to Our Resume Agent

Our agent needs job listings. Where do those come from?

• Maybe a database with thousands of job posts
• Maybe files stored in the cloud (like AWS S3)
• Maybe a job board API

Without MCP: You write separate connection code for each one. Different code for the database. Different code for S3. Different code for the API. Every new service = more custom code.

With MCP: You configure the connection once in a simple settings file. The agent uses the same standard method to talk to all of them. New service? Just add another configuration. No new code.

The first time I set this up, it took me about 5 minutes. Writing custom database connection code used to take me an hour. That's the difference.

What Else Can Agents Connect To?

• Databases - fetch job listings, store results
• File Storage (S3) - read resumes, save tailored versions
• GitHub - read code, create pull requests
• Slack - send notifications, read messages
• Web Search - find information online

One standard way to connect to all of these. That's MCP.

We'll set this up hands-on in the next article. For now, just remember: MCP is how your agent reaches out to the world beyond its own code.

What Agents Can't Do Well (Yet)

Let me be honest about the limitations:

• They make things up. I've had an agent tell me it "successfully completed" something it definitely didn't do. Always check important outputs yourself.
• They cost money. One task = 5-20 AI model calls. A chatbot costs pennies. An agent can cost dollars per run. Multiply by hundreds of runs and your bill gets serious.
• They get stuck in loops. Without a maximum attempt limit, an agent will happily retry the same failing approach forever. (I learned this the hard way at 2 AM.)
• Same input, slightly different output. This makes testing tricky because you can't always predict the exact result.
• They're slow. Multiple AI calls + tool usage = seconds to minutes per task. Not milliseconds.
• They "fix" things you didn't ask about. When fixing one issue, an agent sometimes decides to also change nearby code. In a demo, fine. In production, you get unexpected changes. Set tight boundaries.

How I Handle These Problems

• Use cheap models for simple tasks. Amazon Nova Lite for easy stuff, Nova Pro for complex reasoning.
• Keep prompts short. Every word costs money.
• Always set max attempts. Non-negotiable.
• Log everything. I send all agent activity to CloudWatch Logs token counts, step durations, success/failure at each step. When something breaks at step 5 of 7, I can trace exactly what went wrong.
• Validate outputs. For critical tasks, I add a checking step either another agent that verifies the work, or structured checks that confirm the output meets requirements.

When NOT to Use Agents

Not everything needs an agent. I've seen people over-engineer simple problems because "agents are cool." Skip agents when:

• One AI call is enough - Summarize this text? Translate this paragraph? That's one API call, not an agent.
• The logic never changes - If there are no decisions to make and the steps are always the same, a simple script is cheaper, faster, and more reliable.
• You need instant responses - Agents take seconds to minutes. If you need millisecond responses for a real-time API, agents are too slow.
• High volume + simple task - 5-20 AI calls per task × 10,000 tasks per day = a very expensive month. If the task is simple and repetitive, write a rule-based system.
• Mistakes are unacceptable - Agents make errors. If a wrong answer has serious consequences (medical, legal, financial), don't rely on an agent without heavy human oversight.
• It's just a database query - Reading from a database and returning results? That's a simple API, not an agent.

My rule: If you can draw the logic as a simple flowchart with no "it depends" decisions, you don't need an agent. Use a script. Agents are valuable when there's ambiguity, judgment calls, and multi-step reasoning involved.

What's Next

In the next article, I'm building the resume tailor agent step by step using CrewAI on an EC2 instance with Amazon Nova Pro as the AI model. From setting up the server to running the agent against a real job description.

Stay tuned.

📌 Wrapping Up

Thanks for reading! If this was helpful:

• ❤️ Like if it added value
• 💾 Save for later
• 🔄 Share with your team

Follow me for more on: AWS architecture, FinOps, DevOps, and AI Infrastructure.

👉 Visit my website | Connect on LinkedIn | Email: simplynadaf@gmail.com

Happy Learning 🚀