EscalAI

• 

• 

  Architecture Diagram

Inspiration

Support teams live in constant firefighting mode. Agents manually triage tickets, dig through scattered knowledge bases, and often only realize a ticket is about to escalate — an angry customer, a breached SLA, a repeat contact — after it's already too late. We wanted to build something that flips this: an AI system that watches, understands, and acts before a small issue becomes a churn risk. With the rise of MCP and multi-agent orchestration, it felt like the right moment to build a system where specialized agents collaborate the way a real support team would — instead of one generic chatbot trying to do everything.

What it does

EscalAI is a multi-agent support copilot built on four cooperating agents:

• Triage Agent — reads every incoming ticket and classifies category, urgency, and customer sentiment in real time.
• Knowledge Agent — retrieves relevant KB articles and past resolved tickets via MCP tool calls, then drafts a suggested resolution.
• Resolution Agent — auto-resolves simple, well-understood issues, and for complex ones, hands off to a human agent with a structured context summary so nobody starts from zero.
• Escalation Guardian — continuously scores open tickets for escalation risk based on sentiment trend, SLA countdown, and repeat contact frequency, and proactively alerts a human agent before the situation blows up.

Together, these agents turn a reactive support queue into a proactive one.

How we built it

We designed the four agents as independent, communicating units orchestrated through MCP, so each agent has a clear responsibility and a clean handoff to the next. The Triage Agent's output feeds the Knowledge Agent's retrieval step; the Resolution Agent consumes both to decide whether to auto-resolve or escalate to a human; and the Escalation Guardian runs continuously in the background, independent of the main pipeline, watching every open ticket for risk signals. We prototyped the interface in Figma first — a live ticket queue, an agent handoff trail showing which agent did what, and an escalation-risk indicator — before wiring up the underlying agent logic.

Challenges we ran into

Getting the agents to hand off context cleanly — without losing information or duplicating work — was harder than expected. We also had to balance auto-resolution confidence: being too aggressive risks sending wrong answers to customers, being too conservative defeats the purpose of automation. Tuning the Escalation Guardian's risk scoring so it flagged real risk without drowning agents in false alarms took several iterations.

Accomplishments that we're proud of

We're proud that EscalAI isn't a single chatbot wrapper — it's a genuine multi-agent pipeline where each agent has a distinct job and a visible handoff trail, which makes the system's reasoning transparent to the human support agent instead of a black box. We're also proud of getting the Escalation Guardian to run as a true background process, independently scoring risk across the entire ticket queue rather than only reacting when a ticket is opened — that's the piece that actually shifts the team from reactive to proactive.

What we learned

Multi-agent systems are only as good as the handoffs between agents — the orchestration logic matters as much as any individual agent's intelligence. We also learned a lot about designing for trust: support agents need to see why the AI made a decision, not just the decision itself, which shaped our Figma handoff-trail screens.

What's next for EscalAI

• Wire up a real Freshworks/Freshdesk integration via MCP
• Add voice ticket intake using ElevenLabs, so calls get triaged the same way as text tickets
• Build a feedback loop so the Escalation Guardian's risk model improves from real outcomes

Built With

• api
• figma
• mcp
• node.js
• python
• react
• typescript