Building an AI helpdesk where the machine drafts, advises, and monitors — but never resolves a ticket on confidence alone.

The operational cost of context

Running IT support for multiple client organizations means carrying simultaneous context for each — which platforms they're on, what their last issue was, what's been resolved before, which SLA tier they're under. Without tooling, every new ticket starts with 10–15 minutes of history-reading before any actual support happens. The second problem is automation risk. Auto-closing tickets based on AI confidence alone would recover that time — but at the cost of reliability. A misclassified ticket that gets auto-resolved is a client problem the operator never sees. Too many false positives and the automation becomes a liability rather than a tool. Kocre IT needed an AI layer that was genuinely useful for context-gathering and drafting, and genuinely conservative about autonomous action — not because the AI was weak, but because the conditions for acting on its output needed to be unambiguous.

Ghost Admin — the internal AI brain

Ghost Admin is the orchestration layer. For any open ticket, it fetches a structured context bundle before calling the model: — The full ticket record with all AI triage fields populated — Up to 10 recent client-facing conversation messages — Similar previously resolved tickets, matched on title and category — KB/SOP drafts already linked to the ticket — Published knowledge articles ranked by relevance — The client organization's full lifecycle state: agreement status, payment status, onboarding progress, client_status, whether the account flags for human review Ghost sends this bundle to Claude and returns a 10-field JSON: what the ticket is actually about, the most likely blocker, recommended next action, a scope call (standard_support / watch_scope / likely_scoped_work), client reply guidance, lifecycle signals, and a short operator warning for edge cases. This context synthesis happens in under 3 seconds and gives the operator a starting position that would otherwise require reading the full ticket history, the client profile, and the knowledge base manually. Ghost also generates follow-up drafts in 6 modes: initial response, progress update, resolution, information gathering, escalation update, and needs assessment. Each draft pulls from the same context bundle — meaning drafts reflect the client's lifecycle stage, not just the issue description.

The auto-resolve gate — six conditions, not one

AI triage can flag a ticket ai_can_auto_resolve: true — but this is an input to the gate, not a decision. All six conditions must hold simultaneously before any ticket closes automatically:

The knowledge flywheel

Every ticket that moves through Kocre IT makes the next one faster. The flywheel runs in four stages: Triage enrichment: On ticket creation, AI triage runs immediately — classifying category, scoring confidence, flagging escalation and project risk, estimating time. The ticket is enriched with 10 AI fields before an operator opens it. Context bundling: When Ghost Admin runs on a ticket, it pulls similar resolved tickets from the database. The more resolved tickets exist, the richer the context bundle. A new Microsoft 365 issue gets context from every previously resolved Microsoft 365 ticket for that client. Knowledge generation: When a ticket closes, Ghost can generate a KB/SOP draft from the resolution thread. This captures what the issue was, what was tried, and what fixed it — gated strictly to resolved/closed tickets. In-progress tickets never generate drafts. Knowledge retrieval: Published KB articles rank into future Ghost context bundles. Over time, the system builds institutional memory. By the 50th resolved ticket for a client, new tickets from that client arrive with matched precedents, relevant procedures, and similar past resolutions — automatically.

Sentinel — deterministic monitoring without AI

Sentinel is the monitoring layer and the clearest example of where AI was deliberately excluded. It runs as a Vercel Cron job every hour, making deterministic checks against all monitored client URLs and ticket data. No model is involved in any monitoring decision:

Critical findings auto-create tickets assigned to an admin. Warning findings are logged in the activity log. No model decides what counts as an incident — Sentinel either fires or it doesn't, based on arithmetic. This is intentional. A monitoring system that asks a model whether an outage is significant introduces hallucination risk and latency into a context where determinism matters most. When an SLA breach happens, the operator needs to know — not a probability estimate.

What shipped

• Six-condition auto-resolve gate prevents AI confidence alone from closing tickets — all six conditions must hold simultaneously, not just the AI flag
• Ghost Admin synthesizes similar tickets, KB articles, and client lifecycle state into a 3-second context brief no operator could build manually from raw history
• Knowledge flywheel compounds with every resolved ticket — KB drafts generated on close, published articles ranked into future Ghost bundles automatically
• Sentinel monitors client URLs and SLA compliance deterministically every hour — no AI, no inference, no ambiguity about what triggers an alert
• AI triage enriches every ticket with 10 structured fields on creation — category, confidence, difficulty, time estimate, escalation flag, project flag
• Every Ghost action is logged to a ghost_events table with full input, output, and ticket context — a complete audit trail of every AI-assisted decision

AI drafts the reply, classifies the ticket, and synthesizes the context. Deterministic code decides whether to auto-close, whether to fire an alert, and whether a monitoring threshold was breached. Confidence is an input. It is never a sufficient condition.