DEV Community: Anindya Mukherjee

Why Can't You Debug an AI Agent the Way You Debug an API?

Anindya Mukherjee — Mon, 14 Sep 2026 11:04:25 +0000

I spent two hours staring at a terminal that said nothing useful.

The agent had "succeeded." Status: green. Output: a half-written PR description, a deleted test file it was supposed to fix, and a cheerful summary claiming everything was fine. No stack trace. No failed step. No breadcrumbs. Just vibes.

If this were an API, I'd open the logs, grep the request id, and find the 500 in twelve seconds. With agents, I get a shrug and a bill.

That's the observability gap — and it's why most "autonomous" demos die the moment you try to ship them.

Agents fail like interns, not like services

A microservice fails loudly. Status codes. Timeouts. Structured errors. You can alert on them.

An agent fails politely. It retries the wrong tool. It invents a path that doesn't exist. It loops on a "almost right" answer until your token budget is a sad little crater. Then it writes a confident final message like a student who didn't do the reading.

Think of a normal backend as a subway map: every station reports where the train is. An agent without traces is a paper airplane you threw over a fence. You know it left. You do not know if it hit the neighbor's dog.

Stop debugging with "print(thoughts)"

The first instinct is to dump the chain-of-thought into stdout and squint. That works once. It does not work at 2 a.m. when three tools fired, two of them twice, and the model quietly changed the plan mid-flight.

You need the same three things every debuggable system has:

Identity — a run id for the whole job
Steps — ordered spans: plan → tool call → tool result → decision
Outcomes — success / retry / give-up, with why

Not a novel. A flight recorder.

A pasteable mini flight recorder

Drop this next to your agent loop. It is deliberately boring. Boring is the point.

import json, time, uuid
from contextlib import contextmanager

class AgentTrace:
    def __init__(self, job: str):
        self.run_id = str(uuid.uuid4())[:8]
        self.job = job
        self.events = []
        self.t0 = time.time()

    def log(self, kind: str, **data):
        self.events.append({
            "ts": round(time.time() - self.t0, 3),
            "run": self.run_id,
            "kind": kind,
            **data,
        })

    @contextmanager
    def span(self, name: str, **meta):
        self.log("span_start", name=name, **meta)
        t = time.time()
        try:
            yield
            self.log("span_ok", name=name, ms=int((time.time()-t)*1000))
        except Exception as e:
            self.log("span_err", name=name, error=str(e)[:300])
            raise

    def dump(self, path=None):
        payload = {"job": self.job, "run_id": self.run_id, "events": self.events}
        text = json.dumps(payload, indent=2)
        if path:
            open(path, "w").write(text)
        return text

# usage inside your loop
trace = AgentTrace("fix-flaky-test")

with trace.span("plan"):
    plan = llm.plan(ticket)          # your planner
    trace.log("plan", steps=plan)

for step in plan:
    with trace.span("tool", tool=step["tool"], input=step.get("input")):
        result = tools[step["tool"]](step.get("input"))
        trace.log("tool_result", tool=step["tool"],
                  ok=bool(result), preview=str(result)[:200])
    if not result:
        trace.log("decision", action="retry_or_abort", reason="empty_result")
        break

print(trace.dump("last_run.json"))

Now when the agent "succeeds" while deleting your tests, you open last_run.json and see the exact span where the plan went feral — instead of re-running the whole thing and hoping the model feels different today.

Three signals worth alerting on

You do not need a full OpenTelemetry cathedral on day one. You need three cheap tripwires:

No-progress loop — same tool + same args ≥ N times → abort
Silent success — final message says done, but zero write-tools fired → flag it
Budget burn — tokens or wall-clock past a cap mid-job → checkpoint and stop

These are the agent equivalents of 5xx rate, p99 latency, and disk-full. If you only log "final answer," you are flying without instruments.

Why this beats "just add more prompts"

Prompting harder is like yelling directions at a delivery driver who has no GPS trail. Sometimes they arrive. You still cannot tell which turn went wrong when they do not.

Traces turn "the agent is weird" into "step 4 called rm with a bad path because the planner hallucinated a folder." That is a fixable bug. Vibes are not.

Same lesson as last month's tools-over-prompts rant, different layer: surface area you can inspect beats eloquence you cannot.

A 30-minute upgrade path

Wrap every tool call in a span (name, args hash, ok/error, ms).
Persist one JSON artifact per run — even a local file is fine.
Add the three tripwires above as hard stops, not log lines.
When a run looks cursed, paste the trace into your next prompt as evidence, not as a novel.

You just turned a black box into a system you can shame in code review.

The punchline

APIs earned our trust because they fail in public. Agents will earn it the same way — not with longer system prompts, but with boring, greppable, slightly embarrassing logs.

If your agent cannot explain what it did in a JSON file a human can skim in under a minute, it is not autonomous. It is unsupervised.

