AI-augmented IT operations platform

Internal ops-automation platform I architected and built at the company. It ties the IT team's source systems into one analyzable Supabase store, exposes them as governed Cowork skills the team calls in chat, and runs a conversational triage agent that drafts a first pass on every new ticket and then works tickets alongside technicians in plain language. Source systems span ITSM (Freshservice), identity and device management (Microsoft Graph for Entra / Intune), remote support (ScreenConnect), network (Cisco Meraki), endpoint security (Bitdefender GravityZone), patch management (Action1), an internal GitHub-backed knowledge base, and task tracking (Microsoft Planner).

Force-multiplier for a three-person IT team supporting more than 1,000 employees across 80-plus offices in North America. It turns "half a dozen different consoles you have to log into" into one data store with one AI-augmented interface, and pushes the team's most common operations (search history, triage, diagnose, draft, enrich, look up live state) from minutes to seconds, plus an unattended agent that does the first pass of triage before a human opens the ticket.

Why this exists

The IT team handles roughly 1,000 to 1,200 tickets per technician per year for a workforce spread across 80-plus offices. Knowledge management, automation, and offshore staffing all exist already and carry a lot of weight. This platform is the next layer beyond those: an AI-mediated interface to the team's data, plus an autonomous agent that compresses common operations from minutes to seconds.

The "AI-augmented" framing matters. The platform does not replace human technicians. The agent reads, suggests, and runs read-only diagnostics; it does not close tickets or take destructive action on its own. It removes the boilerplate friction (looking up past tickets, hunting asset records, checking live endpoint or patch state, running the same diagnostic workup, drafting common replies, choosing a category) so human technicians can focus on actual problem-solving.

Architecture

Scheduled GitHub Actions run a Python feed (stdlib-first; idempotent and resumable; rate-limit aware; secrets out of source) that lands every source system into a unified Supabase Postgres backbone (a multi-table schema with audit columns and row-level security enabled). On top sit two front ends sharing one gather/data layer: the curated Cowork skill set the team calls directly, and an event-driven autonomous agent (a Freshservice webhook into a queue, processed on Azure Functions) that drafts a suggestion as a private staff-only note on each new ticket.

Architecture conventions

• Curated, named functions only Every integration exposes a curated set of named functions (read state, search history, look up an asset, draft a reply, run a themed diagnostic) rather than raw SQL or arbitrary tool access. Prevents prompt-injection or careless requests from producing destructive operations.
• stdlib-first Python Dependencies pulled in only where the standard library does not suffice.
• Idempotent and resumable jobs Every ingestion job can be re-run safely; partial failures resume from where they left off. No "watch-the-script-run-don't-touch-it" operational pattern.
• Rate-limit aware The Freshservice feed splits a frequent incremental ticket sync from a once-daily reference refresh (lookup tables, assets, people, KB) to stay inside the rate budget; every source-system client backs off cleanly when throttled.
• Secrets out of source API keys, certificates, and connection strings live outside the repository, delivered through platform secret stores (GitHub Actions secrets for the feed, Azure Function app settings for the agent). Nothing sensitive is committed.
• Row-Level Security at the database layer, not the application layer.

Safety model

Because the agent can read from and act against production systems, the trust boundaries are explicit:

• Auto-triage is read-and-suggest only. Ticket content is treated as data, never as instructions, so a crafted ticket cannot steer the agent. Diagnostic and action targets come from asset / ScreenConnect data, never from ticket text.
• State-changing actions are gated. Operator commands in a private note run read-only diagnostics on request; a scan, an isolate, a patch deploy, a reboot, or a mailbox/OneDrive access grant only ever queues a preview and requires a second explicit confirmation before anything changes.
• Destructive command execution is never in the autonomous path and is denylist-protected.
• All agent notes are private (never tag or notify the requester) and run through secret-redaction before they are written.

Judgment and guardrails

The agent's core design principle: judgment belongs to the model, guardrails belong to the writes. The LLM's whole-ticket comprehension owns intent, the subject person (who the ticket is about, which may differ from who filed it), and repair-vs-replace judgment — while every safety property lives at the action layer, where it's enforceable. The agent can analyze and recommend anything; it cannot change anything without a human confirm. A deterministic path covers model outages.

Status

In production. The unified Supabase backbone is live with row-level security and full ticket history seeded; the legacy SQLite cache that proved out the conventions on a single source system has been retired. The agent runs live on Azure Functions and is conversational: technicians tag it in a private note and talk in plain language; it investigates on its own, asks clarifying questions back, and carries the conversation across notes. On each new ticket it reasons over the whole thing — subject, body, the full email thread, the requester's profile and recent tickets, attached screenshots (vision), live machine and network context (an office-vs-home verdict derived from Cisco Meraki presence), and how similar tickets were resolved before — and posts a suggestion note that leads with the recommendation and ends with its confidence band and the model that reasoned it. It runs the cheapest capable model first and escalates up a Haiku → Sonnet → Opus cascade only on low confidence, with a prompt-cached reasoning prefix and a deterministic fallback. Confirm-gated actions span named machine fixes, reboots and service restarts, Exchange Online changes (composing the exact PowerShell from a plain-language ask), password/MFA resets, group membership, litigation holds, and scheduled offboarding plans that run at the ticket's effective date. A verify loop re-checks whether a fix actually held. A note-driven training loop lets technicians coach the agent from inside the ticket, and the agent can file GitHub issues on itself and propose documentation changes as human-reviewed pull requests. Pushes to main auto-deploy the function.

What this demonstrates

• Building AI-augmentation infrastructure for operational teams rather than just consuming hosted AI products. The platform is the integration layer between the team's source systems and Claude (or any future LLM), not "we use a chatbot to help with tickets."
• Shipping an autonomous agent into production with a conservative safety model Read-and-suggest by default, read-only diagnostics autonomously, state-changing actions confirm-gated and never sourced from ticket text.
• Curated-function exposure rather than raw access, plus an explicit confirm gate for state-changing actions, is the right pattern for AI agents that touch production systems and reflects mature thinking about LLM safety.
• Judgment-led agent design Letting the model's comprehension drive routing while keeping every guardrail at the write layer — analysis unconstrained, actions confirm-gated — instead of subordinating the LLM to brittle intent scripts.
• Multimodal and cost-aware model use Vision for screenshot triage, a prompt-cached reasoning prefix, and a cheap-first / escalate-on-low-confidence model cascade so spend tracks the hard cases — with the model and confidence band named on every note for transparency.
• Multi-source unification with audit and RLS at the database layer is the right shape for an IT data store that crosses ITSM, identity / MDM, remote support, network, endpoint security, and patch management.
• A feedback loop that improves the agent in place Technicians coach it from inside the ticket, and that feedback is captured and applied rather than lost in chat.