The problem your project solves

The problem

Service teams run on manual, inconsistent incident & maintenance response. When a vendor outage, partner maintenance email, or monitoring alert comes in, someone has to:

1. Read the signal and decide how bad it is
2. Figure out which customer-facing features are affected
3. Flip the right feature flags across App, uPortal, and Kiosk
4. Publish a customer banner that matches what was actually turned off
5. Log the whole thing somewhere auditable

Today this is stitched together across Slack threads, dashboards, and tribal knowledge. The cost:

• Fragmented signal interpretation — two operators read the same email and reach different severity calls.
• Delayed mitigation — every minute between "signal arrives" and "flag flipped" is a minute of broken customer experience.
• Multi-channel drift — a flag gets flipped in App but missed on Kiosk, so one channel keeps taking orders the system can't fulfill.
• No audit trail — post-incident reviews rely on Slack scrollback instead of a Service Event ID.

Why it's worth solving

Incident & maintenance response is one of the highest-leverage internal workflows in any ops-heavy company. Shaving minutes off triage, and removing the "did we remember Kiosk?" class of mistake, directly reduces customer impact — and frees operators to handle the judgment calls that actually need a human.

How you are solving it

How Godiva works

Godiva is built on the Vercel Claude Managed Agents template (Next.js 16 App Router + Better Auth + Neon/Drizzle + Vercel Workflow SDK) and turns an unstructured operational signal into an audited, one-click response through a four-step operator console:

Signal → AI recommendation → Human approval → Multi-channel execution

1. Signal intake and structured extraction

Operators submit a maintenance email, vendor alert, or manual note through the dashboard. A fast Claude Haiku pass (POST /api/godiva/classify-signal) extracts the signal into typed JSON — affected system, severity hint, domain, bundle, maintenance window, duration, and affected features — using the godiva-signal-schema skill as the contract. This gives the rest of the workflow a clean, structured input instead of free text.

2. AI decisioning via an Anthropic Managed Agent session

POST /api/godiva/analyze-signal opens an Anthropic Managed Agent session (beta Sessions API) wired to eight custom skills we built and uploaded via the Skills API:

• godiva-severity-rules — Critical / Major / Minor tiering
• godiva-ld-reference — 20+ domains × feature-flag bundle lookup
• godiva-approval-matrix — who has to sign off, per severity
• godiva-sop-playbook — SOP templates per incident class
• godiva-banner-templates — customer-facing banner copy
• godiva-vendor-status-urls — authoritative vendor status pages
• godiva-escalation-contacts — on-call escalation paths
• godiva-signal-schema — the structured-extraction contract used in step 1

A Vercel Workflow (sessionWorkflow) durably polls the session every 3s, persists every event to Postgres, and executes three custom tools the agent can call: check_vendor_status (live HTTP fetch of a vendor status page), submit_recommendation (writes severity + bundle + SOP to godiva_incident.recommendation), and set_feature_status (the flag-flip hook). Built-in tool confirmations are auto-allowed so the workflow never stalls.

3. Checker–maker approval gate

The AI's recommendation never auto-executes. The approval step shows both sides of the checker–maker model — Ops Manager (maker) and Product Lead (checker) — with the proposed bundle, the features it will toggle, and SOP steps laid out for review. Approve or reject hits POST /api/godiva/approve | /reject, which updates the incident row (approvalStatus, approvedBy, approvedAt, reason) and resumes the workflow hook so the agent re-engages with the human decision as context for the next turn.

4. Multi-channel execution + audit trail

On approval, Godiva flips the relevant feature flags across App, uPortal, and Kiosk in a single action and renders a customer-facing banner from a template. A persistent feature status bar polls every 5s so operators see green/red state across all three channels at a glance, and every transition writes to a Service Event ID for post-incident review.

What's real vs. mocked

The AI decisioning, approval loop, workflow orchestration, feature-flag state, and SOP generation are all real end-to-end inside Godiva. The mocked pieces are strictly at the system boundaries:

• Signal ingress — signals come from a pre-populated injector instead of a live email inbox / monitoring webhook.
• Banner / UI announcement egress — customer-facing banners render inside the Godiva UI instead of publishing to real App, uPortal, and Kiosk surfaces.

