Amazon MQ looks simple on the bill until you pull it apart. Most teams spin up a managed ActiveMQ or RabbitMQ broker, send a few messages, and move on. Then the invoice arrives with line items they didn’t expect.

Let’s break down exactly where the money goes — and what catches people off guard.

The Broker Instance: It’s Not a Flat Rate

Amazon MQ charges per broker instance-hour based on the instance type and engine. There’s no single “broker fee.” The range is wide:

Prices shown for us-east-1, On-Demand.

A common mistake is assuming the smallest broker is “cheap.” Even an mq.t3.micro runs 24/7, costing roughly $25/month before anything else. An mq.m5.large — the default many teams pick — is over $200/month per broker.

High Availability Doubles the Compute Cost

ActiveMQ supports active/standby deployment for high availability. This means two broker instances in different Availability Zones. Your compute cost doubles immediately:

• Single-instance mq.m5.large: $201.48/month
• Active/standby mq.m5.large: $402.96/month

RabbitMQ achieves HA through a three-node cluster deployment, which means you’re paying for three instances. An mq.m5.large RabbitMQ cluster costs roughly $604/month in compute alone.

Teams often enable HA for production brokers and forget about it on dev/staging environments — where a single instance would be fine.

Storage: EBS vs. EFS Is a 3× Price Difference

ActiveMQ brokers on Amazon MQ offer two storage backends:

EFS is required for active/standby deployments since both brokers need access to the same persistent store. That’s a 3× premium over EBS.

A broker with 50 GB of message storage on EFS costs $15/month in storage alone. Not huge, but it adds up across multiple brokers and environments.

RabbitMQ brokers use EBS exclusively — no EFS option.

Data Transfer: The Silent Multiplier

Standard AWS data transfer charges apply to Amazon MQ:

• Same AZ: Free
• Cross-AZ (typical for HA): $0.01/GB each way
• Cross-Region: $0.02/GB
• Internet outbound: $0.09/GB (first 10 TB)

For active/standby deployments, replication traffic between AZs is cross-AZ data transfer. High-throughput brokers processing millions of messages per day can accumulate meaningful cross-AZ charges that don’t appear under the “AmazonMQ” line item on your bill — they show up under general data transfer.

The Real Problem: Idle Brokers

Here’s what actually burns money with Amazon MQ: brokers that nobody is using.

It’s remarkably common. A team provisions a broker for a proof of concept, connects a few services, then the project pivots. The broker sits there at $200+/month with zero messages flowing through it. No consumers, no producers, no connections — just a running instance charging by the hour.

Unlike Lambda or SQS, Amazon MQ has no scale-to-zero capability. A broker with zero messages costs the same as one processing thousands per second.

The pattern we see most often:

1. Dev/staging brokers left running after the sprint ends
2. Migration brokers kept “just in case” after switching to SQS or EventBridge
3. HA-enabled brokers in non-production environments

How to Spot the Waste

Look at these CloudWatch metrics for each broker:

• TotalMessageCount: If this is zero over 7–14 days, the broker is idle
• CurrentConnectionsCount: Zero connections means nothing is even trying to talk to it
• TotalConsumerCount / TotalProducerCount: Both at zero confirms no active clients

If all three are zero for more than a week, you’re paying for a parking spot nobody is using.

CloudWise detects idle Amazon MQ brokers automatically by analyzing CloudWatch connection and message metrics. If your broker has had zero activity for 14 days, CloudWise flags it with the full monthly cost so you can decide whether to keep it or shut it down.

CloudWise automates AWS cost analysis across 145+ waste detectors. Try it at cloudcostwise.io

Every data scientist has the same ritual. Load a CSV. Write df.describe(). Squint at column names. Write 14 lines of pandas to answer one question. Repeat.

What if an LLM could write those 14 lines for you — and run them?

That is exactly what data analysis agents do. You ask a question in English. The agent writes pandas code, executes it in a sandboxed Python environment, reads the output, and returns a plain-language answer. No manual wrangling. No copy-pasting between notebook cells.

Here are 4 patterns that make this work in production — from a 5-line quick start to a fully custom analysis pipeline.

Pattern 1: The Pandas DataFrame Agent

LangChain’s create_pandas_dataframe_agent is the fastest path from CSV to answers. It wraps your DataFrame in a tool-calling agent that writes and executes pandas code through a sandboxed Python REPL.

Install the dependencies:

pip install langchain-experimental langchain-openai pandas

Load your data and create the agent:

import pandas as pd
from langchain_openai import ChatOpenAI
from langchain_experimental.agents.agent_toolkits import (
    create_pandas_dataframe_agent,
)

df = pd.read_csv("sales_data.csv")

llm = ChatOpenAI(model="gpt-4o", temperature=0)

agent = create_pandas_dataframe_agent(
    llm,
    df,
    agent_type="tool-calling",
    verbose=True,
    allow_dangerous_code=True,
)

The allow_dangerous_code=True flag is mandatory. The agent executes real Python code against your DataFrame, so it must be opted into explicitly. Run this only in a sandboxed environment — never on a production server with sensitive data.

Now ask questions:

result = agent.invoke("What are the top 5 products by total revenue?")
print(result["output"])