Your turn: open the last agent run you are half-proud of. What is the one field you wish had been in the log — tool args, token burn per step, plan diffs, something else? Drop the field name in the comments. I am collecting a minimal "agent flight recorder" schema and I will steal the good ones.

What If One Boring Specialist Agent Beats Your Swiss-Army Bot?

Anindya Mukherjee — Mon, 07 Sep 2026 11:05:40 +0000

I built a "do-anything" agent.

It could search the web, edit files, send Slack messages, open PRs, query Postgres, and summarize PDFs. On the demo slide it looked like a junior engineer. In production it looked like one on three espressos and no ticket.

It booked the right meeting on the wrong calendar. It opened a PR that reformatted half the repo. It answered a support question with last quarter's pricing. Every failure had the same root cause: the agent had too many hands and no job description.

If your general-purpose agent keeps almost-working on everything and finishing nothing, this is the post I wish I'd read first. The fix usually isn't a smarter model. It's a narrower job.

Generalists are impressive. Specialists ship.

A Swiss-army knife is a great keychain. It is a terrible chef's knife and screwdriver if you need both in the same hour — mediocre versions of each tool, plus a blister.

General agents are the same trick. One system prompt, twelve tools, infinite ambition. The model has to constantly re-decide what kind of worker it is before it decides what to do next. That extra deliberation is where loops, hallucinations, and "helpful" side quests are born.

A specialist agent gets one sentence of identity: "You triage GitHub issues labeled bug and write a minimal repro." Suddenly the tool list shrinks, success criteria fit on a sticky note, and failure modes become debuggable.

The night the generalist lost to a 40-line specialist

My do-anything agent had inbox, docs-search, and CRM tools, plus a "be helpful" prompt the size of a terms-of-service page. A customer asked whether plan tier X included SSO. It searched docs (good), found an outdated blog post (bad), "confirmed" the tier in the CRM (fine), and sent a confident wrong answer (career-limiting).

I didn't fix it with another prompt paragraph. I deleted nine tools and wrote one specialist:

Job: Answer billing/plan questions only.
Tools: get_account_plan(account_id), get_plan_features(plan_id), draft_reply(thread_id, body).
Rule: If the feature isn't in get_plan_features, say you don't know and escalate — never browse the public blog.

Wrong-answer rate fell off a cliff. Not because the model got smarter. Because it stopped freestyling outside a tiny, true dataset.

A tiny specialist scaffold you can steal

from dataclasses import dataclass
from typing import Callable, Dict

@dataclass
class Specialist:
    name: str
    job: str                 # one sentence
    tools: Dict[str, Callable]
    max_steps: int = 8
    escalate_to: str | None = None

def get_account_plan(args):
    return db.accounts.get(args["account_id"]).plan_id

def get_plan_features(args):
    return db.plans.get(args["plan_id"]).features

def draft_reply(args):
    return helpdesk.draft(args["thread_id"], args["body"])

billing_agent = Specialist(
    name="billing_specialist",
    job=(
        "Answer plan/feature questions using account + plan data only. "
        "If a feature isn't listed, say you don't know and escalate."
    ),
    tools={
        "get_account_plan": get_account_plan,
        "get_plan_features": get_plan_features,
        "draft_reply": draft_reply,
    },
    max_steps=6,
    escalate_to="human_support",
)

def run_specialist(agent: Specialist, goal: str) -> str:
    """Model picks a tool or finishes. No freestyle side quests."""
    scratch = []
    for _ in range(agent.max_steps):
        decision = llm.decide(
            job=agent.job, goal=goal,
            tool_names=list(agent.tools), scratch=scratch,
        )
        if decision.action == "finish":
            return decision.output
        if decision.action == "escalate":
            return f"ESCALATE->{agent.escalate_to}: {decision.output}"
        if decision.action not in agent.tools:
            scratch.append(f"rejected unknown tool: {decision.action}")
            continue
        result = agent.tools[decision.action](decision.args)
        scratch.append(f"{decision.action} -> {result!r}")
    return f"ESCALATE->{agent.escalate_to}: max steps hit"

Copy the contract, not the fake llm.decide guts: one job sentence, three tools, hard max steps, explicit escalate path.

How to carve a specialist out of your generalist

Pick the failure that hurts most — the ticket that pages you, not the demo that impresses.
Write the job in one sentence a new hire could follow on day one. Commas and caveats mean two jobs — split them.
List the minimum true tools. Source-of-truth reads beat web browse. Writes stay narrow (draft_reply, not send_anything).
Add a kill switch. max_steps + escalate_to are product, not polish.
Measure one number the specialist owns: wrong-answer rate, time-to-repro, PRs reverted.

Do this three times and you have boring agents you can test, monitor, and replace independently — multi-agent without the hype slide.

Analogies worth stealing in standup

Hospital, not superhero: triage + specialist + handoff beats one doctor doing surgery, billing, and janitorial.
Unix pipes > monolith scripts: small programs that do one thing well compose; god-objects rot.
Menu vs buffet: a buffet agent samples everything and overeats; a menu agent plates three orders.

