Uday Kandyanam Newark, Delaware

Platform engineering, with LLM agents doing real work.

Senior Software Engineer at UnitedHealth Group, operating Kubernetes platforms across AWS and Azure, building scalable CI/CD systems supporting hundreds of microservices, and putting LLM agents to work for the engineers who run them.

See the work Resume (PDF) GitHub profile

Illustration of a cloud platform: server stacks shaped as a cloud, a delivery pipeline carrying containers, connected cluster nodes, and rising metrics charts
The day job in one picture: clusters, pipelines, and the metrics that prove they work.
10+
Years across Linux, DevOps, and platform engineering
200+
Microservices in platform-wide scope at UnitedHealth Group
70%
Reduction in manual Kubernetes operations through automation
LLM agents
In production for platform teams: issue diagnosis and platform knowledge assistance
01

Independent projects

Original projects built on my own time with public tools and synthetic data. This is the code I can show.

Collect a snapshot, or load one from a file Eight detectors check pods, deployments, and nodes Report, with a diff mode for before and after a fix
Go, Kubernetes tooling

KubePulse

A CLI that reads a snapshot of a Kubernetes cluster and reports what is failing, the evidence behind each finding, and the next step. It can collect a snapshot from a live cluster through kubectl, diagnose it with eight detectors, and diff two snapshots to show what a fix resolved. Diagnose only: it changes nothing in a cluster.

The same engine also runs as an MCP server: KubePulse MCP wraps the diagnose and diff commands as tools an LLM client can call.

ACTUAL OUTPUT · DIFF MODE, RUN ON THE SAMPLE SNAPSHOTS IN THE REPO
$ kubepulse diff examples/healthy.json examples/broken.json
KubePulse diff for demo-cluster
9 new, 0 resolved, 0 unchanged

NEW (9)
  Node node-02: node is reporting MemoryPressure
  Node node-03: node is reporting DiskPressure
  Deployment shop/checkout: rollout is stuck at 1 of 3 updated replicas
  Pod batch/worker-5c7d8e9f6-m4n8q: container worker was OOMKilled (exit code 137) and has restarted 6 times
  Pod shop/api-7849c6f5d9-xk2lp: container api is in CrashLoopBackOff after 14 restarts
  Pod shop/web-6b9d7c4f8-p7r3s: container web cannot pull image registry.example.com/shop/web:v2.4.1 (ImagePullBackOff)
  Pod batch/report-job-8f6e5d4c3-t9w2z: pod has been Pending and cannot be scheduled
  Pod shop/cache-7f8e6d5c4-j6k9m: container cache is using 94% of its memory limit
  Pod tools/debug-shell: containers without resource limits: shell

Code and tests: github.com/UdayKandyanam/kubepulse

GokubectlJSON snapshotsGitHub Actions CI31 tests
Platform question Retrieval over the runbook sections Answer with the file and section cited
Python, retrieval

Runbook Assistant

A question answering tool over a folder of runbooks. It splits runbooks into sections, ranks them with BM25 implemented from scratch, and answers from the text with the file and section cited. When the runbooks do not cover a question, it says so instead of guessing. Ships with seven runbooks, a CLI, and an HTTP API.

Code and tests: github.com/UdayKandyanam/runbook-assistant

PythonBM25FastAPIpytest20 tests
Request with an API key Policy check, then dry run or apply Result, recorded in the audit log
Go, API design

Platform API

A self-service platform API. Application teams get namespace and deployment lifecycle operations through an authenticated API instead of raw cluster access. Every write is scoped to the team's own namespaces, audit logged, and can be dry run first so the caller sees exactly what would change.

Code and tests: github.com/UdayKandyanam/platform-api

GoRESTAPI key authAudit loggingDry runs13 tests
Incident snapshot in Findings, cause scoring, and runbook retrieval Diagnosis with evidence and approval-gated proposals
Python, agents and evaluation

Incident Investigator

A read-only investigator for Kubernetes incidents. It reads a cluster snapshot, scores the likely root cause, and cites the runbook sections behind its diagnosis. It never executes anything: proposed actions are listed as proposals that need human approval, and when the evidence is thin it reports low confidence and names the data that is missing. An evaluation set of eight synthetic incidents scores every change.

ACTUAL OUTPUT · ONE OF THE EIGHT EVALUATION CASES IN THE REPO
$ python -m incident_investigator investigate cases/case-03-oom-killed.json
Case: case-03-oom-killed, Report generator dies on every large export
Diagnosis: oom_killed (confidence: high)
Summary: A container was killed for exceeding its memory limit.

Evidence:
- pod report-generator-7b9c8d6f5-w3n8p container report-generator was OOMKilled on its last exit (restart count 6, memory limit 256Mi)

Runbook sections:
- runbooks/crash-loops.md, section "Checks"
- runbooks/memory-pressure-and-oom.md, section "Fix"

Proposed actions (each one requires human approval):
- Compare the memory limit with the peak usage of the workload and size the limit to the real working set [requires_approval: true]
- Check the hot code path for unbounded caching or whole file loads and cap it [requires_approval: true]

