DEV Community: Ajit

I Used an AI "Skill" to Audit My CloudFormation Stack — Found a Broken Alarm Running for 3 Months

Ajit — Wed, 06 May 2026 05:30:43 +0000

TL;DR

Kiro CLI has a feature called "skills" — domain-specific expertise packages you can load on demand. I loaded the aws-cloudformation skill to validate my production Spot Fleet template. It found 4 critical issues including a CloudWatch alarm that literally never worked.

Situation

I run a development environment on AWS Spot instances — Kiro CLI, VS Code Server, persistent EBS, the works. The CloudFormation stack has been deployed since February 2026. It's been updated once, runs daily, and I considered it production-ready.

I was about to upgrade stack and wanted to validate my base template first.

Task

Verify whether my "security-hardened" template actually follows CloudFormation best practices before using it as the foundation for upgrade.

Action

Step 1 — Discover the skill:
search_documentation("CloudFormation deployment", topics=["agent_skills"])

This returned 5 relevant skills. I picked aws-cloudformation.

Step 2 — Load the skill:
retrieve_skill("aws-cloudformation")

What I got back wasn't generic advice. It was:

A structured 10-step authoring checklist
3-layer validation pipeline (syntax → security → pre-deploy)
Troubleshooting SOPs for failed stacks
Decision frameworks for template vs environment fixes

Step 3 — Load the reference SOP:
retrieve_skill("aws-cloudformation", file="references/author-cloudformation-best-practices.script.md")

This gave me the detailed checklist: resource naming, parameter design, security defaults, deletion policies, cross-stack references, conditions, outputs.

Step 4 — Apply it to my template:

I asked Kiro CLI to review CFN yaml against the skill's checklist.

Result

4 critical, 5 recommended, 1 strict finding.

Here's what hit hardest:

🔴 Critical #1: Broken CloudWatch Alarm (3 months undetected)

yaml
HighCPUAlarm:
Dimensions:
- Name: InstanceId
Value: !Ref SpotFleetRequest # ← This is a Fleet ID, not an Instance ID

My "cryptomining detection" alarm was monitoring a dimension that doesn't exist. It never evaluated. Never fired. I had zero protection for 3 months while thinking I was
covered.

Fix: Reference the actual instance ID (requires a Lambda or instance self-registration pattern since Spot Fleet instances are dynamic).

What Are "Skills" Exactly?

They're not prompts. They're not RAG documents. They're structured domain expertise packages containing:

Component	What it does
Workflows	Step-by-step procedures with decision points
Checklists	Deterministic validation (like the 10-step authoring review)
SOPs	Standard operating procedures for troubleshooting
Decision trees	"If X, do Y; if Z, do W" frameworks
Reference files	Architecture docs, schemas, examples

The CloudFormation skill has SOPs for:

Authoring with secure defaults
3-layer pre-deployment validation (cfn-lint → cfn-guard → change set)
Troubleshooting failed stacks (using describe-events --filters FailedEvents=true)
Resource property lookup

Key insight: The skill told me to use describe-events (newer API with filter support) instead of describe-stack-events (legacy, no filters). I didn't know this API existed.

How to Use Skills in Kiro CLI

bash

1. Search for relevant skills