Agentic AI gets more reliable when you stop asking one model to be your entire company.

What to build this week

Skip the orchestration framework. Pick one painful workflow:

Bug triage: read_issue, search_code, post_repro_checklist
Weekly metrics: run_sql, render_chart, open_draft_mr
Oncall summary: fetch_alerts, fetch_deploys, draft_incident_doc

Ship one. Put a max-step guard on it. Compare error rate to the generalist on the same task. If the specialist doesn't win, your job sentence is mushy or your tools point at mushy data.

The punchline

I wanted one agent that could do everything. What I needed was three agents that could each do one thing without inventing the rest.

Prompts make agents polite. Tools make them capable. Job descriptions make them safe.

If you've retired a Swiss-army agent for a boring specialist, drop its one-sentence job + tool names in the comments. I want a museum of narrow agents that actually ship.

What If Your AI Agent Doesn't Need Better Prompts — Just Better Tools?

Anindya Mukherjee — Mon, 31 Aug 2026 11:10:56 +0000

I rewrote the system prompt fourteen times.

Version 3 was "be thorough." Version 7 was a 900-word manifesto about edge cases. Version 12 threatened the model if it hallucinated a file path. Version 14 still booked a meeting on the wrong calendar and cheerfully summarized the disaster.

The agent wasn't dumb. It was unarmed.

If you've been stuck in prompt-tweaking hell with an AI agent that keeps almost-working, this is the post I wish I'd read first. The fix usually isn't another paragraph of instructions. It's giving the thing a real tool.

Prompts are pep talks. Tools are hands.

A prompt is a pep talk before a job interview. A tool is the résumé, the laptop, and the door badge.

You can coach someone forever on "be professional and double-check details." If they can't open the calendar API, they will invent a meeting time that sounds right. LLMs are the same — world-class at sounding competent, terrible at touching the real world unless you wire them up.

That's the agentic AI shift in one sentence: stop asking the model to pretend it did something. Give it a function it can actually call.

The night the prompt lost and the tool won

My agent had one job: when a GitHub issue is labeled needs-repro, clone the repo, run the failing test, and paste the output back.

I tried better prompts first — "always clone before you speculate," "never invent stack traces," "if you're unsure, say so." It invented a beautifully formatted stack trace from a file that didn't exist. From the model's point of view, a plausible stack trace is the assignment when the only tool it has is "generate text."

Then I registered three boring tools: clone_repo(url), run_tests(path), comment_on_issue(number, body). No poetry. Next run: clone → run → paste real output. The intelligence didn't jump. The surface area of reality did.

A tiny tool-registration pattern you can steal

import json, subprocess
from dataclasses import dataclass
from typing import Callable

@dataclass
class Tool:
    name: str
    description: str
    schema: dict
    handler: Callable[[dict], str]

def run_tests(args: dict) -> str:
    path = args["path"]
    # Never let the model shell out raw — pin the command.
    result = subprocess.run(
        ["pytest", path, "-q"],
        capture_output=True, text=True, timeout=120
    )
    return (result.stdout or result.stderr)[-4000:]

TOOLS = {
    "run_tests": Tool(
        name="run_tests",
        description="Run pytest on a path; return the tail of output.",
        schema={
            "type": "object",
            "properties": {"path": {"type": "string"}},
            "required": ["path"],
        },
        handler=run_tests,
    ),
}

def tools_for_llm() -> list[dict]:
    """Send names/descriptions/schemas — not handlers."""
    return [{
        "type": "function",
        "function": {
            "name": t.name,
            "description": t.description,
            "parameters": t.schema,
        },
    } for t in TOOLS.values()]

def dispatch(tool_name: str, arguments_json: str) -> str:
    tool = TOOLS[tool_name]
    return tool.handler(json.loads(arguments_json))

# Loop: messages + tools_for_llm()
# tool_call -> dispatch() -> append result -> repeat
# stop on normal message or max-steps guard

Notice what the prompt no longer has to say: "please don't invent pytest output." The model can't invent what run_tests already returned. Reality is a function return value, not a writing style.

Four rules that beat another prompt rewrite

1. If the model must touch the world, it needs a tool.
Email, APIs, files, tests, databases — tools, not adjectives in a system prompt.

2. Prefer boring, narrow tools over one god-tool.
run_tests(path) beats do_whatever(shell_command). Narrow tools are easier to log and sandbox. God-tools are how you wake up to a deleted directory and a polite apology.

3. Put constraints in code, not in prose.
Timeouts, allow-lists, max bytes, path sandboxes belong in the handler. The model is a creative writer under deadline. Your handler is the adult in the room.

4. Log tool calls like production traffic.
Name, args, duration, success/fail. When an agent goes weird, you won't debug prompt vibes — you'll debug the trace: it called clone_repo with a typo URL three times.

The pizza-shop test

Imagine a pizza shop where the only employee is a poet. Hand them a long script about greeting customers and using the oven. Without an oven dial, a ticket printer, and a delivery map, you don't have a pizza shop — you have spoken-word night with cheese anxiety.