Both are mocked for the same reason: a hackathon project can't legitimately connect to a real company's customer infrastructure, and the underlying systems are confidential. Every boundary is behind the same API contract the production integrations would use, so swapping in the real endpoints is a config change, not a rewrite.

Use of Genspark

How we used Genspark

We used Genspark as a research and validation partner, not as a code generator. It played two specific roles in the build:

1. Product research and validation

Before committing to the four-step operator console we shipped, we used Genspark to pressure-test the problem framing — pulling together how incident & maintenance response is handled across ops-heavy companies, where checker–maker approval models show up in practice, and what severity-tiering conventions real service teams use. That research fed directly into the severity rules, approval matrix, and SOP templates we encoded as skills for the Anthropic Managed Agent.

2. Testing the deployed website

After each deploy, we used Genspark to exercise the live site as a first-pass reviewer — walking the end-to-end flow, probing edge cases in the signal → approval → execution loop, and sanity-checking that the UI communicated what we thought it did. This gave us an outside perspective on rough edges that were easy to miss when you've been staring at the same screens all day.

What we deliberately did not use Genspark for

Code generation. The implementation (API routes, workflow, UI, skills, schema) was written against the Vercel Claude Managed Agents template using Claude. Keeping Genspark on the research/validation side and Claude on the build side gave us clear separation: Genspark helped decide what to build; Claude helped build it.

Use of Claude

How we used Claude

Claude is the engine behind Godiva — both at build time and at runtime. It shows up in five distinct places:

1. Anthropic Managed Agents — the decisioning core

The heart of Godiva is an Anthropic Managed Agent session, invoked via the beta Sessions API (client.beta.sessions) and driven by a Vercel Workflow that durably polls sessions.events.list every 3 seconds. Every event — assistant messages, tool calls, requires_action, status_idle — is persisted to Postgres so the workflow is crash-safe and the UI can replay the full decisioning trace.

2. Eight custom Skills uploaded via the Skills API

We built and uploaded eight domain-specific skills via client.beta.skills (IDs tracked in godiva-skills.json) so the agent can reason with real operational knowledge instead of a bloated system prompt:

• godiva-severity-rules — Critical / Major / Minor tiering
• godiva-ld-reference — 20+ domains × feature-flag bundle lookup
• godiva-approval-matrix — who has to sign off, per severity
• godiva-sop-playbook — SOP templates per incident class
• godiva-banner-templates — customer-facing banner copy
• godiva-vendor-status-urls — authoritative vendor status pages
• godiva-escalation-contacts — on-call escalation paths
• godiva-signal-schema — the structured-extraction contract

A pnpm skills:sync script reads each SKILL.md, pushes a new version to Anthropic, and updates the ID registry — so skill edits are part of the normal dev loop.

3. Three custom tools the agent calls

Inside a session the agent can call three tools we defined: check_vendor_status (live HTTP fetch of a vendor status page), submit_recommendation (writes severity + bundle + SOP to the incident row), and set_feature_status (the flag-flip hook). Built-in tool confirmations are auto-allowed so the workflow never stalls.

4. Claude Haiku 4.5 for fast structured extraction

Three supporting routes use Claude Haiku 4.5 (claude-haiku-4-5-20251001) directly via the SDK for latency-sensitive structured work:

• /api/godiva/classify-signal — parses raw email/alert into the godiva-signal-schema JSON contract
• /api/godiva/generate-signal — synthesizes test signals for the demo
• /api/godiva/generate-banner — fills banner templates from the approved recommendation

5. Claude Code (Sonnet 4.6) to build the whole thing

Every line of Godiva — the Next.js 16 App Router app, the Drizzle schema, the Vercel Workflow, the custom tool handlers, the skills content, the shadcn/ui dashboard — was written collaboratively with Claude Code (Sonnet 4.6). The agent helped us move from the Vercel Claude Managed Agents template to a working incident-response console inside the hackathon timebox.

What is the deployed URL for this project?

https://godiva-pi.vercel.app/