DEV Community: Akshay Kumar BM

Claude Code Just Got 4 Huge Upgrades — Here's What Each One Actually Does

Akshay Kumar BM — Thu, 26 Mar 2026 16:17:37 +0000

I've been using Claude Code for a while now, and most updates are incremental — a quality-of-life tweak here, a small model improvement there. But the v2.1.71 drop (March 2026) genuinely changed how I think about what Claude Code is.

Four features landed at once. Together they shift Claude Code from "chat that helps me code" to something closer to an autonomous system that keeps working while I'm not. Let me walk through each one so you know exactly when and why to use it.

🧠 Feature 1: `/loop` — Recurring Prompts Inside Your Session

Before this, if you wanted Claude to check something repeatedly, you had to keep coming back, typing the same prompt, waiting, coming back again. Tedious.

/loop changes that. You give it a task in plain English and it sets up a cron job inside your current session that fires automatically.

# Check inbox every 10 minutes — no babysitting needed
/loop every 10 minutes check my inbox for important emails

# Daily content repurposing — runs the skill automatically
/loop every day check my YouTube for new videos and run my content repurposing skill

# One-off reminder (not just recurring)
/loop in 5 minutes remind me to update the PR description

Under the hood, Claude uses three tools: cron_create, cron_list, and cron_delete. Standard 5-field cron expressions with minute-level precision. The natural language gets converted automatically.

sequenceDiagram
    participant Dev as Developer
    participant CC as Claude Code
    participant Cron as Cron Engine

    Dev->>CC: /loop every 10 minutes check my inbox
    CC->>Cron: cron_create("*/10 * * * *", task)
    loop Every 10 minutes
        Cron->>CC: Fire task
        CC->>Dev: Results / notification
    end

Limitations to know going in:

Expires after 3 days — intentional safety cap (no runaway loops)
Session-only — close the terminal and all loops are gone
No catch-up — if a loop fires while the session is closed, it just disappears

📌 Pro Tip: Think of /loop as "help me right now on this project." Sprint monitoring, inbox watching, checking build status during a deploy — perfect. Long-term automation? That's next.

🤖 Feature 2: Scheduled Tasks — Permanent Daily/Weekly Automation

/loop is great for bursts. But what about running a skill every Monday morning? Or a daily standup summary at 9 AM? That needs something more permanent.

Scheduled Tasks is that something. You define a task once — with a name, prompt, model, schedule, and folder — and it runs forever. Each run spawns a fresh Claude instance, reads your project files, executes the prompt, and shuts down cleanly.

Here's a task I'd actually set up:

Name: Repurpose Videos
Prompt: Check my YouTube for new videos and run my content repurposing skill
         to create a newsletter and a tweet thread
Frequency: Daily at 9:00 AM
Model: Claude Sonnet

Claude is smart enough to pull in the right skills automatically based on your prompt wording — it finds the YouTube tool and the content skill without you naming them explicitly.

graph TD
    A[Scheduled Task fires at 9AM] --> B[Fresh Claude instance starts]
    B --> C[Read project files]
    C --> D[Match skills from prompt context]
    D --> E[Execute task]
    E --> F[Save output]
    F --> G[Session ends]

Current limitations:

Desktop App only — doesn't work from the terminal or VS Code extension yet (this will change)
Computer must be on and app must be open
Does catch up — miss a run? It queues and runs when you reopen. Unlike /loop, nothing is lost.

`/loop` vs Scheduled Tasks — Quick Reference

	`/loop`	Scheduled Task
Scope	Current session	Persistent
Instance	Same throughout	Fresh each run
Missed runs	Lost forever	Catches up
Expiry	3 days	No expiry
Where	Terminal / VS Code	Desktop App only
Best for	Right now, this sprint	Every day, every week

🛠 Feature 3: Google Workspace CLI — Actually Talk to Your Google Stuff

This one surprised me because it's not strictly a Claude Code update — but it's a massive gap filler.

Until now, Claude Code's built-in skills could manage Gmail and Calendar. But Google Drive, Docs, Sheets, Slides? Nothing. And if you've tried building around the Google APIs directly, you know the pain: documents come out with raw markdown, you need extra API calls just to make them look right.

Google released an open-source Workspace CLI that changes the whole equation. One tool. Entire Google ecosystem. 100+ built-in recipes.

# Option A: Install in terminal directly
# (run the install command for the Google Workspace CLI)

# Option B: Just ask Claude Code
"Set up the Google Workspace CLI for me"
# It walks you through the whole thing

The key difference from API-based approaches:

API approach (n8n, etc.):
  Claude → API call → raw markdown → extra formatting calls → "okay" doc

Google CLI approach:
  Claude → bash command → Google → properly formatted doc with headers,
           images, links, tables — done in one step

📌 Pro Tip: Even though Google labels it "not officially supported," that's just because it's in beta. It works, it's open-source, and the setup is fast. Worth it immediately.

💻 Feature 4: Skills 2.0 — Stop Guessing, Start Measuring

This is the one I'm most excited about. And honestly, the one that's going to save me the most time.

Here's the old loop everyone was stuck in:

Build skill → run it → output is okay-ish → tweak something → run again → still not quite right → keep guessing forever

Skills 2.0 breaks that cycle with built-in eval and testing. Anthropic updated their own skill-creator skill to include this. You now get actual scored results against specific criteria — not just "it worked" or "it didn't."

How to run a useful eval

The key is being specific. Vague prompt = generic, useless results.

Don't do this:

Run some tests on my copywriting skill

Do this:

Run a new test optimized for checking whether my copy follows the persuasive
techniques in my persuasion_toolkit.md reference file.

Criteria:
- Does it use the reference file first?
- Does it include curiosity gaps and open loops?
- How often does it use proof or founder-led stories?

Test: Write landing page copy for my school community
Runs: 5 times

Claude launches 5 sub-agents in parallel to run the skill, then returns an interactive HTML report:

The report shows:

Per-run output (flick between all 5)
Formal grades section with specific failure reasons
Benchmark tab: run time and token count per run
A/B comparison with and without the skill

Real example output

Curiosity gaps: 50% pass rate (6/12 checks)

Failure reason: The copy lacks genuine curiosity gaps that sustain
across multiple sentences. It teases but immediately reveals.

Action: Strengthen the curiosity gap section in persuasion_toolkit.md
        or add explicit instruction to skill.md

The A/B test workflow

Split terminal, two Claude sessions:

# Session A: with skill
Create landing page copy using the copywriting skill.
Score against persuasion toolkit adherence.

# Session B: without skill
Create landing page copy without any skill.
Score against the same criteria.

This answers: Is my skill actually helping, or just burning tokens?

The iteration loop that actually works

graph LR
    A[Build skill.md] --> B[Run eval: 1-3 criteria]
    B --> C[Review HTML report]
    C --> D[Paste specific feedback to Claude]
    D --> E[Claude edits skill.md]
    E --> B
    B --> F{Score ≥ 9/10?}
    F -->|Yes| G[Ship it]
    F -->|No| D

📌 Pro Tip: Only optimize for 1–3 criteria per eval run. More moving parts = harder to isolate what changed. Get one thing to 9/10, then move to the next.

✅ Why This Set of Updates Matters

These four features aren't independent tweaks. They stack:

✅ /loop handles the "watch this for me right now" use case
✅ Scheduled Tasks handles the "do this every morning" use case
✅ Google Workspace CLI removes the biggest integration gap
✅ Skills 2.0 turns skill-building from guesswork into engineering

Before these, Claude Code was a very capable assistant you had to keep talking to. Now it's infrastructure. You set it up, point it at your workflow, and it keeps running.

The shift from "tool I use" to "system that works for me" is a real one — and these four updates are what got it there.

👋 Let's Connect

If you found this helpful or want to talk about how you're using Claude Code in your workflow, I'd love to connect!

🔗 Connect with me on LinkedIn
📧 Email: akshaykumarbedre.bm@gmail.com

Let's build something amazing together. 🚀

I Built an AI Skill That Writes LinkedIn Posts — And Then Used It to Write This Post

Akshay Kumar BM — Thu, 26 Mar 2026 16:01:08 +0000

I built an AI skill that writes LinkedIn posts. Then I used that skill to write the LinkedIn post about it.