Agents are the same. Prompting is coaching the poet. Tool-use is installing the oven. Multi-agent setups multiply the moral: researchers need search, coders need file/test tools, reviewers need diffs. More agents with no tools is just a group chat with confidence issues.

When you should still touch the prompt

Prompts are great at role ("prefer failing closed"), output shape ("short summary after tools"), and tie-breaking ("prefer the read-only tool"). They're bad at physics. "Don't hallucinate test output" is physics. Solve physics with a tool.

A 20-minute challenge

Pick one task your current bot fakes:

Name the real-world action (fetch_invoice, list_open_prs, tail_logs).
Write a ~15-line handler with a timeout and allow-list.
Register it with a tight JSON schema.
Delete two paragraphs of prompt compensating for the missing tool.
Run it three times and read the tool trace, not the final essay.

If success jumps, you didn't find a better spell. You handed the wizard a screwdriver.

The punchline

Agentic AI feels magical in demos because demos hide the plumbing. In production, the magic is mostly tool surface area + boring guardrails + a short honest prompt.

Stop asking your agent to role-play competence. Give it hands. Keep the prompt short enough that you can still read it without scrolling past your own despair.

Your turn: What's one tool you wish your agent had yesterday — the specific function, not a vibe? Drop the name and two args in the comments. I'm collecting a hall-of-fame of "why didn't I add this sooner" tools.

I Watched My AI Agent Loop for 40 Minutes. Here's the Guardrail I Added.

Anindya Mukherjee — Mon, 24 Aug 2026 11:11:05 +0000

I left my laptop open, made coffee, came back, and the terminal was still scrolling.

Same tool call. Same "almost done" message. Same apology. Over and over. Forty minutes of a very polite infinite loop.

If you've ever handed an LLM a task and walked away thinking it'll figure it out, this is the part nobody puts in the demo reel.

The setup that felt smart

I wanted a tiny research agent. Nothing fancy:

Search for a topic
Open the top results
Summarize what matters
Write a short brief to a markdown file

Classic "agentic" pitch: give it a goal, give it tools, let it cook.

I wired up a simple loop — think, act, observe, repeat — with a web search tool and a file writer. The first run looked magical. It found sources. It took notes. It even said "Draft complete."

Then I gave it a slightly messier topic.

That's when the coffee happened.

What a runaway agent actually looks like

The logs were almost funny if you squint:

Thought: I should verify one more source.
Action: search("...")
Observation: (same three links as last time)
Thought: Great, I'll open the first one again to be sure.

It wasn't "thinking harder." It was stuck in a hallway with three doors, opening the same door, nodding solemnly, and opening it again.

Like a Roomba that found a particularly meaningful sock.

The model kept producing confident next steps. The tools kept returning near-identical observations. Nothing in my code said stop, you're not making progress. So it didn't.

Forty minutes later I had:

200+ near-duplicate tool calls
a half-written brief
a slightly warmer laptop
zero new insight

Autonomy without brakes isn't autonomy. It's a very expensive fidget spinner.

The real bug wasn't the model

I wanted to blame the LLM. Easy story. Bad diagnosis.

The model did what models do: it proposed the next plausible action given the context. The failure was mine — I built a loop with a goal and no concept of done enough, stuck, or this is costing real money.

Chatbots fail politely in one reply. Agents fail operationally, over time, with side effects.

That distinction is the whole game.

The guardrail I added (copy-paste this)

I didn't rebuild the agent. I added three boring checks that would have saved the morning:

Hard step budget — absolute max iterations
No-progress detector — same tool + similar args too many times in a row
Circuit breaker — stop, summarize what you know, ask a human

Here's a minimal version you can drop into a toy agent loop:

import hashlib
import json
from collections import deque

class AgentGuardrails:
    def __init__(self, max_steps=12, repeat_limit=3):
        self.max_steps = max_steps
        self.repeat_limit = repeat_limit
        self.steps = 0
        self.recent = deque(maxlen=repeat_limit)

    def _sig(self, tool: str, args: dict) -> str:
        payload = json.dumps({"tool": tool, "args": args}, sort_keys=True)
        return hashlib.sha256(payload.encode()).hexdigest()[:16]

    def check(self, tool: str, args: dict) -> str | None:
        """Return a stop reason, or None if the agent may continue."""
        self.steps += 1
        if self.steps > self.max_steps:
            return f"max_steps_exceeded:{self.max_steps}"

        sig = self._sig(tool, args)
        self.recent.append(sig)
        if len(self.recent) == self.repeat_limit and len(set(self.recent)) == 1:
            return f"no_progress_repeated_tool:{tool}"

        return None


# --- usage inside your loop ---
guard = AgentGuardrails(max_steps=12, repeat_limit=3)

while True:
    thought, tool, args = plan_next_action(state)  # your planner
    stop = guard.check(tool, args)
    if stop:
        state["stop_reason"] = stop
        state["draft"] = summarize_partial(state)
        break
    state["obs"] = run_tool(tool, args)