The agent inspects the DataFrame’s columns and dtypes, writes a pandas expression like df.groupby('product')['revenue'].sum().nlargest(5), executes it, and returns the result as natural language.

Multi-DataFrame support. Pass a list of DataFrames to compare datasets:

df_2024 = pd.read_csv("sales_2024.csv")
df_2025 = pd.read_csv("sales_2025.csv")

agent = create_pandas_dataframe_agent(
    llm,
    [df_2024, df_2025],
    agent_type="tool-calling",
    verbose=True,
    allow_dangerous_code=True,
)

result = agent.invoke(
    "Which products grew more than 20% between 2024 and 2025?"
)

When to use this pattern: Small to medium datasets (under 1 million rows) that fit in memory. Quick exploratory analysis. Prototyping.

Limitation: The agent sends the first few rows and column names to the LLM as context. For wide DataFrames with 100+ columns, this context can overwhelm the model’s attention. For large datasets, use Pattern 2.

Pattern 2: The SQL Agent for Larger Datasets

When your data outgrows a DataFrame — millions of rows, multiple related tables, or anything that benefits from indexing — convert it to SQLite and let a SQL agent handle the queries.

pip install langchain-community langchain-openai sqlalchemy

Load your CSV into SQLite and create the agent:

import pandas as pd
import sqlalchemy
from langchain_community.utilities import SQLDatabase
from langchain_community.agent_toolkits import create_sql_agent
from langchain_openai import ChatOpenAI

engine = sqlalchemy.create_engine("sqlite:///analysis.db")

df_orders = pd.read_csv("orders.csv")
df_customers = pd.read_csv("customers.csv")
df_orders.to_sql("orders", engine, if_exists="replace", index=False)
df_customers.to_sql("customers", engine, if_exists="replace", index=False)

db = SQLDatabase(engine)
print(f"Tables: {db.get_usable_table_names()}")

llm = ChatOpenAI(model="gpt-4o", temperature=0)

agent = create_sql_agent(
    llm,
    db=db,
    agent_type="tool-calling",
    verbose=True,
)

Now ask questions that span multiple tables:

result = agent.invoke(
    "What is the average order value per customer segment?"
)
print(result["output"])

The agent inspects the database schema, writes a SQL query with the appropriate JOINs, executes it, and translates the result into English.

Why SQL beats pandas at scale:

1. Indexing. SQLite creates indexes that make filtering and joining fast. Pandas scans the full DataFrame.
2. Memory. SQLite reads from disk. Pandas loads everything into RAM.
3. Joins. SQL JOINs are declarative and optimized. Pandas merges require explicit column mapping and can be memory-intensive.
4. Audit trail. Every query the agent writes is a valid SQL statement you can review and rerun.

Safety note: The SQL agent generates and executes queries against your database. Use a read-only connection or a copy of your data for analysis. Never point it at a production database with write access.

engine = sqlalchemy.create_engine(
    "sqlite:///analysis.db",
    connect_args={"check_same_thread": False},
)

# For read-only protection, use a copy of the database
# or set PRAGMA query_only = ON
with engine.connect() as conn:
    conn.execute(sqlalchemy.text("PRAGMA query_only = ON"))

Pattern 3: Custom Analysis Tools With Tool-Calling

The pre-built agents handle common cases. But real data analysis needs domain-specific operations — statistical tests, time series decomposition, custom visualizations. Build a custom tool-calling agent that exposes exactly the operations your analysts need.

pip install langchain-openai langgraph scipy

Define your analysis tools as Python functions with clear docstrings — the LLM reads these to decide which tool to call:

import pandas as pd
import json
from scipy import stats
from langchain_openai import ChatOpenAI
from langchain_core.tools import tool

df = pd.read_csv("experiment_results.csv")


@tool
def describe_dataset(column: str) -> str:
    """Get summary statistics for a specific column in the dataset.
    Returns count, mean, std, min, 25%, 50%, 75%, max."""
    if column not in df.columns:
        return f"Column '{column}' not found. Available: {list(df.columns)}"
    return df[column].describe().to_json()


@tool
def compare_groups(
    group_column: str, value_column: str, group_a: str, group_b: str
) -> str:
    """Run a two-sample t-test comparing two groups on a numeric column.
    Returns t-statistic, p-value, and whether the difference is
    statistically significant at alpha=0.05."""
    a = df[df[group_column] == group_a][value_column].dropna()
    b = df[df[group_column] == group_b][value_column].dropna()
    t_stat, p_value = stats.ttest_ind(a, b)
    significant = p_value < 0.05
    return json.dumps({
        "group_a_mean": round(a.mean(), 4),
        "group_b_mean": round(b.mean(), 4),
        "t_statistic": round(t_stat, 4),
        "p_value": round(p_value, 6),
        "significant_at_0.05": significant,
        "n_a": len(a),
        "n_b": len(b),
    })


@tool
def correlation_matrix(columns: list[str]) -> str:
    """Calculate pairwise Pearson correlations between specified columns.
    Returns a correlation matrix as JSON."""
    valid = [c for c in columns if c in df.columns]
    if not valid:
        return f"No valid columns found. Available: {list(df.columns)}"
    corr = df[valid].corr()
    return corr.to_json()