Code and tests: github.com/UdayKandyanam/incident-investigator

PythonLangGraphBM25 retrievalEvaluations34 tests
02

Work

Responsibilities and impact from my current role, described in general terms. The projects above are the hands-on counterpart.

One connected platform at UnitedHealth Group, not a set of side projects: shared platform services, automation, and developer tooling that hundreds of microservices run on. The first two builds below are LLM agents used by platform engineers, the third is the automation layer underneath them, and the systems after that are the portal, data pipeline, and delivery platform they sit on.

Illustration of a chat panel flowing into a cluster of connected services, with a magnifying glass examining log lines
LLM agent · Incident diagnosis

Teams Issue-Diagnosis Agent

Outcome: engineers get a diagnosis with concrete next steps inside the Teams thread where they reported the issue.

When a service misbehaves, the first questions are always the same, and the answers live in five different tools. This agent meets engineers where the conversation already happens, inside Microsoft Teams, and does the gathering for them.

An engineer describes the issue in plain language. The agent pulls the platform context around that service, works through the likely causes, and hands back a diagnosis with concrete next steps, instead of a blank search box and a pile of dashboards.

Ask in Teams

The engineer posts the symptom in Microsoft Teams, in plain language, with the service name. No new tool to learn, no ticket form to fill in first.

Under the hood: a multi-step LangGraph workflow. The agent gathers platform context through platform APIs and observability signals, reasons over what it finds step by step, and replies in the thread.

Safety boundary: the agent diagnoses and recommends. It does not change production systems; engineers review the diagnosis and make any changes themselves.

Tradeoff: a chat surface limits how much raw data can be shown, so the agent hands back a worked diagnosis instead of raw logs. In return, adoption costs nothing: no new tool to learn, no new place to check.

Illustrative example

A synthetic exchange in the shape of a real one. The service name is invented; this is not a transcript.

Engineer: claims-api is failing its health checks since the last deployment. What changed?

Agent: Likely cause: memory pressure after the latest deployment; the platform keeps restarting the service. Context gathered: the recent deployment event, the failing health checks, and the service resource signals. Next steps: compare memory limits with the previous release, roll back if the restarts continue, and work through the service health-check runbook.

KubePulse is a personal project in the same problem space: a Go CLI that reads a cluster snapshot and reports what is failing, the evidence, and the next step.

LLM agentsMicrosoft TeamsPythonPlatform APIsObservability signalsLangChainLangGraphTool calling
Illustration of documents, runbooks, and questions connected by lines and flowing into a single bright answer card
LLM agent · Developer experience

Platform Knowledge Assistant

Outcome: repeat platform questions answered from internal documentation and runbooks, without interrupting a platform engineer.

Platform teams answer the same questions every week: how a service gets onboarded, where a runbook lives, what a pipeline stage is waiting on. The answers exist, scattered across internal documentation, runbooks, and portal pages.

The knowledge assistant answers platform questions directly from that internal material, so engineers get the procedure, the link, and the context in one reply instead of interrupting a platform engineer or digging through search results.

Under the hood: retrieval over internal platform documentation and runbooks. Answers are grounded in that material and come back with the procedure, the source link, and the context, not model guesswork.

  • Grounded in internal sources: answers drawn from platform documentation and runbooks, not model guesswork
  • Built for repeat questions: onboarding, service lifecycle, and how-to questions the team fields daily
  • Part of the platform, not a side demo: maintained alongside the internal developer platform it explains

Runbook Assistant is a personal project built on the same idea: it answers questions from a folder of runbooks and cites the file and section behind each answer.

LLM agentsLangChainLangGraphPythonInternal knowledge bases
Illustration of a hexagonal Kubernetes cluster with gears, circular automation arrows, and a control panel with sliders
Automation · Kubernetes platform

Kubernetes Automation and Platform APIs

Outcome: routine Kubernetes operations became self-service through platform APIs, cutting manual operations by 70%.

Running hundreds of microservices by hand means the same operational tasks repeated daily: provisioning, lifecycle changes, routine cluster operations. Each one is a chance for drift and a slow, manual queue for product teams.

Internal platform APIs, written in Go and Python, turned those recurring Kubernetes operations and service lifecycle tasks into self-service automation that teams call directly.

  • API-first operations: Kubernetes operations and service lifecycle management exposed as internal platform APIs
  • Go and Python automation: the tooling layer platform and product teams build on
  • Production support: deployments, CI/CD, and troubleshooting for Java applications, including Spring Boot microservices on Kubernetes

Tradeoff: the platform team owns an API surface and its support instead of a ticket queue. In return, routine work became consistent and repeatable across teams.

70%

Reduction in manual Kubernetes operations, with the routine work absorbed by automation instead of engineers.

GoPythonKubernetesAWSAzureTerraformArgo CDGitOps
03

Platform work

The surrounding systems at UnitedHealth Group that the agents and automation sit on top of.

Internal Developer Platform Portal

UNITEDHEALTH GROUP

Outcome: engineers start from one portal per service instead of hunting across separate tools.