Is this elegant multi-agent research? No.

Is it the difference between "neat weekend project" and "why is my API bill a horror movie"? Yes.

Why these three checks punch above their weight

Step budgets turn infinite loops into finite embarrassments. Twelve steps is arbitrary — pick a number that matches the task. Research briefs don't need 200 tool calls. If they do, your task is underspecified.

No-progress detection catches the Roomba-sock pattern. Agents love re-checking. Humans do too, but we get bored. Code should get bored for you.

Circuit breakers restore the human to the loop on purpose. The best agent systems I've used don't pretend to be infallible. They fail loudly, early, with a partial artifact you can actually use.

Think of it like a kitchen timer on a toaster oven. The toaster doesn't become a worse toaster because it dings. It becomes a toaster that won't burn the apartment down while you answer Slack.

What I changed in the prompt (small, high leverage)

Guardrails in code are half the fix. The other half is telling the model how to behave when it's unsure:

If you notice you are about to repeat a tool call with the same arguments,
STOP. Write the best brief you can from current notes. List 1–3 unknowns
instead of fetching "one more source."

Models respond surprisingly well to explicit stop conditions. Without them, "be thorough" quietly becomes "never finish."

The weekend checklist before you trust an agent alone

Before you let anything run unattended:

[ ] Max steps (hard cap)
[ ] Repeat/no-progress detector
[ ] Timeout on each tool call
[ ] Cost ceiling if you're on paid APIs
[ ] Partial-result writer on stop
[ ] A log you can read without crying

You don't need a platform. You need seatbelts.

The punchline

Agentic AI is less "magic intern who never sleeps" and more "power tool with a very confident trigger finger."

The demo is the happy path. Production is everything that happens when the happy path gets lonely and starts humming to itself for forty minutes.

Add the boring guardrail. Ship the partial brief. Keep your coffee hot and your laptop cool.

Your turn: What's the dumbest loop you've caught an agent (or yourself) stuck in? Drop the war story — I want the ridiculous ones.

Why Does Your AI Keep Forgetting Everything Mid-Conversation?

Anindya Mukherjee — Mon, 17 Aug 2026 11:12:23 +0000

You just spent 20 minutes briefing ChatGPT on your codebase. One new chat later, it's a stranger again. Here's the fix — and a 30-line memory loop you can paste today.

Me, last Tuesday:

"Remember, our staging DB is stg_not_prod_i_swear, never touch prod."

ChatGPT, three messages later:

"Sure! I'll run the migration against production now 😊"

I did not, in fact, let it do that. But the amnesia was real. And if you've used any LLM for more than a week, you've lived some version of this: the model that was brilliant five prompts ago has the long-term memory of a goldfish who just discovered espresso.

That's not a bug in your prompting. It's a design limit of chat windows. AI agents are how we bolt an actual filing cabinet onto the goldfish.

Chat Windows Are Goldfish Bowls

A normal chat model only "knows" what's inside the current context window — roughly the last N tokens of the conversation. Close the tab, start a new thread, or overflow the window, and everything evaporates.

It's like hiring a genius intern who gets medically-induced amnesia every time they leave the room. Day one: incredible. Day two: "Hi, who are you, and why is there a Postgres container named after a pinky swear?"

Agents flip this. Instead of hoping the window is big enough, they write things down and read them back on purpose. Same brain. Different filing system.

The Three Layers of Agent Memory (No PhD Required)

You don't need a research paper. You need three buckets:

Working memory — the live context window. Short, expensive, fragile. Good for "what are we doing right now?"
Episodic memory — notes from past runs. "Last Tuesday the deploy failed because the env var was API_KEY not OPENAI_API_KEY."
Semantic memory — durable facts about your world. Repo conventions, preferred libraries, that one flaky endpoint that returns 200 while lying.

ChatGPT gives you #1 for free. Useful agents add #2 and #3 — usually as a JSON file, a SQLite table, or a tiny vector store. Fancy is optional. Persistent is not.

A Memory Loop You Can Paste in 30 Lines

Here's a minimal pattern: before each model call, pull relevant notes; after each run, save what mattered. No framework required.

import json
from pathlib import Path
from openai import OpenAI

client = OpenAI()
MEMORY_FILE = Path("agent_memory.json")

def load_memory() -> list[dict]:
    if MEMORY_FILE.exists():
        return json.loads(MEMORY_FILE.read_text())
    return []

def save_memory(entries: list[dict]) -> None:
    MEMORY_FILE.write_text(json.dumps(entries, indent=2))

def remember(fact: str, kind: str = "semantic") -> None:
    mem = load_memory()
    mem.append({"kind": kind, "fact": fact})
    save_memory(mem)

def recall(limit: int = 8) -> str:
    mem = load_memory()[-limit:]
    if not mem:
        return "No saved memory yet."
    return "\n".join(f"- ({m['kind']}) {m['fact']}" for m in mem)

