DEV Community: Gulshan Yadav

What are AI Agents? The Practitioner's Guide to Autonomous Systems

Gulshan Yadav — Tue, 11 Aug 2026 02:30:00 +0000

A practical deep dive into how AI agents perceive, reason, and act autonomously — from classical architectures to modern LLM-based systems.

Two months ago, I was sitting in a co-working space in Dubai, debugging a customer-service pipeline for a fintech client. The system was straightforward: an LLM received a user query, generated a response, and returned it. Simple request-response. The client looked over my shoulder and asked, "Can it check the user's account balance, verify their KYC status, and then decide whether to escalate to a human agent — all on its own, without a separate rule for each step?"

I paused. What he was describing was not a chatbot. It was not a retrieval-augmented generation pipeline. It was not a fine-tuned language model. He was describing an AI agent — a system that perceives its environment, reasons about what to do, and takes autonomous action to achieve a goal.

That question consumed the better part of six weeks. I rebuilt his entire pipeline from scratch. In this guide, I will walk you through everything I learned — not the marketing version, but the working version: what agents actually are, how they are built, where they fail, and when you should not use one at all.

The Three-Letter Definition That Cuts Through the Noise

Every article about AI agents starts with a different definition, and it is exhausting. Here is the one I use when a client asks me to explain it in one sentence:

An AI agent is a system that perceives an environment, reasons about a goal, and takes actions to change that environment — iteratively, without a human authoring each step in advance.

Three words carry the whole idea: perceive, reason, act. A chatbot perceives text and reasons about a reply — but it never acts on the world. A script acts on the world — but never perceives or reasons. An agent does all three, in a loop, until the goal is met or it gives up.

This loop is the single most important mental model in the entire field right now. Keep it in your head and every framework, every paper, every "agentic" product suddenly makes sense:

┌─────────┐     ┌─────────┐     ┌─────────┐
│ Observe │ ──▶ │  Reason │ ──▶ │   Act   │
└─────────┘     └─────────┘     └─────────┘
     ▲                               │
     └──────────── loop ─────────────┘

A Quick History: Agents Were Not Invented by LLMs

Before we talk about modern systems, you need to know that agents are an old idea. The field has been fighting over this concept since the 1980s, and the classical taxonomy is still the cleanest way to understand what you are building.

Reactive agents. The simplest kind. They map current state directly to an action — no internal model, no memory. Think of a thermostat, or a robot vacuum that turns when it hits a wall. Fast, robust, stupid. They cannot plan.

Deliberative agents. They build an internal model of the world and reason over it before acting. Classic AI planning systems used search algorithms over state spaces. More expressive, far more expensive, and notoriously fragile when the model is wrong.

Hybrid agents. The practical compromise: a reactive layer for fast reflexes, a deliberative layer for slow thinking.

BDI (Belief-Desire-Intention) agents. The academic favorite. An agent keeps beliefs (what it knows about the world), desires (goals), and intentions (plans it has committed to). You will recognize BDI wearing a new coat in modern frameworks: beliefs are the system prompt and memory, desires are the goal, intentions are the tool calls in the loop.

The reason this history matters: every "revolutionary" agent framework in 2026 is a hybrid agent with an LLM as the deliberative layer and tools as the reactive layer. The architecture is thirty years old. What changed is the reasoning engine.

The Modern Stack: What Actually Makes an LLM an Agent

An LLM by itself is not an agent — it is a very clever text generator. To turn it into one, you add five things. Get these right and the agent works. Get any one wrong and it will fail in a new and interesting way every week.

1. The Goal (and the System Prompt)

Everything starts with a goal. Not a vague one — a specific, testable one. "Help users with their accounts" is not a goal; "resolve the user's request, or escalate to a human with a summary of what was tried" is.

The system prompt is where the goal lives, and it is also where the agent's personality, constraints, and self-knowledge live. The single biggest mistake I see in production systems is a system prompt that reads like a job description instead of an operating manual. A good one specifies: the goal, the boundaries (what the agent must not do), the tool inventory, the escalation path, and the tone. It is a contract, not a wish.

2. Memory (Two Kinds, Both Non-Negotiable)

Your agent needs two kinds of memory, and they are almost never the same thing:

