DEV Community: Zahid Hasan Tonmoy

The Four Components of an AI Agent, in One Small TypeScript File

Zahid Hasan Tonmoy — Mon, 05 Oct 2026 04:25:20 +0000

Most explanations of AI agents stop at “a model with tools”. That is true, but it doesn't help when your agent forgets a preference, calls the wrong function or loops forever. To debug any of those, you need to know which part is misbehaving.

This post continues my series on building agents. The previous one covered LLMs versus agents.

The four components of an AI agent

An AI agent has four components: a brain (the language model that decides what to do next), memory (the conversation history and stored facts the model can read), tools (functions that let it act outside the model) and an action loop (the code that calls the model, runs the tools it asks for and feeds the results back). The brain is the only part that is a model. The other three are code and data that you write and control.

Part	What it does	Without it
Brain	Reads everything and decides the next step	Nothing decides, so you have a fixed script
Memory	Holds the conversation and stored facts	The agent forgets between steps or sessions
Tools	Let it read or change things outside the model	It can only talk
Action loop	Runs the model, executes tools, returns results	One answer, then it stops

Each part in a few lines

Brain. The language model. Each turn it gets the system prompt, the conversation, the tool list and any tool results, and it returns either text or a request to call a tool. It never runs anything itself.

Memory. Two layers. Short-term memory is the message history you send with every call. Long-term memory is anything written to storage and read back in a later run: a notes file, a database row, a vector store. The model remembers nothing between calls, so both layers are your code's job.

Tools. An ordinary function plus a description: a name, when to use it, and a JSON Schema for the inputs. The model never sees your code, only the description, so write it like API docs for a reader who can't ask questions.

Action loop. Send memory to the brain. Plain text means done. A tool request means run the tool, append the result to memory and go around again. Give the loop exits: a final answer, a step cap, unrecoverable failures, human approval.

All four in one file

This is an expense tracker with a notes file. Install the SDK with npm install @anthropic-ai/sdk, set ANTHROPIC_API_KEY and run npx tsx agent/four-parts.ts.

// agent/four-parts.ts
import Anthropic from '@anthropic-ai/sdk';
import { existsSync, readFileSync, writeFileSync } from 'node:fs';

const client = new Anthropic();
const NOTES_FILE = 'notes.json';

const messages: Anthropic.MessageParam[] = [];
const expenses: { item: string; amount: number }[] = [];

function loadNotes(): string[] {
  return existsSync(NOTES_FILE) ? JSON.parse(readFileSync(NOTES_FILE, 'utf8')) : [];
}

const tools: Anthropic.Tool[] = [
  {
    name: 'add_expense',
    description: 'Record one expense. Use it whenever the user says they spent money.',
    input_schema: {
      type: 'object',
      properties: {
        item: { type: 'string' },
        amount: { type: 'number', description: 'Amount in BDT' },
      },
      required: ['item', 'amount'],
    },
  },
  {
    name: 'get_total',
    description: 'Return the exact total of all recorded expenses in BDT.',
    input_schema: { type: 'object', properties: {} },
  },
  {
    name: 'save_note',
    description: 'Save a lasting fact about the user, such as a preference, for future sessions.',
    input_schema: {
      type: 'object',
      properties: { note: { type: 'string' } },
      required: ['note'],
    },
  },
];

const handlers: Record<string, (input: Record<string, unknown>) => unknown> = {
  add_expense: (input) => {
    expenses.push({ item: String(input.item), amount: Number(input.amount) });
    return { ok: true, recorded: expenses.length };
  },
  get_total: () => ({ total: expenses.reduce((sum, e) => sum + e.amount, 0) }),
  save_note: (input) => {
    writeFileSync(NOTES_FILE, JSON.stringify([...loadNotes(), String(input.note)]));
    return { ok: true };
  },
};

function execute(name: string, input: Record<string, unknown>): unknown {
  try {
    const handler = handlers[name];
    return handler ? handler(input) : { error: 'unknown tool' };
  } catch (err) {
    return { error: String(err) };
  }
}