def ask_agent(user_goal: str) -> str:
    memory_block = recall()
    messages = [
        {
            "role": "system",
            "content": (
                "You are a careful coding agent. Honor saved memory. "
                "Never touch production. If unsure, ask.\n\n"
                f"## Saved memory\n{memory_block}"
            ),
        },
        {"role": "user", "content": user_goal},
    ]
    resp = client.chat.completions.create(model="gpt-4o-mini", messages=messages)
    answer = resp.choices[0].message.content
    # Persist anything the human just taught us
    if "remember:" in user_goal.lower():
        remember(user_goal.split(":", 1)[-1].strip(), kind="semantic")
    return answer

# Seed durable facts once
remember("Staging DB is stg_not_prod_i_swear — NEVER use production", "semantic")
remember("Prefer pytest; repo uses src/ layout", "semantic")

print(ask_agent("Draft a migration plan for the users table on staging."))

Run it twice. The second run still knows about stg_not_prod_i_swear — even though it's a brand-new API call with no prior chat history. That tiny agent_memory.json file is the whole magic trick.

Swap the JSON file for SQLite or Chroma later if you want search. The shape stays the same: recall → reason → act → write back.

Why This Beats "Just Use a Bigger Context Window"

Bigger windows help, the way a bigger desk helps a messy room. Eventually you still need folders.

Context is expensive (you pay per token, every single call).
Context is noisy (old chit-chat crowds out the one constraint that matters).
Context is not shared across sessions, teammates, or cron jobs.

A 20-line memory file is cheaper, sharper, and survives overnight. Agents that remember your constraints feel 10× smarter than a larger model with a blank slate — same way a barista who knows your order beats a genius who asks "and you are…?" every morning.

What to Remember First (Start Embarrassingly Small)

Don't boil the ocean with a multi-agent graph on day one. Write down the five facts your future self will curse you for forgetting:

Env names and "never touch X" rules
How your team names branches / PRs
The weird API that lies about status codes
Preferred libraries and style rules
Who to ping when the agent is stuck

Put those in memory. Wire the recall step. Run one boring job tomorrow morning — a staging migration plan, a PR summary, an inbox triage — and watch the amnesia disappear.

The Real Upgrade

The leap from chatbot to agent isn't "more clever prompts." It's state. Tools let the model touch the world. Memory lets it stay coherent while it does.

So the next time your AI cheerfully offers to "help" by migrating production, don't just sigh and open a new chat. Give it a filing cabinet.

Your goldfish deserves better. So do you.

What's the one thing your AI forgets every single session? Drop it in the comments — I'm collecting the most cursed examples.

What If Your AI Assistant Could Actually Do Things While You Sleep?

Anindya Mukherjee — Thu, 13 Aug 2026 18:45:58 +0000

What If Your AI Assistant Could Actually Do Things While You Sleep?

Spoiler: it can. And it's called an AI agent. Here's how to build one in 10 minutes.

You've used ChatGPT. You've marveled at its answers. You've also, at some point, copy-pasted its output into a spreadsheet, fired off an email yourself, and wondered — "why am I still doing the boring part?"

That's not an AI assistant. That's a very smart autocomplete.

An AI agent is different. An agent doesn't just answer — it acts. It reads your inbox, summarizes the important bits, drafts replies, schedules follow-ups, and then goes to bed before you do. You wake up to a done thing.

This sounds like sci-fi, but it's weekend-project territory right now. Let me show you exactly how it works.

The One Thing That Changes Everything: Tools

The magic ingredient in any agent isn't the language model — those are everywhere now. It's tool use.

Think of it like this: GPT-4 alone is like a brilliant consultant locked in a room with no phone, no laptop, and no door. It can think beautifully, but it can't touch the world. Give it tools — a web browser, a calculator, an API key — and suddenly it can reach out, do stuff, and report back.

Here's the simplest possible version of an agent loop in Python using the OpenAI function-calling API:

import openai
import json

def get_weather(city: str) -> str:
    # In real life, call a weather API here
    return f"It's 22°C and sunny in {city}."

tools = [{
    "type": "function",
    "function": {
        "name": "get_weather",
        "description": "Get current weather for a city",
        "parameters": {
            "type": "object",
            "properties": {
                "city": {"type": "string", "description": "City name"}
            },
            "required": ["city"]
        }
    }
}]

messages = [{"role": "user", "content": "What's the weather in Tokyo?"}]

response = openai.chat.completions.create(
    model="gpt-4o",
    messages=messages,
    tools=tools
)

# If the model wants to call a tool, handle it
if response.choices[0].finish_reason == "tool_calls":
    tool_call = response.choices[0].message.tool_calls[0]
    args = json.loads(tool_call.function.arguments)
    result = get_weather(**args)
    print(f"Tool result: {result}")

Run that. Watch the model decide to call get_weather, extract the city name on its own, and use the result. That decision-and-action loop is the heartbeat of every AI agent.

