DEV Community: T. Alam

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.

Building an AI Data Analyst Agent With DNotifier

T. Alam — Wed, 26 Aug 2026 07:34:18 +0000

Analyzing raw enterprise data takes hours of manual SQL queries, dashboard creation, and endless script tweaks. Traditional setups break when schema definitions shift or data pipelines hit unforeseen bottlenecks. Engineering teams waste time stitching together custom scripts instead of focusing on core architecture.

Building an AI data analyst agent with DNotifier changes how teams query internal databases and parse complex datasets. By leveraging the right AI agent infrastructure, developers can build production AI agents that handle intent routing, execute structured data tasks, and maintain persistent system memory without complex setups.

What is an AI Data Analyst Agent?

An AI data analyst agent is an autonomous digital worker that processes natural language queries, inspects raw database schemas, executes precise data retrieval commands, and generates structured analytical summaries.

Unlike basic query generators, an autonomous AI data analyst agent works as a dedicated system. It evaluates edge cases, retries failed executions safely, and translates complex raw records into readable, executive-ready insights.

Why Use DNotifier for Agent Orchestration?

Most open-source tools require complex glue code for routing, session logging, and state synchronization. DNotifier solves this by providing a unified AI agent platform with native agent runtime management, built-in vector databases, and real-time pub/sub features.

Building the Data Analyst System Architecture

An enterprise-ready AI data analyst agent relies on a multi-agent framework where specialized nodes work together. The system divides analytical workloads across four primary steps:

Intent Router Agent: Receives the natural language request from the user, determines the core analytical goal, and routes the task to appropriate tools.
Schema Retrieval Pipeline: Uses vector search to locate the exact database tables, column names, and metric definitions required for the query.
Execution Engine: Safely constructs validated SQL statements or data retrieval scripts and executes them against your database.
Insight Synthesizer: Interprets the raw dataset returned from the database and packages it into structured business reports.

Step-by-Step Implementation Guide

1.Initialize the DNotifier SDK:
Set up environment credentials and import the core libraries.Import the SDK into your project environment and configure your secret key to authorize connection with the managed production runtime.
2.Configure Schema Retrieval (RAG Pipeline):
Index enterprise database definitions for semantic lookup.Upload your data warehouse schema definitions, metric rules, and table structures into the DNotifier document store to enable context-aware query building.
3.Define Specialized Agents:
Set up router and analytics roles within the workflow.Establish dedicated agent personas within your workflow—assigning specific responsibility roles for parsing user intent and translating context into execution statements.
4.Build and Execute the Orchestrated Workflow:
Chain agent execution and monitor output in real time.Connect your agents into a unified sequence. DNotifier automatically handles session context, data handoffs between steps, and real-time observability logging.

Frequently Asked Questions

Is DNotifier an AI agent framework?
Yes, DNotifier is an enterprise-grade AI agent framework that combines multi-agent orchestration, managed RAG pipelines, and real-time observability in a single platform.

How does DNotifier handle state management across agent?
DNotifier provides managed sessions and workflow context that automatically persist state, variable handoffs, and session history across multi-agent pipelines.

Can I monitor agent actions and LLM calls in real time?
Yes, DNotifier includes real-time tracing, workflow execution graphs, and dashboard analytics to monitor latency, tool execution, and prompt logs.Explore the platform at dnotifier.com to start building production-ready data agents today.

What is DNotifier and how does it work in production?

T. Alam — Thu, 20 Aug 2026 16:47:38 +0000

Building an autonomous AI agent in a Jupyter notebook feels amazing. Getting Deploying DNotifier Agents to Production right for active users is a completely different challenge. Local prototypes rarely handle network spikes, broken state, or rogue API calls.

Moving from a local demo to a enterprise-ready application requires reliable AI agent infrastructure. You need clear trace logs, instant state management, and tight LLM orchestration.

Here is how you can deploy your DNotifier AI agent workforce to live infrastructure safely and cleanly.

What is DNotifier and how does it work in production?

DNotifier is a lightweight AI agent framework designed to simplify Deploying DNotifier Agents to Production. It combines model routing, state management, and real-time pub/sub messaging into a unified SDK and API layer.

Instead of chaining together multiple libraries, DNotifier acts as all-in-one AI middleware. It handles background job queues, multi-agent communication, and LLM observability through a simple single-entry setup.

When users interact with your system, the DNotifier runtime orchestrates execution across your agents automatically.

# Initialize your production AI agent with the DNotifier SDK
from dnotifier import DNotifierClient, Agent

client = DNotifierClient(api_key="dn_live_key")

agent = Agent(
    name="CustomerSupportAgent",
    model="gpt-4o",
    tools=["knowledge_base_search", "refund_calculator"],
    persistence=True
)

# Publish your agent workflow to production
client.deploy(agent, env="production")

1. Set up persistent state and agent memory
Production agents fail when they forget context mid-conversation. Basic prototypes keep short-term memory in RAM, which drops every time your cloud container restarts.

Production AI agents require durable memory backends. DNotifier manages state persistence across user sessions out of the box using built-in database hooks.

Enable state storage in your config file before deployment.
Assign unique session IDs to every user request.
Store system prompts in prompt management layers instead of hardcoding text.
Use vector database integrations for long-term semantic context.

2. Configure real-time pub/sub for multi-agent workflows
When multiple autonomous AI agents work together, direct API calls quickly become a web of unmaintainable code. Production multi-agent platform architecture relies on event-driven communication.

Using real-time pub/sub, your researchers, writers, and code agents talk through dedicated message buses.

3. Implement human-in-the-loop safeguards
Autonomous execution can cause unwanted behavior if left completely unsupervised. High-risk actions—like issuing refunds or sending live emails—demand human review before execution.

