Track 1 - SupposrtPilot Ai
Link to open source: https://github.com/AmanWithGitHub/Track-1--SupportPilot-AI
SupportPilot AI
AI Customer Support Agent that works where your support team works.
SupportPilot AI is an AI customer-support knowledge agent that lives inside Gmail. Open a customer email, click Analyze with SupportPilot, and watch the agent understand the issue, search company knowledge (Notion), check engineering context (GitHub), decide whether engineering is needed (Jira), draft a reply — and only send it after you approve.
Built for the Build with Swytchcode — 8-Hour Buildathon 2026 (Track 1: AI Customer Support Knowledge Agent). Every external integration runs through Swytchcode.
Problem
Support teams drown in triage: read the email → search the knowledge base → check if engineering knows about it → draft a reply → create a ticket → send. Each hop is manual, slow, and inconsistent.
Solution
An AI support engineer living inside Gmail. The agent does the triage for you — with a human in the loop for anything the customer actually sees:
Customer Email
↓
AI understands issue (category, priority, confidence)
↓
Search company knowledge (Notion via Swytchcode)
↓
Check engineering context (GitHub via Swytchcode)
↓
Agent decides next action (ticket needed? knowledge answer?)
↓
Create Jira ticket (via Swytchcode — human confirms)
↓
Generate customer reply (AI draft, editable)
↓
Human approval (explicit confirmation)
↓
Send reply (Resend via Swytchcode)
↓
Activity timeline (full audit trail)
Features
Gmail-native UX — floating "Analyze with SupportPilot" button on open emails; email subject/sender/body captured automatically
Agentic decision making — a password question gets a knowledge answer and no ticket; a technical bug triggers GitHub lookup and a Jira ticket
Live activity timeline — every agent step is timestamped and auditable
Human in the loop — nothing is sent and no ticket is created without explicit approval
Honest integration status — every retrieved artifact is tagged (demo vs live); the backend never silently fakes a real integration
Works offline — deterministic AI fallback and Swytchcode sandbox mode keep the demo reliable without keys or network
Architecture
Tech Stack
Layer Technology
Frontend React 18, TypeScript, Vite 5, Chrome Manifest V3
Backend C#, ASP.NET Core Web API, .NET 10
AI IAIService — OpenAI-compatible LLM (default) or built-in rule-based engine
Integrations Swytchcode (swytchcode exec) → Gmail, Notion, Jira, GitHub, Resend
Swytchcode Integrations
Swytchcode is the execution layer: the backend invokes swytchcode exec <canonical_id> --key value as a subprocess (the documented universal subprocess interface for languages without a runtime SDK, like .NET).
Integration Swytchcode tool Purpose
Notion notion.search.create Search company knowledge base
GitHub github.issues.list Find related engineering issues
Jira jira.api.issue.create Create engineering tickets
Resend resend.email.create Send customer replies
Gmail gmail.user.threads.get Read email threads (optional — capture is done in the Gmail UI)
Execution fallback ladder (never silent fakes):
Live CLI: swytchcode exec <tool> …
Swytchcode's own demo mode: swytchcode exec <tool> --demo
Clearly-labeled local sandbox (badge + tag in the UI)
AI Agent Workflow
The SupportAgentService runs a state machine surfaced in the UI:
ANALYZING → SEARCHING_KNOWLEDGE → CHECKING_GITHUB → GENERATING_REPLY
→ WAITING_FOR_APPROVAL → (CREATE_TICKET) → SENDING → COMPLETED
└─ ERROR at any step
Repository Layout
BUild1/
├── PROJECT_STATUS.md ← living project memory (read first!)
├── README.md
├── .gitignore
├── .env.example
├── backend/
│ └── SupportPilot.Api/
│ ├── Controllers/ ← /api/agent/*, /api/health
│ ├── Agents/ ← SupportAgentService (orchestration)
│ ├── Services/ ← AI, Swytchcode, RunStore
│ ├── Integrations/ ← CLI executor + sandbox simulator
│ ├── Models/ DTOs/ Configuration/
│ └── Program.cs
└── extension/
├── public/ ← manifest.json, icons
├── src/
│ ├── components/ pages/ services/ hooks/ types/
│ ├── content/gmail.ts ← Gmail capture + button
│ ├── background.ts ← opens popup
│ └── App.tsx
├── index.html
└── vite.config.ts
Setup
0. Prerequisites
Node.js ≥ 20 and .NET 10 SDK
Swytchcode CLI: npm install -g swytchcode
1. Backend
cd backend/SupportPilot.Api
dotnet run
# listens on http://127.0.0.1:5197 (Swagger at /swagger)
2. Extension
cd extension
npm install
npm run build # outputs to extension/dist
3. Load the extension in Chrome
Open chrome://extensions
Enable Developer mode
Click Load unpacked → select extension/dist
(Optional) Pin SupportPilot AI
4. Wire up live Swytchcode integrations (recommended for demo day)
# in the repo root — complete the login in your browser when prompted
swytchcode login
swytchcode get gmail notion jira github resend
swytchcode add notion.search.create github.issues.list jira.api.issue.create resend.email.create gmail.user.threads.get
# one-time OAuth per provider
swytchcode auth connect notion
swytchcode auth connect github
swytchcode auth connect jira
swytchcode auth connect resend
swytchcode auth connect gmail
The backend probes the CLI on startup and switches to live mode automatically. Without any of this, everything still runs in clearly-labeled sandbox mode — the demo never breaks.
Environment Variables
Copy .env.example → .env (or set in your shell). Never commit real secrets.
Variable Purpose
AI_API_KEY OpenAI-compatible key (optional; rule-based fallback without it)
AI_BASE_URL LLM base URL (default https://api.openai.com/v1; OpenRouter/Groq work too)
AI_MODEL Model name (default gpt-4o-mini)
SWYTCHCODE_ENABLED true/false (auto-detected from CLI availability)
JIRA_PROJECT_KEY Default project for tickets
JIRA_ISSUE_TYPE Default Bug
GITHUB_REPO Default repo for issue search, e.g. org/repo
NOTION_DATABASE_ID Optional Notion database filter for knowledge search
RESEND_FROM_EMAIL / RESEND_FROM_NAME Sender for customer replies
API_CORS_ORIGINS Comma-separated extra allowed origins
Demo Workflow (2.5-minute script)
Time Action
0:00 Open the test email in Gmail ("Invoice upload failing — 500 error")
0:15 Click the ✦ Analyze with SupportPilot button
0:25 Click Analyze Issue — watch the agent states
0:40 AI Analysis: Technical Bug · High · 94%
0:55 Notion knowledge found
1:10 GitHub issue #142 found
1:25 Create Jira ticket (SUP-417)
1:45 Review/redraft the suggested reply
2:00 Approve — confirmation gate
2:10 Reply sent
2:20 Activity timeline — the full audit trail
API
Endpoint Purpose
GET /api/health Health + mode (live/simulated, AI mode)
POST /api/agent/analyze Full analysis: classify, Notion search, GitHub check, decision, draft reply
POST /api/agent/draft-reply Redraft with an optional instruction
POST /api/agent/create-ticket Create Jira ticket (human-confirmed)
POST /api/agent/send-reply Send the reply via Resend (human-confirmed)
GET /api/agent/activity/{runId} Activity timeline for a run
GET /api/agent/status/{runId} Current agent state
Security
No secrets in the extension or committed to the repo (.env is git-ignored)
Backend only talks to Swytchcode — provider credentials never reach application code
Human approval required for all customer-facing actions
Errors are sanitized for users; technical details go to backend logs
Future Scope
Chrome side panel (always-on agent view) instead of popup
Real Gmail thread reading via gmail.user.threads.get
Persistent run history (SQLite behind RunStore)
Multi-step email threads and follow-up detection
Approval queue / Slack handoff for senior agents
Policy rules per tool in Swytchcode policies.json
PROJECT_STATUS.md is the living memory of this build — read it before continuing work and update it after any meaningful change.
