platform-agent
Your always-on platform engineer — from service provisioning to incident resolution.
AWS-native platform agent that covers both Day 1 and Day 2 workflows:
provision infrastructure, validate deployments, track service health, and respond to incidents.
Status: personal research project, not a product. Some paths have been run end to end against
real infrastructure, others are implemented and unit-tested only — see
Verification status and Known limitations.
The current, dated state lives in docs/STATUS.md.
Slack / Jira / GitHub / Alarm
→ Router Agent
→ Provisioning Agent (CDK + IAM + cost estimate)
→ Deployment Agent (smoke test + canary + rollback)
→ Operations Agent (detect + analyze + decide + execute)
→ Guardian Agent (policy-as-code gatekeeper)
Multi-Cloud AI Deployment Platform
Natural Language Request
→ Strands Agent (AWS — Bedrock Claude)
→ ADK Agent (GCP — Gemini 3.5 Flash)
→ MS Agent Framework (Azure — AI Foundry)
→ On-Prem Agent (On-Prem — local Qwen3-Coder-30B-A3B via MLX, or an API key)
→ Guardian Agent (Policy: APPROVE / AUTO / REJECT)
→ E2E Pipeline DAG (plan→guard→build→push→deploy→validate→report)
Why this exists
Most AWS tooling solves only one slice of the platform lifecycle. platform-agent connects the full loop.
| Tool | What it does |
|---|
| PagerDuty / OpsGenie | Pages a human |
| CloudWatch Alarms | Emits an incident signal |
| Internal platform scripts | Provision or deploy one step at a time |
| platform-agent | Provisions → validates deploys → tracks SLOs → responds to incidents |
Architecture
Slack / Jira / GitHub / Alarm
│
▼
Router Agent + Overnight Harness
│
├─ Provisioning Agent
│ CDK generation, IAM design, cost estimation
│
├─ Deployment Agent
│ Smoke test, canary analysis, rollback decision
│
└─ Operations Agent
Detector → Analyzer → Decision → Executor
CloudWatch Logs/X-Ray → Bedrock RCA → SSM/Slack
Key service choices (SAP-aligned):
- Step Functions over SWF — serverless orchestration, visual debugging, native CDK integration
- EventBridge over SNS — event pattern filtering across alarms and scheduled flows
- Bedrock over external LLM API — IAM-authenticated reasoning without extra egress
- SSM Automation over direct Lambda execution — audit trail, approval gates, reusable runbooks
- CDK (TypeScript) over raw templates — consistent Day 1 provisioning output
More detail: docs/ARCHITECTURE.md · flow walkthrough: GUIDE.md (Korean).
Supported alarm types (built-in runbooks)
| Alarm type | Runbook | Auto actions |
|---|
| EKS pod OOM / restart loop | eks-pod-oom | Restart pod → Scale node group |
| Lambda throttling | lambda-throttle | Increase reserved concurrency |
| RDS CPU high | rds-cpu-high | Scale instance → Add read replica |
| Kafka consumer lag | kafka-lag-spike | Scale consumer group → Rebalance |
| Disk full | disk-full | Cleanup disk → Expand volume |
| Health check failure | health-check-failure | Restart workload → Rollback release |
| Certificate expiry | certificate-expiry | Renew certificate → Notify ops |
| Network latency high | network-latency-high | Drain node → Scale out |
| Any other alarm | generic-recovery | Slack alert only |
Runbooks are capability-based (src/agents/runbooks/catalog.py), so the same plan resolves to
provider-specific actions. Custom runbooks can be registered in DynamoDB (incident-runbooks table);
deployments seed the built-in catalog into that table by default.
Scheduled reporting jobs generate daily SLO summaries, weekly on-call reports, and monthly capacity recommendations.
Remediation modes
| Severity | Mode | Behaviour |
|---|
| P1 | AUTO | SSM executes immediately, polls to completion |
| P2 | APPROVE | Slack interactive approval request sent, Step Functions waits up to 1h |
| P3 | MANUAL | No execution — incident recorded, Slack notified |
Safety override: any action containing Delete, Drop, or Terminate is forced to APPROVE regardless of severity.
Notification-type actions run in-process in the executor rather than as SSM documents
(D17).
Key features
1. Keyless federation (OIDC)
Long-lived cloud keys are avoided where the code path allows it.
- Dashboard → AWS: the Vercel-hosted dashboard reads and writes AWS through Vercel OIDC
(no AWS keys stored on Vercel). Exercised live, including a dashboard-triggered deploy.
- AWS → GCP (WIF) and AWS → Azure (federated token exchange): credential modules exchange
AWS STS identity for short-lived Google / ARM tokens. Implemented and unit-tested; not yet proven
against tenant-bound live credentials (STATUS Risk 10).
2. Multi-region failover (implemented, not drilled)
The remediation executor retries in a standby location when the primary fails:
AWS_FAILOVER_REGION for SSM, GCP_FAILOVER_CLUSTER_NAME for GKE / Cloud Run,
AZURE_FAILOVER_CLUSTER_ID for AKS / Function Apps. Covered by unit tests; no live regional
failover drill has been run.
This is the beginning of the README. Read the rest at the original. Read the full README ↗