async function runAgent(userText: string): Promise<string> {
  messages.push({ role: 'user', content: userText });

  for (let step = 0; step < 6; step++) {
    const response = await client.messages.create({
      model: 'claude-sonnet-5',
      max_tokens: 1024,
      system: `You track expenses. Known about the user: ${loadNotes().join('; ') || 'nothing yet'}`,
      tools,
      messages,
    });

    messages.push({ role: 'assistant', content: response.content });

    if (response.stop_reason !== 'tool_use') {
      return response.content.flatMap((b) => (b.type === 'text' ? [b.text] : [])).join('');
    }

    const results: Anthropic.ToolResultBlockParam[] = [];
    for (const block of response.content) {
      if (block.type === 'tool_use') {
        const output = execute(block.name, block.input as Record<string, unknown>);
        results.push({ type: 'tool_result', tool_use_id: block.id, content: JSON.stringify(output) });
      }
    }
    messages.push({ role: 'user', content: results });
  }

  return 'Stopped: step limit reached';
}

async function main() {
  console.log(await runAgent('I spent 250 on lunch and 80 on a rickshaw. I prefer short answers.'));
  console.log(await runAgent('What is my total so far?'));
}

main();

The brain is client.messages.create. Memory is messages plus notes.json. The tools are tools, handlers and execute. The action loop is the for block in runAgent.

The mistake that cost me an afternoon

The first version of this tracker forgot everything between messages. I had written const messages = [] inside the function that handled each user message, so every call started with a blank history. I blamed the system prompt and kept rewriting it until I noticed the array was being recreated on every call. Moving one line out of the function fixed it.

Common mistakes

Vague tool descriptions. The brain picks tools by reading them, so say what the tool does, what it needs and when to use it.
Sending the whole history forever. Cost and latency climb. Trim or summarize old turns and keep lasting facts in a separate store.
Swallowing tool errors. Return the error text as the result, as execute does, so the model can try again.
Making the brain do work that code can do. Summing amounts inside the prompt invites slips. That is why get_total is a tool.

Read the full version

I write each post in English and Bangla. The full version, with a diagram, is on my blog: What's Inside an AI Agent?

Which of the four parts is hardest for you to debug?

What an AI Agent Actually Is, With a Working TypeScript Loop

Zahid Hasan Tonmoy — Tue, 29 Sep 2026 09:25:53 +0000

When people say “AI agent”, they usually mean one specific thing: a language model that can act, look at what happened, and decide what to do next. Everything else is packaging.

This post is the short version, plus a loop you can run in a few minutes.

The definition I actually use

An AI agent is a software system that uses a language model to work toward a goal on its own. It decides the next step, uses tools such as APIs, databases or a code runner, checks the result, and repeats until the job is done or it needs a human.

A chatbot answers once. An agent keeps going.

The loop

The user gives a goal.
The model reads the goal and the history so far, then picks the next step.
If it needs a tool, your code runs it.
The result goes back to the model as new information.
Back to step 2, until the model returns a final answer.

A runnable version

The example below uses the Anthropic SDK and a fake in-memory order lookup, so an API key is all you need.

// agent/loop.ts
import Anthropic from '@anthropic-ai/sdk';

const client = new Anthropic();

const orders: Record<string, { status: string; eta: string }> = {
  'BD-1042': { status: 'out for delivery', eta: 'today' },
  'BD-1043': { status: 'processing', eta: '5 days' },
};

const tools: Anthropic.Tool[] = [
  {
    name: 'get_order_status',
    description: 'Look up the status and delivery estimate of an order by its ID',
    input_schema: {
      type: 'object',
      properties: { order_id: { type: 'string' } },
      required: ['order_id'],
    },
  },
];

function runTool(name: string, input: { order_id: string }) {
  if (name === 'get_order_status') {
    return orders[input.order_id] ?? { error: 'order not found' };
  }
  return { error: 'unknown tool' };
}

async function runAgent(goal: string) {
  const messages: Anthropic.MessageParam[] = [{ role: 'user', content: goal }];

  for (let step = 0; step < 5; step++) {
    const response = await client.messages.create({
      model: 'claude-sonnet-5',
      max_tokens: 1024,
      tools,
      messages,
    });

    messages.push({ role: 'assistant', content: response.content });

    if (response.stop_reason !== 'tool_use') {
      const block = response.content.find((b): b is Anthropic.TextBlock => b.type === 'text');
      return block?.text ?? '';
    }

    const results: Anthropic.ToolResultBlockParam[] = response.content
      .filter((b): b is Anthropic.ToolUseBlock => b.type === 'tool_use')
      .map((b) => ({
        type: 'tool_result',
        tool_use_id: b.id,
        content: JSON.stringify(runTool(b.name, b.input as { order_id: string })),
      }));

    messages.push({ role: 'user', content: results });
  }

  return 'Stopped: step limit reached';
}

runAgent('Where is my order BD-1042?').then(console.log);