Working memory — the conversation history in the context window; the agent's "train of thought." The hard constraint is the context window: you cannot stuff an entire customer's history into it. Be surgical about what goes in — recent turns, the current task state, and retrieval results.

Long-term memory — everything the agent knows beyond the current conversation. This is where vector databases come in. Embed the relevant knowledge (product docs, past tickets, policy manuals), retrieve the top-k chunks at the start of each turn, and inject them into the prompt. I have written at length about why retrieval quality matters more than model choice, and it is doubly true inside an agent loop: every bad retrieval is a wrong belief, and wrong beliefs produce confident wrong actions.

There is a third kind people forget: episodic memory — what this agent did last time. In serious deployments you log every run and use past runs to inform future ones. It sounds fancy. It is just a database with good querying.

3. Tools (The Agent's Hands)

This is the part that makes it an agent instead of a chatbot. Tools are functions the LLM can invoke: look up a balance, check KYC status, send an email, call an API, run SQL, search the web.

The critical technical detail: you are not calling these functions yourself — the LLM decides to call them and generates the arguments as structured output. In practice this means:

You declare each tool with a name, description, and JSON schema for its inputs.
The LLM emits a tool call (e.g., look_up_balance(user_id=123)).
Your runtime executes it, captures the result, and feeds the result back into the loop.

The description field is where the magic lives. A tool with a lazy description ("gets balance") will be misused constantly. A tool with a precise description ("look up the current available balance for a verified user; returns error if KYC is incomplete") gets used correctly. Treat tool descriptions as product documentation for the model — that is literally what they are.

4. The Loop (Orchestration)

The agent loop is embarrassingly simple in pseudocode:

while goal_not_met and budget_remaining:
    observation = current_state()          # conversation, retrieved docs, tool results
    decision   = llm.act(observation)      # reason → choose action
    if decision.is_final_answer: break
    result     = execute(decision.tool, decision.arguments)
    append(result, to_context)

Everything you will ever read about agent frameworks — LangChain, CrewAI, AutoGen, custom loops — is a wrapper around this loop, with different opinions about how to structure memory, when to stop, and how many agents to spawn. The loop itself is universal.

5. The Guardrails (Budget and Stop Conditions)

Agents can loop forever, spend your API budget, and take actions you never authorized. Every production agent needs:

A step budget — "at most 12 tool calls per task."
A cost budget — "fail soft once spend exceeds $0.10 per conversation."
A time budget — "escalate after 90 seconds."
A permission layer — read-only actions are free; mutating actions (sending email, transferring money, deleting records) require human approval or a stricter policy.
An escape hatch — when the agent is uncertain, it must know how to hand off to a human with a readable summary of what it tried.

I know a startup that deployed an agent with none of these. It was supposed to draft refund decisions for review. Within a week, a prompt-injection in a customer message made the agent approve a refund the company never should have given. The refund itself was small. The trust damage was not. Guardrails are the product, not a nice-to-have.

A Minimal Working Example (Python)

Let me make this concrete with the smallest agent I would ship to a client. No framework — just an LLM call, one tool, and a loop. This is deliberately minimal so you can see every moving part.

import json
from openai import OpenAI

client = OpenAI()  # or any OpenAI-compatible endpoint

TOOLS = [
    {
        "type": "function",
        "function": {
            "name": "get_balance",
            "description": "Get the current available balance for a verified account.",
            "parameters": {
                "type": "object",
                "properties": {
                    "account_id": {"type": "string"}
                },
                "required": ["account_id"]
            }
        }
    }
]

def get_balance(account_id: str) -> str:
    # In production this queries a database with authz checks.
    return json.dumps({"account_id": account_id, "balance": 1240.50})

def run_agent(goal: str, messages: list, max_steps: int = 5) -> str:
    system = (
        "You are a customer support agent. Your goal: resolve the request, "
        "or escalate with a summary of what was tried. "
        "You may call tools when you need data. Be concise and honest."
    )
    msgs = [{"role": "system", "content": system}] + messages + [
        {"role": "user", "content": goal}
    ]
    for step in range(max_steps):
        resp = client.chat.completions.create(
            model="your-model",
            messages=msgs,
            tools=TOOLS,
        )
        msg = resp.choices[0].message
        if not msg.tool_calls:
            return msg.content  # final answer
        msgs.append(msg)
        for tc in msg.tool_calls:
            result = {"role": "tool", "tool_call_id": tc.id,
                      "content": globals()[tc.function.name](
                          **json.loads(tc.function.arguments))}
            msgs.append(result)
    return "ESCALATE: step budget exhausted. Tried: " + repr(msgs[-3:])

print(run_agent(
    "What is the balance on account ACC-1042?",
    [],
))

Run this and you will see the loop in action: the model asks for the balance, your code executes the tool, the result goes back in, and the model answers. That is the entire skeleton of an agent. Everything else is scale and polish.

Multi-Agent Systems: When One Agent Isn't Enough

A natural question follows: if one agent is good, is a team of agents better? Sometimes yes, often no.Multi-agent systems work when the task genuinely decomposes into roles with different expertise, different tools, and different constraints: a researcher agent, a writer agent, a reviewer agent. They shine in complex workflows like due-diligence reports or code review pipelines. They fail when you cannot split the task cleanly, because every agent boundary is a handoff — and every handoff is a place where information is lost, tokens are burned, and latency accumulates. A single agent with good tools will beat a five-agent team on a linear task every time.

The rule I now follow: start with one agent. Split only when a single agent's context, tool surface, or permission boundary becomes the bottleneck. Split for security (read-only researcher vs. write-capable operator), not for fashion.

Where Agents Fail in Production (I Have the Scars)

Let me save you six weeks. These are the failure modes I hit, in order of how much they hurt:

Hallucinated tool calls. The model invents arguments that do not exist, or calls a tool that is not appropriate. Fix: strict JSON schema enforcement, tool descriptions written like contracts, and validation before execution.
Greedy loops. The agent retries the same failing action with slight variations, burning budget. Fix: track repeated failures and force escalation after N identical attempts.
Context poisoning. A retrieval result or a tool output injects instructions ("ignore previous instructions..."). Fix: treat all tool/retrieval content as untrusted data; never let it override the system prompt; sanitize and quote it.
Silent degradation. The agent stops using tools and starts guessing from its training data, quietly producing plausible wrong answers. Fix: instrument every run and alert when tool-call rate drops below a threshold.
Cost creep. Complex tasks average 3–8 tool calls; at production volume that is real money. Fix: measure cost per resolved task, cache retrievals, and use cheaper models for the loop with a stronger model for final synthesis.

The Honest Cost-Benefit: When NOT to Build an Agent

This is the part most articles skip, because "agent" sells. Here is the truth:

Build an agent when: the task is goal-directed, multi-step, requires tools or data lookups, and changes enough that hand-written rules would be a maintenance nightmare.

Do not build an agent when: the task is a single step, the inputs are predictable, or the cost of a wrong autonomous action is high and the approval latency is acceptable. For a fixed, well-understood flow, a deterministic script or a good prompt template beats an agent on cost, latency, and reliability — every single time.

I told this to a client who wanted to "agentify" a form-filling flow. We timed it: the deterministic version resolved requests in 1.4 seconds at $0.0001 each. The agent version took 6 seconds and $0.02 each, and occasionally misread a field. The client saved a lot of money by not building what he asked for. That is what a good consultant is for.

The Practitioner's Checklist

When you ship an agent, go through this list before you call it done:

[ ] Goal is specific and testable (not "be helpful")
[ ] System prompt is an operating manual: goal, boundaries, tools, escalation, tone
[ ] Working memory respects context-window limits
[ ] Long-term memory uses retrieval that is measured, not assumed
[ ] Tool descriptions read like contracts, inputs validated before execution
[ ] Step, cost, and time budgets exist
[ ] Mutating actions have a permission layer
[ ] Escalation path produces a human-readable summary
[ ] Observability: every run logged, tool-call rate monitored
[ ] You have written the test that proves a wrong action cannot silently happen

What I Would Tell That Client in Dubai, Six Weeks Later

The fintech pipeline I rebuilt now checks balances, verifies KYC, drafts refund decisions for human approval, and escalates with a readable summary when it is unsure. It does not run on magic: a goal, a good system prompt, a vector store for memory, four well-described tools, strict budgets, and a loop that knows when to stop.

The next time someone tells you an AI agent "does things on its own," you now know what that sentence actually means: a loop, some tools, a goal, and a lot of guardrails. Start with the minimal example above. Run it. Break it. Fix it. Then and only then add memory, more tools, and finally — maybe — a second agent.

*Gulshan Yad

Introducing Misar.Blog MCP Server: Publish Blog Posts with AI Agents

Gulshan Yadav — Thu, 14 May 2026 12:51:25 +0000

We just launched the Misar.Blog MCP Server — a Model Context Protocol server that lets AI agents publish and manage blog content on Misar.Blog directly.

What is it?

The Misar.Blog MCP Server exposes 20 tools that AI agents (Claude, Cursor, Cline, etc.) can use to:

Publish articles — create drafts, publish posts, schedule content
Manage series — create and organize multi-part article series
Analytics — query article views, engagement, and performance data
Comments & Reactions — moderate comments, fetch reactions
Newsletter — manage subscriber lists and campaigns
AI content generation — generate article content with AI assistance
Tag management — organize content with tags
Media uploads — attach images and files to posts

Quick Start

Connect via Smithery (no setup needed):

https://smithery.ai/servers/misar/misarblog-mcp

Or install locally:

npm install -g misarblog-mcp

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "misarblog": {
      "command": "npx",
      "args": ["-y", "misarblog-mcp"],
      "env": {
        "MISARBLOG_API_KEY": "your_api_key_here"
      }
    }
  }
}