That's either very meta or very efficient. Probably both.

What Even Is a Claude Code Skill?

A skill is a folder with a Markdown file inside it. That Markdown file teaches Claude exactly how to handle a specific task — your tone, your format, your rules, your quirks.

No Python. No backend. No complex config. Just structured instructions.

The folder goes in ~/.claude/skills/. You invoke it with a slash command. Claude reads the instructions and executes them.

That's it. The entire mechanism.

~/.claude/skills/
└── linkedin-post-creator/
    └── SKILL.md          ← this is the whole thing

It sounds too simple until you actually build one and realise how much you've just automated.

How Skills Are Loaded (The Smart Part)

What makes this more than just a text file is Claude's progressive disclosure model:

Level 1 — always loaded: just the skill name and description (token-cheap, always visible)
Level 2 — loaded on trigger: the full SKILL.md instructions (only when you invoke it)
Level 3 — on demand: any scripts, references, or asset files bundled in the folder

Claude only loads what it needs, when it needs it. Your context window stays clean until you actually invoke the skill.

graph TD
    A[Session Start] --> B[Level 1: Load name + description only]
    B --> C{Skill invoked?}
    C -- Yes --> D[Level 2: Load SKILL.md instructions]
    D --> E{Scripts/references needed?}
    E -- Yes --> F[Level 3: Load on demand]
    E -- No --> G[Execute with SKILL.md only]
    C -- No --> H[Skills stay dormant — no context cost]

📌 Pro Tip: Keep your SKILL.md under 500 lines. Move heavy reference docs into a references/ subfolder — Claude loads them only when the task needs them.

🔧 Step 1: Pick Something You Do Repeatedly

The best skill candidates are tasks that:

Happen frequently
Have a consistent structure
Require you to re-explain your preferences every time

For me, writing LinkedIn posts checked all three. Every session I was re-explaining my tone, my formatting style, my target audience, my hashtag strategy. Same setup work, every time.

That's a skill waiting to be built.

📝 Step 2: Write the SKILL.md

The SKILL.md has two parts: YAML frontmatter and a Markdown body.

---
name: linkedin-post-creator
description: "Creates LinkedIn posts in the author's personal voice and format.
  Use when asked to write a LinkedIn post, create content, or draft a professional
  update. Triggers: linkedin post, write post, social media content."
version: "1.0.0"
---

# LinkedIn Post Creator

You write LinkedIn posts in the author's personal voice.

## Voice and Tone
- Conversational but insightful
- First-person experience ("I built", "I tried", "Here's what happened")
- Hook in the first line — no slow warm-ups

## Format
- Short paragraphs, 2–3 lines max
- Emojis as visual anchors, not decoration
- Break ideas with --- dividers
- End with a question to drive comments
- 3–5 relevant hashtags at the bottom

## Workflow
1. Research the topic using live web data
2. Generate 3 complete post variations
3. Save all three to a timestamped file in the project

The description field is the most important. It tells Claude what the skill does and when to use it. Write it in third person with explicit trigger keywords — Claude uses this to decide whether to auto-invoke the skill when your request matches.

🤖 Step 3: Invoke It

Once the skill is in ~/.claude/skills/, invoking it is just:

/linkedin-post-creator grafana alert automation

Claude reads the SKILL.md, applies your voice and format, and generates content. With live web search hooked up (via Tavily MCP), it researches the topic first, then writes.

The output: three post variations, saved to a timestamped file automatically. What used to take 20–30 minutes of drafting and editing takes about 30 seconds of review and picking the best option.

💡 Step 4: Add Supporting Files (Optional but Powerful)

Skills can bundle more than just instructions:

~/.claude/skills/linkedin-post-creator/
├── SKILL.md                    ← instructions
├── references/
│   └── past-posts.md           ← examples of your best posts for calibration
├── examples/
│   └── sample-output.md        ← ideal output format
└── scripts/
    └── save-post.sh            ← auto-save to project folder

The references/ and scripts/ directories are only loaded on demand (Level 3). They don't cost context tokens until needed.

📌 Pro Tip: Drop a few of your best past posts into references/past-posts.md. Claude will calibrate its output to match your actual style, not a generic version of it.

🚀 Step 5: Build Your First Skill With a Skill

Anthropic ships a skill-creator meta-skill in their official repo. It guides you through building other skills interactively — which is exactly as recursive as it sounds.

# 1. Download from the official repo
#    https://github.com/anthropics/skills/tree/main/skills/skill-creator

# 2. Drop it in your skills directory
cp -r skill-creator ~/.claude/skills/

# 3. Invoke it inside Claude Code
/skill-creator

It asks what you want to automate, walks you through defining the instructions, and generates the SKILL.md for you. Then it can also eval and benchmark the skill to make sure it triggers correctly.

If you're not sure where to start, start here.

The Compounding Effect

Here's what surprised me most: skills don't just save time once. They compound.

After /linkedin-post-creator, I built:

/commit — structured git commit messages in my preferred format
/agent-builder — scaffolds new Claude agent configurations from a description
/breakdown — takes a product requirement and breaks it into epics and tasks
/tech-blog-generator — writes dev.to posts in my personal style (meta: this post was written with it)

Each took less than an hour. Each saves hours per month. And each one made the next faster to build — the pattern becomes automatic.

The mental model shifts: you stop thinking "how do I do this task" and start thinking "should I build a skill for this?"

graph LR
    A[Identify repetitive task] --> B[Write SKILL.md]
    B --> C[Invoke with /skill-name]
    C --> D[Iterate instructions]
    D --> E[Task automated]
    E --> F[Build next skill faster]
    F --> A

What I Learned About Writing Good Skill Instructions

A few things that made the difference between skills that work and skills that don't:

Be explicit about WHEN to use it. Vague descriptions mean Claude either never auto-fires or fires at the wrong time. Add positive triggers ("use when writing a LinkedIn post") and negative boundaries ("do not use for email drafts").

Keep the body under 500 lines. Long skill files bloat Level 2 load. Move domain-specific docs to references/ and reference them by filename.

Add examples. An examples/ folder with ideal inputs and outputs calibrates Claude's output style better than any amount of written instruction.

Iterate. Your first skill will be too vague. Use it once, notice what Claude gets wrong, tighten the instructions, try again. Skills improve through iteration, not perfection.

Why This Feels Different From Other AI Tools

I've used AI tools that need APIs, pipelines, and orchestration frameworks. Powerful for complex systems — overkill for daily workflow tasks.

Skills are the right abstraction for the right problem:

Portable — a folder you copy anywhere
Version-controllable — just text, lives in git
No infrastructure — no deployment, no API keys beyond what Claude already has
Hot-reload — Claude Code 2.1 detects edits to ~/.claude/skills/ without restarting the session

The closest analogy is a specialist who already knows your preferences. You don't explain your style every time. You just assign the task.

✅ Zero infrastructure — a folder with a text file
✅ Persistent preferences — voice, format, and rules applied every time
✅ Composable — skills can reference other skills
✅ Compounding value — each skill makes the next faster to build
✅ Hot-reloadable — iterate without restarting your session

What Would You Automate First?

I'm curious what repetitive tasks you're still doing manually that a skill could handle. Writing? Code review? Documentation? Stand-up summaries?

Drop it in the comments — I'd love to brainstorm.

👋 Let's Connect

If you found this useful or want to compare skill setups, I'd love to connect.

🔗 Connect with me on LinkedIn
📧 Email: akshaykumarbedre.bm@gmail.com

Building AI-native developer workflows, one skill at a time. 🚀

How I Gave Claude Code Access to My Entire Company's Knowledge Base (In 30 Minutes)

Akshay Kumar BM — Thu, 26 Mar 2026 15:55:39 +0000

In a large company, getting one answer can cost you half a day.

You don't just find the information. You find the person who has it. Then you wait for them to reply. Hope they're not in a meeting. Maybe follow up. Eventually get a Slack message with a Confluence link to a page that hasn't been updated since 2023.

I was doing this every week. Same friction, different questions.

Then I discovered MCP servers — and wired Claude Code directly into our company's knowledge stack. Here's exactly how I did it.

The Problem: Information is Always 3 People Away