@tool
def filter_and_aggregate(
    filter_column: str,
    filter_value: str,
    agg_column: str,
    agg_function: str,
) -> str:
    """Filter the dataset by a column value, then aggregate another column.
    Supported agg_function values: mean, sum, count, min, max, median."""
    valid_aggs = {"mean", "sum", "count", "min", "max", "median"}
    if agg_function not in valid_aggs:
        return f"Invalid agg_function. Use one of: {valid_aggs}"
    filtered = df[df[filter_column] == filter_value]
    result = getattr(filtered[agg_column], agg_function)()
    return json.dumps({
        "filter": f"{filter_column} == {filter_value}",
        "rows_matched": len(filtered),
        "aggregation": f"{agg_function}({agg_column})",
        "result": round(float(result), 4),
    })

Wire the tools into a tool-calling agent:

from langchain_core.messages import SystemMessage

tools = [describe_dataset, compare_groups, correlation_matrix, filter_and_aggregate]

llm = ChatOpenAI(model="gpt-4o", temperature=0)
llm_with_tools = llm.bind_tools(tools)

system_prompt = """You are a data analysis assistant. You have access to a dataset
with these columns: {columns}

When the user asks a question:
1. Identify which tools can answer it
2. Call the appropriate tool(s)
3. Interpret the results in plain language
4. Note statistical significance, sample sizes, and caveats

Always mention sample sizes when reporting statistical results.""".format(
    columns=list(df.columns)
)

from langgraph.prebuilt import create_react_agent

agent = create_react_agent(llm, tools)

Ask domain-specific questions:

result = agent.invoke({
    "messages": [
        {"role": "system", "content": system_prompt},
        {
            "role": "user",
            "content": "Is there a significant difference in conversion rate between the control and treatment groups?",
        },
    ]
})

print(result["messages"][-1].content)

Why custom tools beat the generic pandas agent:

1. Controlled operations. The agent can only call functions you defined. No arbitrary code execution.
2. Domain language. Tool descriptions use your team’s terminology. The LLM maps natural language to the right operation.
3. Safety. No Python REPL. No allow_dangerous_code. Each tool validates its inputs and returns structured output.
4. Reproducibility. Every tool call is logged with exact parameters. You can replay any analysis.

Pattern 4: Output Validation and Guardrails

An analysis agent that returns wrong numbers is worse than no agent at all. These guardrails catch errors before they reach your stakeholders.

Guardrail 1: Schema validation on tool inputs.

Use Pydantic to enforce that tool arguments match expected types and ranges:

from pydantic import BaseModel, field_validator


class AggregationRequest(BaseModel):
    filter_column: str
    filter_value: str
    agg_column: str
    agg_function: str

    @field_validator("agg_function")
    @classmethod
    def validate_agg(cls, v: str) -> str:
        allowed = {"mean", "sum", "count", "min", "max", "median"}
        if v not in allowed:
            raise ValueError(f"Must be one of {allowed}, got '{v}'")
        return v

    @field_validator("filter_column", "agg_column")
    @classmethod
    def validate_columns(cls, v: str) -> str:
        if v not in df.columns:
            raise ValueError(
                f"Column '{v}' not in dataset. "
                f"Available: {list(df.columns)}"
            )
        return v

Guardrail 2: Result sanity checks.

Wrap your agent’s output with automatic validation:

def validate_numeric_result(result: dict, column: str) -> dict:
    """Check that a computed result falls within the column's actual range."""
    col_min = float(df[column].min())
    col_max = float(df[column].max())
    value = result.get("result")

    if value is not None and not (col_min <= value <= col_max):
        result["warning"] = (
            f"Result {value} is outside the column range "
            f"[{col_min}, {col_max}]. Verify the calculation."
        )
    return result

Guardrail 3: Row count assertions.

Catch empty results before they produce misleading statistics:

def safe_aggregate(
    filtered_df: pd.DataFrame,
    column: str,
    operation: str,
    min_rows: int = 5,
) -> dict:
    """Aggregate with a minimum sample size requirement."""
    n = len(filtered_df)
    if n == 0:
        return {"error": "Filter returned zero rows. Check filter criteria."}
    if n < min_rows:
        return {
            "warning": f"Only {n} rows matched (minimum {min_rows}). "
            "Results may not be statistically meaningful.",
            "result": getattr(filtered_df[column], operation)(),
            "n": n,
        }
    return {
        "result": getattr(filtered_df[column], operation)(),
        "n": n,
    }

Guardrail 4: Query logging for audit.

Log every tool call so analysts can verify what the agent actually computed:

import logging
from datetime import datetime, timezone

logger = logging.getLogger("analysis_agent")
handler = logging.FileHandler("agent_audit.log")
handler.setFormatter(
    logging.Formatter("%(asctime)s | %(message)s")
)
logger.addHandler(handler)
logger.setLevel(logging.INFO)


def log_tool_call(tool_name: str, params: dict, result: dict):
    logger.info(
        f"TOOL={tool_name} | PARAMS={params} | "
        f"RESULT_KEYS={list(result.keys())} | "
        f"TIMESTAMP={datetime.now(timezone.utc).isoformat()}"
    )

