EdgeCase

• 

  The demo persona selection

• 

  Main command center

Inspiration

Enterprise support teams do not struggle most with routine tickets. They struggle with exceptions: cases where systems disagree, policy conflicts with a previous commitment, and a high-value action could create financial or compliance risk.

A customer might be told by a support representative that a replacement will be provided, while the logistics system says the original shipment was delivered. A normal ticketing workflow can record the disagreement, but someone still has to investigate the evidence, interpret the conflict, determine whether policy allows an action, obtain approval, execute it, and verify that it actually happened.

Generic chatbots and ticket summarizers are not enough for these cases. They can explain what happened, but explanation is not the same as safe resolution.

We built EdgeCase around a different idea:

Exceptions require governed decisions, not just better summaries.

What It Does

EdgeCase is a governed exception-resolution command center for enterprise service operations.

Our demonstration centers on EC-1042, "The Broken Promise."

A customer claims they never received a $1,200 laptop, while the logistics system reports that the shipment was delivered. EdgeCase investigates the case by gathering evidence from multiple enterprise systems through the Model Context Protocol (MCP).

The system discovers a conflict between the delivery record and the customer's claim, identifies a previous support commitment, and evaluates the proposed resolution against deterministic policy.

Because the replacement exceeds the financial approval threshold, EdgeCase does not allow the AI to authorize the action. Instead, the case enters an approval state for a manager.

After approval, the backend claims the execution atomically, triggers the replacement through MCP, and then performs an independent verification read.

Only after verification succeeds does the case become a verified resolution.

If verification fails, EdgeCase refuses to mark the case as resolved and instead creates a justified escalation for human review.

How We Built It

EdgeCase is built with Next.js, React, TypeScript, Tailwind CSS, Zod, and the Model Context Protocol SDK.

The architecture deliberately separates reasoning from authority.

The LLM is an untrusted reasoning component. It can analyze structured evidence and identify conflicts, but it cannot directly approve financial actions, bypass policy, execute privileged tools, or arbitrarily change workflow state.

A deterministic backend state machine owns the workflow and enforces valid state transitions.

A local MCP server exposes enterprise-style tools for CRM history, logistics information, replacement-order execution, and independent order verification.

For the demonstration, these enterprise systems use deterministic mock adapters so the workflow is reproducible and does not depend on external service availability.

Freshworks integration is also represented through a mock adapter, with an optional live Freshdesk API adapter when real credentials are supplied.

Authentication uses server-side sessions with HTTP-only cookies, while role-based authorization and tenant isolation are enforced on the backend.

What Makes It Different

EdgeCase separates reasoning from authority.

The AI can say:

"These systems disagree, and the customer's previous commitment suggests a replacement."

But the AI cannot say:

"Therefore, I am authorized to spend $1,200."

That decision belongs to deterministic policy and the appropriate human role.

The same principle applies after execution.

The system does not assume that a successful tool call means the customer's problem has been solved. It performs an independent verification step before declaring the case resolved.

This creates a chain of trust:

Evidence → AI reasoning → Deterministic policy → Human authorization → Execution → Independent verification → Resolution

If any critical step fails, the system fails safely rather than silently claiming success.

Challenges We Faced

The hardest challenge was making the system genuinely agentic without giving the AI unsafe control.

We had to separate LLM reasoning from authorization, define explicit state transitions, validate tool outputs, enforce tenant isolation, prevent approval bypasses, protect execution from race conditions, and make failures first-class outcomes.

Another challenge was making the demonstration deterministic enough for judges to reproduce while still representing a realistic enterprise workflow.

We therefore created controlled enterprise-system adapters and a local MCP server while keeping the security boundaries and workflow enforcement in the real application code.

Accomplishments

• Built a complete enterprise-style exception-resolution command center
• Implemented a real local MCP server using the MCP SDK
• Connected the workflow to CRM, logistics, order execution, and verification tools
• Implemented deterministic policy gates
• Enforced role-based approval for high-value actions
• Implemented server-side authentication and tenant isolation
• Added atomic execution claiming to prevent duplicate execution
• Added independent verification after tool execution
• Created a safe escalation path when verification fails
• Added deterministic mock adapters for reproducible demonstrations
• Added an optional live Freshdesk integration path
• Built a complete audit timeline showing the lifecycle of each case
• Added automated functional and security testing for critical invariants

What We Learned

Trustworthy enterprise AI is not about giving an agent unlimited autonomy.

It is about giving the agent useful autonomy inside clearly defined boundaries.

The most important design lesson was that an AI system should not be the final authority over actions that affect money, customers, or compliance.

Instead, AI should contribute reasoning while deterministic systems enforce policy and humans retain authority where required.

We also learned that verification must be independent from execution. A system should never assume that because an action was requested successfully, the real-world state necessarily changed.

What's Next

Our next steps include:

• Deeper live Freshworks/Freshdesk integration
• Production-grade enterprise authentication and SSO
• Configurable policy authoring for operations teams
• Additional exception domains beyond customer support
• More enterprise-system connectors through MCP
• Richer audit analytics and operational dashboards
• Production database infrastructure and transactional persistence
• Expanded evaluation of AI reasoning quality and failure modes

Built With

• ai
• api
• audit
• automation
• context
• css
• customer
• enterprise
• freshdesk
• governance
• logs
• mcp
• model
• next.js
• protocol
• rbac
• react
• saas
• sdk
• support
• tailwind
• typescript
• workflow
• zod