I needed to understand how our platform was configured. So I opened Confluence — our internal knowledge base. Hundreds of pages. No obvious entry point.

So I went through the usual steps:

Search Confluence, find 12 loosely related pages
Figure out who owns the relevant docs
Ping them on Slack
Wait
Get a partial answer, repeat from step 2

This wasn't a one-time thing. It was a recurring tax on my working day.

The underlying problem: all this institutional knowledge exists — it's just scattered across tools that weren't designed to answer questions. They were designed to store information.

The Discovery: MCP Servers Can Bridge the Gap

MCP (Model Context Protocol) is an open standard that lets AI assistants connect to external tools and data sources. I knew it existed. I hadn't thought to apply it to our internal company tools.

Turns out, there are ready-made MCP servers for Confluence, Jira, and GitHub. Once connected, Claude can query them directly — not web search results, your actual internal data.

The idea clicked: if Claude can read Confluence, it can answer the questions I've been pinging people about for months.

🛠 Step 1: Confluence MCP — Your Internal Knowledge Base

The package is mcp-atlassian, installed via uvx (no manual install needed):

"confluence": {
  "command": "uvx",
  "args": ["mcp-atlassian"],
  "env": {
    "CONFLUENCE_URL": "https://yourcompany.atlassian.net/wiki",
    "CONFLUENCE_USERNAME": "you@yourcompany.com",
    "CONFLUENCE_API_TOKEN": "your-api-token"
  }
}

Get your API token from Atlassian account settings → Security → API tokens.

After this, Claude can search and read your Confluence spaces directly. Not summaries. Your actual internal docs, with exact page references.

I asked Claude the same question I'd been pinging people about for months. It answered in seconds. With the exact page reference.

📌 Pro Tip: uvx runs the tool in an isolated environment — nothing to install globally, no version conflicts.

🔧 Step 2: Jira MCP — Tickets, Blockers, Sprint Status

The package mcp-server-jira-cloud gives Claude full access to your Jira projects:

"jira": {
  "command": "npx",
  "args": ["-y", "mcp-server-jira-cloud"],
  "env": {
    "JIRA_BASE_URL": "https://yourcompany.atlassian.net",
    "JIRA_API_TOKEN": "your-api-token",
    "JIRA_EMAIL": "you@yourcompany.com"
  }
}

Note the env var names: JIRA_BASE_URL and JIRA_EMAIL — different from the Confluence config. Use the same Atlassian API token.

Now instead of opening Jira, switching tabs, filtering by sprint, and cross-referencing three tickets — you just ask:

"What's blocking PROJ-412, and are there related tickets in the current sprint?"

Claude reads the ticket, follows the issue links, checks the sprint board, and gives you a coherent answer. No browser required.

📊 Step 3: GitHub MCP — PR History, Code Context, Review Threads

GitHub ships an official remote MCP server — no local install, just a bearer token:

"github": {
  "type": "http",
  "url": "https://api.githubcopilot.com/mcp",
  "headers": {
    "Authorization": "Bearer your-github-token"
  }
}

This is particularly useful for understanding why code is the way it is — architectural decisions buried in PR review threads become instantly accessible.

"Why was the retry logic changed in the auth service last quarter?"

Claude searches PR history and surfaces the relevant discussion. What used to require git log, git blame, and a browser becomes one question.

🌐 Bonus: Tavily MCP — Web Search When You Need It

For questions that aren't in your internal docs, Tavily gives Claude access to real-time web search:

"tavily-remote-mcp": {
  "command": "npx",
  "args": [
    "-y",
    "mcp-remote",
    "https://mcp.tavily.com/mcp/?tavilyApiKey=your-tavily-key"
  ],
  "env": {}
}

The API key is passed directly in the URL. No extra env vars needed.

The Full Config (Copy-Paste Ready)

Drop this into your Claude Code MCP settings:

{
  "mcpServers": {
    "confluence": {
      "command": "uvx",
      "args": ["mcp-atlassian"],
      "env": {
        "CONFLUENCE_URL": "https://yourcompany.atlassian.net/wiki",
        "CONFLUENCE_USERNAME": "you@yourcompany.com",
        "CONFLUENCE_API_TOKEN": "YOUR_ATLASSIAN_TOKEN"
      }
    },
    "jira": {
      "command": "npx",
      "args": ["-y", "mcp-server-jira-cloud"],
      "env": {
        "JIRA_BASE_URL": "https://yourcompany.atlassian.net",
        "JIRA_API_TOKEN": "YOUR_ATLASSIAN_TOKEN",
        "JIRA_EMAIL": "you@yourcompany.com"
      }
    },
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_GITHUB_TOKEN"
      }
    },
    "tavily-remote-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://mcp.tavily.com/mcp/?tavilyApiKey=YOUR_TAVILY_KEY"
      ],
      "env": {}
    }
  }
}

Total setup time: ~30 minutes. One API token per service, one config block each.

graph LR
    A[Claude Code] --> B[Confluence MCP\nuvx mcp-atlassian]
    A --> C[Jira MCP\nmcp-server-jira-cloud]
    A --> D[GitHub MCP\napi.githubcopilot.com]
    A --> E[Tavily MCP\nWeb Search]
    B --> F[Internal Docs]
    C --> G[Tickets & Sprints]
    D --> H[PR History & Code]
    E --> I[Real-Time Web]

The Result: Claude Knows Your Company

After this setup, the experience shifts noticeably.

Before:
Open Confluence → search → find wrong page → find right person → wait

After:
Ask Claude → get answer with exact page reference → keep working

The key distinction: this isn't generic AI knowledge. Claude now has access to your company's architecture docs, your team's tickets, your repo's history.

✅ Questions that used to require a coworker now answer in seconds
✅ Onboarding becomes faster — Claude becomes a guided tour of your stack
✅ Incident investigation is faster — no more context-switching between tools
✅ Setup cost: one afternoon, one token per tool

Which Tool Should You Connect First?

If I had to pick one: Confluence. That's where institutional knowledge lives, and it's where the "3 people away" problem hits hardest.

Jira is a close second if your team is ticket-driven. GitHub MCP earns its place quickly once you're using Claude for debugging or code review — having PR history in context changes how you approach both.

👋 Let's Connect

If you found this useful or want to compare MCP setups, I'd love to connect.

🔗 Connect with me on LinkedIn
📧 Email: akshaykumarbedre.bm@gmail.com

Building AI-native developer workflows, one config block at a time. 🚀

Stop Loading 30 MCP Tools Into One Agent — 3 Design Patterns That Actually Work

Akshay Kumar BM — Sun, 15 Mar 2026 09:14:42 +0000

I hit a wall building an AI agent with MCP.

The agent had access to 30+ tools — database queries, file ops, Slack notifications, ticket management, you name it. And it kept making dumb decisions. Wrong tool calls. Hallucinated parameters. Context that made no sense.

Then I read the research: at 32K tokens of context, 11 models tested dropped below 50% of their short-context baseline. Every tool schema you load burns tokens. More tools = more context rot = worse decisions.

Here are the 3 design patterns I switched to — with working Python MCP server code for each one.

Prerequisites

Python 3.11+
mcp SDK: pip install mcp
Basic familiarity with MCP servers and Claude agents

🔧 Pattern 1: Sub-Agent Grouping

The idea: Don't wire 30 tools to one agent. Group tools by domain. Give each group its own focused MCP server. An orchestrator delegates; sub-agents specialize.

30 tools to 1 agent  ❌
     ↓
Orchestrator → DB Agent (5 tools)
             → Comms Agent (6 tools)
             → Storage Agent (4 tools)  ✅

Each sub-agent only sees 5–8 tools. Its attention stays sharp.

The Code

db_agent_server.py — Database sub-agent:

from mcp.server.fastmcp import FastMCP
import sqlite3

mcp = FastMCP("db-agent")

@mcp.tool()
def query_records(table: str, filters: dict = {}) -> list[dict]:
    """Query records from a table with optional filters."""
    conn = sqlite3.connect("app.db")
    cursor = conn.cursor()

    where_clause = ""
    values = []
    if filters:
        conditions = [f"{k} = ?" for k in filters]
        where_clause = "WHERE " + " AND ".join(conditions)
        values = list(filters.values())

    cursor.execute(f"SELECT * FROM {table} {where_clause}", values)
    columns = [d[0] for d in cursor.description]
    return [dict(zip(columns, row)) for row in cursor.fetchall()]

