Portfolio case study

OpsDesk AI

OpsDesk AI is a full-stack, policy-gated AI workflow demo that turns messy service enquiries into structured tickets, retrieval-aware drafts, human approval gates, audit trails, and production-ready integration boundaries.

Open the demo View architecture Agent delivery

AI handoff loopTicket queue -> review gate -> audit trail

5seeded DragonTech cases across quotes, incidents, documents, compliance, and complaints

2AI decisions per ticket: triage plus controlled response-template selection

0silent AI actions on urgent, low-confidence, complaint, payment, or mismatch cases

100%model actions logged with prompt version, validation state, confidence, cost, and reviewer outcome

Reviewer path

If you only have a few minutes, follow the workflow in this order.

StartBusiness problem, product story, AI boundary, and production-shaped architecture.Try workflowSubmit a messy customer enquiry and trigger deterministic AI triage.Review queueInspect owners, priorities, summaries, policy status, and follow-up work.Inspect safetyReview prompts, validation, costs, trace spans, approvals, and audit events.Production pathSee hosted demo mode mapped to database, queue, webhook, search, and observability boundaries.

The problem

Local service businesses lose time inside email threads, PDFs, half-written quotes, missed follow-ups, and unclear ownership. A chatbot does not fix that. The workflow needs ticket state, background jobs, human review, and an audit trail that makes AI output inspectable.

OpsDesk AI is framed around DragonTech Facilities, a small operator handling installation quotes, urgent incidents, supplier mismatches, compliance chasing, and customer complaints from the same queue.

Workflow and data model

The core product object is a ticket, not a chat message. Each ticket keeps the raw customer input beside AI summaries, selected templates, policy decisions, events, webhook attempts, and Watchtower trace spans.

That model makes the workflow obvious: intake creates durable state, AI prepares a bounded recommendation, policy decides whether automation is allowed, and the audit trail explains the decision later.

TicketRaw customer source, company, contact, category, priority, owner, status, sentiment, and SLA context.

AI runPrompt version, model, confidence, validation result, selected template, tokens, latency, cost, and output hash.

Knowledge chunkPolicy/document/ticket evidence prepared for retrieval with source metadata and pgvector-ready shape.

Audit eventPolicy decision, reviewer action, trace span, event envelope, webhook attempt, and replay context.

Solution

Structured ticketing, AI triage, document extraction, retrieval-aware drafting, human approval gates, and Watchtower audit records.

My role

I designed the workflow, modeled ticket and AI-run data, built the UI and demo flow, defined policy gates, and separated production adapters.

Tradeoffs

The public demo stays deterministic for reliability while real database, queue, webhook, search, graph, and observability adapters remain explicit boundaries.

Screenshots and GIF

A portfolio page with product evidence, not just claims.

Operations desk in OpsDesk AI — ScreenshotOperations deskTicket queue with owners, AI summaries, status, priority, and follow-up work visible in one scan.

AI handoff loop in OpsDesk AI — GIFAI handoff loopA compact walkthrough from ticket queue to Watchtower review and the architecture trace.

Watchtower audit in OpsDesk AI — ScreenshotWatchtower auditEvery model call shows validation, approval state, cost, prompt version, trace, and event evidence.

Full-stack implementation proof

TypeScriptDomain types for tickets, AI runs, documents, events, webhooks, traces, search, and graph records.

React RouterFull-stack loaders/actions for enquiry intake, ticket workspaces, Watchtower, and platform routes.

PostgreSQL + pgvectorDrizzle schema models tickets, response templates, knowledge chunks, AI runs, and evaluations.

Vercel AI SDKAI boundary is ready for model calls while the public demo stays deterministic and reviewable.

VitestUnit coverage for AI triage, repositories, runtime config, adapters, and OTLP trace export payloads.

PlaywrightRoute smoke tests cover the desk, enquiry flow, Watchtower, architecture, case study, and integrations.

Product loop

The product workflow

CaptureWebsite enquiries, email-like messages, and file notes become durable tickets with raw source retained.

TriageAI classifies category, priority, missing info, risk, and the next suggested desk action.

DraftOnly approved response templates can be selected; business commitments stay out of automation.

ReviewPolicy gates route urgent incidents, complaints, mismatches, and low confidence to named humans.