These guardrails are not optional extras. In any workflow where analysis drives decisions — A/B test results, revenue forecasts, user segmentation — a wrong number costs more than a slow answer.

Which Pattern Fits Your Data

Start with Pattern 1 to prototype. Move to Pattern 2 when data gets large. Move to Pattern 3 when you need control. Add Pattern 4 when wrong answers have consequences.

What to Watch Out For

Code execution risks. Patterns 1 and 2 execute generated code. Run them in Docker containers or sandboxed environments — never on the same machine as production data without isolation.

LLM hallucination in analysis. The agent can write syntactically valid pandas code that answers the wrong question. Always log the generated code (verbose=True) and spot-check against manual queries.

Token costs scale with data context. The pandas agent sends column names, dtypes, and sample rows to the LLM on every call. Wide DataFrames with 100+ columns burn tokens fast. Use Pattern 3’s targeted tools to control exactly what context the LLM sees.

Statistical literacy. The LLM knows how to call scipy.stats.ttest_ind. It does not always know when a t-test is the wrong test for your data distribution. Domain expertise still matters — the agent accelerates the workflow, it does not replace the analyst.

Every analyst spends more time wrangling data than analyzing it. These 4 patterns shift that ratio. The LLM handles the pandas syntax, the SQL joins, and the boilerplate. You handle the questions that matter.

Follow @klement_gunndu for more AI engineering content. We’re building in public.

Last week, a maintainer at LlamaIndex closed our pull request. Not because of code quality. Not because of test failures. The reason: “We are pausing contributions that contribute net-new packages.”

This is a story about what happens when open-source frameworks become gatekeepers in the agent ecosystem — and why it matters less than you’d think.

What we built

GPU-Bridge is an inference API — 30 services, 98 models, 8 backends. We built a LlamaIndex integration package that added:

• Custom embeddings provider (BGE-M3, Qwen3-Embedding, E5-Large via our unified API)
• Reranker integration (Jina, BGE via single endpoint)
• Standard LlamaIndex interfaces, full test coverage, docs

