DEV Community: Ajit

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