Install the SDK with npm install @anthropic-ai/sdk, set ANTHROPIC_API_KEY and run npx tsx agent/loop.ts. Three parts carry the idea: the tools array (what the model may do), the loop (how real results flow back), and the step cap (so a confused model cannot circle forever).

Why people are suddenly talking about agents

The idea is decades old. What changed is that the pieces became dependable:

Tool calls got reliable. Models now produce structured calls that code can execute, and they read error messages to try again.
Loops became affordable. A job can take ten model calls, and lower prices plus faster models made that practical.
Shared plumbing. Function calling is everywhere, and open protocols like MCP (introduced by Anthropic in late 2024) let one agent talk to many tools.
Visible results. Coding agents that edit files, run tests and fix their own failures showed developers finished work instead of suggestions.

Agents still fail: the wrong tool, repeated steps, a confident answer to the wrong task. That is why limits, logging and human approval are part of the job.

The mistake I made first

My first support-style assistant kept inventing delivery dates when I tested it. I blamed the system prompt and kept rewriting it. The real problem was that the model had no way to look anything up. One lookup tool fixed what no amount of prompt rewriting had.

Three things I watch for now:

Calling every fixed script an agent. A fixed sequence of model and function calls is a workflow. It is often the better design, but it debugs differently.
No step limit. A stuck model can loop and spend your API budget while you sleep.
Write access too early. Start read-only and add human approval before anything irreversible.

What's next

This is the first post in a series where I build agents step by step, from how they are put together to running one in production. I write each post in English and Bangla, and the original lives on my blog: What Is an AI Agent, Really?

What was the first thing you tried to make an agent do?

Building a Laravel Marketplace with PostgreSQL While Debugging React State

Zahid Hasan Tonmoy — Mon, 21 Sep 2026 05:21:29 +0000

I spent the last few days building instead of just watching — a small Laravel marketplace project backed by PostgreSQL, plus some hands-on React work. I also got stuck a couple of times, and writing down where I got stuck turned out to be the most useful part of the process.

On the Laravel side, I went back to fundamentals first: routes, controllers, views, and Blade. I practiced the full request cycle — a route hitting a controller, the controller passing data to a view, and Blade handling variables, loops, and conditionals. I also worked through basic form validation, mostly to get the muscle memory right before moving on to anything more complex.

The more interesting part was designing the database for a marketplace-style project with PostgreSQL. The plan is four roles — Admin, Moderator, Seller, and Buyer — with two business rules that shaped most of the schema decisions: a seller can't buy their own product (though buying from other sellers is fine), and a seller's product doesn't go live the moment it's created. It has to be approved by an Admin or Moderator first.

Translating those two rules into actual migrations is where the real learning happened. I added a role field to the users table, defaulting to buyer. Then I built a products table with seller_id, title, description, price, stock, status, approved_by, and approved_at. New products start with a pending status so the approval workflow has something to act on.

Working through this made migration concepts click in a way tutorials hadn't — up() and down(), foreign keys, nullable columns, defaults, and relationships. The seller relationship uses cascading deletes (delete a seller, their products go too), but the approver relationship just sets approved_by to null if that admin or moderator is removed — the product itself stays. Seeing why those two behaviors need to be different made foreign key constraints feel a lot less abstract.

I also hit a real environment issue: running Laravel's db:table command failed because of a missing PHP intl extension. It took a minute to realize the error wasn't in my code at all — it was a missing PHP extension. Small as it was, debugging it felt like as much a part of "learning Laravel" as writing the migrations themselves.

On the React side, I worked with useState and useEffect, fetching show data from the TVMaze API. The main lesson here was that fetch only rejects on a network failure — not on an HTTP error like a 404 or 500. So I started checking response.ok explicitly and throwing an error when it fails, then wrapped the whole request in try/catch/finally to keep loading, data, and error states cleanly separated:

useEffect(() => {
  const fetchShows = async () => {
    setLoading(true);
    try {
      const res = await fetch("https://api.tvmaze.com/search/shows?q=all");
      if (!res.ok) throw new Error("Failed to fetch shows");
      const data = await res.json();
      setShows(data);
    } catch (err) {
      setError(err.message);
    } finally {
      setLoading(false);
    }
  };
  fetchShows();
}, []);

I also ran into a small but genuinely confusing bug: logging state right after calling setShows still showed the old value. It wasn't that the update failed — it was that the log was reading a stale value from that render's closure, before React had re-rendered with the new state. Chasing that down taught me more about how React's state updates and re-renders actually work than any explanation had.

