DEV Community: T. Alam

Reading a Real Agent Run, Step by Step

T. Alam — Fri, 30 Oct 2026 08:40:42 +0000

An agent gives a wrong answer. Your logs say the request succeeded. That's it. Now you're guessing which step went bad.

An AI agent observability dashboard ends the guessing. It shows each step of a run in order, with what went in and what came out. This guide reads one run, start to finish, in DNotifier's workflow dashboard.

What an AI Agent Observability Dashboard Shows

An AI agent observability dashboard records every step an agent takes during one run. You see the order, the inputs, and the outputs. Then you can point at the step that broke.

In DNotifier, setting [observability](https://www.dnotifier.com/): true sends execution and step data to the workflow dashboard. The run result also includes an executionId.

Turn It On

Turning on an AI agent observability dashboard takes one flag. Set observability: true on the workflow. The docs say you need no extra setup beyond connect().

const workflow = new Workflow({
  name: 'refund-triage',
  observability: true,
  entry: async (ctx) => {
    const intent = await ctx.runAgent('intent-agent');
    const policy = await ctx.search({ query: ctx.input, limit: 3, label: 'Policy lookup' });
    return ctx.runAgent('reply-agent', { input: { intent, policy } });
  },
});

const run = await notifier.runWorkflow({ workflow, input });
console.log(run.executionId);

SDK calls like ctx.sendAI and ctx.search show up as steps. The label field names each one. Good labels make the dashboard easy to read later.

The Sample Run

Here's a made-up example. A refund-triage workflow has three agents: intent-agent, policy-agent, and reply-agent. A customer asks for a refund on an annual plan, 45 days after buying. The reply promises one. The policy says no.

The trace looks like this (illustrative):

refund-triage
├─ 1. Intent classification   (sendAI)   output: "refund"
├─ 2. Policy lookup           (search)   output: general refund FAQ
├─ 3. Refund decision         (custom)   output: "eligible"
└─ 4. Reply draft             (sendAI)   output: "Refund approved"

Step 1: Start With the Result

Grab run.executionId and open that run in your AI agent observability dashboard. Read the final output first. It tells you what "wrong" looks like.

Here, the reply approves a refund it shouldn't.

Step 2: Walk the Steps in Order

Go top to bottom. Don't jump to the last step. Each label is a clue, so name steps by what they do. "Policy lookup" beats "step 2."

Step 3: Read Input, Then Output

At each step, ask two questions:

Was the input what I expected?
Does the output make sense for that input?

In the sample, step 1 passes. The input was the customer's message, and "refund" fits. Step 2 fails. The input mentioned an annual plan and 45 days, but the output was a general FAQ. If both answers are yes, move on. If one is no, stop there.

Step 4: Find the First Bad Step

Errors pile up. The last step usually looks guilty, but it often just trusted bad input.

In the sample, step 2 returned a general FAQ instead of the annual plan terms. Steps 3 and 4 acted sensibly on that input. So the fix belongs in the knowledge base or the search query. Rewriting the reply agent would change nothing.

Step 5: Add Custom Steps

Some logic isn't a model call. A rule check is a good example. Record it yourself with ctx.recordStep. It takes a label, plus optional input and output.

ctx.recordStep({
  label: 'Refund decision',
  input: { plan: 'annual', daysSincePurchase: 45 },
  output: { eligible: false },
});

Now the decision shows up in the trace like everything else.

Quick Symptom Guide

Symptom	Check this step	Likely cause
Confident but wrong answer	Search output	Weak or missing documents
Wrong branch taken	Intent output	Vague classification prompt
Odd reply	Reply input	Too much or too little context passed in
Missing step in trace	Workflow entry code	Step never ran, or was never recorded

One Trade-Off

More steps means more to scan. Record decisions, not every helper function. An AI agent observability dashboard is only as clear as your labels.

Also, step inputs and outputs can hold customer data. Decide what you pass in before you flip the flag.

FAQ

What should an AI agent observability dashboard show?

It should show ordered steps with inputs, outputs, and status. Anything less leaves you guessing which step failed.

Does DNotifier record steps automatically?

Yes, for SDK calls. With observability: true, calls like sendAI are sent to the dashboard. Use recordStep for your own logic.

What is the executionId for?

It identifies one run. Log it with every run result so you can find that run's data later.

What's the difference between `logs: true` and `observability: true`?

logs: true tracks AI sessions in the logs dashboard, including session start, completion, and token usage. observability: true adds execution and step data for workflows.

Final Takeaway

Debug from the first bad step, not the last one. A good AI agent observability dashboard turns that into a two-minute job instead of an afternoon. To try it yourself, explore the DNotifier SDK and docs at www.dnotifier.com.

Build a Minimal Agent Harness in Node.js

T. Alam — Wed, 21 Oct 2026 08:37:37 +0000

Your agent works fine in the demo. Then you run it on a real task and it loops for ten minutes, racks up a bill, and you've got no idea why. Usually the model isn't to blame. What's missing is a harness. So we'll write one, in Node, in about 60 lines.

What Is an Agent Harness?

It's the code around your model. It calls the model, checks whether the model wants a tool, runs that tool, and sends the result back. Then it does it all again until the job's finished. The model picks what to do. The harness decides what's allowed.

Why Write One Yourself?

You'll see the loop. That's the main reason. Most tools bury it, so when something breaks you're guessing. Write it once and the guessing stops.

You also get to set your own limits. How many steps? What happens when a tool crashes? Your call. And the whole thing fits on one screen, which still surprises me.

What's Inside

Four things, really. A loop that keeps calling the model. A few tools, which are just functions. The message history, so the model remembers what happened a minute ago. And some stop rules, because without them the loop never ends.

task -> [history] -> model -> tool request? -> run tool -> back to history
                         \-> final answer -> stop

That's the entire design. No magic.

Step 1: Set Up the Project

Use Node 18 or newer. fetch is built in, so there's nothing to install. Run npm init -y, then add "type": "module" to package.json. Make three files: tools.js, model.js, and harness.js.

Step 2: Add a Couple of Tools

A tool is a name, a one-line description, and a function. Keep them dull. Dull tools are easy to test and hard to break.

// tools.js
export const tools = {
  get_time: {
    description: "Returns the current time as an ISO string.",
    run: async () => new Date().toISOString(),
  },
  add: {
    description: "Adds two numbers. Args: a, b.",
    run: async ({ a, b }) => String(a + b),
  },
};

Step 3: Write the Loop

Put your provider call inside model.js. The harness doesn't care which one you pick. It only needs callModel to hand back one of two shapes: { type: "tool", name, args } or { type: "final", text }.

// harness.js
import { tools } from "./tools.js";
import { callModel } from "./model.js";

const LIMIT = 8; // my default. bump it if your tasks run long

// runs one tool and never throws. the model just gets the error as text
async function useTool(name, args) {
  const tool = tools[name];
  if (!tool) return `No tool called "${name}"`;

  try {
    return String(await tool.run(args));
  } catch (e) {
    return `Tool failed: ${e.message}`;
  }
}

export async function runHarness(task) {
  const msgs = [{ role: "user", content: task }];
  let n = 0;

  while (n < LIMIT) {
    n++;
    const out = await callModel(msgs, tools);
    console.log("step", n, "->", out.type, out.name || "");

    if (out.type === "final") return out.text;

    const res = await useTool(out.name, out.args);
    msgs.push({ role: "assistant", content: JSON.stringify(out) });
    msgs.push({ role: "tool", name: out.name, content: res });
  }

  return "gave up after " + LIMIT + " steps";
}

Read it once, top to bottom. The model answers. If it's final, you're done. If it wants a tool, useTool runs it, you store the result, and the loop goes again.

Step 4: Add Some Guardrails

Look closely at that code and you'll spot three small safety nets. The step cap kills runaway loops. The try/catch turns a crashing tool into plain text, so the model can read the error and try something else. The log gives you a trail to follow later.

Add a timeout too. One hung tool shouldn't freeze everything.

const withTimeout = (promise, ms) =>
  Promise.race([
    promise,
    new Promise((_, reject) =>
      setTimeout(() => reject(new Error("timeout")), ms)
    ),
  ]);

// inside useTool, swap the tool.run line for this one:
return String(await withTimeout(tool.run(args), 5000));

What It Can't Do Yet

This version has gaps. It forgets everything once the run ends. A failed model call just fails, with no retry. Nothing asks a human before a risky tool runs. And if you add a second agent, you can't follow a task across both.

For learning, that's fine. For production, it isn't.

When One File Isn't Enough

It usually hits you around the second or third agent. Now you want monitoring. You want traces. You want to test prompts without redeploying, and you want agents to message each other. Building all that is doable. It's also weeks of work that has nothing to do with your product.

DNotifier handles that part with one SDK and one API. It covers orchestration, observability, traceability, and multi-agent systems. You keep the understanding from your own harness and skip the busywork around it.

FAQ

What's the difference between a harness and a framework?
A harness is the loop that runs one agent. A framework wraps extra pieces around it, like memory or routing. Build the harness first, and you'll know which extras you need.

How many steps should I allow?
Start at 8 to 10. Most simple tasks wrap up in two or three. Log every time the cap gets hit, and raise it only if real tasks need more room.

Can I test it without a real model?
Yes. Swap callModel for a stub that returns a scripted tool request, then a final answer. Your loop, tools, and limits all get tested, and it costs nothing.

Do I need multi-agent support on day one?
No. One loop per agent is plenty at first. Add messaging between agents later, once one of them needs something from another.

Wrapping Up

Small, strict, and easy to read. That's what a good harness looks like. Build the tiny version first and you'll catch problems sooner.

When you're ready to skip the busywork, explore the SDK at www.dnotifier.com. And if you build your own version, drop it in the comments. I'd like to see it.

Your First Multi-Agent System in Node.js

T. Alam — Fri, 09 Oct 2026 10:53:41 +0000

Ask one prompt to research, write, and check its own work and it'll do all three badly. Teams split the job across agents instead. Then a new mess shows up. Who goes first? What gets handed over? And when a run fails at 2 a.m., which step actually broke?

This post builds a small multi-agent system in Node.js, one step at a time. It also covers what shifted in 2026, and what you still have to write yourself.

Why One Agent Stops Scaling

One agent is fine until the work has distinct roles. Research, drafting, and review each want different instructions. Cram them into one long prompt and the output gets muddy. Debugging turns into guessing.

Most teams reach for a script that calls the model a few times in a row. Fine for a demo. In production it falls apart, because nobody can see inside the steps, data gets passed around by hand, and swapping a model means rewriting code.

It helps to pull four things apart. Orchestration decides which agent runs and when. Messaging moves data between services or users. Model execution is the call to the model itself. Application state is whatever your app has to keep once the run ends. People blur these together all the time, and the design gets confusing fast.

What Changed in 2026

Two protocols moved in 2026. A2A, which lets agents talk to each other, hit its first stable 1.0 release. MCP, which gives agents access to tools, dropped protocol-level sessions. You don't need either for a first build, but they affect where you're headed.

A2A first. Before it, every framework wired agents together its own way, and crossing vendors meant custom glue. The Linux Foundation marked A2A's first birthday on April 9, 2026, announcing the stable 1.0 spec and more than 150 supporting organizations. It earns its place when agents sit on different servers or come from different vendors. For agents in one process, skip it. You'd just add a network hop.

MCP isn't new. Its 2026-07-28 revision is. Older versions opened with an initialize handshake and could keep sessions alive. The new revision removes both, so every request carries its own version and capabilities. That makes remote tool servers easier to run behind load balancers. SDKs adopt revisions at their own pace, though, so check yours before assuming support.

One runtime note. Node.js 24 is the Active LTS line this year, and Node 26 is scheduled to enter LTS in October 2026.

Build It Step by Step

The build needs three pieces: an agent for each role, a workflow that sequences them, and a runner to start it. The example below is hypothetical. A brief generator with a researcher, a writer, and a reviewer. The code follows the DNotifier workflow documentation.

Step 1: Install. The SDK needs Node.js 18 or newer.

npm install @dnotifier-realtime/dnotifier

Step 2: Define the agents. One job each. Anything they share goes into ctx.state.

import { DNotifier } from "@dnotifier-realtime/dnotifier";

const researcher = DNotifier.defineAgent({
  name: "researcher",
  async run(ctx) {
    const res = await ctx.sendAI({
      message: { text: `List key facts about: ${ctx.input.topic}` },
      saveHistory: false,
      label: "Research",
    });
    ctx.state.notes = res?.data?.content ?? "";
    return { notes: ctx.state.notes };
  },
});

const writer = DNotifier.defineAgent({
  name: "writer",
  async run(ctx) {
    const res = await ctx.sendAI({
      message: { text: `Write a short brief from:\n${ctx.input.notes}` },
      saveHistory: false,
      label: "Draft",
    });
    return { draft: res?.data?.content ?? "" };
  },
});

const reviewer = DNotifier.defineAgent({
  name: "reviewer",
  async run(ctx) {
    const ok = ctx.input.draft.length > 200;
    await ctx.recordStep({
      label: "Length check",
      output: { ok },
      status: ok ? "ok" : "error",
    });
    return { approved: ok, draft: ctx.input.draft };
  },
});

Step 3: Compose the workflow. The entry function is plain JavaScript, so the order is yours to control.

const workflow = new DNotifier.Workflow({
  name: "brief-pipeline",
  observability: true,
  async entry(ctx) {
    const { notes } = await ctx.runAgent("researcher");
    const { draft } = await ctx.runAgent("writer", { input: { notes } });
    return ctx.runAgent("reviewer", { input: { draft } });
  },
}).registerAgents({ researcher, writer, reviewer });

Step 4: Run it. Workflows use the HTTP transport.

const notifier = new DNotifier({
  appId: process.env.DNOTIFIER_APP_ID,
  secret: process.env.DNOTIFIER_SECRET,
  transport: "http",
  userId: "brief-service",
  onConnected: () => {},
  onMessage: () => {},
  onDisconnected: () => {},
});

await notifier.connect();
const run = await notifier.runWorkflow({
  workflow,
  input: { topic: "multi-agent systems" },
});
console.log(run.executionId, run.result);

Want agents running side by side? ctx.runAgents starts several at once and hands back results when the last one finishes.

Where DNotifier Fits

DNotifier provides one SDK and one API with multi-model support. In this build it handles two of the four concerns: orchestration and model execution. The workflow runs agents in the order the entry function says, and sendAI calls whichever model is configured.

Providers include OpenAI, Anthropic, Google Gemini, and Ollama. An agent can override the provider and model, so the researcher can run on one and the writer on another.

Observability covers the 2 a.m. question. With observability: true, the dashboard lists agent steps, model calls with latency, and any custom steps. The executionId ties a run to its trace.

Plenty stays on your side. Durable data is yours, since ctx.state only lives for one run. Output quality and billing belong to the model provider. And DNotifier's documentation doesn't list A2A or MCP support today, so those integrations are separate work.

Trade-offs and Mistakes

Every agent is one more model call. Cost and latency stack up. Run agents in sequence and total time is the sum of every step. Run them in parallel and the slowest one sets the pace.

DNotifier's documentation doesn't describe automatic retries or checkpoints either. Wrap the risky steps in your own error handling, and throw DNotifier.WorkflowError when something should fail loudly.

A few mistakes show up again and again. Adding agents before the roles are really different. Passing entire transcripts when a summary would do. Treating ctx.state like a database. Leaving out label, which makes traces painful to read. And trusting model output with no check at all, which is why the reviewer exists.

FAQ

Do I need A2A or MCP for my first multi-agent system?
No. Agents in one process can call each other directly. Bring in A2A when agents live on different servers or vendors, and MCP when they need shared tools.

Can each agent use a different model?
Yes. DNotifier supports provider and model settings per agent. Save each provider's key in your project first.

How do I debug a failed run?
Grab the executionId and open that run in the dashboard. Check each step's status and latency. Add recordStep calls wherever your own logic could go wrong.

Final Thought

Start with two agents and one clear handoff. Add more only when a role has earned its spot. To see how DNotifier handles orchestration and tracing, explore www.dnotifier.com.

The Azure Bug That Cost Us an Afternoon Was One String Not Matching Another String

T. Alam — Fri, 25 Sep 2026 19:42:26 +0000

We migrated a feature from calling OpenAI's API directly to going through Azure AI instead — same underlying model family, just routed through our Azure subscription for reasons that had nothing to do with the model itself. Should've been a config change. Instead it turned into an afternoon of checking API keys, checking network rules, checking whether our Azure subscription had actually provisioned correctly, before someone finally found the actual problem: a string that didn't match another string, in a place none of us thought to look first.

Writing this up because we're fairly sure we won't be the last team to lose an afternoon to it.

What's actually different about Azure

Every other provider we'd connected before this — OpenAI, Anthropic, Gemini, Hugging Face — you get an API key and you call model names directly. gpt-4o means gpt-4o. Azure AI doesn't work that way. You have to have already deployed a model inside your own Azure resource before anything can call it, and Azure doesn't let you address that model by its public name. You address it by whatever name you (or whoever set up the resource) gave that deployment when it was created in the Azure portal.

That one fact is responsible for basically all of the confusion in this story.

Two things have to exist before this works at all: an Azure resource, and a model actually deployed inside it.

The setup, which looked completely normal

In the DNotifier portal: Projects → AI Studio → Providers → Azure AI. We plugged in the resource endpoint (something like https://your-resource.openai.azure.com), an API key, and the deployment list. Installed the SDK:

npm install @dnotifier-realtime/dnotifier

Took our existing OpenAI-calling code, swapped the provider field, and shipped it:

const notifier = new DNotifier({ apiKey: process.env.DNOTIFIER_API_KEY });

const response = await notifier.sendAI({
  senderId: USER_ID,
  provider: "azure_ai",
  model: "gpt-4o", // <-- this is the line that broke everything
  message: {
    messages: [{ role: "user", content: "Summarize this quarter's key metrics." }],
  },
  saveHistory: true,
});

Looks completely reasonable. It is completely reasonable, if your Azure deployment happens to be named gpt-4o. Ours wasn't.

What actually failed, and why nothing pointed at the real cause

Every call came back with a 404-ish deployment error. Not "invalid API key," not "network unreachable" — a deployment error, which in hindsight is exactly the right error and in the moment told us almost nothing, because none of us had internalized yet that model here doesn't mean what it means for every other provider.

We checked the API key. Fine. We checked the resource endpoint URL for typos. Fine. We checked whether the Azure resource had finished provisioning. Fine. Somewhere around the twenty-minute mark, someone actually opened the Azure portal and looked at the resource's deployment list instead of staring at our own code one more time.

Azure Portal → your-resource → Deployments

Deployment name          Model                Status
chatapp-gpt4o-prod        gpt-4o               Succeeded

The error looks like an integration problem. It's almost always a naming mismatch, checked against the Azure portal's deployment list.

There it was. Whoever set up this Azure resource — months earlier, a different engineer, long since moved to a different team — had named the deployment chatapp-gpt4o-prod, not gpt-4o. Reasonable choice on their part, especially in an org with more than one deployment floating around. Just not the string our code was sending.

The fix, once we knew what to look for

const response = await notifier.sendAI({
  senderId: USER_ID,
  provider: "azure_ai",
  model: "chatapp-gpt4o-prod", // the actual deployment name, not the model's public name
  message: {
    messages: [{ role: "user", content: "Summarize this quarter's key metrics." }],
  },
  saveHistory: true,
});

One line. Worked immediately, no other changes needed anywhere. The fix took about two minutes once someone knew to look at deployment names specifically. Finding that out took the other twenty-plus.

The rule we now follow, no exceptions

The model field in a sendAI() call against Azure AI is whatever your deployment is named in the Azure (or Microsoft Foundry) portal, full stop. It can match the underlying model's public name — Azure's default deployment name sometimes does — but "sometimes" is exactly the trap. We stopped assuming and started checking the actual deployment list every single time we point new code at an Azure resource, especially one we didn't personally set up.

Azure Portal → [your resource] → Model deployments

Whatever appears here, verbatim, is what belongs in the `model` field.

Not the model's public name. Not an abbreviation. Not what you assume it "should" be called based on every other provider's convention.

One resource, several model families — the decision is which lane a task actually belongs in, not which model sounds most impressive.

It's not just the name — deployment type is its own decision

Once we'd fixed the immediate bug, we ran into the second layer of this: Azure's model catalog spans OpenAI's GPT family, Claude, Llama, Mistral, DeepSeek, and others, all inside the same Foundry resource, and picking a model family is only half the decision. Deployment type — Standard, Global Standard, Data Zone Standard, Provisioned Throughput — behaves differently on pricing, data residency, and latency consistency under load. A task with hard data-residency requirements might need Data Zone Standard regardless of which model family you picked. A high-volume, latency-sensitive feature might justify Provisioned Throughput even for a mid-tier model.

We'd initially deployed our most capable available model for a document-summarization tool, assuming quality would scale with size. Running the same representative prompts through DNotifier's Prompt Testing Studio against a smaller, cheaper deployment from the same model family showed statistically indistinguishable output quality for our specific documents — the task just didn't need the bigger model. Switching cut per-request cost substantially with zero measurable drop in quality, and we wouldn't have made that switch with any real confidence without the side-by-side comparison sitting in front of us.

// same task, two deployments, tested against the same real prompts
// before committing production traffic to either one
const resultA = await notifier.sendAI({
  provider: "azure_ai",
  model: "chatapp-gpt4o-prod",
  message: { messages: [{ role: "user", content: testPrompt }] },
});

const resultB = await notifier.sendAI({
  provider: "azure_ai",
  model: "chatapp-gpt4o-mini-prod",
  message: { messages: [{ role: "user", content: testPrompt }] },
});
// compare quality, latency, and cost before picking one for real traffic

What we'd tell anyone setting this up fresh

Before you write a single line pointing at an Azure deployment: open the portal, find the actual deployment name, and use that string exactly. Don't assume it matches the model's public name just because every other provider you've touched works that way — Azure is genuinely different here, not being difficult for no reason, just structured around your own resource rather than a shared public catalog. And once it's working, don't stop at "which model family" — test the actual deployment type and tier against real prompts before you commit production traffic to it. Twenty minutes of confusion over a naming mismatch is annoying. Overpaying for capability a task never needed is the quieter, more expensive version of the same mistake.

We Built a Multi-Agent Support System That Refuses to Auto-Send Refunds. Here's the Whole Thing.

T. Alam — Thu, 24 Sep 2026 17:21:58 +0000

One AI agent answering every support ticket is a good demo. We know because we built that first, showed it around internally, and got exactly the reaction you'd expect — "cool, when's it live." Then we actually thought about what "live" meant. Billing questions need real invoice data. Technical questions need product docs and sometimes an actual diagnostic call. And anything involving a refund above a certain amount needs a human to look at it before it goes out, because we were not comfortable with a language model unilaterally deciding to give someone their money back.

Cramming all of that into one system prompt and one model call gets you something mediocre at everything instead of good at anything. So we didn't. Here's the actual build — three specialized agents, a shared session, and a human approval gate that we do not let anything skip.

What we're building

customer message
       │
       ▼
 [router agent] ──reads session memory, classifies──┐
       │                                              │
   ┌───┴────┬─────────────┐                           │
   ▼         ▼             ▼                          │
[billing] [technical] [escalation] ──always flags for human review
   │         │             │
   └─────────┴─────────────┘
              │
              ▼
     draft response + needsHumanApproval flag
              │
     ┌────────┴────────┐
     ▼                  ▼
 auto-send          held for review
 (routine)          (sensitive)

One shared session, three specialists, one gate that anything sensitive has to pass through before a customer ever sees it.

One ticket, one shared session, three specialized agents, and a human who signs off before anything sensitive ships.

Defining the agents

DNotifier's agent primitive is DNotifier.defineAgent({ name, model, run(ctx) }). The ctx your run function gets handed gives you the shared workflow state, this step's input, and a sendAI() scoped to whatever model you put on that specific agent.

import { DNotifier } from "@dnotifier-realtime/dnotifier";

const routerAgent = DNotifier.defineAgent({
  name: "router-agent",
  model: "gpt-4o-mini", // cheap and fast — this runs on every single message
  async run(ctx) {
    const classification = await ctx.sendAI({
      message: {
        text: `Classify this support message into one category:
        billing, technical, or escalation. Message: "${ctx.input.message}"
        Respond with just the category word.`,
      },
    });

    ctx.state.category = classification.text.trim().toLowerCase();
    return ctx.state.category;
  },
});

const billingAgent = DNotifier.defineAgent({
  name: "billing-agent",
  model: "gpt-4o",
  async run(ctx) {
    const answer = await ctx.sendAI({ message: { text: ctx.input.message } });
    ctx.state.draftResponse = answer.text;
    return answer.text;
  },
});

const technicalAgent = DNotifier.defineAgent({
  name: "technical-agent",
  model: "gpt-4o",
  async run(ctx) {
    const answer = await ctx.sendAI({ message: { text: ctx.input.message } });
    ctx.state.draftResponse = answer.text;
    return answer.text;
  },
});

const escalationAgent = DNotifier.defineAgent({
  name: "escalation-agent",
  model: "gpt-4o",
  async run(ctx) {
    const draft = await ctx.sendAI({
      message: {
        text: `Draft a careful, empathetic response to this escalated
        issue, and flag it for human review before sending:
        "${ctx.input.message}"`,
      },
    });
    ctx.state.draftResponse = draft.text;
    ctx.state.needsHumanApproval = true;
    return draft.text;
  },
});

The model choice per agent isn't an afterthought — it's the whole point. The router runs on gpt-4o-mini because deciding "is this a billing question or a technical one" doesn't need a flagship model, and it's going to run on literally every incoming message, so it had better be cheap. The specialists run on gpt-4o because they're doing the reasoning a customer will actually judge. If we ran everything through the expensive model just because the escalation path needed it, we'd be paying flagship prices for "what are your support hours" questions all day.

Tying it into a workflow

const supportWorkflow = new DNotifier.Workflow({
  name: "customer-support-pipeline",
  description: "Routes and resolves inbound support tickets across three specialist agents",
  observability: true,
  async entry(ctx) {
    const category = await ctx.agents.run(routerAgent, { message: ctx.input.message });

    let result;
    if (category === "billing") {
      result = await ctx.agents.run(billingAgent, { message: ctx.input.message });
    } else if (category === "technical") {
      result = await ctx.agents.run(technicalAgent, { message: ctx.input.message });
    } else {
      result = await ctx.agents.run(escalationAgent, { message: ctx.input.message });
    }

    return {
      category,
      response: result,
      needsHumanApproval: ctx.state.needsHumanApproval ?? false,
    };
  },
});

supportWorkflow.registerAgents([routerAgent, billingAgent, technicalAgent, escalationAgent]);

observability: true is one line and it's saved us more debugging time than almost anything else in this system. The first time someone from support Slacked us "the bot gave a weird answer on ticket #4471," we didn't reconstruct anything from a transcript. We opened the run, saw exactly which agent handled it, on which model, with what input, and had an answer back in under a minute.

Running it against a real ticket

const notifier = new DNotifier({
  appId: process.env.DNOTIFIER_APP_ID,
  secret: process.env.DNOTIFIER_SECRET,
  userId: "support-system",
  transport: "ws",
  WebSocketImpl: WebSocket,
});

await notifier.connect();

const outcome = await notifier.runWorkflow(supportWorkflow, {
  message: "I was charged twice for my subscription this month.",
  sessionId: "ticket-88213",
});

console.log(outcome);
// { category: 'billing', response: '...', needsHumanApproval: false }

Routine billing question, routes to the billing agent, resolves without anyone in the loop. Now the same customer, same ticket, a follow-up:

const followUp = await notifier.runWorkflow(supportWorkflow, {
  message: "This is the third time this has happened and I want to cancel and get a full refund for the year.",
  sessionId: "ticket-88213",
});

// { category: 'escalation', response: '...', needsHumanApproval: true }

Because it's the same sessionId, the escalation agent isn't starting from zero — it already has the prior turn's context about the duplicate charge, without our application code having to reassemble and re-pass that history manually. That part genuinely surprised us the first time we tested it; we expected to have to wire up our own history-stitching logic and didn't need to.

The part we actually care about most: the approval gate

needsHumanApproval coming back true is a hard stop, not a suggestion. This is where the drafted response gets pushed into whatever review surface support already uses — for us that's a Slack channel with an approve/reject button — and the "send to customer" function only fires once a human actually clicks approve.

if (outcome.needsHumanApproval) {
  await notifyReviewQueue({
    ticketId: "ticket-88213",
    draft: outcome.response,
  });
  // held here. nothing goes out until a human approves it.
} else {
  await sendToCustomer(outcome.response);
}

We'll be blunt about why this matters more than it might look on the page: a system that can draft a refund confirmation and a system that can send one without anyone checking it first are very different systems from a risk standpoint. "Which of our agents can take an irreversible action without a human in the loop" is a question we wanted a deliberate answer to, not one we backed into by accident because the demo worked and nobody circled back to add the guardrail.

Why three agents instead of one really good prompt

We got this pushback internally more than once, and it's a fair question — doesn't one sufficiently detailed prompt handle all of this? For a while it kind of does. It falls apart for a few concrete reasons once you're past the prototype stage.

The knowledge base gets muddier fast. A billing agent grounded only in invoice and pricing docs gives sharper answers than one generalist searching across billing, technical, and policy docs at once — less noise for the retrieval step to sort through.

Cost stops making sense. Routing "what's your refund policy" through the same expensive model handling genuine escalations is money spent for zero quality gain on the easy majority of traffic.

Debugging gets genuinely harder. One sprawling prompt that goes wrong means untangling a single enormous set of instructions. Three focused agents means the observability dashboard tells you exactly which one misfired, every time.

And the approval logic gets fuzzy. "Escalate to a human if the refund's over $500" is a clean, auditable rule sitting in a dedicated escalation agent. It's a rule that's a lot easier to lose track of buried inside one long prompt that's also handling billing lookups and troubleshooting steps.

None of this is specific to support tickets, either. The same router-then-specialists-then-shared-state shape, with an optional human gate bolted on, shows up in content review pipelines and internal ops tooling we've built since. Support was just the clearest place to build it first and see if the pattern actually held up under real traffic. It did.

If you're staring down a single monolithic support prompt that's slowly turning into a maintenance headache, this is the refactor. It took us about a day to build the version above, and the approval gate alone was worth it the first week — it caught a draft response none of us would have wanted to send automatically.

Everyone's Talking About MCP Servers. Here's What Actually Happens When You Wire One Into an Agent

T. Alam — Wed, 23 Sep 2026 17:33:25 +0000

If you've been anywhere near agent frameworks in the last year, you've seen "MCP" mentioned enough times that it's started to feel like one of those terms everyone nods along to without necessarily having built anything with it. We were in that camp for a while too. Then we actually needed an agent that could check a customer's real account data instead of answering from general knowledge, and MCP stopped being a buzzword and started being the thing that saved us from writing the same integration glue code for the fourth time.

This post is what MCP actually is, why it's grown as fast as it has, and the actual code for wiring an MCP server into a DNotifier agent — not the conceptual version, the one we run.

The one-line version

The Model Context Protocol is an open standard, built by Anthropic, that gives a model a consistent way to talk to external tools and data sources — a filesystem, a database, an internal API — without every single application inventing its own bespoke integration for each one. Think of it as a shared plug shape: build a server once, and any MCP-aware model or platform can use it, instead of writing custom glue per tool per model.

That sounds like a small thing until you've been the person writing the fourth version of "describe this tool to the model in the system prompt, parse whatever comes back, hope the format doesn't drift."

Why it's not just Anthropic's pet project anymore

We didn't take this seriously until we looked at the actual numbers. As of a recent count, there are roughly 15,930 public MCP servers spread across the major registries, with close to 9,700 of those in the official one alone. Monthly SDK downloads are past 97 million. And — this is the part that actually got our attention — Microsoft, Google, and AWS have all built native MCP support into their own platforms (Copilot Studio, Gemini, Bedrock AgentCore). That's an unusual amount of cross-vendor agreement for anything in this space. Companies that compete on basically everything else agreed on this one plug shape.

The protocol also shipped what its maintainers called the biggest revision in its history: the transport layer moved to stateless-by-default, and three older features got put on a 12-month deprecation clock. The major SDKs had compatible releases out within about three weeks of that announcement. That's a protocol being taken seriously enough to move fast on breaking changes, not something coasting on hype.

The honest caveat, because we'd be doing you a disservice not to mention it: independent security scans have found real, exploitable flaws in a meaningful chunk of public MCP servers — enough that the NSA and CISA jointly put out security guidance on it. Fast growth plus low friction to publish a server means you get both real adoption and real sloppiness in the same ecosystem. Whatever server you're about to connect to a production agent deserves the same scrutiny you'd give any other third-party dependency touching your data. "It implements a protocol Anthropic built" is not the same thing as "it's trustworthy."

How this actually fits into DNotifier

DNotifier's AI Foundation layer treats MCP servers as a first-class connection type, right alongside your models and your enterprise data sources. You connect a server once, in the dashboard, and it becomes available to whatever agents need it — the same mental model as connecting an API key.

One agent, two channels. The model side and the tool side are both configured once, in the dashboard — not re-wired into every prompt.

// the agent's own call doesn't change based on which MCP tools are attached —
// tool access is a dashboard-level connection, not something you re-describe
// on every request
const response = await notifier.sendAI({
  senderId: userId,
  sessionId,
  message: { text: "Check the latest invoice for this account and summarize it." },
});
// behind the scenes: the model reasons about the request, decides it needs
// the invoice data, and DNotifier routes that lookup through the connected
// MCP server — none of that plumbing lives in this call

That's genuinely the whole client-side shape of it. The heavy lifting — deciding a tool call is warranted, structuring the call, interpreting what comes back — is the model's job and the protocol's job, not something we're writing per feature anymore.

A real example: grounding a support agent in a live account database

Here's roughly what we had before MCP, for an agent that needed to check account state:

// the old way — a hand-rolled function, described in the prompt,
// parsed manually, and repeated for every new data source
async function checkAccountStatus(accountId) {
  const row = await db.query("SELECT * FROM accounts WHERE id = $1", [accountId]);
  return row;
}

const systemPrompt = `
You can call checkAccountStatus(accountId) to look up account data.
If the user asks about their account, call this function and use the result.
Respond in this format: ...
`;
// then hand-parse whatever the model decides to output, hope it matches
// the format you asked for, repeat this whole dance for the next tool

That works, technically, for one tool. It gets worse fast once you have four or five data sources, each with its own quirks, each needing its own parsing logic, each one more surface area for the model to accidentally hallucinate a call it never actually makes.

With a database MCP server connected once through DNotifier, the same capability looks like this from the application's side:

const response = await notifier.sendAI({
  senderId: customerId,
  sessionId,
  message: { text: "Why was I charged twice this month?" },
});
// the model recognizes it needs account/invoice data, calls the MCP
// server's exposed tool for it, gets back structured data, and reasons
// over the actual result — no bespoke parsing code on our end

The integration code didn't grow. When we added a second MCP server a few weeks later — this one for an internal ticketing system — the application-side code for the agent's sendAI() call didn't change at all. That's the part that made this worth adopting for us: the cost of adding tool number five is the same as tool number one.

Does this only matter if you're using Claude?

No, but it's worth being straight about why Claude specifically tends to be smoother here. Anthropic didn't just publish the spec and walk away — Claude's own training and tool-use behavior were shaped by being the model built alongside this exact protocol. In practice that shows up as Claude being noticeably more fluent about deciding when a tool call is warranted and structuring it correctly, with less prompt-engineering scaffolding required to hold its hand through the process. We've run MCP-connected tools against other providers through DNotifier too, and it works — it's just that Claude needed less coaxing to use them well, which tracks given who built the protocol.

What we'd actually check before connecting a new server

Not a formal checklist, just what we've started doing by habit: who maintains it, and how actively. Is it in the official registry or some unlisted repo somebody linked in a Discord. What permissions is it actually requesting versus what the task genuinely needs. If any of those answers feel shaky, we don't connect it to anything touching real customer data, full stop — there are enough servers out there now that "just use a different one" is usually a real option, not a hypothetical.

If you're still hand-rolling tool descriptions into system prompts for every integration you add, this is worth the hour it takes to try. The protocol did the annoying part already. What's left is mostly picking servers you trust and wiring them in once.

We Ran a Model Locally with Ollama and DNotifier. It Failed Silently, and Then We Accidentally Exposed It to the Internet.

T. Alam — Tue, 22 Sep 2026 17:35:19 +0000

Here's a fun way to spend an afternoon: get an integration working perfectly on your laptop, ship the exact same config to your actual deployment, and watch every single call fail with an error message that tells you absolutely nothing useful. That's what happened the first time we hooked Ollama up to DNotifier, and the fix — once we understood it — took about four minutes. Understanding it took considerably longer.

This is the writeup of what actually went wrong, why, and then the second mistake we made fixing it, which was arguably worse than the first one.

Why bother with local models at all

Every other provider we'd connected to DNotifier up to this point — OpenAI, Claude, Gemini, Bedrock — is the same basic shape: you get an API key, you make a network call to somebody else's cloud, you get a bill. Ollama isn't that. It's an open-source runtime, MIT-licensed, built on llama.cpp, that runs models on hardware you control. Your laptop, a workstation, a box in your own data center, whatever. No account to create on DNotifier's side for it, no key to paste, no usage-based bill from a model vendor.

We didn't reach for it because it's cooler (though it kind of is). We reached for it because we had one specific workflow step where the data genuinely could not leave our own infrastructure — some internal document analysis where "send this to a third-party API" wasn't a decision we got to make casually. Ollama was the obvious answer for that one step. Everything else stayed on cloud providers.

Every cloud provider routes to someone else's infrastructure. Ollama routes to yours.

Setting it up looks almost insultingly simple

On the machine running Ollama:

ollama pull llama3.2
ollama list
# NAME               ID              SIZE      MODIFIED
# llama3.2:latest     a80c4f17acd5    2.0 GB    3 minutes ago

Then in the DNotifier portal, under Projects → AI Studio → Providers → Ollama, you configure exactly one thing: the base URL DNotifier should call. That's it. No auth field, because Ollama doesn't require one by default. Provider string in code is just "ollama":

const notifier = new DNotifier({ apiKey: process.env.DNOTIFIER_API_KEY });

const response = await notifier.sendAI({
  senderId: userId,
  provider: "ollama",
  model: "llama3.2", // has to match what `ollama list` actually shows
  message: { messages: [{ role: "user", content: "Summarize this doc." }] },
  saveHistory: false, // more on this below
});

We copy-pasted http://127.0.0.1:11434 into the base URL field, because that's what curl had been happily talking to on the dev machine for the last hour. Saved it. Ran the exact same code against the deployed environment.

Every single call failed. Not a helpful failure either — nothing that said "hey, this address is unreachable from here." Just generic connection errors that looked, at a glance, like they could be an auth problem, a firewall thing, a DNS thing, basically anything.

The mistake, once we actually understood it

127.0.0.1 is a loopback address. By definition, it means "this exact machine, and nothing else." When we tested with curl on our own laptop, 127.0.0.1:11434 correctly meant our laptop. When DNotifier's cloud AI runtime tried to call that same address, 127.0.0.1 from its perspective means itself — some server sitting in DNotifier's infrastructure, definitely not our laptop, and definitely not running Ollama.

The single most common Ollama setup failure, illustrated: pasting a loopback URL into a portal that runs somewhere else entirely.

It's such an obvious mistake in hindsight that it's almost embarrassing to write up. But it's also, apparently, the single most common way this integration goes wrong for basically everyone, based on how directly DNotifier's own docs call it out: "That address only works if the DNotifier worker that runs AI can reach that address. Cloud workers cannot see your laptop loopback."

There are three real fixes, and we want to be honest that we tried them roughly in order of "least amount of work" before landing on the right one:

Run Ollama on a host that's actually network-reachable from wherever DNotifier's AI runtime executes.
Use a tunnel or VPN.
Use a self-hosted DNotifier deployment, if that's available to you.

We ended up standing up a small VM inside our own cloud VPC, running Ollama there instead of on anyone's laptop, and pointing the portal at that address. Same three lines of code as above, just a different base URL. The whole "fix" was maybe four minutes once we knew what we were actually looking at — the twenty-plus minutes before that were spent checking API keys and network settings that had nothing to do with the actual problem.

// what actually worked, pointed at the internal VM instead of a loopback address
// base URL configured in the portal: http://10.0.4.17:11434

Then we made the second mistake

Solving "unreachable" by making an endpoint public solves reachability and opens a new problem in the same step, unless you also solve for who else can reach it.

Getting Ollama reachable from DNotifier's side solves exactly one problem: reachability. It does not solve the problem of who else can reach it. We learned this the annoying way.

To get past the loopback issue quickly on a proof-of-concept, someone on the team opened the VM's inference port directly to the public internet, no auth in front of it, with the reasoning "it's just a demo, we'll tear it down soon." The demo ran longer than "soon" implies demos ever do. A routine security review a few weeks later flagged it as an active finding: an unauthenticated model-inference endpoint, reachable by anyone who found the IP, with no way to tell legitimate traffic from anything else. Somebody could, in theory, have been running their own workloads on our compute and we'd have had no way to know.

The fix for that was also small — a reverse proxy in front of the Ollama endpoint that checks a credential before forwarding anything through — but it should never have been necessary in the first place if we'd thought about reachability and security as two separate questions from the start, instead of assuming solving one solved the other.

# rough shape of what we put in front of it — nginx checking a
# shared secret header before forwarding to Ollama at all
location /ollama/ {
    if ($http_x_internal_key != "REDACTED") {
        return 401;
    }
    proxy_pass http://127.0.0.1:11434/;
}

(That's illustrative, not a copy-paste production config — the actual setup uses a proper secrets manager for the key, not a string sitting in an nginx conf file. Don't do that part the way this snippet implies.)

The three ways to close that gap, and which we'd actually recommend

A tunnel or VPN, done right, keeps the endpoint reachable only to traffic that's already authenticated at the network layer — closest in spirit to the original "only reachable from trusted places" property a loopback address has, just extended specifically to include DNotifier's runtime. A public host needs its own explicit protection layered on top, since nothing about a public IP restricts who can hit it — that's the reverse-proxy-with-a-credential pattern above, or an IP allowlist if DNotifier's outbound traffic comes from a known, stable range. A self-hosted DNotifier deployment shifts the boundary again, potentially keeping the entire call path inside infrastructure you already control end to end.

None of these are exotic — they're the same patterns any team uses to expose an internal service safely, applied here to a model-inference endpoint.

If we were starting over, we'd go straight to the VPN/tunnel option instead of "public host plus proxy," mostly because it means the endpoint is never actually internet-facing at any point — one less thing to get wrong later.

What we'd tell past-us

Two things, really. First: if you're setting this up and it's failing silently, check the base URL before you check anything else — 127.0.0.1 anywhere in that config is almost always the actual bug, no matter what the error message seems to be pointing at. Second: reachability and security are not the same problem, and solving the first one doesn't get you the second one for free. Budget the extra hour for the proxy or the VPN from the start — it's a lot cheaper than fixing it after a security review flags it for you.

We still run Ollama for that one document-analysis step where it genuinely earns its place, mixed into the same DNotifier Workflow as our cloud-provider steps. Same defineAgent shape, same ctx.state, no special-casing in the application code for the fact that one step never leaves our own hardware. That part, at least, worked exactly the way it was supposed to the first time.

We Stopped Hardcoding a Model Provider Into Every Feature. Here's the Router That Fixed It

T. Alam — Mon, 21 Sep 2026 17:23:33 +0000

A couple of months ago we had four different features in production, each one calling a different model provider directly, each one with its own little pile of error handling, its own retry logic, its own idea of what a "timeout" should mean. OpenAI for the chat widget. A cheaper Hugging Face model for the classification step nobody thought about until the AWS bill showed up. Claude for anything that touched a document. It worked, technically. It also meant that every time we wanted to try a new model, or a cheaper one, or route around an outage, someone had to go change code in four places and redeploy four things.

The fix wasn't "pick one provider and stick with it forever." It was building a router — one small agent whose entire job is deciding where a request should go, sitting in front of everything else. This post is that router, built with DNotifier's actual defineAgent and Workflow primitives, not a diagram with boxes and arrows that doesn't compile.

The problem with "just pick the best model"

Here's the thing nobody tells you until you've shipped a few of these systems: most of your traffic doesn't need your best model. We looked at three weeks of real requests hitting one of our internal tools and something like 80% of them were dead simple — short factual lookups, basic rewrites, one-line classifications. The other 20% actually needed real reasoning. Running everything through the expensive model because some requests need it is just burning money on the easy majority.

So the router's job isn't "find the best model." It's "figure out what this specific request actually needs, then send it to the cheapest thing that can handle it."

What we're building

One classifier agent that looks at an incoming request and decides how hard it is. Two (or more) answer agents behind it, each pointed at a different model. A workflow that ties them together and logs every routing decision so you can actually see what happened later, instead of guessing.

request → [classifier agent] → "simple" or "complex"
                                      │
                    ┌─────────────────┴─────────────────┐
                    ▼                                     ▼
           [small/cheap model]                   [larger/capable model]
                    │                                     │
                    └─────────────────┬─────────────────┘
                                       ▼
                                   response
                                (logged + observable)

The routing decision is itself a small, cheap model call — not a guess encoded in application logic.

Step 1: the classifier

This is the part people over-engineer. You don't need a big model to decide if a question is simple — you need a small, fast one that's good at exactly one narrow job.

import { DNotifier } from "@dnotifier-realtime/dnotifier";

const routerAgent = DNotifier.defineAgent({
  name: "complexity-router",
  model: "huggingface/meta-llama/Llama-3.1-8B-Instruct:fastest",
  async run(ctx) {
    const classification = await ctx.sendAI({
      message: {
        text: `Classify this request as "simple" or "complex".
        Simple: factual lookups, short rewrites, basic classification.
        Complex: multi-step reasoning, long-document analysis, nuanced judgment calls.
        Respond with exactly one word.

        Request: "${ctx.input.text}"`,
      },
    });
    ctx.state.complexity = classification.text.trim().toLowerCase();
    return ctx.state.complexity;
  },
});

Notice the :fastest hint on the model string. That's us telling DNotifier we care more about latency than shaving fractions of a cent on this particular call — it's an 8B model running one classification, it should come back almost instantly. We'll flip that priority for the expensive path in a second.

One thing worth being honest about: this is a soft classifier, not a guarantee. Occasionally it'll call something "simple" that really wasn't. That's fine — we'll get to why that's a recoverable problem later, not a fatal one.

Step 2: the two answer paths

const simpleAnswerAgent = DNotifier.defineAgent({
  name: "simple-answer-agent",
  model: "huggingface/meta-llama/Llama-3.1-8B-Instruct:fastest",
  async run(ctx) {
    const answer = await ctx.sendAI({ message: { text: ctx.input.text } });
    ctx.state.answer = answer.text;
    return answer.text;
  },
});

const complexAnswerAgent = DNotifier.defineAgent({
  name: "complex-answer-agent",
  model: "huggingface/openai/gpt-oss-120b:cheapest",
  async run(ctx) {
    const answer = await ctx.sendAI({ message: { text: ctx.input.text } });
    ctx.state.answer = answer.text;
    return answer.text;
  },
});

See the difference in routing hints — :fastest on the small model, :cheapest on the big one. That's not a copy-paste mistake. On the small model, latency is what matters, and the cost difference between backing providers is basically noise. On the bigger, pricier call, the cost spread between backing providers is actually worth optimizing for, so we tell DNotifier to go find the cheapest route to that model instead of the fastest one. Small detail, but it adds up once you're running this at any real volume.

Step 3: wire it into a workflow

const routingWorkflow = new DNotifier.Workflow({
  name: "complexity-based-model-router",
  description: "Classifies request complexity and routes to an appropriately sized model",
  observability: true,
  async entry(ctx) {
    await ctx.agents.run(routerAgent, { text: ctx.input.text });

    if (ctx.state.complexity === "complex") {
      await ctx.agents.run(complexAnswerAgent, { text: ctx.input.text });
    } else {
      await ctx.agents.run(simpleAnswerAgent, { text: ctx.input.text });
    }

    return { complexity: ctx.state.complexity, answer: ctx.state.answer };
  },
});

routingWorkflow.registerAgents([routerAgent, simpleAnswerAgent, complexAnswerAgent]);

observability: true is doing more work here than its one line suggests. Once this is live, every routing decision — what came in, what it got classified as, which model actually answered — shows up in the dashboard as it happens. The first time a teammate asked "why did the bot give a weak answer to this," we didn't have to reproduce anything. We opened the run and looked.

Step 4: actually run it

const notifier = new DNotifier({
  appId: process.env.DNOTIFIER_APP_ID,
  secret: process.env.DNOTIFIER_SECRET,
  userId: "routing-system",
  transport: "ws",
  WebSocketImpl: WebSocket,
});

await notifier.connect();

const outcome = await notifier.runWorkflow(routingWorkflow, {
  text: "What year did the Berlin Wall fall?",
});

console.log(outcome.complexity, "→", outcome.answer);
// simple → 1989

Same workflow, harder question:

const outcome2 = await notifier.runWorkflow(routingWorkflow, {
  text: "Given these three quarterly reports, what's driving the margin decline and is it structural or seasonal?",
});

console.log(outcome2.complexity, "→", outcome2.answer);
// complex → [a real, reasoned answer from the larger model]

Nobody flipped a switch between those two calls. The router looked at the second question, decided it actually needed reasoning depth, and sent it somewhere else — automatically.

Where this stops being a toy example

The version above routes between two Hugging Face model sizes because that's a clean example, but nothing about defineAgent ties you to one provider. This is the part that actually changed how we think about this stuff: because every agent is just a name, a model string, and a run function, the exact same pattern routes across any combination of providers you've got connected.

We eventually extended this same shape to include a local model running through Ollama, for one specific category of request where the data genuinely couldn't leave our own infrastructure:

const localOnlyAgent = DNotifier.defineAgent({
  name: "local-only-agent",
  provider: "ollama",
  model: "llama3.2",
  async run(ctx) {
    const answer = await ctx.sendAI({ message: { text: ctx.input.text } });
    ctx.state.answer = answer.text;
    return answer.text;
  },
});

Same defineAgent shape. Same workflow wiring. The only thing that changed is which agent gets picked, and now the router isn't just choosing between "cheap" and "expensive" — it's choosing between "cloud" and "stays on our own hardware," based on whatever classification rule you want to write into the router's prompt.

The same pattern, generalized past two model sizes into any mix of providers you've got connected — cloud or local.

We'll get into the specifics of running Ollama in production (and the very dumb networking mistake we made the first time) in the next post.

Why we bothered with the extra agent instead of an if/else in application code

We got asked this internally more than once — why not just check input.length > 200 or some heuristic in plain code and skip the model call entirely? Two honest reasons. First, a length check is a terrible proxy for complexity — "what's 2+2" and a three-sentence question requiring real synthesis can be the same length. Second, the classifier call is cheap enough (one small, fast model call) that the cost of running it on every single request, even the ones that end up routed to the expensive model anyway, is trivial next to what it saves on the 80% that don't need the expensive model at all.

And when the router does misclassify something — it happens, rarely — it's a soft failure, not a crash. A complex question that gets routed to the simple model comes back with a weaker answer, not an error. We watch the classification and the answer quality together over time through the observability dashboard, and when the pattern shows the router being too aggressive about sending things downmarket, we adjust the prompt. It's tuning, not firefighting.

If you're juggling more than one provider right now and every new one means another SDK, another auth flow, another set of error codes to learn — this pattern is worth the hour it takes to set up. It paid for itself for us within the first week.

Build Agent-to-Agent Communication With Events

T. Alam — Tue, 15 Sep 2026 08:22:10 +0000

Your agents are stuck waiting on each other. One finishes a task, the next has no idea until you poll for it. That delay adds up fast, especially once you're running more than two or three agents at once. Agent-to-agent communication fixes this. Events are the cleanest way to build it, and that's what this piece digs into: why direct calls fall apart, how event-driven messaging actually works, and what you need in place before things get messy.

What Is Agent-to-Agent Communication?

Agent-to-agent communication is how one agent hands off information, requests, or results to another, no human required. Could be a research agent passing data to a summarizer. Could be a planner triggering three worker agents at once. Get it wrong and agents either sit around waiting or trip over each other's work. A clear agent-to-agent protocol keeps the handoff predictable, even when you can't predict much else.

Why Direct Calls Don't Scale

Most teams start with direct calls. Agent A calls Agent B, waits, moves on. Fine with two agents. Add a third, a fourth, a fifth, and the wiring turns into a mess fast. Every new agent means new connections you have to manage by hand.

Distributed agent communication makes this worse. Agents often run on separate servers, with no shared memory to lean on when something goes wrong.

Here's the comparison:

	Direct calls	Event-driven
Adding a new agent	Rewire existing agents	Just subscribe to events
Failure handling	One slow agent blocks the rest	Agents fail independently
Coordination	Manual, agent by agent	Centralized through events
Scaling	Gets harder with each agent	Stays flat as agents grow

Direct calls create tight coupling. Every agent has to know who else exists and how to reach them. Brittle setup. Breaks the moment you add or remove an agent.

Events Change How Agents Talk

An event is just a message saying something happened. "Task completed." "New data available." "Error detected." Agents publish events instead of calling each other directly, and other agents subscribe to whatever they care about, reacting when something fires.

That's the core idea behind any solid agent communication protocol: nobody needs to know who's listening. The planner agent publishes a "plan ready" event. Three worker agents pick it up and start their tasks in parallel, no direct connection between any of them.

It's what makes multi-agent coordination possible at scale. Add a tenth agent and it just subscribes to what it needs. No rewiring.

Core Pieces of an Event System

A working AI agent communication protocol needs a few pieces in place, and skipping even one means agents either miss events entirely or drown in too many.

Component	What it does
Event publisher	Sends out events when something happens
Event subscriber	Listens for specific event types
Message broker	Routes events to the right subscribers
Event schema	Keeps event formats consistent across agents
Monitoring layer	Tracks what fired, when, and who responded

Get the schema wrong and agents start misreading each other's messages. And without real monitoring, you won't know why an agent went quiet until something breaks in production.

Where DNotifier Fits In

Building this agent messaging architecture from scratch usually means stitching together a queue, a broker, and custom logging yourself. DNotifier skips that. Real-time pub/sub is built into one SDK, so agents publish and subscribe to events without extra infrastructure sitting on top.

Every event gets traced automatically as it moves through the system. Say a worker agent never responds to a "plan ready" event. DNotifier's monitoring and observability tools show you exactly where the message stopped, instead of leaving you to guess.

For teams running multiple agents that need to coordinate in real time, this kind of agent collaboration infrastructure saves weeks of setup.

Common Mistakes to Avoid

Publishing too many event types is a common trap. Fire an event for every tiny action and subscribers get flooded, then start tuning them out. Keep events meaningful: task done, error found, data ready.

Skipping event versioning is another one. Change an event's structure and older subscribers break silently, no warning. Version from day one, even when it feels like overkill.

And don't treat events as fire-and-forget. Track whether they were actually received and acted on. Skip that, and failures stay hidden until a customer finds them first.

FAQ

What's the difference between an agent communication protocol and event-driven messaging?
A protocol defines the rules agents follow to exchange messages. Event-driven messaging is just one way to implement that protocol, using events instead of agents calling each other directly.

Can agent-to-agent communication work without a message broker?
Technically, yes. But it gets messy fast. A broker routes events reliably and keeps agents decoupled, so skip one and you're back to managing direct connections by hand.

How is multi-agent communication different from single-agent workflows?
Single-agent workflows run one process start to finish, nothing else involved. Multi-agent communication means several agents work in parallel and need a shared way to pass information back and forth.

Does event-driven architecture add latency?
A little, but not much. A well-built event system adds delay measured in milliseconds, not seconds. Worth the tradeoff once you're running more than a couple of agents.

Final Thought

Agent-to-agent communication only gets harder to manage as you add more agents, unless it's built on events from day one. Start small. Keep your event types meaningful. Track what happens after each one fires.

Want to see it in action? Explore the SDK at dnotifier.com.

Build a Production Agent Architecture With Node.js

T. Alam — Thu, 10 Sep 2026 16:42:25 +0000

Your AI agent works fine in the demo. Then real users show up, and it breaks in ways you never tested for. That gap, between a working prototype and a real production agent architecture, is where most Node.js teams get stuck.

The problem usually isn't your prompt. It's your infrastructure. A single script calling an LLM API isn't an architecture, it's a proof of concept. That's the difference this guide covers: the production AI architecture patterns that separate a demo from something people can actually rely on.

What a Production Agent Architecture Actually Is

A production agent architecture is the full system around an agent, not just the model call. It includes orchestration, memory, tool execution, monitoring, deployment. Everything the model call doesn't cover.

Think of it like a car engine. The engine matters, but you still need wheels, brakes, and a fuel line to get anywhere. Skip those parts and it looks great in the demo, then stalls the second something unexpected happens.

Why Your Prototype Falls Apart in Production

Most demos run one request, get one response, and stop there. Production traffic doesn't behave. Users send messages out of order. APIs time out. Models return broken JSON.

A prototype has no memory between calls. No retry logic. No visibility into why something failed. These gaps stay hidden until real traffic hits them, and by then you're debugging live instead of building.

The Core Layers Your Node.js Stack Needs

A solid stack breaks into five layers, and each one has a different job. Input handles what comes in, whether that's a chat message or a webhook firing at 3am. Orchestration decides what happens next, which tool gets called, and in what order.

Then there's execution, the layer that actually runs the functions, hits the APIs, queries the database. Memory keeps context around so the agent doesn't forget step two by the time it reaches step five. Semantic search helps here too, pulling in relevant history instead of dumping the whole conversation back into the prompt.

Last is observability. Logs, traces, whatever tells you what the agent actually did instead of what you assumed it did.

That's the idea behind decent AI agent system design: keep failures contained to one layer. If execution breaks, orchestration retries or falls back. The whole request doesn't have to die because one API call timed out.

Single Agent or Multi-Agent? Pick Based on the Job

Not every task needs multiple agents. A single agent handles narrow, linear work fine, like answering support tickets. Multi-agent setups earn their keep when the work splits into real roles: research, drafting, review.

Factor	Single-Agent	Multi-Agent
Best for	Narrow, linear tasks	Multi-step workflows
Complexity	Low, easy to debug	Higher, more moving parts
Latency	Faster, one call	Slower, multiple handoffs
Failure points	One	Several
Coordination needed	None	Orchestration layer required

Multi-agent production architecture only pays off when a task actually needs separate roles. Bolt three agents onto a job one agent could handle, and you've just added three new ways for things to go wrong.

Orchestration Is the Glue That Holds It Together

Orchestration decides what happens next. It routes requests, manages handoffs between agents, and enforces the order tasks run in. Skip it and your agents just work in isolation, tripping over each other's outputs.

In Node.js, this usually means an event-driven layer that tracks state and triggers the next action. That's what turns a loose set of scripts into a reliable agent architecture. DNotifier centralizes all of this in one SDK. You configure workflows and agent behavior from a single place instead of stitching five different services together.

You Can't Fix What You Can't See

Monitoring and traceability aren't optional here. When an agent gives a wrong answer, you need to know which step caused it, not just that something went wrong.

That's what enterprise AI agent architecture actually means in practice: traceability from day one, not something you bolt on after the incident already happened. Traceability logs every decision an agent makes, from the prompt it got to the tool it called. DNotifier's monitoring and traceability tools do this automatically, tracing a bad output back to its source in minutes instead of hours of log-diving.

Deployment Patterns That Actually Hold Up

How you deploy an agent shapes how it fails. Pick based on your traffic pattern, not what's trendy this month.

Pattern	Best For	Trade-off
Serverless functions	Spiky, unpredictable traffic	Cold starts, time limits
Containers (Docker)	Steady, predictable load	More setup and upkeep
Long-running process	Real-time, stateful agents	Needs manual scaling

Good AI agent infrastructure design rarely means picking just one option and calling it done. Plenty of teams run orchestration on a long-running process and push tool calls out to serverless functions instead. Whatever you pick, test prompt changes before they go live. DNotifier's prompt testing catches regressions before a user ever notices.

Real-Time Sync Keeps Agents From Going Stale

Agents that talk to users, or to each other, need real-time updates. A pub/sub layer pushes events as they happen instead of forcing clients to poll for status.

This matters most in chat-based agents, where users expect a response to stream in, not appear all at once. That's what AI application infrastructure actually looks like once you strip away the buzzwords. DNotifier's real-time pub/sub and chat system features cover this out of the box, so you're not building a WebSocket layer from scratch just to get agents talking.

FAQ

What makes an architecture "production-ready" instead of just a working demo?
A production-ready setup handles failure, not just success. It includes retries, logging, monitoring, and recovery paths for when a model or tool call fails. A demo just has to work once. Production has to work every time, including the times it shouldn't.

Do I need Kubernetes to run agents in production?
No, not really. Kubernetes helps once you're at scale, but plenty of teams run solid agents on a single container or one long-running Node process. Start simple. Add complexity only when traffic actually forces you to.

How do I stop one agent failure from breaking the whole system?
Isolate each layer so one failure doesn't cascade into five. If a tool call fails, orchestration should retry or fall back, not take the entire request down with it.

Can Node.js handle multi-agent systems at scale?
Yes, easily. Node's event loop is built for concurrent I/O, which is basically what multi-agent coordination needs. Most limits come from bad architecture, not the runtime itself.

A production agent architecture was never about adding more agents. It's about building something that survives real traffic, bad inputs, and the failures you didn't see coming. Start with the layers. Worry about the feature list later.

If you're building this in Node.js, DNotifier gives you orchestration, monitoring, and real-time infrastructure in one SDK. Explore it at www.dnotifier.com.

Building a Simple Agent Runtime With Node.js

T. Alam — Fri, 04 Sep 2026 08:40:51 +0000

You built an agent that calls a model, picks a tool, and prints an answer. It works fine in a script. Then you try to run it for real, and it falls apart.

No memory between steps. No retry when a call fails. No record of what actually happened. That's the moment every builder finds out they didn't build an agent. They built a function pretending to be one.

What they actually needed was an agent runtime.

In this post, we'll build a small one in Node.js from scratch. No framework, no magic. Just the pieces that make an agent runtime work, so you understand what's happening under the hood before you reach for a bigger tool.

What Is an Agent Runtime, Really?

An agent runtime is the system that keeps an agent alive between calls. It holds state, decides what step comes next, and routes work to models and tools.

Without a runtime, your agent forgets everything the second the function returns. It can respond, but it can't act, retry, or remember. A runtime turns a single call into a process that runs, tracks, and finishes a task.

The Loop Every Agent Execution Engine Runs

Strip away the buzzwords and every agent execution engine does the same four things, over and over, until the task is done:

 ┌─────────┐
 │ Perceive│  read the current state + input
 └────┬────┘
      ▼
 ┌─────────┐
 │  Decide │  ask the model what to do next
 └────┬────┘
      ▼
 ┌─────────┐
 │   Act   │  call a tool or return an answer
 └────┬────┘
      ▼
 ┌─────────┐
 │ Observe │  save the result, update state
 └────┬────┘
      │
      └──────► back to Perceive

That loop is the entire job of an agent runtime. Everything else, memory, tools, logging, is built around keeping this loop honest.

Setting Up the Project

Nothing fancy here. Just a plain Node project.

mkdir agent-runtime && cd agent-runtime
npm init -y
npm install node-fetch

We'll keep everything in one file to start, then split it up once the pieces are clear.

Building the Agent Runtime Class

This is the core of an LLM agent runtime: a class that owns the loop, the state, and a hard limit on how many steps it can take.

class AgentRuntime {
  constructor({ model, tools = {}, maxSteps = 6 }) {
    this.model = model;
    this.tools = tools;
    this.maxSteps = maxSteps;
    this.state = { history: [], memory: {} };
  }

  async run(task) {
    this.state.history.push({ role: "user", content: task });

    for (let step = 0; step < this.maxSteps; step++) {
      const decision = await this.model(this.state);

      if (decision.type === "final_answer") {
        return decision.content;
      }

      if (decision.type === "tool_call") {
        const result = await this.callTool(decision.tool, decision.input);
        this.state.history.push({
          role: "tool",
          tool: decision.tool,
          content: result,
        });
      }
    }

    return "Runtime stopped: max steps reached.";
  }

  async callTool(name, input) {
    const tool = this.tools[name];
    if (!tool) return `No tool named ${name}`;
    try {
      return await tool(input);
    } catch (err) {
      return `Tool ${name} failed: ${err.message}`;
    }
  }
}

Notice the maxSteps guard. Without it, a confused model can loop forever. Every serious agent runtime architecture needs a hard stop like this.

Giving Your Agent Runtime Some Memory

Right now, state.history grows forever. That's fine for a demo, but a real agent state runtime needs to manage memory on purpose, not by accident.

addMemory(key, value) {
  this.state.memory[key] = value;
}

trimHistory(limit = 20) {
  if (this.state.history.length > limit) {
    this.state.history = this.state.history.slice(-limit);
  }
}

Call trimHistory at the end of each loop. It keeps your context small and your costs predictable.

Wiring Up Tools

Tools are just functions. Register them by name, and the runtime handles the rest.

const tools = {
  getWeather: async (city) => {
    return `Weather in ${city}: 28°C, clear skies.`;
  },
  searchDocs: async (query) => {
    return `Top result for "${query}": use the trimHistory method.`;
  },
};

const runtime = new AgentRuntime({ model: myModelFn, tools });

Your model function just needs to return { type: "tool_call", tool, input } or { type: "final_answer", content }. That's the whole contract.

Where a Simple Runtime Breaks in Production

The loop above works for a demo. It won't survive real traffic. Here's what changes once you move from a toy to a production agent runtime:

Concern	Simple runtime	Production runtime
Failures	Crashes or hangs	Retries with backoff
Visibility	Console logs	Full traceability of each step
Concurrency	One task at a time	Many agents running in parallel
Communication	None	Real-time updates via pub/sub
Debugging	Guesswork	Step-by-step monitoring

This is usually the point where teams stop hand-rolling everything. An autonomous agent runtime that handles many users needs monitoring, observability, and traceability baked in, not bolted on later.

That's the gap DNotifier is built to close. It gives you one SDK for orchestration, multi-agent coordination, and real-time pub/sub, so your agent runtime gets production features without you writing them from scratch. You still own the loop. You just stop reinventing the plumbing around it.

Testing the Loop

Before adding more features, write a fake model function that returns scripted decisions. Run it through your runtime and check the history at each step. If the loop behaves correctly with a fake model, it'll behave correctly with a real one.

const fakeModel = async (state) => {
  if (state.history.length < 3) {
    return { type: "tool_call", tool: "getWeather", input: "Lahore" };
  }
  return { type: "final_answer", content: "Done checking the weather." };
};

This kind of test catches loop bugs before they cost you an API bill.

FAQ

What's the difference between an agent and an agent runtime?
An agent is a single decision-making call. An agent runtime is the system that runs that call repeatedly, tracks state, and manages tools and memory across steps.

Do I need a framework to build an agent runtime?
No. A small class with a loop, state, and a tool registry covers the basics. Frameworks help once you need retries, tracing, and multi-agent coordination at scale.

How do I add memory to an agent runtime?
Store history and key facts in a state object, then trim it on a schedule. Keep only what the next decision actually needs.

Can a simple agent runtime handle production traffic?
Not on its own. You'll need retries, monitoring, and concurrency handling. That's usually when teams bring in a platform like DNotifier instead of building it by hand.

Migrating From LangChain to DNotifier: A Practical Guide

T. Alam — Sat, 29 Aug 2026 18:56:23 +0000

Anyone who's built something real with LangChain knows how this goes. The first prototype comes together fast, almost too fast. Then you try to add memory. Or hook up a second agent. Or figure out why a chain failed silently in production, and you're three layers deep in a stack trace that tells you nothing useful.

That's usually when people start looking at a LangChain to DNotifier migration. Not because LangChain is bad. It's just not built for what most teams actually need now: multiple agents working together, visibility into what they're doing, and something that doesn't quietly break at 2am.

Here's what actually changes when you make the switch, step by step, no fluff.

Why Teams Are Leaving LangChain

It's rarely one big problem. It's a dozen small ones that pile up.

Chains get hard to follow past a certain point. Memory feels bolted on rather than built in. And the second you add another agent, you're writing glue code just to keep the two of them talking.

DNotifier gets rid of that glue code. One SDK, one API, and orchestration, memory, and agent communication are already handled for you instead of something you duct-tape together yourself.

What Actually Changes With an AI Orchestration Platform

The mental model shifts. In LangChain you're chaining function calls and hoping the flow holds together under load. With an AI orchestration platform like DNotifier, you define the workflow up front and let the platform handle execution, retries, and state.

Sounds small. Isn't. When something breaks at 2am, you want a system that tells you exactly which step failed, not a stack trace and a guess.

Step 1: Map Your Chains to Workflows

Start dumb. List every chain you're running right now. Inputs, outputs, whatever tools it calls.

Each one becomes a workflow in DNotifier. You're not rewriting your logic from scratch, you're translating a sequence of calls into something the platform can actually monitor.

Migrate your busiest chain first. Test it end to end before touching anything else.

Step 2: Migrate Memory and State

This is where most migrations get real, honestly. LangChain's memory objects work fine, but they're easy to lose track of once you're spanning sessions or multiple agents.

DNotifier handles agent memory and state management natively. No passing memory objects between functions by hand, your workflow reads and writes state straight through the platform. Context sticks across sessions without you babysitting it.

If anything you're building talks to customers directly, this step alone justifies the switch.

Step 3: Move Your RAG Pipeline

Good news here: the core logic barely changes. Chunking, embedding, retrieval, all of it carries over.

What changes is where the pipeline lives. DNotifier connects to your vector database and folds retrieval into the workflow itself, so a RAG pipeline doesn't need its own separate orchestration layer bolted on top. Still, check your retrieval quality after moving it. Settings usually carry over clean, but "usually" isn't "always."

Step 4: Set Up Multi-Agent Systems

Honestly, this is the real reason most people migrate. Getting agents to coordinate in LangChain means building your own message-passing system and crossing your fingers.

DNotifier treats agent orchestration as a core piece, not an afterthought. You define each agent's role, and the platform handles the handoffs and keeps everyone in sync. Research agents, support agents, whatever the team looks like, the coordination layer already exists. You're configuring it, not building it.

Step 5: Add Observability and Traceability

Once workflows are live, you need to see what's happening inside them. LangChain gives you logs, which is fine until it isn't.

DNotifier gives you observability and traceability across every agent and every workflow. You can see which step failed, what data hit it, and why the decision went the way it did. In production, that's not a nice-to-have. It's the difference between a fragile demo and something a team can actually trust.

Mistakes People Make Mid-Migration

Don't move everything at once. One workflow, confirm it works, then the next one. Trying to flip the whole stack in a single sprint tends to create bugs nobody meant to write.

And don't rush the memory and state piece. It's the part people skip, and it's the part users notice first when it's wrong.

FAQ

What is DNotifier used for?
It's used to build, run, and monitor agents and workflows in one place. Basically the orchestration layer most teams end up hand-building on top of LangChain anyway.

Is DNotifier good for production?
Yes. Built-in observability, traceability, and state handling are exactly what production needs and LangChain doesn't give you by default.

Do I need to rewrite my RAG pipeline from scratch?
No. Your chunking and embedding logic usually stays as-is. What moves is the orchestration sitting on top of it.

How long does a migration actually take?
Depends how many chains and agents you're running. Migrating one workflow at a time, figure a few days per workflow, not weeks.

Final Thought

Moving from LangChain to DNotifier isn't throwing out what you've built. It's giving it a foundation that can handle real traffic, more than one agent, and the debugging you're going to need eventually anyway.

Start with one workflow. See how it feels. Go from there.

Want to see what your migration looks like in practice? Explore the SDK at dnotifier.com.

DEV Community: T. Alam

Reading a Real Agent Run, Step by Step

What an AI Agent Observability Dashboard Shows

Turn It On

The Sample Run

Step 1: Start With the Result

Step 2: Walk the Steps in Order

Step 3: Read Input, Then Output

Step 4: Find the First Bad Step

Step 5: Add Custom Steps

Quick Symptom Guide

One Trade-Off

FAQ

What should an AI agent observability dashboard show?

Does DNotifier record steps automatically?

What is the executionId for?

What's the difference between logs: true and observability: true?

Final Takeaway

Build a Minimal Agent Harness in Node.js

What Is an Agent Harness?

Why Write One Yourself?

What's Inside

Step 1: Set Up the Project

Step 2: Add a Couple of Tools

Step 3: Write the Loop

Step 4: Add Some Guardrails

What It Can't Do Yet

When One File Isn't Enough

FAQ

Wrapping Up

Your First Multi-Agent System in Node.js

Why One Agent Stops Scaling

What Changed in 2026

Build It Step by Step

Where DNotifier Fits

Trade-offs and Mistakes

FAQ

Final Thought

The Azure Bug That Cost Us an Afternoon Was One String Not Matching Another String

What's actually different about Azure

The setup, which looked completely normal

What actually failed, and why nothing pointed at the real cause

The fix, once we knew what to look for

The rule we now follow, no exceptions

It's not just the name — deployment type is its own decision

What we'd tell anyone setting this up fresh

We Built a Multi-Agent Support System That Refuses to Auto-Send Refunds. Here's the Whole Thing.

What we're building

Defining the agents

Tying it into a workflow

Running it against a real ticket

The part we actually care about most: the approval gate

Why three agents instead of one really good prompt

Everyone's Talking About MCP Servers. Here's What Actually Happens When You Wire One Into an Agent

The one-line version

Why it's not just Anthropic's pet project anymore

How this actually fits into DNotifier

A real example: grounding a support agent in a live account database

Does this only matter if you're using Claude?

What we'd actually check before connecting a new server

We Ran a Model Locally with Ollama and DNotifier. It Failed Silently, and Then We Accidentally Exposed It to the Internet.

Why bother with local models at all

Setting it up looks almost insultingly simple

The mistake, once we actually understood it

Then we made the second mistake

The three ways to close that gap, and which we'd actually recommend

What we'd tell past-us

We Stopped Hardcoding a Model Provider Into Every Feature. Here's the Router That Fixed It

The problem with "just pick the best model"

What we're building

Step 1: the classifier

Step 2: the two answer paths

Step 3: wire it into a workflow

Step 4: actually run it

Where this stops being a toy example

Why we bothered with the extra agent instead of an if/else in application code

Build Agent-to-Agent Communication With Events

What Is Agent-to-Agent Communication?

Why Direct Calls Don't Scale

Events Change How Agents Talk

What's the difference between `logs: true` and `observability: true`?