@mcp.tool()
def insert_record(table: str, data: dict) -> str:
    """Insert a new record into a table."""
    conn = sqlite3.connect("app.db")
    columns = ", ".join(data.keys())
    placeholders = ", ".join(["?"] * len(data))
    conn.execute(
        f"INSERT INTO {table} ({columns}) VALUES ({placeholders})",
        list(data.values())
    )
    conn.commit()
    return f"Inserted record into {table}"

@mcp.tool()
def delete_record(table: str, record_id: int) -> str:
    """Delete a record by ID."""
    conn = sqlite3.connect("app.db")
    conn.execute(f"DELETE FROM {table} WHERE id = ?", [record_id])
    conn.commit()
    return f"Deleted record {record_id} from {table}"

if __name__ == "__main__":
    mcp.run()

comms_agent_server.py — Notifications sub-agent:

from mcp.server.fastmcp import FastMCP
import httpx

mcp = FastMCP("comms-agent")

SLACK_WEBHOOK = "https://hooks.slack.com/services/YOUR/WEBHOOK/URL"

@mcp.tool()
def send_slack_message(channel: str, message: str) -> str:
    """Send a message to a Slack channel."""
    payload = {"channel": channel, "text": message}
    resp = httpx.post(SLACK_WEBHOOK, json=payload)
    return "Message sent" if resp.status_code == 200 else f"Failed: {resp.text}"

@mcp.tool()
def send_email(to: str, subject: str, body: str) -> str:
    """Send an email notification."""
    # plug in your SMTP/SES logic here
    print(f"Email to {to}: [{subject}] {body}")
    return f"Email sent to {to}"

if __name__ == "__main__":
    mcp.run()

orchestrator_server.py — The orchestrator that delegates:

from mcp.server.fastmcp import FastMCP
from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client

mcp = FastMCP("orchestrator")

async def call_sub_agent(server_script: str, tool_name: str, args: dict):
    """Call a tool on a sub-agent MCP server."""
    params = StdioServerParameters(command="python", args=[server_script])
    async with stdio_client(params) as (read, write):
        async with ClientSession(read, write) as session:
            await session.initialize()
            result = await session.call_tool(tool_name, args)
            return result.content[0].text

@mcp.tool()
async def get_user_data(user_id: int) -> str:
    """Fetch user data — delegates to the DB sub-agent."""
    return await call_sub_agent(
        "db_agent_server.py",
        "query_records",
        {"table": "users", "filters": {"id": user_id}}
    )

@mcp.tool()
async def notify_user(user_email: str, message: str) -> str:
    """Notify a user — delegates to the comms sub-agent."""
    return await call_sub_agent(
        "comms_agent_server.py",
        "send_email",
        {"to": user_email, "subject": "Notification", "body": message}
    )

if __name__ == "__main__":
    mcp.run()

graph TD
    A[Claude / Orchestrator Agent] --> B[Orchestrator MCP Server]
    B -->|query_records, insert_record| C[DB Agent Server]
    B -->|send_slack_message, send_email| D[Comms Agent Server]
    B -->|read_file, write_file| E[Storage Agent Server]

📌 Pro Tip: Run each sub-agent as a separate process. The orchestrator spins them up on demand. Claude only ever sees the orchestrator's 4–5 tools in its context, not the 30 underneath.

🛠 Pattern 2: Skill-as-Tool (Lazy Loading)

The idea: Instead of loading all 30 tool schemas upfront, expose one discover_skill tool. The agent calls it first to find out what's available, then makes the real call. Anthropic calls this "progressive discovery."

The agent's context stays lean until it actually needs depth. Think of it like a lazy import — don't load what you don't need yet.

The Code

from mcp.server.fastmcp import FastMCP
from typing import Literal
import json

mcp = FastMCP("lazy-skill-server")

# --- Skill Registry ---
SKILL_REGISTRY = {
    "incident_management": {
        "description": "Create, update, escalate and resolve incidents",
        "tools": ["create_incident", "update_incident", "escalate_incident", "resolve_incident"],
        "example": "discover_skill('incident_management') then call create_incident(...)"
    },
    "user_management": {
        "description": "Create, suspend, or look up user accounts",
        "tools": ["create_user", "suspend_user", "get_user_profile"],
        "example": "discover_skill('user_management') then call get_user_profile(...)"
    },
    "reporting": {
        "description": "Generate and export operational reports",
        "tools": ["generate_report", "export_csv", "email_report"],
        "example": "discover_skill('reporting') then call generate_report(...)"
    }
}

@mcp.tool()
def list_skills() -> str:
    """
    List all available skill domains. Call this first to discover
    what capabilities are available before making deeper calls.
    Returns skill names and short descriptions only — no schema bloat.
    """
    summary = {
        name: info["description"]
        for name, info in SKILL_REGISTRY.items()
    }
    return json.dumps(summary, indent=2)

@mcp.tool()
def discover_skill(skill_name: str) -> str:
    """
    Get the full details and available tools for a specific skill.
    Call list_skills() first, then call this to expand the skill you need.

    Args:
        skill_name: One of the skill names returned by list_skills()
    """
    if skill_name not in SKILL_REGISTRY:
        available = list(SKILL_REGISTRY.keys())
        return f"Unknown skill '{skill_name}'. Available: {available}"

    skill = SKILL_REGISTRY[skill_name]
    return json.dumps({
        "skill": skill_name,
        "description": skill["description"],
        "tools": skill["tools"],
        "usage_example": skill["example"]
    }, indent=2)

# --- Real tools loaded only when the agent asks ---

@mcp.tool()
def create_incident(title: str, severity: Literal["low", "medium", "high", "critical"],
                    description: str) -> str:
    """Create a new incident. Discovered via discover_skill('incident_management')."""
    incident_id = f"INC-{hash(title) % 10000:04d}"
    print(f"[Incident Created] {incident_id}: {title} [{severity}]")
    return json.dumps({"id": incident_id, "title": title, "severity": severity, "status": "open"})

@mcp.tool()
def resolve_incident(incident_id: str, resolution_note: str) -> str:
    """Resolve an incident by ID. Discovered via discover_skill('incident_management')."""
    return json.dumps({"id": incident_id, "status": "resolved", "note": resolution_note})

@mcp.tool()
def get_user_profile(user_id: str) -> str:
    """Fetch user profile. Discovered via discover_skill('user_management')."""
    return json.dumps({"id": user_id, "name": "Jane Doe", "role": "engineer", "active": True})

if __name__ == "__main__":
    mcp.run()

The agent's discovery flow looks like this:

sequenceDiagram
    participant Agent as Claude Agent
    participant MCP as Skill MCP Server

    Agent->>MCP: list_skills()
    MCP-->>Agent: {incident_management, user_management, reporting}

    Note over Agent: Only 2 tools loaded in context so far

    Agent->>MCP: discover_skill("incident_management")
    MCP-->>Agent: {tools: [create_incident, update_incident, ...]}

    Agent->>MCP: create_incident(title=..., severity=...)
    MCP-->>Agent: {id: "INC-0042", status: "open"}

📌 Pro Tip: The list_skills() tool returns only names + descriptions — no JSON schemas. Schemas only enter the context when the agent explicitly calls discover_skill(). This keeps your initial context tiny.

🎯 Pattern 3: Parameterized Tool Consolidation

The idea: Instead of one tool per action, build one tool that handles all related actions via an action parameter. Fewer tools = less schema noise in context.

Before:

create_ticket()   # 1 tool
update_ticket()   # 1 tool
close_ticket()    # 1 tool
reopen_ticket()   # 1 tool
get_ticket()      # 1 tool
# = 5 tools, 5 schemas loaded

After:

manage_ticket(action="create"|"update"|"close"|"reopen"|"get")
# = 1 tool, 1 schema loaded

The Code

from mcp.server.fastmcp import FastMCP
from typing import Literal, Optional
import json
import uuid

mcp = FastMCP("consolidated-tools-server")

# In-memory store for demo purposes
TICKETS: dict = {}
ALERTS: dict = {}