The biggest takeaway from this stretch is that learning a framework isn't about memorizing syntax — it's routes, controllers, migrations, relationships, API calls, and state management all working together inside one real application. Next up: building out the approval flow and seller dashboard on top of this schema, and getting more reps in with React's data-fetching patterns.

This article was originally published on Zahid Hasan Tonmoy's Portfolio.
Connect with Zahid on GitHub & LinkedIn.

Laravel Blade: Passing Data from Controller to View and Rendering It Dynamically

Zahid Hasan Tonmoy — Wed, 16 Sep 2026 12:04:53 +0000

Laravel applications often need to pass data from a Controller to a View and then turn that data into HTML. I recently practiced this flow using Blade templating.

The Practice

I worked with a simple student data structure containing values such as name, department, university, CGPA, and skills.

The goal was to understand how this data can move from the Controller into a Blade View and then be rendered dynamically.

Dynamic Values in Blade

Blade uses double curly braces to display values safely in a template. For example:

The same pattern can be used for other fields:

This is more flexible than writing the actual values directly into the HTML.

Rendering an Array with @foreach

The student data also contained multiple skills. Instead of creating a separate HTML element manually for every skill, I used @foreach:

@foreach($student['skills'] as $skill)

Skill: {{ $skill }}

@endforeach

The loop goes through the array and creates the required output for each item.

Conditional Content with @if

Blade also provides directives for conditional rendering. I practiced @if to display content when a condition is satisfied.

This becomes useful when a View needs to present different information depending on the data it receives.

Why This Practice Matters

This exercise helped connect a few Laravel concepts together instead of learning Blade syntax in isolation.

The basic flow is:

Controller → data → View → Blade rendering

Understanding this flow makes it easier to move toward database-backed Laravel applications, where Controllers receive or prepare real application data and Blade presents it to users.

Final Takeaway

The practice was simple, but it clarified how Blade works with dynamic data. {{ }} handles values, @foreach handles repeated data, and @if handles basic conditional rendering.

These are small building blocks, but they are useful when creating Laravel Views that depend on real application data.

From MERN to Laravel: Why I'm Learning PHP and PostgreSQL as a MERN Developer published: false tags: laravel, php, postgresql, webdev

Zahid Hasan Tonmoy — Mon, 14 Sep 2026 06:33:14 +0000

If you'd told me a couple of years ago that I'd spend my evenings writing PHP, I would've laughed it off. I built my whole identity as a developer around MERN — MongoDB, Express, React, Node. It was fast, it was JavaScript top to bottom, and it felt like the "modern" stack compared to what a lot of local agencies were still running.

So it's a little funny to be sitting here now, a few months into learning Laravel and PostgreSQL, actually enjoying it. This isn't a "PHP was secretly amazing the whole time" post. It's more of an honest breakdown of why I started, what's been genuinely harder than I expected, and what's actually made me a better developer in the process.

Why bother, if MERN already works

Two things pushed me here.

First, the job and freelance market. I'm based in Dhaka, and if you look at what local agencies, small businesses, and even a lot of remote clients are actually running, PHP is everywhere. Laravel specifically shows up constantly in job posts and freelance briefs here — way more than I expected when I was deep in my MERN bubble. Sticking to one stack was quietly shrinking the pool of work I could take on.

Second, and this one surprised me more — I wanted to actually understand a relational database properly. I'd built a handful of projects on MongoDB, and I realized I'd never really had to think hard about schema design, foreign keys, or joins. MongoDB lets you get away with a lot of "figure it out later" thinking. I wanted to know what I was missing.

The parts that messed with my head

Coming from Mongoose, Eloquent felt oddly strict at first. In Mongoose, your schema is basically a suggestion:

// Mongoose — schema is more of a guideline
const productSchema = new mongoose.Schema({
  name: String,
  price: Number,
  tags: [String], // add whatever, whenever
});

In Laravel, the database is the source of truth, and migrations force you to commit to a structure before you write a line of app logic:

// Laravel migration — schema is law
Schema::create('products', function (Blueprint $table) {
    $table->id();
    $table->string('name');
    $table->decimal('price', 8, 2);
    $table->foreignId('category_id')->constrained();
    $table->timestamps();
});

That foreignId()->constrained() line is such a small thing, but it represents a mindset shift I didn't expect. In MongoDB, "relationships" are usually just an ID you remember to populate correctly in your app code. In PostgreSQL, the database itself refuses to let you insert a product with a category that doesn't exist. The first time a constraint error caught a bug I would've silently shipped in MERN, I actually said "huh" out loud at my desk.