AuditWatchtower keeps prompts, outputs, validation, approvals, trace IDs, tokens, and cost inspectable.

Architecture diagram

The AI path is separated from durable operations state.

The design keeps intake, queueing, AI output, retrieval, audit, and integration contracts explicit, so a reviewer can inspect what happened without trusting a black box.

01Ticket intakeReact Router actions validate enquiries and persist the raw customer source.

02AI triageStructured outputs force category, confidence, missing info, priority, and next action fields.

03Knowledge/RAGpgvector-ready chunks support cited retrieval from policies, documents, and past tickets.

04Policy gateTemplate permissions, confidence, urgency, complaints, and mismatches decide auto-send or review.

05Event/webhookKafka-shaped events and signed webhooks hand review tasks to CRM or downstream tools.

06Audit/WatchtowerAI runs, audit events, trace spans, and approval outcomes share the ticket correlation ID.

Human review and audit

AI can prepare work. Humans own risk.

OD-1025 is the clearest story: AI summarises an urgent Wi-Fi incident and drafts diagnostic questions, but the policy gate blocks auto-send because phone contact and customer urgency require a named human owner.

Allowed to auto-sendHigh-confidence missing-information requests using approved templates only.

Queued for reviewUrgent incidents, complaints, low confidence, document/payment mismatches, refunds, closes, or price commitments.

Always loggedEvery model output keeps prompt version, validation result, correlation ID, cost, latency, and reviewer outcome.

Open Watchtower

Source retainedRaw email, uploaded note, and extracted document fields stay beside the AI summary.

Policy evaluatedThe gate checks confidence, urgency, category, customer risk, and template permissions.

Human assignedPriya owns OD-1025 because urgent phone contact cannot auto-send from the model output.

Decision recordedApproval, rejection, edit notes, prompt hash, template ID, trace ID, tokens, and cost are logged.

Outcome

DragonTech gets one queue for quotes, urgent incidents, compliance chasing, document exceptions, and complaints. Operators can scan ownership and next actions quickly, while reviewers can inspect every AI decision before trusting it.

The result is a demo that shows the ambiguous business problem, the workflow model, the data model, and the AI boundary on the page instead of hiding those details in architecture notes.

Technical shape

Built as a React Router full-stack app with server loaders/actions, seeded demo state, Drizzle schema for PostgreSQL and pgvector, pg-boss worker scaffolding, AI SDK-ready boundaries, retrieval-aware agent contracts, evaluation tables, and a restrained operations UI designed for repeated use.

The expanded delivery view shows how the project would be sold and adopted with a client team: stakeholder discovery, success metrics, agent blueprinting, RAG pipeline design, rollout controls, and ROI measurement.

This project reflects the same implementation pattern I use in enterprise software delivery: understand the real operational workflow, protect data integrity, automate the repeatable path, keep exceptions reviewable, and design the result so it can be demoed, supported, and extended.

Production next

Auth/RBACAdd tenant-aware roles for operator, manager, auditor, and integration-admin workflows.

ObservabilityImplemented now: Watchtower traces can be converted to OTLP/JSON via OTEL_EXPORTER_OTLP_* config.

EvalsExpand fixture regression packs for template selection, retrieval citations, and policy-gate decisions.

Queue retriesMove pg-boss job contracts from simulator to retryable workers with DLQ replay controls.

Customer configPersist per-customer channels, templates, SLA rules, risk settings, and webhook destinations.

Why it demos well

Junior-operator behaviorAI can suggest, extract, summarise, and select approved missing-info templates, but it cannot close tickets, make commitments, or silently change business-critical records.

End-to-end service storyThe seeded cases show quote intake, urgent incident triage, document mismatch handling, compliance chasing, and complaint recovery.

Production-shaped backendThe repo includes database, queue, vector retrieval, evaluation, event, webhook, and observability boundaries that can grow into a deployed app.

Integration proofKafka-shaped events and signed webhooks show how review-required decisions leave the desk without losing correlation, replay, or idempotency.

Consulting narrativeAgent delivery pages connect discovery, prototype, rollout controls, and ROI so the project reads like a client-ready implementation case.

Audit postureWatchtower preserves prompt versions, output hashes, validation failures, approvals, and feedback so every AI action can be reviewed later.