@mcp.tool()
def manage_ticket(
    action: Literal["create", "update", "close", "reopen", "get"],
    ticket_id: Optional[str] = None,
    title: Optional[str] = None,
    description: Optional[str] = None,
    priority: Optional[Literal["low", "medium", "high"]] = None,
    status_note: Optional[str] = None
) -> str:
    """
    Manage support tickets. Use the 'action' parameter to specify the operation.

    Actions:
      - create: Requires title, description, priority
      - update: Requires ticket_id; optionally title, description, priority
      - close:  Requires ticket_id; optionally status_note
      - reopen: Requires ticket_id
      - get:    Requires ticket_id
    """
    if action == "create":
        if not all([title, description, priority]):
            return "Error: create requires title, description, and priority"
        tid = f"TKT-{str(uuid.uuid4())[:8].upper()}"
        TICKETS[tid] = {
            "id": tid, "title": title, "description": description,
            "priority": priority, "status": "open"
        }
        return json.dumps({"created": TICKETS[tid]})

    if not ticket_id:
        return f"Error: action '{action}' requires ticket_id"
    if ticket_id not in TICKETS:
        return f"Error: ticket {ticket_id} not found"

    ticket = TICKETS[ticket_id]

    if action == "get":
        return json.dumps(ticket)

    if action == "update":
        if title:       ticket["title"] = title
        if description: ticket["description"] = description
        if priority:    ticket["priority"] = priority
        return json.dumps({"updated": ticket})

    if action == "close":
        ticket["status"] = "closed"
        if status_note: ticket["resolution"] = status_note
        return json.dumps({"closed": ticket})

    if action == "reopen":
        ticket["status"] = "open"
        ticket.pop("resolution", None)
        return json.dumps({"reopened": ticket})

    return f"Unknown action: {action}"


@mcp.tool()
def manage_alert(
    action: Literal["acknowledge", "silence", "escalate", "get", "list"],
    alert_id: Optional[str] = None,
    silence_duration_minutes: Optional[int] = None,
    escalate_to: Optional[str] = None
) -> str:
    """
    Manage monitoring alerts.

    Actions:
      - acknowledge: Requires alert_id
      - silence:     Requires alert_id, silence_duration_minutes
      - escalate:    Requires alert_id, escalate_to (team or person)
      - get:         Requires alert_id
      - list:        No extra params needed
    """
    if action == "list":
        return json.dumps(list(ALERTS.values())) if ALERTS else "[]"

    if not alert_id:
        return f"Error: action '{action}' requires alert_id"

    # Seed a demo alert if needed
    if alert_id not in ALERTS:
        ALERTS[alert_id] = {"id": alert_id, "status": "firing", "severity": "high"}

    alert = ALERTS[alert_id]

    if action == "get":
        return json.dumps(alert)

    if action == "acknowledge":
        alert["status"] = "acknowledged"
        return json.dumps({"acknowledged": alert})

    if action == "silence":
        if not silence_duration_minutes:
            return "Error: silence requires silence_duration_minutes"
        alert["status"] = "silenced"
        alert["silenced_for_minutes"] = silence_duration_minutes
        return json.dumps({"silenced": alert})

    if action == "escalate":
        if not escalate_to:
            return "Error: escalate requires escalate_to"
        alert["escalated_to"] = escalate_to
        alert["status"] = "escalated"
        return json.dumps({"escalated": alert})

    return f"Unknown action: {action}"


if __name__ == "__main__":
    mcp.run()

Now instead of loading 8 separate ticket + alert tool schemas, the agent loads 2. Less schema surface area, cleaner decision-making.

📌 Pro Tip: Group by resource, not action. If it's all about the same entity (ticket, alert, user), it belongs in one parameterized tool. Only split tools when the domains are genuinely different.

Putting It All Together

Here's how the three patterns layer on top of each other:

graph TD
    A[Claude Agent] --> B[Orchestrator MCP Server]

    B --> C["🎯 Consolidated Tools<br/>manage_ticket()<br/>manage_alert()"]
    B --> D["🛠 Lazy Skill Server<br/>list_skills()<br/>discover_skill()"]
    B --> E["🔧 Sub-Agent: DB<br/>query / insert / delete"]
    B --> F["🔧 Sub-Agent: Comms<br/>email / slack"]

    style A fill:#4A90D9,color:#fff
    style B fill:#7B68EE,color:#fff
    style C fill:#2ECC71,color:#fff
    style D fill:#F39C12,color:#fff
    style E fill:#E74C3C,color:#fff
    style F fill:#1ABC9C,color:#fff

Sub-Agent Grouping handles domain separation — each agent is a specialist
Lazy Loading handles discovery — context stays minimal until needed
Consolidation handles action sprawl — fewer tools for the same functionality

✅ Key Takeaways

✅ More tools = more context tokens = worse agent decisions — it's not just intuition, it's empirically measured
✅ Sub-agent grouping gives each agent a focused toolset (5–8 tools max)
✅ Lazy loading keeps initial context lean; schemas only appear when the agent needs them
✅ Parameterized consolidation cuts tool count by 60–70% without losing capability
✅ MCP tool design is an engineering discipline — the same principles as good API design apply

The core mental model: you don't expose every database table directly to an API. Don't expose every capability directly to an agent.

Structure beats surface area. Every time.

👋 Let's Connect

If you're building AI agents with MCP and want to compare notes — or ran into patterns I didn't cover — I'd love to hear about it.

🔗 Connect with me on LinkedIn
📧 Drop me a message

Let's build agents that actually make good decisions. 🚀

MCP Server: The Practical Guide to Building Tool-Aware AI Apps

Akshay Kumar BM — Sat, 14 Mar 2026 06:44:05 +0000

MCP Server: The Practical Guide to Building Tool-Aware AI Apps

How the Model Context Protocol (MCP) helps AI assistants use your tools safely and consistently.

Suggested cover image: data center / server infrastructure

Why MCP matters

Most teams can connect an AI model to a single API quickly.
The real challenge starts when you need many tools, reliable behavior, and safe permissions.

Model Context Protocol (MCP) solves this by defining a standard way for assistants to discover and call tools.
Instead of custom one-off integrations, you get a reusable protocol layer.

What is MCP (in simple words)?

MCP is a protocol that lets AI clients (like coding assistants) communicate with tool providers (MCP servers).

At a high level:

The client asks: “What tools do you provide?”
The server responds with tool definitions (name, input schema, behavior).
The client calls a tool with structured arguments.
The server executes and returns structured results.

Suggested inline image: network / connected systems

Core MCP architecture

A practical MCP setup usually has these layers:

MCP Client
- Runs inside your AI app or assistant host.
- Handles tool discovery, tool invocation, and response routing.
MCP Server
- Exposes your tools in a protocol-compliant format.
- Validates inputs and controls execution.
Tool Adapters
- Thin wrappers around real systems (REST APIs, databases, CI/CD, files).
- Keep protocol logic separate from business logic.
Policy + Observability
- Access controls, logging, rate limits, and audit trails.

Suggested inline image: layered software / code

Building your first MCP server (practical steps)

Step 1: Start with one narrow use case

Pick one workflow that has clear value, for example:

“Create a blog draft from a topic”
“Read project docs and summarize risks”
“Trigger CI status check”

Small scope helps you validate tool contracts quickly.

Step 2: Define tool contracts first

For each tool, define:

name
description
input schema (required + optional)
output schema (success + error)

This is where consistency is won or lost.

Step 3: Add strict validation

Validate every input before execution:

required fields
type checks
enum checks
bounds (length, range)

Never trust tool arguments blindly.

Step 4: Add safe execution guards

timeout per tool call
retry policy (only where idempotent)
rate limiting
permission checks

Step 5: Add logs for every tool call

At minimum log:

timestamp
tool name
user/session id
execution time
success/failure

Security and governance checklist

Before production, ensure your MCP server has:

Authentication for client-to-server access
Authorization per tool and per action
Input sanitization for all untrusted fields
Output filtering to avoid sensitive leakage
Audit logs for compliance and incident review
Kill switch to disable risky tools instantly

Suggested inline image: cybersecurity concept

Common mistakes teams make