The PR (#21014) followed their contribution guidelines. Tests passed. The integration worked.

What happened

Logan (logan-markewich), a core maintainer, closed it with a clear explanation: they’re pausing all net-new package contributions. Not a quality judgment — a policy freeze.

Fair enough. Their repo, their rules.

Why this matters

LlamaIndex has become infrastructure for thousands of agent builders. When they freeze contributions, they’re not just managing their codebase — they’re deciding which services get first-class status in the agent ecosystem.

This is the tension at the heart of open source in AI:

1. Frameworks become platforms. LlamaIndex started as a library. Now it’s a platform that shapes which tools agents can easily use.

2. Contribution freezes are invisible moats. The existing integrations (OpenAI, Cohere, Pinecone) are grandfathered in. New providers need to wait. The longer the freeze, the wider the gap.

3. The code doesn’t care about the PR status. Our integration works. You can install it independently. The PR was about convenience and discoverability, not functionality.

The real question

Should agent frameworks curate their integration ecosystem, or should they be open rails?

There’s a legitimate argument for curation: quality control, maintenance burden, security reviews. LlamaIndex has hundreds of integration packages. Each one is a surface area for bugs, breaking changes, support requests.

There’s also a legitimate argument for openness: the value of an agent framework is proportional to what it can connect to. Every closed PR is a connection that didn’t happen.

What we did instead

We published the integration as a standalone npm package. It works with LlamaIndex without being in their monorepo. We listed on MCP Registry, Smithery, Glama (triple-A security/license/quality rating). We built direct REST endpoints that don’t need any framework at all.

The lesson: don’t build your distribution strategy on a single framework’s merge queue.

For other infrastructure providers

If you’re building compute, storage, or any other service that agents need:

1. Ship standalone packages first. Framework integrations are a bonus, not a requirement.
2. Protocol > platform. MCP, x402, A2A — these are open protocols that no single maintainer can freeze.
3. Direct API access is the floor. If an agent can make an HTTP request, they can use your service. Everything else is convenience.

The agent ecosystem is young enough that today’s framework decisions shape tomorrow’s defaults. Build for the protocols, and the frameworks will follow.

GPU-Bridge provides unified inference across 98 models and 30 services, with native x402 payments for autonomous agents. gpubridge.io

I ran a single command against my Claude Code skills directory last week. Out of 47 skills I’d written over three months, 31 had structural problems that degraded how often Claude actually triggered them. Two had never fired at all. Their descriptions were so vague that Claude’s skill-matching logic couldn’t determine when to use them.

The fix took 20 minutes once I knew what was wrong. Here’s the full setup.

TL;DR: npx pulser@latest audits your Claude Code skills against Anthropic’s documented principles — frontmatter structure, description specificity, body quality, reference coverage. It scores each skill 0–100, flags exact issues, and generates fix commands. 73% of 214 community skills I tested scored below 60. Free, open-source, MIT-licensed, runs in under 5 seconds.

The Problem: Skills That Silently Fail

Claude Code skills fail silently. A bad SKILL.md doesn’t throw an error — it just never gets invoked. The description field in your frontmatter is what Claude uses at runtime to decide whether to activate a skill. Too vague, and Claude skips it. Every time. No warning.

I spent two weeks wondering why my api-testing skill wasn’t firing during debugging sessions. The description read:

description: Helps with API testing

Five words. Claude had no idea when to use it. The fix was embarrassingly simple:

yaml
description: This skill should be used when the user asks to “test an API endpoint”, “write integration tests for REST APIs”, “debug a failing HTTP request”, or “generate API test fixtures”. Activate when the conversation involves HTTP status codes, request/response payloads, or API authentication flows.

The difference between a working skill and a dead one is often a single frontmatter field. When you have 30, 50, or 100+ skills across plugins, manual auditing doesn’t scale. That’s why I built pulser.

What pulser Actually Checks

pulser reads your SKILL.md files and validates them against 14 weighted criteria drawn directly from Anthropic’s official plugin development documentation. Not guessing at best practices — checking against the published source. Each skill receives a 0–100 score based on frontmatter completeness, description quality, body structure, and reference coverage.

1. Frontmatter Validation

The minimum viable frontmatter needs name and description. But “minimum viable” and “actually works reliably” are different things.

npx pulser@latest ./my-plugin/skills/

Output for a broken skill:

  ✗ api-testing                              22/100
    ├─ WARN  description too short (5 words, need 20+)
    ├─ FAIL  no trigger phrases in description
    ├─ WARN  missing version field
    └─ INFO  no references/ directory found

  ✓ hook-management                          87/100
    ├─ PASS  description contains 4 trigger phrases
    ├─ PASS  frontmatter complete
    └─ INFO  3 reference files detected

**pulser checks 14 frontmatter attributes**, weighted by their measured impact on skill invocation reliability:

| Check | Weight | What It Catches |
|-------|--------|-----------------|
| Description length | 20% | Under 20 words = Claude can't match it |
| Trigger phrases | 25% | No quoted phrases = no reliable activation |
| Name present | 10% | Missing name = skill won't load |
| Description format | 15% | First-person instead of third-person |
| Version field | 5% | Missing = no change tracking |
| Body content length | 15% | Under 200 words = insufficient guidance |
| Reference files | 10% | No examples = Claude guesses patterns |

### 2. Description Quality Analysis

**The most critical check: descriptions must use third-person format and include exact quoted phrases that users would say.** This is in Anthropic's plugin development guidelines. It's also where 68% of community skills fail.

Bad:

yaml
description: A skill for handling database migrations

Good:

description: This skill should be used when the user asks to "create a migration", "run database migrations", "rollback a migration", or "check migration status". Activate for any task involving schema changes, Prisma migrate, or Knex migrations.

pulser counts quoted trigger phrases, checks for third-person voice, and measures description specificity. **A description without trigger phrases scores 0 on the most heavily weighted check — that's 25% of your total score, gone.**

### 3. Body Content Scoring

**The body of `SKILL.md` is the actual instruction set Claude follows when the skill activates.** pulser evaluates four dimensions:

- **Word count**: Under 200 words means Claude is flying blind. Over 3,000 means you probably need to split content into reference files.
- **Code block presence**: Skills without code examples force Claude to improvise patterns from scratch.
- **Section structure**: Headers, lists, and structured content score higher than walls of prose.
- **Actionable instructions**: Lines starting with imperative verbs ("Use", "Create", "Check") score higher than descriptive text.

Body Analysis: api-testing/SKILL.md
  Words: 142 (WARN: below 200 minimum)
  Code blocks: 0 (FAIL: no examples)
  Sections: 1 (WARN: no sub-sections)
  Imperative ratio: 0.12 (WARN: mostly descriptive)
  Score: 18/100

### 4. The eval Subcommand

**`pulser eval` detects whether skills fire correctly in realistic scenarios — without manually testing every prompt combination.** It sends synthetic prompts to your skill set and checks whether Claude activates the right skill. This is what caught my two permanently-dead skills.

bash
npx pulser@latest eval ./skills/ –prompts 10

Evaluating skill activation with 10 synthetic prompts…

“Create a new database migration for adding user roles”
Expected: database-migrations Actual: database-migrations ✓

“Help me debug this flaky test”
Expected: debugging Actual: (none) ✗
→ No skill matched. Check debugging/SKILL.md description.

“Set up a pre-commit hook for linting”
Expected: hook-management Actual: git-workflow ✗
→ Wrong skill activated. Descriptions overlap.

Results: 7/10 correct (70%)
2 skills never activated
1 skill conflict detected

Skill conflicts are the silent killer. Two skills with overlapping descriptions compete, and Claude picks whichever seems closest — which might be wrong. This is how git-workflow eats prompts meant for hook-management.

5. The Prescriber

Once pulser identifies issues, it generates exact fixes:

npx pulser@latest --prescribe ./skills/

Prescriptions for api-testing/SKILL.md:

  1. Replace description with:
     ---
     description: This skill should be used when the user asks to
     "test an API endpoint", "write API integration tests",
     "mock HTTP responses", or "validate API contracts". Activate
     when the task involves REST, GraphQL, HTTP clients, or
     API authentication.
     ---

  2. Add version field:
     version: 1.0.0

  3. Create references/ directory with:
     - references/rest-patterns.md
     - references/auth-flows.md

  4. Add code examples to body (minimum 2 blocks)

The generated descriptions aren't perfect — you'll want to customize the trigger phrases for your actual workflow. **But a prescriber-generated description is a massive upgrade over "Helps with API testing," and it typically pushes a skill past the 70-point threshold where reliable activation begins.**

## What I'd Do Differently

**I should have built eval first.** I started with frontmatter validation because it was measurable and straightforward, but eval catches the problems that actually matter — skills that don't fire when they should. A skill can score 90/100 on frontmatter and still be functionally dead.

**I over-indexed on word count.** Early versions penalized short skills too heavily. Some skills genuinely need to be brief — a 150-word skill that's all actionable instructions beats a 500-word skill that's mostly context. v0.4.0 weighs *instruction density* instead of raw word count.

**The prescriber needs user context.** Right now it generates generic trigger phrases. A future version should analyze actual conversation history to suggest phrases you *actually use* when you want a particular skill.

## The Numbers

### Cost Comparison

| Approach | Cost | Time per Skill | Catches Conflicts |
|----------|------|----------------|-------------------|
| Manual review | $0 | 2–3 minutes | No |
| pulser audit | $0 | ~0.3 seconds | No |
| pulser eval | $0 | ~2 seconds | Yes |
| Paid linter + manual QA | $20+/month | ~1 minute | Sometimes |

### Audit Results Across 214 Community Skills

| Metric | Value |
|--------|-------|
| Skills audited | 214 |
| Average score | 48/100 |
| Skills scoring below 60 | 73% |
| Missing trigger phrases | 68% |
| Description under 20 words | 41% |
| No code examples in body | 55% |
| Missing version field | 62% |
| Skill conflicts detected (eval) | 12 pairs |
| Time to audit all 214 | 47 seconds |

**The #1 failure mode: vague descriptions with no trigger phrases (68% of audited skills).** It's also the highest-impact fix — adding quoted trigger phrases typically raises a skill's score by 20–35 points in a single edit.

## FAQ

### Does pulser modify my files?

**No — pulser is read-only by default.** The `--prescribe` flag generates suggestions but writes nothing. Your skills stay untouched until you decide to apply changes.

### What's the minimum score I should target?

**70 is the reliability threshold.** Below 60, you're gambling on whether Claude picks up the skill. Above 80, you're consistently solid. I've seen skills score 95+ and still have edge cases — don't chase perfection, chase "fires when it should."

### Does this work with the new plugin system?

**Yes — pulser reads any `SKILL.md` file regardless of directory structure.** It works with both the legacy `~/.claude/skills/` layout and proper plugin structures under `.claude-plugin/`. It follows the directory convention from Anthropic's plugin-dev reference: `skills/skill-name/SKILL.md` with optional `references/`, `examples/`, and `scripts/` subdirectories.

### Can I run this in CI?

**Yes — `npx pulser@latest` returns a non-zero exit code when skills fall below a configurable threshold.** I run it as a pre-commit check on every plugin repo.

yaml

.github/workflows/skill-lint.yml

• name: Audit skills
  run: npx pulser@latest ./skills/ –min-score 65 –exit-code

How is this different from just reading Anthropic’s docs?

It’s the difference between knowing the speed limit and having a speedometer. The docs tell you what good looks like. pulser tells you where your skills fall short right now — with scores, flagged lines, and fix suggestions. I read Anthropic’s docs three times before building this and still shipped 31 broken skills out of 47.

Try It

30 seconds to your first audit:

npx pulser@latest ./path/to/skills/

Then dig deeper:

bash

Check for skill conflicts

npx pulser@latest eval ./skills/ –prompts 20

Generate fixes for anything below 70

npx pulser@latest –prescribe –min-score 70 ./skills/

Add to CI to prevent regressions

npx pulser@latest ./skills/ –min-score 65 –format json –exit-code

Most skills jump 20–30 points just from fixing the description field. Re-run after fixes to see the difference.

What’s the worst score you’ve found in your own setup? I had a skill with a 4-word description and zero code examples — it scored 8/100. Drop your worst score in the comments.

If this saved you debugging time, run npx pulser@latest before your next skill lands in production. Your future self will thank you.

I write about AI tooling, Claude Code workflows, and the unglamorous parts of making LLMs actually work. Follow me here — next post covers how to structure skill references so Claude stops hallucinating file paths.

pulser is free, open-source, and MIT-licensed. Contributions and bug reports welcome on GitHub.

From “Prove It in Code” to “Prove It in Judgment”

For decades, credibility in software came from what you built with your own hands. Writing robust systems required stamina, coordination, and deep technical craft. The effort itself acted as a filter; only ideas worth the cost were implemented.
That constraint is gone.

Today, large language models can generate entire services, documentation, tests, and deployment scripts in minutes. The barrier to producing software artefacts has collapsed. The limiting factor is no longer typing speed or knowledge of syntax; it is clarity of thinking.

Inside an organisation adopting AI, this shift is profound. A team can spin up a prototype payments reconciliation service over a weekend using AI assistance. But the real question becomes: Who defined the problem well? Who validated the trade-offs? Who understands the system well enough to maintain it?
Code is abundant. Judgment must not become scarce.

When Output Becomes Cheap, Signal Changes

Well-structured codebases and thorough documentation used to be signals of maturity and care. Today, AI tools can generate pristine README files, polished APIs, and layered architectures instantly.
This makes surface quality an unreliable proxy for depth.
Within an AI-enabled engineering team, you might see beautiful documentation generated in seconds, clean abstractions suggested by the model, and automated test scaffolding created in bulk, but none of these guarantee that the system handles scale, edge cases, or operational realities.

An AI can generate an event-driven order processing service, complete with retry logic, dead-letter queues, and idempotency keys, and the code will look immaculate. But does it handle message ordering under partition rebalancing? Does the retry backoff account for downstream rate limits? A model can scaffold a Kubernetes deployment manifest with health checks, resource quotas, and horizontal pod autoscaling, yet miss that the pod affinity rules will starve a specific availability zone under real traffic patterns.

The signal of quality shifts from how polished it looks to something harder to fake: Does the team understand the system deeply? Is there ownership and accountability? Can someone explain why the circuit breaker threshold is set to 60% and not 40%, without re-prompting the model?
In AI adoption, governance and provenance become more valuable than aesthetics.

The Compression of Effort

AI drastically reduces the mechanical cost of building software. Tasks that once required weeks, writing gRPC service definitions with protobuf schemas, building CDC pipelines to sync state across bounded contexts, and standing up end-to-end integration test harnesses with containerised dependencies can now be compressed into hours.
This is not hype. It is leverage. Used correctly, AI frees engineers to spend more time on architecture and systems thinking, explore multiple design alternatives quickly, and run experiments that previously felt too expensive. In an organisation adopting AI at scale, this means faster iteration cycles and broader experimentation: scaffolding a complete OAuth2 flow with PKCE, token rotation, and role-based access control in an afternoon instead of a sprint; generating contract tests between fifteen microservices to catch breaking changes before deployment; spinning up a feature-flagged canary release pipeline to compare two ranking algorithms in production traffic. Teams can prototype an entire event-sourced domain model, evaluate its query performance against a traditional CRUD approach, and make an informed architectural decision all before the old process would have finished the design document.
However, speed without discipline produces fragile systems. The advantage goes to teams that combine AI acceleration with experienced technical oversight.

The Risk: Infinite Artefacts, Finite Understanding

If software can be generated endlessly, its perceived value drops. A pull request that took weeks of focused effort once carried an implicit sense of respect. Now, large AI-generated diffs may appear instantly with unclear human involvement.
This creates tension. Reviewing becomes harder than generating. Accountability becomes blurry. Junior engineers may rely on tools without building fundamentals.

For organisations, the real danger is not “bad AI code.” It is teams that lose the ability to reason about systems independently.
If AI writes the data pipeline, optimises the SQL, and configures the infrastructure, but no one fully understands the flow, technical debt becomes invisible.

AI adoption must therefore include a strong review culture, explicit learning paths, and clear architectural ownership. Otherwise, productivity gains today become fragility tomorrow.

Talk Becomes the Multiplier

In this new landscape, the most valuable skill is not typing code, it is articulating intent`
The engineer who can frame a problem precisely, define constraints clearly, ask the right questions, and evaluate model output critically will outperform someone who merely executes.
AI does not eliminate engineering roles. It amplifies differences in clarity and systems thinking. Organisational structures compress too – design, coding, testing, and iteration increasingly blur into tight feedback loops.

The Future Is Thinking-First

The future of software development is not code-first. It is thinking-first.
When machines can generate implementation at scale, the competitive edge shifts to strategic problem definition, technical stewardship, responsible governance, and mentorship that builds foundational skill.
Code may be cheap now. But reasoning, accountability, and leadership are not.

Got any questions? Drop a comment

Pavan leads multiple engineering departments at Moniepoint

In March 2026, Delve.co was found to have fabricated 494 SOC 2 reports. Pre-written auditor conclusions. Identical templates across hundreds of clients. It went completely under the radar because the evidence was a PDF. You either opened and trust what you read or you didn’t.

That’s not a Delve problem(though what people did find in those reports is truly wild). That’s an architecture problem. Compliance evidence today can’t prove itself. It can and should, by design.

Built pip install agentmint for teams to build their own receipts:

The Receipt

AgentMint generates this for every agent action — allowed or blocked:

{
  "receipt_id": "7d92b1a4",
  "agent": "sre-bot",
  "action": "delete:database:production",
  "in_policy": false,
  "reason": "no scope pattern matched",
  "signature": "Ed25519:a3f9c8e2...",
  "prev_hash": "sha256:e7f2a1b3...",
  "timestamp_rfc3161": "MIIb3gYJKoZI..."
}

Three things make this unfakeable:

Ed25519 Signature — covers the entire receipt. Change one character, signature breaks. Verifiable with the public key alone. No API call. No vendor. No internet.

SHA-256 Hash Chain — each receipt includes the hash of the previous one. Gaps, insertions, or reordering break the chain. Delve’s 494 reports had no linkage — no way to detect if a report was modified or fabricated after the fact.

RFC 3161 Timestamp — an independent authority signs the receipt hash with its own clock. Proves the receipt existed at a specific time, even if your servers are compromised.

What Happens When Someone Tampers

$ # Receipt says action was denied (in_policy: false)
$ # Attacker changes it to look approved
$ sed -i 's/"in_policy": false/"in_policy": true/' receipt.json

$ python3 verify_sigs.py

  ✓ c391e43c  read:logs:prod  (in policy)
  ✗ FAILED  7d92b1a4  delete:database:production  (in policy)

  Signatures: 1 verified, 1 failed
  ↳ One bit changed. Signature broken. Receipt tampered.

The math is mathing or it isn’t. No trust required.

What’s NOT in the Receipt

Same principle as Merkle trees — the chain is all hashes and metadata, never the underlying data. Which agent, what action, in-policy or not, timestamps, signatures. No customer data. No PII. No credentials. Nothing confidential.

Delve leaked a Google spreadsheet with confidential client reports. AgentMint receipts contain nothing that can be leaked.

How It Maps to Compliance

One receipt chain covers the common denominator across frameworks: who did what, when, was it authorized, and can you prove it.

SOC 2, HIPAA, EU AI Act, AIUC-1, ISO 27001, GDPR — the same signed, hash-chained evidence satisfies audit trail requirements across all of them. Full mapping in COMPLIANCE.md.

Try It

from agentmint import AgentMint

mint = AgentMint(quiet=True)
plan = mint.issue_plan(
    action="read:reports:quarterly",
    user="[email protected]",
    scope=["read:reports:*"],
    delegates_to=["analytics-agent"],
)

result = mint.delegate(plan, "analytics-agent", "delete:reports:quarterly")
# result.status.value → 'checkpoint_required'
# result.receipt — signed denial, hash-chained, timestamped

$ bash VERIFY.sh evidence/
  Timestamps: 2 / 2 verified
  Signatures: 2 verified, 0 failed
  Flagged: 1 out-of-policy

pip install agentmint — GitHub

If Your Compliance Evidence Can’t Survive the Vendor Disappearing, It Was Never Evidence

AgentMint is open source. The receipts are yours. They verify with openssl alone and never expire — even if AgentMint does.

If you were affected by Delve or need compliance evidence that proves itself, I embed with your team and get this running in 2-3 weeks. You keep everything.

Book 15 min · DM me on LinkedIn

Built by Aniketh Maddipati. NYC. Runtime enforcement for AI agents.

Multi-Agent Orchestration: The Art of the Handoff

After running multi-agent systems for months, I have learned that the magic is not in individual agents. It is in the handoffs.

The Problem with Single Agents

Most people approach AI agents like this:

• Build one smart agent that does everything
• Give it all the tools
• Hope it figures it out

This approach fails. Here is why:

1. Context overload – The agent accumulates too much state
2. Role confusion – It is not clear what the agent should prioritize
3. Debugging nightmare – When something breaks, you do not know why

The Better Approach: Specialization + Handoffs

Instead of one super-agent, I run a system where:

• Each agent has ONE job
• Each handoff is a contract
• Context passes cleanly between agents

The Content Flywheel

Here is how it works in practice:

CONTENT → finds insights, does research
VOICE → drafts, edits, polishes

REVENUE → monetizes, tracks, optimizes
DISTRIBUTION → posts, shares, engages

Each agent in this chain:

• Knows exactly what it needs to produce
• Receives clear input from the previous agent
• Produces clear output for the next agent

The Handoff Contract

The key insight: each handoff is a contract.

When CONTENT finishes, it does not just dump data. It produces:

• The insight itself
• Supporting evidence
• Suggested angles for VOICE to explore
• Clear next steps

This way, VOICE does not have to re-research. It just writes.

What I have Learned

1. Fewer agents, more handoffs – 4 specialized agents beat 1 super-agent
2. Clear contracts matter – Vague handoffs = vague output
3. Each agent needs constraints – Without boundaries, agents drift
4. Human review points – Build checkpoints where humans verify output

The Result

This system runs 24/7 without burning out. It produces content that sounds like me—because I designed the contracts, not the sentences.

If you are building AI systems, stop asking how do I make one agent smarter?

Start asking: how do I make agents pass context cleanly?

That is where the real power is.

Running multi-agent systems at scale. Follow for more insights on AI infrastructure.

Every week, developers get told the same thing:

Use this new AI tool.
Automate this workflow.
Deliver faster.
Do more.

But I think the real gap in 2026 is not access to tools.

It’s judgment.

Knowing:

when AI output is good enough
when it is risky
when it needs human review
when speed is creating future tech debt
when “it works” is not the same as “it’s ready”

That matters because Google’s guidance for AI search experiences says there are no extra requirements to appear in AI Overviews beyond the usual SEO basics, and it emphasizes creating helpful, reliable, people-first content. It also says AI-generated content can perform well when it is original, high-quality, and trustworthy.

The same thing is true in software.

AI can speed up output.
But it cannot replace engineering judgment.

And honestly, that might become the most valuable developer skill of all.

Do you think AI is raising the value of engineering judgment or making people overconfident too early?