How to Build a Customer Support Triage Agent in CogniAgent: From Inbound Message to Routed Ticket

If your support inbox is one undifferentiated stream — urgent outages mixed in with password resets — you don't need more agents answering tickets. You need something deciding which agent should handle each conversation. That's a triage agent, and in CogniAgent it's built as a parent-child chain of actors, connected by Activation Conditions, and configured through Context, Instructions, Definition of Done, and Focus Mode.

The architecture at a glance

In the builder canvas, this is branches fanning out directly from Start to Triage Actor, spanning into more specific actors:

Step 0: Add the channel in Flow Settings

Before wiring up actors, open Flow Settings -> Channels -> Add Communication Channel. This is set at the flow level, not per-actor — every actor in this workflow shares the same intake channel. For a support triage flow, Widget (website chat widget) is the simplest place to start, since it's where most inbound support conversations begin and doesn't require external API setup like Twilio SMS or Gmail. You can always add Gmail, Slack, or Twilio SMS as additional channels later — Flow Settings supports multiple instances of the same channel and a mix of channels at once. Set the Execution Mode to Responder and Global Context — it will be injected into every actor's system prompt when the actor has Global flow context checked under Inherit. Also available to the routers.

Step 1: Add the Triage Actor and Set the Activation Condition 

Click the "+" button and add the first Actor, name it. Click the connector between Start and the Triage Actor to open its Activation Condition panel — "When should this route be taken?" This is where you describe the user intent or situation that should trigger this path, e.g. "Any new inbound widget message" if Triage Actor is meant to catch everything by default. This is also where multi-branch routing actually happens architecturally: if you later add a second branch straight from Start into a Specialist Actor (bypassing triage for something like a simple FAQ), its Activation Condition is what keeps the two paths from colliding — e.g. "User asks a general pricing question with no account specifics."

Step 2: Configure the Triage Actor — Context

Open the Triage Actor and go to the Basic tab. Context is general knowledge and background — domain knowledge, company info, tone of voice — and may be inherited by child actors. Put stable, company-wide information here: product names, business hours, escalation policy, tone.

Step 3: Configure the Triage Actor — Instructions

Instructions are specific behavior and rules for this actor only, and are never inherited. This is where the triage logic itself lives: identify whether the request is billing, technical, sales, or general; identify urgency; do not attempt to resolve the issue, only determine where it belongs.

Step 4: Add Specialist Actors with their own Activation Condition to Triage Actor

Each connection from the Triage Actor to a downstream Specialist Actor gets its own Activation Condition — this is the actual routing mechanism, not a separate condition node. For example:

• To the Billing Actor: "User asks about orders, pricing, charges, or refunds"
• To the Technical Actor: "User reports something broken, an error, or asks how to use a feature"
• To the Sales Actor: "User is evaluating the product or asking about plans before purchasing"

Keep these descriptions specific and non-overlapping — vague conditions ("billing stuff") create ambiguous routing once real conversations hit edge cases.

Step 5: Set Inherit Context on each Specialist Actor

On each Specialist Actor (Basic tab), check Inherit Context:

• Global flow context
• Collected information so far

This pulls in whatever the Triage Actor already established — without it, a Specialist Actor starts cold with no memory of what was already gathered.

Step 6: Set Definition of Done on each actor 

For the Triage Actor: "category and urgency have been identified." For each Specialist Actor: its actual resolution criteria — "all required billing details collected," "customer confirms issue resolved." This is what tells an actor when to stop and hand off cleanly instead of continuing to ask questions.

Step 7: Set Focus Mode on the Triage Actor

Focus Mode controls how the actor handles topic changes mid-conversation: Auto, Flexible, Persistent, Strict. For a Triage Actor, Strict or Persistent keeps it locked on classifying the request rather than getting pulled into resolving it. Specialist Actors can usually run Flexible, since some topic drift is normal once you're actually resolving something.

A note on what NOT to do

Don't leave Activation Conditions vague or blank — that's the field actually deciding which path a conversation takes, so an empty or generic condition means CogniAgent has no real basis for routing. Don't put routing logic in Context — it won't behave the way Instructions do. And don't forget Inherit Context on Specialist Actors, or every handoff starts from zero.

Why this pattern matters beyond support

The same structure — a channel set once at the flow level, Activation Conditions deciding which actor handles a conversation, and Context/Instructions/Definition of Done/Focus Mode configuring each actor — is the general shape for any classify-then-route problem in CogniAgent: sales lead qualification, recruiting screening, internal IT requests. Swap the channel, the Activation Conditions, and what's in Instructions per actor; keep the parent-child structure intact.