Get your API key from misar.blog/settings/api.

Remote MCP URL

You can also connect directly via streamable HTTP:

https://www.misar.blog/api/mcp

With header: Authorization: Bearer <your_api_key>

Show DEV: MisarMail — Self-Hosted Email Infrastructure (Transactional, Marketing, Bulk)

Gulshan Yadav — Sat, 28 Mar 2026 12:33:01 +0000

What I Built

MisarMail is a self-hosted email infrastructure platform for sending transactional, marketing, and bulk email — without paying SendGrid, Mailgun, or Resend.

URL: https://mail.misar.io

Why I Built It

Every product I ship needs email — welcome emails, password resets, newsletters, bulk campaigns. Third-party email services add up fast. I wanted full control, zero per-email cost, and a simple API I own.

How It Works

REST API — POST /api/v1/send with your payload, done
SMTP relay — drop-in replacement for any SMTP config
Bounce handling — automatic bounce and complaint processing
Delivery tracking — opens, clicks, delivery status
Multi-domain — send from multiple domains and identities

Tech Stack

Self-hosted on a Hetzner VPS via Coolify. Mailcow under the hood for SMTP, custom API layer on top.

Try It

https://mail.misar.io

No third-party email spend. Full delivery control. API-first.

Show DEV: Free AI Cost Calculators for Developers — LLM Costs, Evaluations, Tokens, RAG