Why This Is Actually a Big Deal

Traditional software follows a script. You write if X then do Y. Every branch is something you predicted.

An agent follows goals, not scripts. You say "clear my inbox" and it figures out the steps. It reads emails, classifies them, decides which need replies, drafts them, and flags the edge cases for you. You didn't specify any of that — it reasoned its way there.

This shift — from scripted to goal-directed — is the same shift that happened when we went from hand-coding websites to using frameworks. It doesn't replace programmers. It raises the ceiling of what one person can build.

The Three Components Every Agent Has

Whether you're using LangChain, AutoGen, CrewAI, or rolling your own, every agent has the same three parts:

1. A brain (the LLM) — decides what to do next based on its goal and what it knows so far.

2. A memory — keeps track of what's happened. Short-term memory is the conversation history. Long-term memory is a vector database or a file the agent reads/writes. Without memory, your agent has the attention span of a goldfish. A goldfish with a PhD, but still.

3. Tools — the hands. APIs, file readers, web scrapers, calculators, code runners. The more tools, the more the agent can reach.

Strip any of these out and you don't have an agent — you have a chatbot with ambition.

What You Can Build This Weekend

Here are three genuinely doable weekend projects, ordered by ambition:

Inbox summarizer — connects to Gmail, reads unread emails, groups them by topic, drops a bullet-point briefing into a Slack DM. ~100 lines of Python + LangChain.
Research agent — give it a topic, it searches the web, reads 5 articles, compares them, and writes a one-page summary with citations. No more 45-minute rabbit holes.
Dev assistant — watches a GitHub repo for new issues, classifies them (bug/feature/question), drafts a triage response, and pings the right team member. Saves about 30 minutes per day on a busy repo.

None of these require a PhD. They require an API key, a few hours, and the willingness to let a machine handle the boring part.

The Real Question

The question isn't "can AI agents do this?" anymore. That ship has sailed.

The question is: which part of your day are you still doing manually that an agent could own?

Pick the most tedious thing on your to-do list — the recurring task you dread, the copy-paste job that eats 20 minutes, the report nobody reads but everyone requests. That's your first agent.

Build that one. You'll understand agentic AI better from one small working example than from reading every explainer on the internet.

Including, possibly, this one.

Building something with agents? Drop it in the comments — I'd love to see what people are making.

5 Things That Make an AI Agent Actually Useful (Not Just Cool)

Anindya Mukherjee — Mon, 03 Aug 2026 11:24:47 +0000

You've seen the demos. An AI agent books a flight, refactors a codebase, or spins up a whole research report while you sip coffee. Cool? Absolutely. Useful enough to trust with real work on a Tuesday afternoon? That's a different question.

Most "agents" today are ChatGPT with a trench coat and a to-do list. They look autonomous until they hit a wall, loop forever, or confidently invent a file path that never existed. The gap between demo-cool and actually useful is where the real engineering lives.

I've spent the last year building, breaking, and babysitting agentic systems. Here are the five things that separate a parlor trick from something you'd put in a production workflow.

1. It knows when to stop talking and start doing

A chatbot answers. An agent acts.

That sounds obvious until you watch an "agent" spend twelve turns politely discussing your request instead of calling a tool. Useful agents have a bias toward action. Give them a goal and a toolbox, and their default move is: pick a tool, use it, check the result, repeat.

Think of it like the difference between a friend who says "you should really clean the kitchen" and a friend who just... starts loading the dishwasher. One is advice. The other is help.

The technical version of this is tool-use loops — the model proposes a function call, your runtime executes it, the result goes back into context, and the model decides the next move. LangChain, CrewAI, AutoGen, the OpenAI Agents SDK — they all orbit this same idea. Without a tight act-observe loop, you don't have an agent. You have a very expensive Magic 8-Ball.

2. It has memory that isn't just "the last 20 messages"

Chat windows are goldfish bowls. Useful agents need something closer to a filing cabinet.

There are roughly three layers of memory that matter:

Working memory — the current context window. Short-term. Fragile. Expensive.
Episodic memory — what happened in past runs. "Last Tuesday I tried X and it failed because Y."
Semantic memory — durable facts about your world. Your codebase conventions, your team's preferences, the weird API that returns 200 even when it errors.

Without the last two, every session starts from zero. Your agent re-learns that your staging database is named stg_not_prod_i_swear every single time. That's not autonomy. That's amnesia with extra steps.

The practical move: store structured notes (vector DB, plain JSON, a Postgres table — pick your fighter) and retrieve the relevant ones before each run. Agents that remember your constraints feel 10x smarter than agents with a bigger model and a blank slate.

3. It can fail without falling apart

Here's an uncomfortable truth: agents fail constantly. Tools time out. APIs return garbage. The model misreads a schema. The useful ones don't panic — they recover.

A useful agent has:

Retries with backoff for flaky tools
Fallback paths when Plan A is clearly dead
A definition of done so it doesn't retry forever
The ability to ask a human when it's genuinely stuck

