Camilo Valderruten

Essay

·

Automating Infrastructure Support Triage: Building a Multi-Skill Intake Agent in Cursor

How we built an event-driven Cursor Cloud Agent triggered by issue webhooks and Slack to classify infrastructure tickets, search historical precedents, and auto-tag business units.

In platform engineering, on-call engineers spend an enormous amount of time acting as human ticket routers.

When hundreds of product and data engineers submit requests to a centralized Infrastructure and DevOps service desk, the queue is inevitably flooded with a wide variety of tasks:

  • Provisioning enterprise AI API keys
  • Registering custom subdomains and DNS records
  • Updating reverse proxy routes and ingress policies
  • Configuring cross-account cloud IAM roles and SSO access
  • Routine misroutes, such as asking infrastructure teams for web application logins or database connectors that belong to IT or DataOps

Triage becomes an operational tax. Engineers lose focus trying to parse ambiguous summaries, search for previous precedent tickets, redirect misplaced requests, and manually tag metadata required by Finance for internal cost allocation.

To streamline this process, we built an event-driven Intake Automation using Cursor Cloud Agents, Model Context Protocol (MCP), and a modular skills architecture.

                   Trigger Events
        ┌────────────────────────────────┐
        │ 1. Ticket Created Webhook      │
        │ 2. New Customer Comment        │
        │ 3. Ticket Moved to Done        │
        │ 4. Slack Support Channel Post  │
        └───────────────┬────────────────┘
                        │
                        ▼
       ┌─────────────────────────────────┐
       │      Cursor Cloud Agent         │
       │   (Grok 4.5 / Claude Sonnet)    │
       └────────────────┬────────────────┘
                        │
       ┌────────────────┼────────────────┐
       ▼                ▼                ▼
 ┌───────────┐    ┌───────────┐    ┌───────────┐
 │  Service  │    │  Ticket   │    │ Precedent │
 │  Catalog  │    │ Platform  │    │  Search   │
 │   (MCP)   │    │   (MCP)   │    │  (JQL)    │
 └─────┬─────┘    └─────┬─────┘    └─────┬─────┘
       └────────────────┼────────────────┘
                        │
                        ▼
         Triage Mode & Execution Branch
   ┌────────────────────┼────────────────────┐
   ▼                    ▼                    ▼
[ AUTO ]             [ ASSIST ]          [ ESCALATE ]
Self-serve redirect  Human infra work;   Unclear request;
or noise cleanup     drafts numbered     acknowledges receipt
(No infra work)      execution steps     & asks for diagnostics

The Philosophy: “Skills Before Automation”

The most common failure mode when introducing LLMs into infrastructure workflows is giving an agent raw CLI access and asking it to solve problems unguided. In production infrastructure, unconstrained autonomy leads to hallucinated commands, unexpected configuration drift, and security risks.

We structured our automation around a foundational principle: Skills Before Automation.

  1. Deterministic Skill Monorepo: We first encoded our repeatable infrastructure workflows into standardized SKILL.md documents under a centralized repository. Each skill explicitly defines required inputs, verification checks, target Infrastructure-as-Code repositories, and exact step-by-step commands.
  2. The Agent as a Classifier and Orchestrator: The Cursor Cloud Agent’s role is not to invent infrastructure changes from scratch; its role is to read the inbound ticket, identify the exact matching skill, find verified precedent tickets, tag metadata, and arm the on-call engineer with a pre-computed execution plan.

Three Operational Modes

When a webhook fires from the ticketing platform or a Slack support thread, the agent classifies the request into one of three explicit operational paths:

1. AUTO (Self-Serve Redirection and Noise Cleanup)

Many requests in an infrastructure queue require zero infrastructure modifications. They are either self-service requests, duplicate tickets, or misroutes:

  • An engineer requesting web chat access rather than API tokens is immediately redirected to the IT Helpdesk with direct single-sign-on links.
  • An engineer asking for data warehouse connectors is redirected to the DataOps team.
  • Test tickets, automated notification spam, and exact duplicates are identified immediately.

In AUTO mode, the agent tags the relevant business unit, posts a polite response with the correct redirection link, and resolves the triage loop without requiring human intervention.

2. ASSIST (Human-in-the-Loop Infrastructure Execution)

For legitimate infrastructure modifications (such as updating edge routes, modifying cloud SSO roles, or adjusting container image lifecycle policies), the agent acts as an automated co-pilot for the on-call engineer:

  1. Precedent Retrieval: Executes a search across historical tickets to surface 1 to 3 previous cases that resolved the identical problem, mirroring verified solution patterns.
  2. Context Resolution: Resolves the reporter’s engineering team and organizational hierarchy via the service catalog MCP.
  3. Structured Plan Delivery: Provides the on-call engineer with the matched skill, historical precedent references, and numbered execution steps to complete the task quickly.