(you can't guess skill names — they must be discovered)

search_documentation("your task description", topics=["agent_skills"])

2. Load the skill

retrieve_skill("exact-skill-name-from-search")

3. Load reference files if the skill links to them

retrieve_skill("skill-name", file="references/some-sop.md")

4. Apply — ask the AI to use the loaded expertise

"Review my template against the authoring checklist"
"Troubleshoot my failed stack using the SOP"
"Validate before I deploy"

Available skills I found:

aws-cloudformation — authoring, validation, troubleshooting
launching-ec2-instance-with-best-practices — secure EC2 launches
creating-production-vpc-multi-az — VPC design
creating-ec2-image-builder-pipeline — AMI automation
aws-cdk — CDK patterns and deployment

Lessons Learned

"It works" ≠ "It's correct." My stack ran fine for 3 months with a broken alarm. Functional doesn't mean secure.
Validate infrastructure like you lint code. We wouldn't ship code without tests. Why do we ship CloudFormation without a structured review?
AI skills > AI chat. A general "review my template" prompt gives generic advice. A loaded skill applies a deterministic, comprehensive checklist. The difference is like
asking a random person vs. asking a CloudFormation specialist with a clipboard.
The scariest bugs are silent ones. A broken alarm doesn't throw errors. It just... doesn't protect you.

The skill doesn't just find problems — it prevents them in new templates.

The Model Is the Brain. The Harness Is the Body. Here's Why That Matters

Ajit — Mon, 04 May 2026 05:18:31 +0000

TL;DR: I built the same browser agent twice — once with 500 lines of Python, once with 7 lines of JSON. The second one took 5 minutes. The agent harness layer is becoming the real competitive advantage, not the model.

Last month, I built a browser automation agent. Playwright. Custom orchestration. Login handlers. Error retries. Session management. React-aware form filling. Anti-detection scripts. 500+ lines of Python.

This week, I built the same thing:

{
  "model": { "provider": "bedrock", "modelId": "us.anthropic.claude-sonnet-4-6" },
  "tools": [{ "type": "agentcore_browser", "name": "browser" }],
  "systemPrompt": "You are a web browsing assistant."
}

Deploy. Invoke. It browses websites, extracts data, fills forms. Seven lines. Zero orchestration code.

But here's the thing most people miss: I kept both versions. And that's the real insight.

What Changed (and What Didn't)

	500-Line Script	7-Line Harness
What it does	Automates a specific multi-site workflow	Browses any website, extracts info
How it decides	I wrote every step	AI decides the steps
Cost per run	$0 (Playwright, local)	~$0.10-0.50 (Bedrock tokens)
Reliability	95%+ (deterministic)	~80% (AI reasoning varies)
Flexibility	Only does what I coded	Handles any browsing task
Time to build	3 days of debugging	5 minutes

The 500-line script is better for its specific job. It runs faster, cheaper, and more reliably. Because it doesn't need AI — the steps are known.

The 7-line harness is better for everything else. Research tasks. Data extraction from unfamiliar sites. Competitive analysis. Anything where the steps aren't known in advance.

This is my POV: deterministic + AI is the right architecture. Don't use a $0.03/call model to click a button you can click with Playwright for free. But don't write 500 lines of Playwright when 7 lines of config can handle it.

The Harness Is the New Battleground

Everyone's talking about which model is best. Claude vs GPT vs Gemini. Benchmarks. Context windows. Reasoning scores.

That conversation is becoming irrelevant.

Models are commoditizing. Claude Sonnet 4.6 and GPT-5.5 are both "good enough" for most agent tasks. The real question is: what wraps around the model to make it actually work in production?

That's the harness — the orchestration loop, tool execution, memory, security, compute isolation. And every cloud provider is racing to own it:

Provider	Harness Product	Status
AWS	AgentCore Harness	Preview (Apr 2026)
AWS	Bedrock Managed Agents (OpenAI-specific)	Limited Preview
Google	Gemini Enterprise Agent Platform	GA (Apr 2026)
Microsoft	Azure AI Agent Service	GA
Salesforce	Agentforce	GA

This is the container orchestration war all over again. In 2015, everyone had containers. The question was who manages running them. Kubernetes won, and whoever controlled K8s controlled where workloads ran.

In 2026, everyone has models. The question is who manages running agents. Whoever controls the harness controls the next decade of cloud spend.

How AgentCore Harness Works

You (prompt) → AgentCore Harness → Bedrock Model (reasoning)
                    ↓                      ↓
              Firecracker microVM    Tool selection
              (isolated per session)       ↓
                    ↓              AgentCore Browser / Shell / Code
              Persistent memory    
              (across sessions)    
                    ↓
              Streamed response → You

What AWS handles: compute, orchestration loop, tool invocation, memory, auth, observability.
What you handle: a JSON config and a prompt.

Each session runs in its own Firecracker microVM — the same isolation technology behind Lambda. Not a container. A VM. One session can't see another's data, cookies, or credentials.

Getting Started (I Actually Ran This)

# Install CLI
sudo npm install -g @aws/agentcore@preview

# Create project
agentcore create --name browseragent --model-provider bedrock
cd browseragent

# Add browser tool
agentcore add tool --harness browseragent --type agentcore_browser --name browser

# Set target account + region
# Edit agentcore/aws-targets.json: [{"name":"default","region":"us-west-2","account":"YOUR_ACCOUNT"}]

# Deploy (~3 min)
agentcore deploy --yes

# Use it
agentcore invoke --harness browseragent --stream \
  --prompt "Go to example.com and describe what you see"

Output from my actual run:

🔧 Tool: browser
⚡ 6005 in · 110 out · 2.2s
Here's what's on the page at example.com:
### Example Domain
The page contains: "Example Domain" heading, body text about documentation use,
and a "Learn more" link to IANA documentation.

Real. Not a demo. Not a screenshot from someone else's blog.

Production Considerations

Area	What I Found
Cost	No harness charge. You pay for Bedrock tokens + Browser session time
Regions	us-west-2, us-east-1, eu-central-1, ap-southeast-2 (preview)
Models	Any Bedrock model, plus OpenAI and Gemini. Switch mid-session
Security	Firecracker microVM isolation, IAM execution role, Cedar policies
Limitation	Preview — not for production workloads yet

⚠️ Gotcha I hit: The harness execution role needs bedrock:Converse and bedrock:ConverseStream permissions, plus aws-marketplace:ViewSubscriptions for 3P models. The default CDK policy only includes bedrock:InvokeModel. I had to add permissions manually.

When NOT to Use Harness

Deterministic automation (same steps every time) → Playwright. Cheaper, faster, more reliable.
Complex multi-agent workflows → Strands Agents SDK with AgentCore Runtime. More control.
Existing framework investment (LangChain/CrewAI) → Use AgentCore tools standalone.
Production workloads → Wait for GA. It's preview.

Bottom Line

The model is the brain. The harness is the body. Most teams are spending all their time picking the brain and hand-building the body from scratch every time.

AgentCore Harness lets you stop building bodies and start building solutions. For 80% of agent use cases, config beats code. For the other 20%, write code — but use the harness infrastructure underneath.

The teams still hand-coding agent orchestration loops are building technical debt. The same way teams hand-coding REST APIs built technical debt before API Gateway existed.

The question isn't whether to adopt managed agent infrastructure. It's whether you'll be building on it — or competing against someone who already is.

Ajit NK — AWS Community Builder, APN FasTrack Partner. Building AI agent solutions at CloudNestle.
"The model is the brain. The harness is the body. I build the body."

📚 Sources:

How I Track 44 New AWS Repos Per Week Automatically with EventBridge, Bedrock, and FAISS

Ajit — Wed, 01 Apr 2026 09:38:28 +0000

AWS publishes new sample repos almost daily — reference architectures, agent patterns, CDK constructs, security blueprints — spread across 5 different GitHub organizations.

Most developers never see them until weeks later.

I built a system that catches them the same day. Here's how.

The Problem

AWS maintains 9,657+ repos across these orgs:

aws-samples (8,044 repos)
awslabs (992 repos)
aws-ia (234 repos)
aws-solutions (153 repos)
aws-solutions-library-samples (234 repos)

When AWS publishes a new repo — say, a production-ready Bedrock AgentCore sample or a CDK construct for EKS — it's buried. GitHub search doesn't surface it. Google takes days to index it. By the time you find it, someone else already built on it.

The Solution: Auto-Indexing Pipeline

I built AWS Solution Finder with a twice-daily auto-indexing pipeline that detects and classifies new repos automatically.

Architecture

EventBridge (cron: 2 AM + 2 PM UTC daily)
↓
5 separate rules (one per org)
↓
Indexer Lambda (Docker, Python 3.12, 3GB, 15-min timeout)
↓
For each org:

Fetch ALL repos from GitHub API (paginated)
Compare with master index in S3 → find NEW + REMOVED repos
Classify new repos with Bedrock Nova Pro (22 metadata fields)
Generate Titan Embed v2 embeddings (1024-dim)
Incrementally update FAISS index
Save to S3 + publish new Lambda version
Write run record to DynamoDB

The 22 Metadata Fields

Every repo gets classified by Bedrock Nova Pro:

Solution type, competency area, AWS services used
Primary/secondary language, deployment tools
Cost range, setup time, complexity
Business value, target audience, freshness status
Agentic capabilities (yes/no/partial)
And more

This is what makes search actually useful — you're not just matching keywords, you're matching intent against structured metadata.

Safety Guards

If >50% of repos would be removed in a single run → blocked (likely GitHub API error)
If GitHub returns 0 repos → master index NOT updated
Ghost repo detection: repos in FAISS but not on GitHub get cleaned up
Rate limiting on GitHub API calls (1 sec between classifications)

The New Feature: "New Repos This Week"

Today I shipped a badge on the search page showing repos added in the last 7 days:

🆕 44 new repos this week
Grouped by org (aws-samples, awslabs, etc.)
Direct GitHub links for each
Rolling 7-day window, updated twice daily

This gives users a reason to come back daily — not just when they need to search.

Tech Stack

Layer	Technology
Scheduling	Amazon EventBridge (5 rules, twice daily)
Compute	AWS Lambda (Docker, Python 3.12, 3GB)
AI Classification	Amazon Bedrock Nova Pro
Embeddings	Amazon Bedrock Titan Embed v2 (1024-dim)
Vector Search	FAISS (IndexFlatL2, in-memory)
Storage	Amazon S3
Audit Trail	Amazon DynamoDB
IaC	AWS CDK (TypeScript)

Total cost for the indexing pipeline: almost nothing. The Lambda runs for ~5 minutes twice a day. Bedrock calls are only for NEW repos (not re-classifying existing ones).

Try It

The 🆕 badge is live now. Free to try — 3 searches without registration.

→ awssolutionfinder.solutions.cloudnestle.com/search

What AWS repos have you discovered recently that more people should know about?

Built by Ajit NK — AWS Community Builder (Dev Tools). Building AI-powered developer tools at CloudNestle.

How I Search 10,000+ AWS GitHub Repos in 10 Seconds

Ajit — Tue, 31 Mar 2026 12:51:14 +0000

The Problem

Every AWS developer knows this pain: you need a reference architecture or sample code, and you end up with 47 browser tabs open across GitHub, AWS docs, Stack Overflow, and random blog posts from 2019.

GitHub search gives you 2,000 results with zero context. ChatGPT confidently hallucinates repos that don't exist. Stack Overflow answers are outdated.

What I Built

I built an AI-powered search engine that indexes 10,000+ repos from AWS's official GitHub organizations:

aws-samples: 8,031 repos
awslabs: 993 repos
aws-solutions-library-samples: 315 repos
aws-ia: 234 repos
aws-solutions: 72 repos

How It Works

The search uses a hybrid approach:

70% BM25 (keyword matching) — catches exact AWS service names
30% FAISS (semantic vector search) — understands what you mean, not just what you type

Each repo is classified by Amazon Bedrock (Nova Pro) across 22 metadata fields: solution type, AWS services used, complexity, freshness, setup time estimate, and more.

Auto-indexed twice daily via EventBridge — new AWS repos are searchable within 12 hours.

Tech Stack

Amazon Bedrock (Nova Pro) for AI classification
FAISS with Titan Embed v2 (1024-dim) for vector search
AWS Lambda (Docker, Python 3.12)
API Gateway
DynamoDB for usage tracking
CloudFront + S3 for frontend
EventBridge for scheduled indexing
AWS CDK (TypeScript) for infrastructure

Key Architecture Decisions

Why hybrid search over pure vector?
AWS service names are precise — "Lambda" means something specific. Pure semantic search sometimes returns "serverless compute" results when you specifically want Lambda. BM25 catches exact matches, FAISS catches intent. The 70/30 split was tuned through testing.

Why FAISS over OpenSearch?
Cost. OpenSearch Serverless has a minimum cost that runs 24/7. FAISS on Lambda + S3 costs under $6/month for the search component. For a bootstrapped product, that matters.

Why 22 metadata fields?
Developers don't just want to find a repo — they want to know: Is it maintained? How complex is it? What AWS services does it use? How long will setup take? Nova Pro classifies each repo across all 22 fields automatically.

What I Learned

Hybrid search beats pure vector for domain-specific queries
FAISS on Lambda is surprisingly cost-effective
The 22-field classification is what makes results actually useful — not just the search itself
Auto-indexing twice daily keeps results fresh without manual work

Try It

Free to use — 3 searches without registration, 10 per day with a free account.

AWS Solution Finder

What's Next

Exploring ways to improve relevance scoring and add more metadata fields. If you've worked with FAISS or hybrid search, I'd love to hear your approach.

Built solo by an AWS Community Builder. Questions? Drop a comment.

# Building a Mobile AI Assistant with Kiro CLI and the Agent Client Protocol

Ajit — Tue, 24 Mar 2026 11:14:41 +0000

Situation

AI coding assistants are powerful — but they're trapped. Locked inside your terminal or IDE. Step away from your desk and you lose access to your AI agent, your workspace context, your tools.

I work across multiple environments — laptop, phone, sometimes just a quick check between meetings. My AI assistant (Kiro CLI) knows my codebase, has access to MCP tools (web search, AWS docs), and can read/write files. But only when I'm sitting at my terminal.

The question: Can I take my AI agent mobile without rebuilding it from scratch?

Task

Build a bridge that connects Kiro CLI to Telegram — so I can message my AI assistant from my phone and get the same capabilities as the terminal: file access, tool execution, MCP servers, streamed responses.

Constraints:

No modifications to Kiro CLI itself — use its public protocol
Channel-agnostic architecture — Telegram today, Slack/Discord tomorrow
Real tool access — not just a chatbot wrapper, but actual file reads, terminal commands, web search
Production-ready — auth, error handling, message splitting, typing indicators

Action

Discovering ACP

Kiro CLI implements the Agent Client Protocol (ACP) — an open standard for AI agent communication, similar to how LSP standardized language servers. It uses JSON-RPC 2.0 over stdio.

This means any process that can spawn kiro-cli acp and pipe JSON through stdin/stdout becomes an ACP client. Not just IDEs — anything.

Architecture

Three layers, cleanly separated using the Adapter Pattern:

Telegram Adapter — Auth, typing indicators, message splitting. Knows nothing about ACP.
ACP Client — JSON-RPC transport. Manages protocol lifecycle. Knows nothing about Telegram.
Kiro CLI — AI agent runtime. Model inference, tool execution, MCP servers.

Swap Telegram for Slack by writing a new adapter. The ACP client stays identical.

Implementing the ACP Handshake

ACP has a clear lifecycle — initialize, create session, prompt, stream:

// Step 1: Spawn Kiro CLI as ACP agent
const proc = spawn("kiro-cli", ["acp", "--trust-all-tools"], {
  stdio: ["pipe", "pipe", "pipe"],
  cwd: "/path/to/workspace",
});

// Step 2: Initialize — exchange capabilities
const init = await request("initialize", {
  protocolVersion: 1,
  clientCapabilities: {
    fs: { readTextFile: true, writeTextFile: true },
    terminal: true,
  },
  clientInfo: { name: "my-bot", version: "1.0.0" },
});

// Step 3: Create session
const session = await request("session/new", {
  cwd: "/path/to/workspace",
  mcpServers: [],
});

The clientCapabilities declaration is the key insight — it tells Kiro what your client can handle. Declare fs.readTextFile: true and Kiro will send file read requests to your client:

// Kiro sends requests TO us when it needs tools
async function handleServerRequest(msg) {
  switch (msg.method) {
    case "fs/readTextFile":
      return { content: fs.readFileSync(msg.params.path, "utf-8") };
    case "terminal/execute":
      return { output: execSync(msg.params.command, { encoding: "utf-8" }) };
  }
}

Streaming Responses

ACP streams responses via session/update notifications — each containing a text chunk:

function prompt(text) {
  return new Promise((resolve) => {
    const chunks = [];
    acp.on("notification", (method, params) => {
      if (params.update?.sessionUpdate === "agent_message_chunk") {
        chunks.push(params.update.content.text);
      }
    });
    request("session/prompt", {
      sessionId,
      prompt: [{ type: "text", text }],
    }).then(() => resolve(chunks.join("")));
  });
}

Adding MCP Tools

MCP servers extend the agent with external capabilities. One JSON config gives the bot web search:

{
  "name": "my-agent",
  "tools": ["*"],
  "mcpServers": {
    "web-search": {
      "command": "npx",
      "args": ["-y", "duckduckgo-mcp-server"]
    }
  }
}

Ask the bot "What's the weather in Tokyo?" — Kiro automatically invokes the search tool, processes results, and responds. All within a single session/prompt call.

Wiring Telegram

The adapter is the simplest layer — receive, forward, respond:

bot.on("message", async (msg) => {
  if (!allowedUsers.has(String(msg.from.id))) return;
  await bot.sendChatAction(msg.chat.id, "typing");
  const response = await acp.prompt(msg.text);
  for (const part of splitMessage(response, 4096)) {
    await bot.sendMessage(msg.chat.id, part);
  }
});

Result

~200 lines of code. A fully functional mobile AI assistant that:

✅ Connects to Kiro CLI via ACP (JSON-RPC 2.0 over stdio)
✅ Full workspace access — reads files, writes files, runs terminal commands
✅ MCP tool integration — web search, AWS docs, custom tools
✅ Streamed responses — no waiting for the full response to generate
✅ Auth, typing indicators, automatic message splitting for Telegram's 4096 char limit
✅ Channel-agnostic — adding Slack or Discord means writing one new adapter file

Patterns That Made It Work

Pattern	Why It Matters
Adapter Pattern	Telegram adapter is decoupled from ACP. New channels = new adapter, same core.
JSON-RPC 2.0 / stdio	Same transport as LSP. Battle-tested, no HTTP overhead, works with any language.
Capability Negotiation	Client declares what it supports during `initialize`. Forward-compatible.
Bidirectional Requests	Client sends prompts, agent sends tool requests back. Both sides are client and server.
Streaming via Notifications	Agent streams chunks as generated. No polling, no buffering.

Key Learnings

ACP is underutilized. Most people use Kiro in the terminal or IDE. But ACP is a general-purpose protocol — any client that speaks JSON-RPC can connect.
MCP servers are the real power. The bot isn't just a chatbot — it's an agent with tools. Web search, AWS docs, file operations. MCP turns text generation into action.
stdio is elegant. No HTTP servers, no WebSocket complexity, no ports. Spawn a process, pipe JSON, done.
The Adapter Pattern pays off immediately. Started with Telegram. Slack would take an afternoon because the ACP client is completely separate.

What's Next

[ ] Multi-channel — Slack and WhatsApp adapters using the same ACP client
[ ] Voice messages — Speech-to-text → prompt → response → voice note
[ ] Serverless — Lambda + API Gateway with Telegram webhooks
[ ] Session persistence — Resume conversations across restarts

Try It

The full source is open: kiro-acp-telegram-bot

MIT-0 licensed. Fork it, extend it, build your own channels.

git clone https://github.com/ajitnk-lab/kiro-acp-telegram-bot.git
cd kiro-acp-telegram-bot
npm install
cp .env.example .env  # add your Telegram token
npm start

I'd love your feedback:

What channels would you connect next?
Would a serverless (Lambda) deployment be useful?
What MCP servers would you want on your phone?

Drop a comment or open an issue on the repo. If you build something with this — a Slack bot, a Discord integration, a voice assistant — let me know. 🚀

Built with Kiro CLI · Agent Client Protocol · MCP

References

Kiro CLI Documentation — Installation, authentication, usage
Kiro ACP Integration Guide — Supported methods, session updates, Kiro extensions
Agent Client Protocol Specification — The open standard for AI agent-editor communication
Kiro MCP Configuration — Setting up MCP servers (stdio + HTTP)
Kiro Custom Agents — Agent JSON config, hooks, MCP server selection
Model Context Protocol — Anthropic's open standard for AI tool integration
JSON-RPC 2.0 Specification — The transport protocol ACP is built on
Telegram Bot API — Bot creation, message handling, polling vs webhooks
ACP Changelog — Kiro 1.25 — ACP launch, MCP tools, session management
Exploring the latest features of Amazon Q Developer CLI — Background on CLI + MCP architecture