Exposing too many tools too early
Weak schema definitions (“string everywhere”)
Missing permission boundaries
No structured error model
No observability for failed calls

A good MCP server is not just “connected”; it is predictable, safe, and measurable.

Example: Blog publishing tool chain via MCP

A useful workflow can be split into tools like:

draft_blog(topic, audience, tone)
insert_images(markdown, style)
review_quality(markdown)
publish_post(markdown, tags, cover_image)

This modular design keeps responsibilities clean and easier to test.

Final thoughts

MCP is becoming the standard foundation for serious tool-using AI applications.
If you design your server with strict contracts, safety controls, and clear observability, you can scale from a demo to production confidently.

If you are starting now, keep it simple:

one use case
one or two tools
strict validation
good logs

Then iterate.

Optional SEO metadata (for publishing)

Proposed Title: MCP Server: The Practical Guide to Building Tool-Aware AI Apps
Meta Description: Learn how to design, secure, and scale an MCP server for reliable AI tool integration, with practical architecture and production tips.
Suggested Tags: mcp, ai, llm, api, backend, developer-tools

DSPy: The Future of Language Model Programming - A Comprehensive Guide

Akshay Kumar BM — Tue, 12 Aug 2025 13:12:53 +0000

From prompt engineering to prompt programming: How Stanford's DSPy framework is revolutionizing AI development

Introduction: Beyond Prompt Engineering

If you've been working with language models, you've likely experienced the frustration of prompt engineering: crafting the perfect prompt through trial and error, only to find it breaks when you change the model or use case. What if I told you there's a better way?

Enter DSPy - Stanford's groundbreaking framework that transforms prompt engineering into prompt programming. Instead of manually crafting prompts, DSPy lets you write programs that automatically optimize themselves.

In this comprehensive guide, I'll walk you through my hands-on journey learning DSPy, from basic operations to advanced optimization techniques. By the end, you'll understand why DSPy represents a paradigm shift in AI development.

What is DSPy? Understanding the Paradigm Shift

DSPy (Declarative Self-improving Python) is not just another LLM wrapper. It's a complete programming framework that treats language models as computational modules that can be:

Programmed with structured signatures
Composed into complex applications
Automatically optimized using data
Systematically evaluated and improved

The Core Philosophy

Traditional prompt engineering is like writing assembly code - you're managing low-level details. DSPy is like writing in a high-level programming language - you focus on what you want, not how to get it.

# Traditional approach: Manual prompt crafting
prompt = "You are an expert mathematician. Solve this step by step: {question}"

# DSPy approach: Declarative programming
math_solver = dspy.ChainOfThought("question -> reasoning: str, answer: float")

Setting Up Your DSPy Environment

Before diving into the exciting parts, let's set up a robust development environment:

# Install required packages
!pip install -U dspy mlflow datasets

# Configure experiment tracking
import mlflow
mlflow.dspy.autolog()  # Automatic logging for DSPy
mlflow.set_experiment("DSPy_Learning_Tutorial")

# Set up DSPy with OpenAI
from dotenv import load_dotenv
import os
import dspy

load_dotenv()
api_key = os.getenv("OPENAI_API_KEY")

lm = dspy.LM("openai/gpt-4o-mini", api_key=api_key)
dspy.configure(lm=lm)

Pro tip: Always use environment variables for API keys and set up experiment tracking from day one. It's much easier to track your progress and debug issues when everything is logged.

Core Concept 1: Signatures - The Building Blocks

DSPy signatures are like function signatures in programming - they define inputs, outputs, and behavior without specifying implementation details.

Basic Signatures

# Simple question-answering
qa = dspy.ChainOfThought('question -> answer')

# Multi-output with types
math = dspy.ChainOfThought("question -> reasoning: str, answer: float")

Advanced Signatures with Custom Classes

from typing import Literal

class SentimentAnalysis(dspy.Signature):
    """Analyze sentiment with confidence and emotional dimensions."""

    text: str = dspy.InputField(desc="Text to analyze")
    sentiment: Literal["positive", "negative", "neutral"] = dspy.OutputField()
    confidence: float = dspy.OutputField(desc="Confidence score 0-1")
    emotions: list[str] = dspy.OutputField(desc="Detected emotions")

The beauty of signatures is that they're declarative - you specify what you want, and DSPy figures out how to get it.

Core Concept 2: Chain of Thought Reasoning

One of DSPy's most powerful features is built-in Chain of Thought reasoning. Instead of hoping your model will think step-by-step, you can guarantee it.

Mathematical Problem Solving

math_solver = dspy.ChainOfThought("question -> reasoning: str, answer: float")

question = "Four dice are tossed. What is the probability that all four show the same number?"

result = math_solver(question=question)
print(f"Reasoning: {result.reasoning}")
print(f"Answer: {result.answer}")

What makes this powerful:

Automatic step-by-step reasoning
Structured outputs with proper types
Consistent performance across different problems
Easy to debug and understand

Core Concept 3: Retrieval Augmented Generation (RAG)

DSPy makes RAG implementation surprisingly straightforward. Here's how to build a Wikipedia-powered Q&A system:

def search_wikipedia(query: str) -> list[str]:
    """Search Wikipedia using ColBERTv2 retrieval."""
    results = dspy.ColBERTv2(url="http://20.102.90.50:2017/wiki17_abstracts")(query, k=3)
    return [x["text"] for x in results]

# Create RAG pipeline
rag = dspy.ChainOfThought("context, question -> response")

# Use it
question = "What's the name of the castle that David Gregory inherited?"
context = search_wikipedia(question)
answer = rag(context=context, question=question)

Key insight: DSPy's modular approach means you can easily swap retrieval systems, modify the generation logic, or add new components without rewriting everything.

Core Concept 4: Agent-Based Reasoning with Tools

This is where DSPy gets really exciting. You can create agents that use tools and reason through complex problems:

def evaluate_math(expression: str):
    """Tool for mathematical calculations."""
    return dspy.PythonInterpreter({}).execute(expression)

def search_wikipedia(query: str):
    """Tool for Wikipedia search."""
    results = dspy.ColBERTv2(url="http://20.102.90.50:2017/wiki17_abstracts")(query, k=3)
    return [x["text"] for x in results]

# Create ReAct agent
react = dspy.ReAct("question -> answer, steps: str", tools=[evaluate_math, search_wikipedia])

# Complex multi-step question
question = "What is 9362158 divided by the year of birth of David Gregory of Kinnairdy castle?"
result = react(question=question)

The agent automatically:

Searches for David Gregory's birth year
Performs the mathematical division
Shows its reasoning steps

Advanced: Modular Composition

DSPy shines when building complex applications. Here's an article generation system that demonstrates modular composition:

class Outline(dspy.Signature):
    """Create a comprehensive outline for an article."""
    topic: str = dspy.InputField()
    title: str = dspy.OutputField()
    sections: list[str] = dspy.OutputField()
    section_subheadings: dict[str, list[str]] = dspy.OutputField()

class DraftSection(dspy.Signature):
    """Write detailed content for a specific section."""
    topic: str = dspy.InputField()
    section_heading: str = dspy.InputField()
    section_subheadings: list[str] = dspy.InputField()
    content: str = dspy.OutputField(desc="markdown-formatted section")

class DraftArticle(dspy.Module):
    def __init__(self):
        self.build_outline = dspy.ChainOfThought(Outline)
        self.draft_section = dspy.ChainOfThought(DraftSection)

    def forward(self, topic):
        # Create outline
        outline = self.build_outline(topic=topic)

        # Draft each section
        sections = []
        for heading, subheadings in outline.section_subheadings.items():
            section = self.draft_section(
                topic=outline.title,
                section_heading=f"## {heading}",
                section_subheadings=[f"### {sub}" for sub in subheadings]
            )
            sections.append(section.content)

        return dspy.Prediction(title=outline.title, sections=sections)

This demonstrates DSPy's modular composition - complex applications built from simple, reusable components.

The Game-Changer: Automatic Optimization

Here's where DSPy becomes truly revolutionary. Instead of manually tuning prompts, you can automatically optimize them using data:

from dspy.datasets import HotPotQA

# Load training data
trainset = [x.with_inputs('question') for x in HotPotQA(train_seed=2024, train_size=500).train]