Artisan took some getting used to too. php artisan make:model Product -m scaffolds a model and migration in one command, and there's a generator for basically everything — controllers, requests, seeders, jobs. Coming from hand-rolling most of my Express boilerplate, it felt like cheating at first. Now I just think of it as Laravel handling the parts of backend dev that were never interesting anyway.

Blade was the smallest adjustment, honestly, mostly because I'd already done enough server-rendered work to not be precious about JSX. It's just PHP mixed into HTML with some sugar on top — @if, @foreach, component includes. Nothing revolutionary, but nothing to fight either.

What I'm not giving up

I want to be clear this isn't a "MERN was a phase" post. I'm still building with React and Node, and most of what I've shipped so far leans on that stack — a machine-learning-backed gold price predictor, a peer-to-peer file sharing tool built on WebRTC, an IoT drainage monitoring setup running on an ESP32 feeding into Firebase. None of that goes away.

What's changed is that I stopped treating "the stack" as a personality trait. Laravel and PostgreSQL are just more tools now, and honestly, having both a document-store mental model and a relational one makes me design better MERN apps too. I catch myself asking "should this actually be normalized?" in Mongoose schemas now, which never used to occur to me.

If you're a MERN dev thinking about doing the same

A few things that would've saved me time:

Don't fight Eloquent relationships — learn hasMany, belongsTo, and belongsToMany properly before building anything. Half of Laravel's "magic" is just these three.
Migrations are version control for your schema. Treat them like git commits — small, descriptive, one change at a time.
php artisan tinker is basically a Node REPL for your Laravel app. Use it constantly to test queries before wiring them into controllers.
PostgreSQL's EXPLAIN ANALYZE is worth learning early. Coming from Mongo, I never had to think about query performance this explicitly.

Where this is heading

I'm still early — a few real projects deep, not an expert by any stretch. But I'm at the point where I'd genuinely take on Laravel or PostgreSQL work alongside MERN projects, and I'm actively looking for freelance and full-time opportunities where I can keep building across both.

If you're working on something and think there's a fit, or you just want to see what I've built so far, my projects and contact info are here:

🔗 Portfolio: https://zahidhasantonmoy.vercel.app
🔗 GitHub: https://github.com/zahidhasantonmoy

From Web Apps to Blinking LEDs: Why Every Software Developer Should Try Hardware 🛠️

Zahid Hasan Tonmoy — Mon, 24 Aug 2026 08:55:30 +0000

Hey everyone! 👋 Zahid here.

Let us be honest—staring at code all day can become a little tiring. Most of my time is spent in the software world: writing Python tweaking a Flutter UI deploying databases on Supabase or making sure my cloud hosting on Render runs smoothly. It is fun. It is all... Virtual.

Recently I decided to step from purely software projects and started tinkering with hardware. I grabbed an ESP32, some sensors and just began playing around.. Honestly? It completely changed my view on programming.

Here’s why I think every software developer should try messing around with hardware at once:

The "Physical" Reward 💡

When you build a web app a successful compilation means a tick on your terminal or a webpage loading correctly.. When you write a few lines of code and a physical LED lights up or a robotic arm moves on your desk? That dopamine hit is just built different! It makes your code feel alive.

It Makes You Appreciate the Cloud More ☁️

Working with microcontrollers that have limited memory makes you realize how spoiled we are with cloud infrastructure. Suddenly every byte of data matters. It teaches you to write more efficient code—which ultimately makes you a better software developer.

The Ultimate Playground for AI 🤖

This is the part I'm most excited about. I have been exploring No‑Code AI agents and machine learning lately. Imagine combining an AI model with a sensor—like a smart camera that actually reacts to its environment in real time. Hardware is the bridge that brings AI out of the browser and into the world.

The Takeaway

You do not need to be an engineer to start. If you know a bit of Python you are already 90%. Grab a microcontroller a few jumper wires and build something useless but fun.

Have any of you made the jump, from software to hardware?. Have you built any cool IoT projects lately? Let us chat in the comments! 👇

Let us Connect! 🚀 If you want to talk about tech, AI or see what I am building feel free to reach out. I would love to connect!

🌐 Portfolio: zahidhasantonmoy.vercel.app

💼 LinkedIn: linkedin.com/in/zahidhasantonmoy

🐦 X (Twitter): @zahidhasan_bd

📘 Facebook: zahidhasantonmoybd