EscalateAi

Inspiration

Every support team has the same quiet, expensive problem: a customer reports an issue, it gets a reply, and if it isn't actually fixed, they come back — worded slightly differently each time — and nothing connects ticket one to ticket three. By the time a human notices the pattern, the customer has already lost patience.

The hackathon's theme — "agents that think, agents that act, agents that remember" — pointed at exactly the gap we'd seen: most "AI support tools" retrieve memory, they don't act on it. We wanted to build something where memory isn't a lookup step before a canned response, it's the evidence an agent actually reasons over before deciding what to do. CockroachDB's pitch — one distributed, always-on database for both transactional state and vector embeddings — was the missing piece that made that possible without duct-taping a separate vector store to a Postgres instance.

What it does

EscalateAI is an autonomous support agent with persistent memory. When a ticket comes in, the agent doesn't follow a fixed script — it investigates. It calls tools, through CockroachDB's Managed MCP Server, to semantically search that customer's past tickets (via CockroachDB's distributed vector index) and pull their structured ticket history. Based on what it actually finds, it decides for itself: if this looks like a repeat, unresolved issue, it escalates the ticket and writes a context-rich summary — what happened before, what was tried, why it's likely still broken. If it's a new or routine issue, it drafts a helpful reply instead.

A human agent opening the dashboard doesn't start from zero on a repeat case — they see the ticket already flagged, with the reasoning trace and prior context attached.

How we built it

• CockroachDB Cloud (Serverless) as the single system of record: customers, tickets (with a VECTOR(1536) column and a distributed vector index), and escalations tables — structured and semantic data living in the same cluster.
• CockroachDB Managed MCP Server as the only path the agent has into the database — every read and write goes through it, fully audited, rather than the agent (or our backend) touching SQL directly.
• Amazon Bedrock for both the embedding model (used to vectorize incoming ticket text) and the reasoning model, driven through Bedrock's Converse API with tool-calling.
• An agent orchestrator built around a genuine tool-calling loop — Thought → Tool call → Observation → Decision — rather than hardcoded thresholds. The model itself decides when to search memory, when it has enough evidence, and which terminal action (create_escalation or send_reply) to take.
• A FastAPI ingestion service exposing the agent behind a simple API, and a Streamlit dashboard with a live "Agentic Tool-Calling & Memory Trace" panel so the agent's reasoning is visible, not a black box.
• A safety-net fallback and a test suite (59 unit, property-based, and integration tests) covering both the agentic path and the deterministic fallback path.

Challenges we ran into

The biggest one was self-inflicted and worth being honest about: our first working version was a clean pipeline — embed the ticket, run a vector search, check a hardcoded repeat-count threshold, then call an LLM only to write the final summary text. It worked, but it wasn't actually agentic — the model was a text generator bolted onto a rule-based script, not a system that reasoned over memory. Recognizing that distinction, and refactoring the decision logic itself into a Bedrock tool-calling loop where the model chooses what to query and when to stop, was the real engineering challenge of this project.

That refactor introduced its own problems: making sure every tool call the model requests actually round-trips through the MCP Server (and doesn't quietly bypass it with direct SQL), preventing duplicate writes when a terminal tool like create_escalation fires, and giving the loop a safe, clearly-logged fallback path for the rare cases where the model doesn't converge on a decision within a bounded number of steps — without letting that fallback silently masquerade as "the agent decided this."

Accomplishments that we're proud of

• A genuinely autonomous decision loop, not a rules engine with an LLM writing the summary at the end — the model decides what evidence to gather and when it has enough.
• A real reasoning trace, visible end to end, that shows every tool call and observation the agent made before it acted — which also happens to be exactly what makes the memory layer demonstrable on camera.
• One database doing double duty as both the vector store and the system of record, with zero sync logic between them.
• Every agent-to-database interaction going through an audited, read/write-scoped MCP interface rather than raw credentials.
• A test suite that grew alongside the refactor instead of being an afterthought — 59 tests covering both the happy path and the fallback.

What we learned

The line between "an app that uses an LLM" and "an agent" is thinner in code than it sounds, and easy to cross without noticing — a threshold check with an LLM-generated summary at the end looks agentic in a demo but isn't, and judges (and users) can tell the difference once you show them the reasoning trace, or the lack of one. We also came away convinced that unifying transactional and vector data in one database isn't just an operational convenience — it changes what an agent can safely reason over, since it never has to reconcile two sources of truth that might disagree. And building the trace/observability layer alongside the agent, not after it, turned out to be as important as the agent logic itself — it's the difference between an agent you can trust and one you can only hope is working.

What's next for EscalateAI

• Native Amazon Bedrock Agents integration to move the orchestration loop from our own code into AWS's managed agent framework.
• Proactive detection — instead of waiting for a second ticket, flag rising-risk customers from sentiment and frequency trends before they escalate themselves.
• Real ticketing platform integrations (Zendesk, Intercom, Freshdesk) so this sits in front of the tools support teams already use, instead of a standalone dashboard.
• Deeper use of the CockroachDB Agent Skills Repo and ccloud CLI so the agent can also reason about its own database's health and performance, not just customer data.
• Multi-tenant hardening — per-team RBAC scoping through MCP, rate limiting, and clearer escalation routing rules for larger support orgs.

Built With

• amazon-web-services
• bedrock
• cockroachdb
• cockroachdbmcp
• mcp
• python