# Create base agent
react = dspy.ReAct("question -> answer", tools=[search_wikipedia])

# Set up optimizer
optimizer = dspy.MIPROv2(
    metric=dspy.evaluate.answer_exact_match,
    auto="light",
    num_threads=24
)

# Optimize!
optimized_react = optimizer.compile(react, trainset=trainset)

What just happened?

MIPROv2 automatically tested thousands of prompt variations
It found the best prompts using your training data
The optimized agent often outperforms hand-crafted prompts
Everything is tracked and reproducible

Real-World Benefits: Why DSPy Matters

After working extensively with DSPy, here are the key benefits I've observed:

1. Maintainability

Code is structured and modular
Easy to debug and modify
Version control works properly

2. Performance

Automatic optimization often beats manual tuning
Consistent performance across different inputs
Scientific approach to improvement

3. Scalability

Components are reusable across projects
Easy to swap models or add new capabilities
Built-in experiment tracking

4. Reliability

Structured outputs reduce parsing errors
Type safety catches issues early
Systematic evaluation and testing

Best Practices and Lessons Learned

From my hands-on experience, here are key recommendations:

1. Start Simple

Begin with basic signatures and gradually add complexity. DSPy's power comes from composition, not individual components.

2. Use Types Extensively

Leverage Python's type hints and DSPy's structured outputs. They prevent many runtime errors and make your code self-documenting.

3. Track Everything

Set up MLflow from day one. The ability to compare different approaches and track performance over time is invaluable.

4. Optimize Early and Often

Don't spend time manually tuning prompts. Use DSPy's optimizers to find better solutions automatically.

5. Build Incrementally

Test each component individually before composing them into larger systems.

Looking Forward: The Future of LM Programming

DSPy represents a fundamental shift in how we build AI applications. Instead of the current paradigm of:

Write prompt
Test manually
Adjust based on intuition
Repeat

We now have:

Define what you want (signatures)
Compose modules
Optimize automatically
Deploy with confidence

This isn't just about better prompts - it's about systematic AI development.

Getting Started: Your Next Steps

Ready to dive into DSPy? Here's your roadmap:

Week 1: Foundations

Set up your environment
Learn signatures and basic modules
Build simple Chain of Thought examples

Week 2: Composition

Create multi-module applications
Experiment with RAG systems
Build your first agent

Week 3: Optimization

Learn MIPROv2 and optimization
Set up proper evaluation metrics
Compare optimized vs. manual approaches

Week 4: Production

Build a complete application
Set up monitoring and logging
Deploy and iterate

Resources and Community

Documentation: DSPy Official Docs
GitHub: Stanford DSPy Repository
Research: DSPy Paper
Community: Join the discussions and share your experiments

Conclusion: The Programming Revolution

DSPy isn't just another tool - it's a new way of thinking about AI development. By treating language models as programmable components rather than black boxes, we can build more reliable, maintainable, and powerful applications.

The transition from prompt engineering to prompt programming is happening now. The question isn't whether you should learn DSPy, but how quickly you can get started.

The future of AI development is systematic, optimizable, and maintainable. And with DSPy, that future is available today.

Have you experimented with DSPy? What's been your experience with systematic LM programming? Share your thoughts in the comments below!

About the Author: [Your bio and credentials - position yourself as someone who has hands-on experience with cutting-edge AI tools]

Follow for more: [Your Medium profile and other social links]

If you found this helpful, please clap 👏 and follow for more deep dives into AI development tools and techniques.

How I Built a Fully Functional AI Agent Chatbot in Just 2 Days — End-to-End with AWS Bedrock

Akshay Kumar BM — Wed, 21 May 2025 04:54:56 +0000

From concept to deployment — powered by AWS Bedrock, Lambda, and API Gateway.

In the fast-paced world of AI development, being able to move from idea to deployment quickly is critical — especially when showcasing what you’re capable of. That’s exactly what I set out to do: design, build, and deploy an intelligent AI chatbot agent in just 2 days, entirely end-to-end.

In this post, I’ll walk you through the journey — from setting up the knowledge base to integrating with Lambda and creating a working frontend demo. Whether you're a developer or a business owner, you'll see how fast and powerful custom AI agents can be.

🧠 Step 1: Setting Up the Knowledge Base with AWS Bedrock

The foundation of any smart AI agent is a strong knowledge base. I used Amazon S3 as the data source and uploaded a simple .txt file containing key business FAQs and details.

Once the file was uploaded, I synced it within the Bedrock console to ensure it's indexed and available for real-time use. Bedrock allows you to choose custom embedding models and retrieval methods — offering powerful flexibility.

🤖 Step 2: Creating the Agent with Bedrock

Creating the agent itself is straightforward in AWS Bedrock:

I started by creating a basic agent and saving it.
Then, I jumped into the Agent Builder for custom configuration.

Here’s the custom prompt I used to guide the chatbot’s behavior:

Prompt Example:
“You are a sales chatbot for a company that builds custom chatbots for websites to automate customer support and lead generation...”

I also enabled memory features so the chatbot can retain past interactions — crucial for a natural, flowing conversation.

📚 Step 3: Linking the Knowledge Base

With the prompt and settings in place, I attached the previously created knowledge base to the agent. This enabled the bot to respond to user queries with rich, relevant information pulled from the data source.

The result? A context-aware, friendly, and professional chatbot — ready to assist users.

🛠 Step 4: Connecting with Lambda + API Gateway

Now comes the integration part. I created an AWS Lambda function using Python 3.12. The function interacts with the Bedrock agent runtime, takes user input, and returns the chatbot’s response.

Here’s a look at the Lambda logic:

import boto3
import json
import os

bedrock_client = boto3.client("bedrock-agent-runtime", region_name="us-east-1")
AGENT_ID = "FINC1****"
AGENT_ALIAS_ID = "XFZSG***"

def lambda_handler(event, context):
    try:
        body = json.loads(event.get("body", "{}"))
        user_input = body.get("inputText", "hi")
        session_id = body.get("sessionId", "default-session-001")

        response = bedrock_client.invoke_agent(
            agentId=AGENT_ID,
            agentAliasId=AGENT_ALIAS_ID,
            sessionId=session_id,
            inputText=user_input,
            enableTrace=True,
        )

        for event in response['completion']:
            if 'chunk' in event:
                data = event['chunk']['bytes'].decode('utf-8')
                response = data

        return {
            "statusCode": 200,
            "headers": { "Content-Type": "application/json" },
            "body": json.dumps({ "response": response })
        }

    except Exception as e:
        return {
            "statusCode": 500,
            "body": json.dumps({ "error": str(e) })
        }

📌 Pro Tip:

Increase Lambda timeout to 2 minutes
Create a dedicated IAM role with access to S3, Lambda, and Bedrock

🌐 Step 5: Exposing via API Gateway

To allow the chatbot to communicate with external apps or frontend interfaces, I connected the Lambda function to API Gateway (HTTP API).

Created a new API
Linked the Lambda function
Deployed the endpoint
Tested the setup using Postman

💻 Final Result: Live Chatbot Demo for a Business Use Case

Here’s a snapshot of the live chatbot built to assist a fictional chatbot-building company. It handles everything from customer queries to tier-based service explanations.

🔥 Why This Matters

This project wasn’t just about building a chatbot — it was a real-world demonstration of my ability to:

✅ Rapidly prototype intelligent systems
✅ Integrate multiple AWS services (Bedrock, Lambda, S3, API Gateway)
✅ Build production-ready AI agents for business use cases
✅ Deliver results fast — just 2 days from scratch to live demo

If you’re a business looking to automate conversations, generate leads, or scale your customer support — this is the kind of intelligent automation I can build for you.

👋 Let’s Connect

Whether you're a startup, agency, or enterprise, I specialize in building custom AI chatbot agents, LLM-powered workflows, and automation solutions tailored to your needs — fast.

📬 Interested in working together or want a demo?
Feel free to reach out:

🔗 Connect with me on LinkedIn
📧 Email: akshaykumarbedre.bm@gmail.com

Let’s bring your AI ideas to life. 🚀

How Udemy’s AI Chatbot is Enhancing the Learning Experience with RAG Systems

Akshay Kumar BM — Tue, 20 May 2025 09:30:43 +0000