Built the UI for an internal platform tool that brings everything about a service into one place: the security portal, the GitHub repository list for each service, a vulnerability dashboard, and the application and platform information engineers otherwise hunt across tools.

One portal per service means one starting point for ownership, security posture, and platform status.

Event-Driven ETL for the Developer Dashboard

UNITEDHEALTH GROUP

Outcome: the developer dashboard stays current as repository and deployment events happen, rather than by manual inventory.

An event-driven pipeline in Python and Go that consumes GitHub repository creation and application deployment events, transforms the operational metadata, and loads it into PostgreSQL.

The pipeline powers the internal developer dashboard, keeping service and deployment data current as events happen rather than by manual inventory. The tradeoff is operating a pipeline that has to stay reliable, where a scheduled job would be simpler to run.

CI/CD Standardization and Dynatrace Migration

UNITEDHEALTH GROUP

Outcome: standardized CI/CD and a completed observability migration, recognized in recommendations from the Principal Engineer and Director on the team.

Standardized CI/CD across services and migrated observability to Dynatrace SaaS across hundreds of services, work recognized in LinkedIn recommendations from the Principal Engineer and Director on the team.

Also part of the platform-wide remit: SLOs and SLIs, error budgets, operational readiness reviews, release quality gates, and 24/7 on-call for the platform.

Service Mesh, Control Planes, and Telemetry

UNITEDHEALTH GROUP

The rest of the platform plumbing: Istio for service mesh traffic management and policy, Crossplane for provisioning cloud resources through Kubernetes, OpenTelemetry instrumentation and collectors alongside the Dynatrace migration, and Splunk searches for log investigation during incidents and on-call.

"On our team he standardized CI/CD delivery across more than 100 microservices and led the migration of over 100 services from self-hosted Dynatrace to Dynatrace SaaS."

WILLIAM SPENCER · PRINCIPAL ENGINEER, UNITEDHEALTH GROUP

"His work included driving cloud cost optimization, supporting our Dynatrace cloud migration, improving CI/CD capabilities across 100+ microservices, and developing vulnerability dashboards that strengthened security visibility."

SAJI MATTAMANA · DIRECTOR, PLATFORM ENGINEERING, UNITEDHEALTH GROUP

Full recommendations on LinkedIn.

Four principles run through the work above: build reusable capabilities instead of one-off fixes; design for real operational conditions, with failure handling and observability as part of the design; keep intelligent systems grounded, with a clear boundary between model reasoning and operational execution; and treat developer experience as an engineering outcome, not a by-product.

04

Timeline

A decade moving from Linux administration into DevOps, DevSecOps, and platform engineering, with AI platform work layered on top in the current role.

Jun 2023 to Present
Senior Software Engineer · UnitedHealth Group
Horsham, PA

Kubernetes platforms on AWS and Azure, CI/CD for hundreds of microservices, internal platform tooling, and production LLM agents for platform teams.

Jun 2021 to Jun 2023
DevOps Engineer · Best Buy
Remote

CI/CD with Jenkins and Azure DevOps. CI/CD for 50+ applications; automated provisioning cut provisioning time by 70%.

Aug 2018 to May 2021
DevSecOps Engineer · AIG
Charlotte, NC

DevSecOps and cloud infrastructure, including CloudFormation. Release cycles down 40% through application and database automation; SSO integrated across the DevOps tooling.

Jan 2014 to Aug 2015
Linux Administrator · O2 Technologies, Inc
India

Linux systems administration, the foundation everything since builds on.

EDUCATION · M.S., Wilmington University (Jun 2018) · B.Tech., JNTU (2014)   |   CERTIFICATIONS · GenAI and Predictive AI Architecture Foundations · Advanced RAG with Vector Databases · AWS Certified Solutions Architect (Associate) · Certified Kubernetes Administrator (CKA)

05

Skills

Grouped the way the work actually breaks down.

▸ Platforms and cloud

Kubernetes platform operations at scale across two clouds, including service lifecycle management and GitOps delivery.

KubernetesAWSAzureAKSIstioCrossplaneArgo CDGitOps

▸ AI and LLM agents

Production LLM agents for platform teams: issue diagnosis in Teams and a knowledge assistant over internal platform material.

LLM agentsLangChainLangGraphMCPPythonFastAPI

▸ Automation and IaC

Go and Python automation and platform APIs, with infrastructure as code across AWS and Azure estates.

GoPythonTerraformCloudFormationAnsiblePowerShellPostgreSQL

▸ Reliability and delivery

CI/CD standardization, observability migrations, and the reliability practices that keep hundreds of services healthy.

CI/CDJenkinsGitHub ActionsAzure DevOpsDynatraceSplunkOpenTelemetrySLOs / SLIsError budgets24/7 on-call

Talking about a platform, DevOps, SRE, or AI platform role?

The fastest way to see the work is the projects and case studies on this page. For roles, email is best: a short note about the team and the stack is plenty to start.

Email Uday github.com/udaykandyanam linkedin.com/in/udaykandyanam Resume (PDF)