Portfolio · Case Study

Diego S.
Diego S.
AI Engineering Agentic Systems LLM Orchestration DevOps Automation
Education
Florida International University
BS · Computer Science
Florida International University
MBA · Marketing & E-Commerce
Pennsylvania State University
Master of Applied Statistics
Available now
Expert-VettedExpert-Vetted
Top RatedTop Rated
100%Job Success
Case Study
Agentic Support
Ticket Triage
Agentic Platform Build
Engineering Operations
< 10s
Phase A ticket classification
2.4 min
Phase B investigation to Jira
3
Agentic phases
01 · 09
Project overview
Key project facts
Platform
Agentic Triage System
Domain
Engineering Operations
Engagement type
Agentic Platform Build
Deployed
In production · internal tooling
Scope
Classify · Investigate · Approve · Implement
Technical stack
Node.js Express Claude Code SDK Anthropic Claude Jira REST API Mem0 Slack GitHub LLM Tool Use Webhook Listener
Engagement summary

A two-phase agentic system for automated engineering support ticket triage. When a Jira ticket is created, a webhook triggers Phase A — a fast LLM classifier (~6 seconds) that routes the ticket to the correct project and repository. Phase B launches a Claude Code investigation agent inside the target repo (~2.4 minutes), reading CLAUDE.md, tracing relevant files, checking git history, and producing a structured root cause analysis with a proposed fix. A human-in-the-loop approval gate sits between diagnosis and Phase C, where a dev agent implements the approved fix and opens a pull request. A Mem0 learning loop captures HITL corrections, PR outcomes, and CI failures to continuously improve future investigations.

< 10s
Phase A Classification
One-shot Claude call with slim project registry — routes ticket to correct repo
2.4 min
Phase B Investigation
Full codebase analysis, Mem0 context injection, structured Jira report
3
Agentic Phases
Classify (Phase A) · Investigate (Phase B) · Implement (Phase C)
02 · 09
Technical Design · Agentic Support Ticket Triage
End-to-End Triage Pipeline
Two-Phase + HITL + Dev Agent
1
Jira Webhook
POST /webhooks/jira
Jira fires on issue_created · agent responds 200 OK immediately · processing is async
async · port 9200
~0s
2
Phase A — Classification
Claude Code · Slim Registry
One-shot call with slim project registry · matches reporter email domain + keywords · returns structured JSON
~6s
~6s
JSON output
project_id repo issue_type severity summary
3
Phase B — Deep Investigation
Claude Code · Triage Subagent
Runs in target repo · reads CLAUDE.md + relevant files + git log · injects Mem0 context · produces structured report
~2.4 min
~2.4 min
4
Human in the Loop
Approval Gate
Slack notification with diagnosis + proposed fix · human approves, edits, or rejects · timeout = auto-approve · corrections stored as learning signal
Slack · async
5
Phase C — Implementation
Claude Code · Dev Agent
Implements approved fix in repo · runs tests · opens PR · posts PR link back to Jira ticket
~variable
~variable
6
Output
PR + Jira Update
Pull request opened in target repo · Jira comment updated with PR link and implementation summary
GitHub · Jira
~end
Why Two Phases

Phase A is cheap — a 6-second classifier that routes the ticket to the right repo. Phase B is expensive — 2.4 minutes of full codebase investigation. Separating them means a misclassification costs 6 seconds to catch, not 2.4 minutes. The HITL gate sits between diagnosis and implementation: the most expensive mistake is a code change, not a classification.

Key Decisions
Async response to Jira — webhook returns 200 immediately; all investigation runs in the background, preventing Jira timeout.
HITL gate before Phase C only — classification errors are low-stakes; a code change is high-stakes. Human approval is scoped to the right risk.
Timeout auto-approve — off-hours tickets don't block indefinitely; critical-severity tickets bypass the gate entirely.
03 · 09
Technical Design · Agentic Support Ticket Triage
Feedback & Learning Loop
Mem0 · Three Signal Types
HITL
Signal
Human edits fix
approval gate delta
→
Mem0 write
project + issue_type key
→
Phase B injection
next similar ticket
PR
Signal
PR merged / closed
reviewer feedback
→
Mem0 write
repo + approach + outcome
→
Phase C injection
implementation patterns
CI
Signal
Tests fail
Phase C output
→
Phase C retry
same ticket loop
→
Mem0 write
failure pattern logged
Tight loop — Phase C retries before human sees it
Mem0
Store
Prior investigations
searchable by project+keyword
·
Fix patterns
what got approved/rejected
·
Repo conventions
per-repo learnings
·
Failure modes
CI patterns
How Mem0 Is Used

Each signal type writes a different category of memory. At the start of Phase B, the agent searches Mem0 for the project and ticket keywords — returning relevant prior investigations, known repo quirks, and fix patterns that worked. At Phase C, the agent retrieves implementation-level memories: which approaches were rejected in PR review and why.