3. ESCALATE (Ambiguous or High-Risk Requests)

If the ticket description lacks crucial parameters (e.g. asking for a DNS cutover without specifying the target origin or CNAME value), the agent posts a calm acknowledgment outlining what is missing, while noting the candidate teams and diagnostics for the human assignee.

Persistent Cross-Run Learning with Cursor Automation Memories

One of the fundamental challenges with traditional stateless webhook bots is context amnesia: every invocation starts from scratch with zero recollection of what happened yesterday or even five minutes ago. If an engineer clarifies an unusual network constraint or an obscure domain routing rule on one ticket, a stateless bot forgets it on the next run.

Cursor Cloud Automations solve this by incorporating native Memories.

Inbound Ticket Event ────────> Read Cursor Automation Memories
                                  │ (Ingests durable environment facts,
                                  │  network boundaries, precedent index)
                                  ▼
                             Execute Triage & Plan
                                  │
                                  ▼
Write Back New Learnings ◄──── Extract Durable Patterns
(API limits, unusual targets,   (During ASSIST and Resolution phases)
verified precedents)

How Memory Compounding Works in Practice:

  1. Durable Facts over Transient State: The automation maintains a persistent memory index recording high-leverage architectural patterns: cloud environment identifiers, egress IP rules, provider API rate limits, and cross-repo dependencies.
  2. Continuous Learning Across Runs: When an on-call engineer completes an unusual edge case in ASSIST mode or when a ticket is closed, the automation records a durable memory note. Future runs facing similar tickets instantly retrieve that precedent directly from memory, eliminating repetitive exploratory queries.
  3. Zero Secrets or PII: The agent prompt enforces strict memory hygiene: durable structural patterns and resolution paths are retained, but secrets, credentials, and customer PII are strictly excluded.

Automated Cross-Charge Finance Attribution

One of the most persistent operational headaches for platform teams is cost allocation. Finance often requires every incoming support ticket to be tagged with a specific business unit or department based on the reporter’s actual organization.

Because busy on-call engineers frequently skipped this manual step or guessed incorrectly based on ticket titles, reporting was consistently fragmented.

The Cursor agent automates this entirely:

  1. Ingests the ticket reporter’s user identity.
  2. Queries the service catalog MCP to retrieve the user’s primary team and organizational hierarchy.
  3. Maps the organizational unit against a centralized lookup table.
  4. Automatically updates the business unit metadata via the ticketing API before the engineer even opens the ticket.

Closing the Loop: Continuous Skill Generation on Resolution

When an infrastructure engineer completes a ticket and marks it resolved, the agent triggers a post-resolution learning loop:

  1. It analyzes the final resolution comments, pull requests, and commit diffs.
  2. It compares the resolution path against existing skills in the repository.
  3. If the resolution represents an uncataloged workflow that has occurred two or more times, the agent automatically opens a pull request adding a new SKILL.md recipe to the skills repository.
Ticket Resolved
       │
       ▼
Analyze Resolution Diffs
       │
       ▼
Uncataloged Pattern Observed?
       │
  ┌────┴────────────────────────┐
  ▼ (No / Already Handled)      ▼ (Yes, seen ≥ 2x)
Save to Memory                Auto-Open Pull Request
(Durable Patterns)            with new SKILL.md Recipe

Safety Guardrails That Matter

  1. No Autonomous Status Transitions: The agent is strictly forbidden from transitioning ticket lifecycle states (e.g. moving tickets to in-progress or closed). Workflow state remains 100% human-owned.
  2. No Unsolicited Production Mutations: The bot does not alter live DNS zones, delete storage buckets, or modify IAM permissions directly. It drafts the exact diff or CLI command for a human to review and apply.
  3. Strict Deduplication: The automation inspects its own message IDs to prevent feedback loops when users reply to automated comments.

Key Takeaways

  1. Encode skills before automating agents: An AI intake agent is only as good as its underlying playbook. Having a modular, version-controlled repository of infrastructure skills makes triage deterministic and reliable.
  2. Memory turns stateless bots into learning platforms: Using Cursor Automation Memories allows agents to accumulate durable infrastructure context over time rather than re-discovering the same constraints on every ticket.
  3. Assistive AI beats unconstrained autonomy: By pairing automated classification with human execution, platform teams eliminate triage toil without introducing production risk.
  4. Platform engineering is developer enablement: Instant misroute redirects, pre-computed execution plans, and automated finance attribution turn a chaotic support queue into a predictable, transparent developer service.
← All essays Home