How to Fix 'callback not firing in production' in AutoGen (TypeScript)

If your AutoGen callback works locally but never fires in production, the problem is usually not AutoGen itself. It’s almost always one of three things: the callback was never registered on the actual runtime path, the process exited before async work completed, or production is running a different build than your local environment.

In TypeScript, this shows up most often with AssistantAgent, UserProxyAgent, or event hooks wired through a wrapper that looks correct but never executes in the deployed process.

The Most Common Cause

The #1 cause is registering the callback on an object that is not the one actually used to run the conversation, or registering it after the chat already started.

A common mistake is to create an agent, start the run, then attach handlers too late. In production, timing differences make this fail consistently.

// BROKEN
import { AssistantAgent } from "autogen";

const agent = new AssistantAgent({
  name: "assistant",
  modelClient,
});

const resultPromise = agent.run("Draft a claims summary");

// Too late: this won't fire for the current run
agent.on("message", (msg) => {
  console.log("callback fired:", msg);
});

await resultPromise;

// FIXED
import { AssistantAgent } from "autogen";

const agent = new AssistantAgent({
  name: "assistant",
  modelClient,
});

agent.on("message", (msg) => {
  console.log("callback fired:", msg);
});

const result = await agent.run("Draft a claims summary");
console.log(result);

If you’re using a wrapper around AssistantAgent, make sure the callback is registered on the inner agent, not just on a factory object or DI container. In production, that mismatch often produces no visible error; it just looks like “callback not firing”.

Other Possible Causes

1) The Node process exits before async work completes

This is common in serverless functions and short-lived jobs. The chat starts, but the process returns before AutoGen finishes streaming or invoking handlers.

// BROKEN
export default async function handler(req: Request) {
  const agent = new AssistantAgent({ name: "assistant", modelClient });

  agent.on("message", (msg) => console.log(msg));

  agent.run("Summarize this ticket"); // missing await
  return Response.json({ ok: true });
}

// FIXED
export default async function handler(req: Request) {
  const agent = new AssistantAgent({ name: "assistant", modelClient });

  agent.on("message", (msg) => console.log(msg));

  await agent.run("Summarize this ticket");
  return Response.json({ ok: true });
}

If you see logs like UnhandledPromiseRejectionWarning or nothing at all in production logs, this is a strong candidate.

2) Production build strips your debug path

A lot of teams gate callback registration behind environment checks and accidentally exclude it in prod.

// BROKEN
if (process.env.NODE_ENV !== "production") {
  assistant.on("message", handleMessage);
}

// FIXED
assistant.on("message", handleMessage);

if (process.env.NODE_ENV !== "production") {
  console.debug("Debug logging enabled");
}

Don’t gate functional code behind NODE_ENV. Gate logging only.

3) You’re using the wrong event name or API version

AutoGen TypeScript APIs have changed across versions. If you copied code from an older example, your handler may be wired to an event that no longer fires.

// BROKEN: old/incorrect event name for your installed version
agent.on("reply", (msg) => {
  console.log(msg);
});

// FIXED: use the event supported by your installed package version
agent.on("message", (msg) => {
  console.log(msg);
});

Check your installed package and docs together:

npm ls autogen

If you upgraded AutoGen recently and callbacks stopped working after deploy, compare your local lockfile with what CI builds.

4) Your production runtime does not support the same Node features

Some deployments run older Node versions or edge runtimes with partial support for streams/events. AutoGen agents depend on standard Node behavior.

{
  "engines": {
    "node": ">=20"
  }
}

If you’re deploying to an edge runtime, verify that EventEmitter, streaming responses, and async iteration are supported. If not, move AutoGen execution to a Node serverless function or backend worker.

How to Debug It

1. •

   Prove registration happens Add a log immediately before attaching the callback.

   console.log("registering message callback");
   assistant.on("message", handleMessage);
   

   If this log appears and the callback still never fires, registration timing or event mismatch is likely.

2. •

   Prove the exact instance is used Log object identity around construction and execution.

   console.log("assistant instance:", assistant.name);
   

   In DI-heavy codebases, it’s easy to register on one instance and run another.

3. •

   Force awaits everywhere Search for missing await on run(), tool calls, or wrapper methods.

   await assistant.run(prompt);
   

   If adding await fixes it, you had a lifecycle bug.

4. •

   Check production-only config Compare these between local and prod:

   • •NODE_ENV
   • •Node version
   • •deployment target: serverless vs long-lived process vs edge
   • •package lockfile / installed AutoGen version

Prevention

• •Register callbacks during construction or immediately after instantiation, before any call to run().
• •Treat every AutoGen execution path as async and await it explicitly.
• •Pin your AutoGen version and Node version in CI so local and production behave the same.
• •Avoid wrapping functional event registration inside environment checks or optional debug branches.

If you still see something like callback not firing in production with no stack trace, assume lifecycle first, API mismatch second. In AutoGen TypeScript projects, that’s where this bug usually lives.

Keep learning

• •The complete AI Agents Roadmap — my full 8-step breakdown
• •Free: The AI Agent Starter Kit — PDF checklist + starter code
• •Work with me — I build AI for banks and insurance companies

By Cyprian Aarons, AI Consultant at Topiax.