DNotifier includes human-in-the-loop workflows at the runtime level.
Configure action policies inside your agent definition.
Flag high-impact tools as requires_approval=True.
Route pending actions to a review dashboard using real-time alerts.
Resume execution once an admin approves the action.

4. Set up AI observability and prompt testing
You cannot optimize what you do not trace. Debugging non-deterministic LLM chains requires granular log tracking for every agent step.

DNotifier logs token usage, step latency, tool inputs, and raw model outputs automatically.

[INFO] Agent Run ID: run_98234x
[TRACE] Step 1: Retrieval augmented generation pipeline queried successfully. (42ms)
[TRACE] Step 2: Tool `refund_calculator` called with args: {"user_id": 402}. (112ms)
[SUCCESS] Execution finished. Total Tokens: 412

Use prompt testing environments to evaluate new system prompts against real production traces before pushing updates live.

DNotifier vs LangChain for production workloads

Teams often compare DNotifier vs LangChain when choosing an AI orchestration platform. While open-source chaining tools work well for early experiments, DNotifier is built specifically for production stability and easy maintenance.

LangChain: Flexible, huge library ecosystem, but complex to maintain in large apps.
DNotifier: Unified API, native pub/sub, built-in monitoring, and lower deployment overhead.

If you want a single SDK that replaces fragmented tracing tools, state databases, and task runners, DNotifier gives you a cleaner path to launch.

Frequently Asked Questions

Is DNotifier an AI agent framework?

Yes, DNotifier is a complete AI agent framework that provides tools, memory management, and orchestration for production workloads.

How do I build a RAG application with DNotifier?

Connect your vector database to the DNotifier document loader to create an event-driven retrieval pipeline in a few lines of code.

Is DNotifier good for production?

Yes, DNotifier is engineered specifically for production environments with built-in tracing, failovers, and multi-agent pub/sub messaging.

How to Build DNotifier Human in the Loop Workflows for Production AI

T. Alam — Wed, 19 Aug 2026 08:40:29 +0000

Fully autonomous agents fail in production when edge cases break business rules. You need humans to review risky decisions without slowing down your AI agent workflow.

Implementing DNotifier human in the loop patterns gives you safety and control. This guide shows you how to pause autonomous AI agents, request approval, and resume execution cleanly.

What Is Human-in-the-Loop in AI Workflows?

Human-in-the-loop (HITL) pauses an AI agent execution path until a real person approves, rejects, or edits the state. It prevents hallucinated actions from reaching production environments.

Instead of letting an AI writer agent publish content automatically, HITL routes the draft to a manager. The workflow resumes only after explicit authorization.

Why Use DNotifier for HITL Orchestration?

Traditional AI agent frameworks force you to write custom polling loops or manage external databases for paused states. This adds fragile boilerplate code to your AI infrastructure.

The dnotifier framework simplifies state suspension using an event-driven agent runtime.
Native State Suspension: Freeze the execution state without losing event context.
Real-Time Pub/Sub: Stream review requests directly to your human UI.
Unified Observability: Trace every prompt, model response, and human intervention in one audit log.
Comparing LangChain vs DNotifier, dnotifier ai handles messaging and state natively in one AI SDK.

Step-by-Step: Implementing Human Approval with DNotifier

Here is how to set up human verification for an AI automation agents system using the DNotifier SDK.

Step 1: Initialize the DNotifier Client
Set up your connection using the DNotifier agent framework.

import { DNotifier } from "@dnotifier/sdk";

const dnotifier = new DNotifier({
  appId: process.env.DNOTIFIER_APP_ID,
  secret: process.env.DNOTIFIER_APP_SECRET,
});

Step 2: Define the Suspended Workflow State
When your AI agent workflow framework hits a sensitive step, pause execution and emit a review event.

async function processRefund(userId: string, amount: number) {
  const workflow = await dnotifier.workflows.create({
    name: "Refund Processing",
  });

  if (amount > 500) {
    // Pause workflow and request human approval
    await dnotifier.events.publish({
      channel: "human-approvals",
      event: "approval_required",
      data: {
        workflowId: workflow.id,
        amount,
        userId,
        status: "PENDING_HUMAN_REVIEW",
      },
    });

    return { status: "PAUSED", workflowId: workflow.id };
  }

  return executeRefund(userId, amount);
}

Step 3: Handle the Human Decision Signal
When the human manager approves the action in your dashboard, send a resume signal back to the AI orchestrator.

async function handleHumanDecision(workflowId: string, approved: boolean) {
  if (approved) {
    await dnotifier.workflows.resume(workflowId, {
      action: "APPROVED",
    });
    console.log(`Workflow ${workflowId} resumed by operator.`);
  } else {
    await dnotifier.workflows.cancel(workflowId, {
      reason: "Rejected by human reviewer",
    });
  }
}

This pattern ensures safe execution without manual database state stitching.

Architectural Patterns for Human-Agent Collaboration

Different business problems need different AI agent architecture
patterns.

1. The Gatekeeper PatternThe
AI agent processes tasks autonomously until a risk threshold is met. High-value transfers or public communications pause for human sign-off.
2. The Interactive Copilot Pattern
The human and AI customer support agents work together in real-time. The agent drafts responses while the human edits before sending.

Frequently Asked Questions

What is DNotifier used for?
DNotifier is a unified AI infrastructure platform providing orchestration, real-time messaging, and multi-agent coordination.

Is DNotifier good for production?
Yes, dnotifier production deployments scale reliably using event-driven real-time infrastructure and multi-model support.

How do I build an AI agent with DNotifier?
Initialize the SDK, define model roles, attach enterprise data sources, and trigger execution using the dnotifier tutorial docs.

Can I build RAG workflows with DNotifier?
Yes, you can build a full RAG pipeline using the built-in DNotifier vector database capabilities.