This is less "AI magic" and more "the same reliability engineering you'd do for any distributed system," except the component making decisions is a probabilistic text generator. Treat it accordingly.

My favorite analogy: a junior hire who's brilliant but occasionally confident about wrong things. You don't fire them on day one. You give them guardrails, code review, and a clear escalation path. Agents need the same management style.

4. Its goals are sharper than "be helpful"

"Be helpful" is how you get an agent that writes a 40-page essay when you asked it to rename a variable.

Useful agents run on narrow, testable goals:

"Open a PR that fixes issue #482 and passes CI"
"Summarize today's support tickets into 5 bullets for Slack"
"Find three vendors under $2k/mo that integrate with Salesforce"

Notice the pattern: a clear output, a success condition, and a scope boundary. The more you can evaluate the result with a script (or a very short human glance), the more you can safely let the agent cook.

If you can't write an acceptance test for the task, you're not ready to agent-ify it. You're ready to chat about it. Different sport.

5. A human can interrupt it without a court order

Full autonomy is a great sci-fi premise and a terrible default for production.

The agents I actually trust in real workflows all have a human-in-the-loop checkpoint at the moments that matter: before spending money, before pushing to main, before emailing a customer, before deleting anything. Everything else can run hot. The irreversible stuff waits for a nod.

This isn't a failure of the technology. It's product design. Seatbelts didn't make cars less useful.

The best agent UIs I've used feel like pair programming with a very fast intern: you see the plan, you approve the risky steps, you course-correct in one sentence when it drifts. Autonomy with a steering wheel.

Putting it together

A useful AI agent is not "an LLM that uses tools." It's a small system with:

Trait	Chatbot	Useful agent
Default move	Reply	Act, then check
Memory	This thread	This thread + your world
Failure mode	Apologize	Retry, fall back, or escalate
Goal shape	Vibes	Testable outcome
Human role	Conversation partner	Supervisor at checkpoints

If you're evaluating an agent framework or building your own, score it on those five. Demos will lie to you. Tuesday-afternoon reliability will not.

Where to start this week

Don't boil the ocean. Pick one repetitive workflow you already do by hand — something with a clear done-state and low blast radius. Wire up tool calls, add a memory scratchpad, put a human approval step before anything irreversible, and run it ten times.

The tenth run will teach you more about agentic AI than any thinkpiece (including this one).

And when your agent finally completes a real task without you hovering — that's the moment it stops being cool and starts being useful. That moment is worth chasing.

Building agents, breaking agents, writing about both. If this was useful, a reaction or comment helps more of the right people find it — and tells me which rabbit holes to go down next.

DEV Community: Anindya Mukherjee

Why Can't You Debug an AI Agent the Way You Debug an API?

Agents fail like interns, not like services

Stop debugging with "print(thoughts)"

A pasteable mini flight recorder

Three signals worth alerting on

Why this beats "just add more prompts"

A 30-minute upgrade path

The punchline

What If One Boring Specialist Agent Beats Your Swiss-Army Bot?

Generalists are impressive. Specialists ship.

The night the generalist lost to a 40-line specialist

A tiny specialist scaffold you can steal

How to carve a specialist out of your generalist

Analogies worth stealing in standup

What to build this week

The punchline

What If Your AI Agent Doesn't Need Better Prompts — Just Better Tools?

Prompts are pep talks. Tools are hands.

The night the prompt lost and the tool won

A tiny tool-registration pattern you can steal

Four rules that beat another prompt rewrite

The pizza-shop test

When you should still touch the prompt

A 20-minute challenge

The punchline

I Watched My AI Agent Loop for 40 Minutes. Here's the Guardrail I Added.

The setup that felt smart

What a runaway agent actually looks like

The real bug wasn't the model

The guardrail I added (copy-paste this)

Why these three checks punch above their weight

What I changed in the prompt (small, high leverage)

The weekend checklist before you trust an agent alone

The punchline

Why Does Your AI Keep Forgetting Everything Mid-Conversation?

Chat Windows Are Goldfish Bowls

The Three Layers of Agent Memory (No PhD Required)

A Memory Loop You Can Paste in 30 Lines

Why This Beats "Just Use a Bigger Context Window"

What to Remember First (Start Embarrassingly Small)

The Real Upgrade

What If Your AI Assistant Could Actually *Do* Things While You Sleep?

What If Your AI Assistant Could Actually Do Things While You Sleep?

The One Thing That Changes Everything: Tools

Why This Is Actually a Big Deal

The Three Components Every Agent Has

What You Can Build This Weekend

The Real Question

5 Things That Make an AI Agent Actually Useful (Not Just Cool)

1. It knows when to stop talking and start doing

2. It has memory that isn't just "the last 20 messages"

3. It can fail without falling apart

4. Its goals are sharper than "be helpful"

5. A human can interrupt it without a court order

Putting it together

Where to start this week

What If Your AI Assistant Could Actually Do Things While You Sleep?