Online learning platforms like Udemy have always focused on delivering high-quality education at scale. With the integration of advanced AI systems—particularly chatbots powered by Retrieval-Augmented Generation (RAG)—Udemy is now elevating how students learn, explore, and engage with their courses.

This image from Udemy's website shows an intelligent AI chatbot interface embedded directly within a course. But what’s happening behind the scenes is even more exciting. Udemy is leveraging cutting-edge technologies to convert video content into a powerful knowledge base that students can interact with naturally.

Let’s break down how this works—and why it’s a game-changer for learners.

From Course Videos to Conversational AI: The RAG Pipeline

📝 Transcription: Course videos are first transcribed using automatic speech recognition (ASR), converting lectures into raw text.
🧹 Preprocessing: This text is then cleaned and structured—removing noise, splitting into semantically meaningful chunks, and indexing for retrieval.
🤖 RAG System: A large language model is integrated with a retrieval system. When a student asks a question, the model fetches relevant pieces of content from the course materials before generating a precise and contextual answer.

This architecture ensures that the chatbot gives factually accurate answers grounded in the course’s actual content—not just generic AI responses.

How This Helps Students

✅ Instant Clarification: Students can ask questions at any point while watching a lecture and get instant answers without leaving the course interface.

✅ Personalized Assistance: The chatbot can guide learners through tough concepts with contextualized examples based on what they’ve watched.

✅ Better Retention: By converting passive video watching into an interactive learning experience, students are more engaged and retain more.

✅ Reduces Friction: No more skimming through hours of video to find a specific point—just ask!

Ready to Add AI to Your E-Learning Platform?

If you're building an e-learning platform and want to offer your users a smarter, more interactive experience with AI chatbots and RAG systems—I can help.

👨‍💻 I'm offering a free consultation to help you design and integrate a custom AI assistant tailored to your platform’s content and audience.

🚀 Ready to bring AI to your e-learning platform?
Connect with me on LinkedIn or visit Agenticflow.com to learn more and book a free consultation.

Build a No-Code AI Telegram Bot with n8n (On-Premise & Free)

Akshay Kumar BM — Sat, 17 May 2025 09:33:47 +0000

Create a fully functional AI-powered Telegram bot without writing a single line of code! In this tutorial, you'll learn how to set up n8n locally and connect it to Telegram and an AI model—completely free and on-premise.

Prerequisites

Node.js (v14 or higher) installed on your system
Telegram account to create a bot using BotFather
OpenAI API key or Google AI credentials for LLM integration
n8n (installed using npx) for automation workflows
ngrok (optional) to expose local webhooks over HTTPS

1. Install n8n via npx

To install and run n8n locally, simply use the following command:

npx n8n

This command:

Downloads the n8n package
Installs the necessary dependencies
Launches the n8n editor at http://localhost:5678

Setup Screenshots

2. Create Your Telegram Bot

Open the BotFather in Telegram.
Send the command /newbot and follow the instructions:

Choose a display Name
Set a Username (must end with bot, e.g., MyAIHelperBot)
1. Copy the Bot Token provided after creation.

3. Configure the Telegram Trigger in n8n

In the n8n editor, drag in a Telegram Trigger node.
Authenticate using your Bot Token.
Optionally specify filters such as chat IDs.

4. Build the AI Agent Workflow

a. Connect to an AI Model

Use one of the following nodes to process user messages with AI:

OpenAI Node: For GPT-3.5/GPT-4
Google Vertex AI Node: For models hosted by Google

Configure the node with your API key and set the model to use (e.g., gpt-3.5-turbo).

b. (Optional) Store Chat History

To support context or logs, add a Database or Google Sheet node to save messages and responses.

c. Send AI Responses Back to Telegram

Use the Telegram Send Message node and link it to the output of the AI node.

5. Test the Bot Locally Using ngrok

Save and Activate the workflow in n8n.
ngrok automatically starts when you run it for the first time using the n8n start command. Copy the HTTPS URL generated by ngrok.
Set this HTTPS URL as the Webhook URL in n8n’s settings.
Send a message to your bot in Telegram.
View the live execution logs in n8n to confirm the workflow is triggered and a response is sent.

Final Architecture Overview

Here's a visual overview of how all components—Telegram, n8n, and the AI model—interact in this workflow:

Conclusion

With just a few tools and no coding, you've built an intelligent, conversational Telegram bot powered by AI and managed entirely within your own infrastructure. Whether you're prototyping or building a production bot, n8n makes it easy and flexible.

Happy automating! 🚀

DEV Community: Akshay Kumar BM

Claude Code Just Got 4 Huge Upgrades — Here's What Each One Actually Does

🧠 Feature 1: /loop — Recurring Prompts Inside Your Session

🤖 Feature 2: Scheduled Tasks — Permanent Daily/Weekly Automation

/loop vs Scheduled Tasks — Quick Reference

🛠 Feature 3: Google Workspace CLI — Actually Talk to Your Google Stuff

💻 Feature 4: Skills 2.0 — Stop Guessing, Start Measuring

How to run a useful eval

Real example output

The A/B test workflow

The iteration loop that actually works

✅ Why This Set of Updates Matters

👋 Let's Connect

I Built an AI Skill That Writes LinkedIn Posts — And Then Used It to Write This Post

What Even Is a Claude Code Skill?

How Skills Are Loaded (The Smart Part)

🔧 Step 1: Pick Something You Do Repeatedly

📝 Step 2: Write the SKILL.md

🤖 Step 3: Invoke It

💡 Step 4: Add Supporting Files (Optional but Powerful)

🚀 Step 5: Build Your First Skill With a Skill

The Compounding Effect

What I Learned About Writing Good Skill Instructions

Why This Feels Different From Other AI Tools

What Would You Automate First?

👋 Let's Connect

How I Gave Claude Code Access to My Entire Company's Knowledge Base (In 30 Minutes)

The Problem: Information is Always 3 People Away

The Discovery: MCP Servers Can Bridge the Gap

🛠 Step 1: Confluence MCP — Your Internal Knowledge Base

🔧 Step 2: Jira MCP — Tickets, Blockers, Sprint Status

📊 Step 3: GitHub MCP — PR History, Code Context, Review Threads

🌐 Bonus: Tavily MCP — Web Search When You Need It

The Full Config (Copy-Paste Ready)

The Result: Claude Knows Your Company

Which Tool Should You Connect First?

👋 Let's Connect

Stop Loading 30 MCP Tools Into One Agent — 3 Design Patterns That Actually Work

Prerequisites

🔧 Pattern 1: Sub-Agent Grouping

The Code

🛠 Pattern 2: Skill-as-Tool (Lazy Loading)

The Code

🎯 Pattern 3: Parameterized Tool Consolidation

The Code

Putting It All Together

✅ Key Takeaways

👋 Let's Connect

MCP Server: The Practical Guide to Building Tool-Aware AI Apps

MCP Server: The Practical Guide to Building Tool-Aware AI Apps

Why MCP matters

What is MCP (in simple words)?

Core MCP architecture

Building your first MCP server (practical steps)

Step 1: Start with one narrow use case

Step 2: Define tool contracts first

Step 3: Add strict validation

Step 4: Add safe execution guards

Step 5: Add logs for every tool call

Security and governance checklist

Common mistakes teams make

Example: Blog publishing tool chain via MCP

Final thoughts

Optional SEO metadata (for publishing)

DSPy: The Future of Language Model Programming - A Comprehensive Guide

Introduction: Beyond Prompt Engineering

What is DSPy? Understanding the Paradigm Shift

The Core Philosophy

Setting Up Your DSPy Environment

Core Concept 1: Signatures - The Building Blocks

Basic Signatures

Advanced Signatures with Custom Classes

Core Concept 2: Chain of Thought Reasoning

Mathematical Problem Solving

Core Concept 3: Retrieval Augmented Generation (RAG)

Core Concept 4: Agent-Based Reasoning with Tools

Advanced: Modular Composition

The Game-Changer: Automatic Optimization

Real-World Benefits: Why DSPy Matters

1. Maintainability

🧠 Feature 1: `/loop` — Recurring Prompts Inside Your Session

`/loop` vs Scheduled Tasks — Quick Reference