Signal Categories
HITL corrections — highest quality signal. When a human edits the proposed fix, the delta is stored verbatim. These shape Phase B's next proposal for similar issues.
PR outcomes — lagging signal but most accurate. A merged PR confirms an approach worked; a closed PR with reviewer feedback is the best negative example.
CI failures — tight loop signal. Phase C retries immediately on test failure, then logs the failure pattern so future implementations avoid the same mistake.
04 · 09
Technical Design · Phase C
Isolated Execution Environment
Devcontainer · Git Worktree · In-Container CI
1
Trigger
HITL Approval → Agent Dispatch
Human-approved plan fires dispatch signal · target project identified from Phase A classification · dev agent session initialized
async dispatch
~0s
2
Environment
Target Devcontainer
Dedicated Docker devcontainer per project on bare-metal Hetzner · isolated filesystem, ports, and dependencies · no cross-project contamination
Docker · Hetzner
~2s
3
Version Control
Git Worktree · Isolated Branch
git worktree add creates an isolated working tree on a new branch · main is never touched · multiple agents can work concurrently on separate branches
git worktree
~1s
4
Code Changes
Claude Code Dev Agent
Implements approved fix within the worktree boundary · reads CLAUDE.md for repo conventions · makes targeted changes to identified files only
claude-code
~variable
5
In-Container Testing
Test Suite Validation
Tests run inside the devcontainer — same runtime and dependencies as production · fast feedback loop before any human review
in-container
~variable
Outcome routing
Tests pass → PR opened · Jira updated Tests fail → Phase C self-correction retry
6
Promotion
Pull Request + Jira Update
PR opened from worktree branch · Jira ticket updated with PR link · worktree cleaned up · ready for human code review and merge
GitHub · Jira
~end
Why Isolated Workspaces

Each project has a dedicated devcontainer — its own filesystem, ports, and dependency stack. When the dev agent is dispatched, it enters that container's boundary. Changes stay isolated until a PR is opened and reviewed. There is no risk of one agent's work affecting another project or touching the production branch.

Key Decisions
Git worktree over clone — creates an isolated working tree on a new branch without a full repo clone. main is always clean; the agent cannot accidentally push to it.
In-container test validation — tests run inside the same devcontainer environment as production builds. A passing suite is a strong signal before the PR goes to human review.
Worktree cleanup on PR — after the PR is opened, the local worktree is removed. The branch lives in the remote; the container stays clean for the next task.
05 · 09
Jira ticket with TriageAgent investigation comment
01 / 04 Agentic Support Ticket Triage · Deliverable
Jira: Investigation
Report

Phase B's structured investigation lands directly in the ticket as a TriageAgent comment — the same surface the team already uses.

What this screen does
Structured comment format
Classification, root cause, affected files, proposed fix, risk, and complexity — every report uses the same template.
In-context investigation
The agent reads the ticket, traces the codebase, and posts findings without leaving Jira.
File-level precision
Affected files are listed with line ranges so a reviewer can jump straight to the code.
Approval actions inline
Approve, edit, or reject the proposed fix right from the comment — no separate tool to open.
Node.js · Express · Claude Code SDK · Anthropic Claude · Jira REST · Mem0 · Slack · GitHub Actions Illustrative UI · representative data
06 · 09
Slack channel with bot alert and approval buttons
02 / 04 Agentic Support Ticket Triage · Deliverable
Slack: HITL
Approval

Every Phase B finding fans out to Slack as a structured card — humans approve or override in two taps without opening Jira.

What this screen does
Block Kit summary card
Root cause, files to change, and estimated effort surfaced at a glance.
Three-button decision
Approve & dispatch, edit, or reject — the human's choice is one click.
Sources visible
The ticket, the file path, and the Mem0 patterns the agent used to score this fix.
Threaded approval trail
The decision (approved / rejected / edited) lands as a reply, so the audit log lives in the channel.
Node.js · Express · Claude Code SDK · Anthropic Claude · Jira REST · Mem0 · Slack · GitHub Actions Illustrative UI · representative data
07 · 09
Mem0 dashboard showing accumulated triage learnings
03 / 04 Agentic Support Ticket Triage · Deliverable
Mem0: Learning
Loop

Every HITL correction, PR outcome, and CI failure writes back to Mem0 — the agent gets better at the next ticket without retraining.

What this screen does
Three signal types
HITL corrections, PR outcomes, and CI failures are tracked separately and filterable.
Tagged + retrievable
Every memory carries a project/component tag so the right patterns get pulled for the right ticket.
Relevance scored
Each memory shows a relevance score; the highest-relevance ones get injected into the next Phase B run.
Usage tracking
"Used 4× by Phase B" makes it explicit which memories are shaping the agent's behavior — the learning loop is auditable.
Node.js · Express · Claude Code SDK · Anthropic Claude · Jira REST · Mem0 · Slack · GitHub Actions Illustrative UI · representative data
08 · 09
GitHub PR opened by the dev agent with green CI
04 / 04 Agentic Support Ticket Triage · Deliverable
GitHub:
Phase C PR

Once approved, the dev agent implements the fix in an isolated worktree, opens a PR, and runs the test suite — the reviewer sees the result, not the process.

What this screen does
PR opened by the agent
Dedicated triage-agent bot account branches, commits, and opens the pull request.
Auto-linked to the ticket
The PR description closes the originating Jira issue and references the investigation comment.
CI green before review
Phase C runs tests inside its devcontainer; the reviewer only sees PRs where the suite already passed.
Human-readable diff context
Description summarizes the change, the test added, and the manual verification — ready for a fast sign-off.
Node.js · Express · Claude Code SDK · Anthropic Claude · Jira REST · Mem0 · Slack · GitHub Actions Illustrative UI · representative data
09 · 09