Gulshan Yadav — Fri, 27 Mar 2026 21:07:16 +0000

I built a set of 4 free AI calculators that run entirely in the browser — no signup, no API keys, no backend.

🔗 tools.misar.io

What's included

1. LLM Cost Calculator

Compare pricing across 14 models from OpenAI, Anthropic, Google, Mistral, Groq, and DeepSeek. Enter your token usage and get real-time daily, monthly, and annual cost projections. See all providers side-by-side sorted by cost.

2. AI Evaluation Scorecard

Assess AI system quality across multiple dimensions — accuracy, latency, cost efficiency, safety, and more. Get a weighted composite score to compare different AI approaches.

3. Prompt Token Estimator

Count tokens before making API calls so you know exactly what you'll pay. Supports multiple tokenizer models.

4. RAG Cost Estimator

Calculate the true cost of running retrieval-augmented generation pipelines — embedding costs, vector DB storage, retrieval queries, and generation costs combined.

Why I built this

Every AI team I've worked with wastes time on spreadsheets trying to estimate costs. These tools solve that with zero friction — open the URL, use the calculator, done.

Tech stack

Pure HTML/CSS/JavaScript — no frameworks, no dependencies
Runs entirely client-side in your browser
Mobile responsive
Free forever

Would love feedback from the community. What other AI calculators would be useful?

Built by Gulshan Yadav at Misar AI