Forem: Bilal Saeed

MCP Hit 97 Million Downloads in One Year. Security Researchers Say It Wasn't Ready.

Bilal Saeed — Wed, 07 Jan 2026 16:36:47 +0000

Model Context Protocol downloads exploded from 100,000 in November 2024 to 97 million monthly by year's end. That's a 970x growth rate that made MCP the fastest-adopted protocol in AI history.

But here's what most adoption stories aren't telling you: the protocol prioritized interoperability over security from day one.

The Numbers Look Incredible on Paper

OpenAI, Google, Microsoft, AWS—they all adopted MCP within months of its launch. The ecosystem now includes over 10,000 published servers covering everything from developer tools to Fortune 500 deployments. Boston Consulting Group called it "a deceptively simple idea with outsized implications."

The market projections reflect this momentum. Analysts estimate the MCP ecosystem will grow from $1.2 billion to $4.5 billion by the end of 2025. Some predict 90% of organizations will be running MCP integrations. Block, Bloomberg, Amazon, and hundreds of enterprise customers have already deployed it in production.

So what's the problem?

Security Came Second

In April 2025, security researchers at Palo Alto Networks identified five critical attack vectors: prompt injection, tool shadowing, privilege escalation, data exfiltration, and what they called "rug pull" attacks. The last one is particularly insidious—MCP tools can silently change their definitions after installation. You approve something safe-looking on Monday, and by Friday it's routing your API keys to an attacker.

The official MCP specification says there "SHOULD always be a human in the loop." Security experts at Strobes responded bluntly: treat that SHOULD as a MUST.

June 2025 brought CVE-2025-6514, a critical vulnerability (CVSS 9.6) in mcp-remote—a popular OAuth proxy with over 437,000 downloads. The flaw turned every unpatched installation into a supply chain backdoor. Attackers could execute arbitrary commands, steal cloud credentials, and grab SSH keys just by pointing an LLM host at a malicious endpoint.

Red Hat published its own analysis noting that MCP servers store OAuth tokens for services like Gmail, Google Drive, and corporate resources. Compromise one server, and you get keys to everything. Traditional account breaches trigger notifications. Token theft through MCP often looks like legitimate API access.

The December Pivot Changes the Game

On December 9, 2025, Anthropic donated MCP to the newly formed Agentic AI Foundation under the Linux Foundation. OpenAI, Google, Microsoft, AWS, Block, Bloomberg, and Cloudflare signed on as founding members.
This matters for one simple reason: enterprises don't bet on protocols controlled by single vendors. They bet on open standards with transparent governance.

The move signals that MCP is transitioning from rapid experimentation to actual infrastructure. Jim Zemlin, Linux Foundation's Executive Director, put it directly: "Bringing these projects together under the AAIF ensures they can grow with the transparency and stability that only open governance provides."

But governance alone won't fix the security gaps. The specification is maturing—the June 2025 update adopted OAuth 2.1 principles for authentication, and the November release added new primitives for long-running tasks. Still, as one researcher noted, "hundreds of MCP servers on the web today are misconfigured, unnecessarily exposing users of AI apps to cyberattacks."

What This Means for Your AI Strategy

MCP adoption isn't optional anymore. The integration efficiency gains are real—BCG found that without MCP, integration complexity rises quadratically as AI agents spread through an organization. With MCP, it increases linearly. That's a significant operational advantage.
The question isn't whether to adopt, but how to do it without creating new attack surfaces.

Three things worth considering:

First, audit every MCP server before deployment and implement allowlisting. Community-built servers vary wildly in quality and security posture.

Second, don't trust tool definitions that change. Any MCP client should alert users when server definitions evolve—if yours doesn't, that's a red flag.

Third, treat the human-in-the-loop guidance as mandatory, not optional. The protocol's flexibility is exactly what makes autonomous agent actions dangerous without explicit consent mechanisms.

MCP represents a fundamental shift in how AI systems connect to enterprise tools. The growth trajectory is undeniable. But the gap between adoption velocity and security maturity should make every technical leader pause.

What's your organization's approach to MCP security—are you building safeguards into your adoption strategy, or racing to catch up?

Sources:

Linux Foundation AAIF Announcement: https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation

MCP Official Blog - One Year Anniversary: https://blog.modelcontextprotocol.io/posts/2025-11-25-first-mcp-anniversary/

Palo Alto Networks MCP Security Research: https://unit42.paloaltonetworks.com/model-context-protocol-attack-vectors/

Red Hat Security Analysis: https://www.redhat.com/en/blog/model-context-protocol-mcp-understanding-security-risks-and-controls
eSentire CISO Security Guide: https://www.esentire.com/blog/model-context-protocol-security-critical-vulnerabilities-every-ciso-should-address-in-2025

Building Your First MCP Server: A Developer's Honest Guide

Bilal Saeed — Tue, 30 Dec 2025 12:34:11 +0000

8 million downloads. 5,800+ servers in the ecosystem. Every major AI company on board.

Model Context Protocol is everywhere right now. But most tutorials skip the parts that actually trip you up in production. After building three MCP servers for internal tools at my company, I want to share what I wish someone had told me on day one.

What MCP Actually Does (Skip If You Know This)

MCP standardizes how AI models talk to external tools. Before MCP, connecting Claude or GPT to your database meant writing custom integration code. Every. Single. Time. Different formats, different auth flows, different everything.

MCP fixes that with a simple client-server architecture over JSON-RPC 2.0. Your AI assistant becomes the client. Your data sources become servers. One protocol handles the communication.

Think of it like USB-C for AI integrations. Plug anything into anything.

The Architecture You'll Actually Build

Here's the mental model that clicked for me:

┌─────────────────┐ JSON-RPC 2.0 ┌─────────────────┐
│ │ ◄──────────────────► │ │
│ MCP Client │ │ MCP Server │
│ (Claude, GPT) │ stdio / HTTP │ (Your Code) │
│ │ ◄──────────────────► │ │
└─────────────────┘ └─────────────────┘
│
▼
┌─────────────────┐
│ Your Database │
│ APIs, Files │
│ Whatever │
└─────────────────┘

The server exposes three things: Tools (functions the AI can call), Resources (data the AI can read), and Prompts (reusable templates). Most tutorials focus on tools. That's where we'll start.

Setting Up a Real MCP Server

Let's build something useful: a server that queries your PostgreSQL database. Not a toy example—something you'd actually deploy.

First, install the SDK:

npm install @modelcontextprotocol/sdk pg

Now the server skeleton:

// src/index.ts
import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import {
  CallToolRequestSchema,
  ListToolsRequestSchema,
} from "@modelcontextprotocol/sdk/types.js";
import { Pool } from "pg";

// Database connection
const pool = new Pool({
  connectionString: process.env.DATABASE_URL,
});

// Initialize the MCP server
const server = new Server(
  {
    name: "postgres-query-server",
    version: "1.0.0",
  },
  {
    capabilities: {
      tools: {},
    },
  }
);

// Define available tools
server.setRequestHandler(ListToolsRequestSchema, async () => {
  return {
    tools: [
      {
        name: "query_database",
        description: "Execute a read-only SQL query against the database",
        inputSchema: {
          type: "object",
          properties: {
            query: {
              type: "string",
              description: "SQL SELECT query to execute",
            },
          },
          required: ["query"],
        },
      },
      {
        name: "list_tables",
        description: "List all tables in the database",
        inputSchema: {
          type: "object",
          properties: {},
        },
      },
    ],
  };
});

// Handle tool execution
server.setRequestHandler(CallToolRequestSchema, async (request) => {
  const { name, arguments: args } = request.params;

  if (name === "query_database") {
    return await executeQuery(args.query as string);
  }

  if (name === "list_tables") {
    return await listTables();
  }

  throw new Error(`Unknown tool: ${name}`);
});

async function executeQuery(query: string) {
  // Security: Only allow SELECT statements
  const normalizedQuery = query.trim().toUpperCase();
  if (!normalizedQuery.startsWith("SELECT")) {
    return {
      content: [
        {
          type: "text",
          text: "Error: Only SELECT queries are allowed for safety.",
        },
      ],
    };
  }

  try {
    const result = await pool.query(query);
    return {
      content: [
        {
          type: "text",
          text: JSON.stringify(result.rows, null, 2),
        },
      ],
    };
  } catch (error) {
    return {
      content: [
        {
          type: "text",
          text: `Query error: ${error.message}`,
        },
      ],
    };
  }
}

async function listTables() {
  const query = `
    SELECT table_name 
    FROM information_schema.tables 
    WHERE table_schema = 'public'
    ORDER BY table_name;
  `;

  try {
    const result = await pool.query(query);
    const tables = result.rows.map((row) => row.table_name);
    return {
      content: [
        {
          type: "text",
          text: `Available tables:\n${tables.join("\n")}`,
        },
      ],
    };
  } catch (error) {
    return {
      content: [
        {
          type: "text",
          text: `Error listing tables: ${error.message}`,
        },
      ],
    };
  }
}

// Start the server
async function main() {
  const transport = new StdioServerTransport();
  await server.connect(transport);
  console.error("Postgres MCP server running on stdio");
}

main().catch(console.error);

That's about 120 lines for a working database query server. Not bad.

The Part Everyone Skips: Configuration

Your shiny new server won't do anything until you tell Claude Desktop (or whatever client) where to find it. This config file lives at

~/Library/Application Support/Claude/claude_desktop_config.json

on Mac:

{
  "mcpServers": {
    "postgres": {
      "command": "node",
      "args": ["/absolute/path/to/your/dist/index.js"],
      "env": {
        "DATABASE_URL": "postgresql://user:pass@localhost:5432/mydb"
      }
    }
  }
}

Restart Claude Desktop after editing this. I've lost count of how many times I forgot that step and wondered why nothing worked.

Where Things Get Tricky

Here's the stuff that bit me in production.

*Problem 1: Error Handling That Actually Helps
*
The basic example above returns generic error messages. In practice, you want structured errors the AI can reason about:

interface QueryError {
  code: string;
  message: string;
  suggestion?: string;
}

function formatError(error: any): QueryError {
  // PostgreSQL-specific error codes
  if (error.code === "42P01") {
    return {
      code: "TABLE_NOT_FOUND",
      message: `Table does not exist: ${error.message}`,
      suggestion: "Use list_tables to see available tables",
    };
  }

  if (error.code === "42703") {
    return {
      code: "COLUMN_NOT_FOUND",
      message: `Column does not exist: ${error.message}`,
      suggestion: "Check column names in the table schema",
    };
  }

  if (error.code === "28P01") {
    return {
      code: "AUTH_FAILED",
      message: "Database authentication failed",
      suggestion: "Check DATABASE_URL environment variable",
    };
  }

  return {
    code: "UNKNOWN_ERROR",
    message: error.message || "An unexpected error occurred",
  };
}

The AI can now understand why something failed and suggest fixes. This matters more than you'd think.

Problem 2: Query Timeouts

Long-running queries will hang your server. Always set timeouts:

async function executeQuery(query: string) {
  const client = await pool.connect();

  try {
    // Set a 30-second timeout for this query
    await client.query("SET statement_timeout = 30000");

    const result = await client.query(query);
    return {
      content: [
        {
          type: "text",
          text: JSON.stringify(result.rows, null, 2),
        },
      ],
    };
  } catch (error) {
    if (error.message.includes("statement timeout")) {
      return {
        content: [
          {
            type: "text",
            text: "Query timed out after 30 seconds. Try adding LIMIT or optimizing the query.",
          },
        ],
      };
    }
    throw error;
  } finally {
    client.release();
  }
}

Problem 3: Result Size Limits

Return 10,000 rows and watch everything grind to a halt. The AI's context window can't handle it, and you're wasting tokens anyway.

async function executeQuery(query: string) {
  const MAX_ROWS = 100;

  // Inject LIMIT if not present
  let safeQuery = query.trim();
  if (!safeQuery.toUpperCase().includes("LIMIT")) {
    safeQuery = `${safeQuery} LIMIT ${MAX_ROWS}`;
  }

  const result = await pool.query(safeQuery);

  const response = {
    rowCount: result.rows.length,
    data: result.rows,
    truncated: result.rows.length >= MAX_ROWS,
  };

  if (response.truncated) {
    response.note = `Results limited to ${MAX_ROWS} rows. Add specific filters for complete data.`;
  }

  return {
    content: [
      {
        type: "text",
        text: JSON.stringify(response, null, 2),
      },
    ],
  };
}

Adding Resources for Schema Context

Tools let the AI do things. Resources let it know things. For a database server, exposing the schema as a resource helps the AI write better queries:

import {
  ListResourcesRequestSchema,
  ReadResourceRequestSchema,
} from "@modelcontextprotocol/sdk/types.js";

// Update server capabilities
const server = new Server(
  {
    name: "postgres-query-server",
    version: "1.0.0",
  },
  {
    capabilities: {
      tools: {},
      resources: {},
    },
  }
);

// List available resources
server.setRequestHandler(ListResourcesRequestSchema, async () => {
  const tables = await pool.query(`
    SELECT table_name 
    FROM information_schema.tables 
    WHERE table_schema = 'public'
  `);

  return {
    resources: tables.rows.map((row) => ({
      uri: `postgres://schema/${row.table_name}`,
      name: `${row.table_name} schema`,
      description: `Column definitions for the ${row.table_name} table`,
      mimeType: "application/json",
    })),
  };
});

// Read a specific resource
server.setRequestHandler(ReadResourceRequestSchema, async (request) => {
  const uri = request.params.uri;
  const tableName = uri.replace("postgres://schema/", "");

  // Validate table name to prevent injection
  if (!/^[a-zA-Z_][a-zA-Z0-9_]*$/.test(tableName)) {
    throw new Error("Invalid table name");
  }

  const schema = await pool.query(
    `
    SELECT 
      column_name,
      data_type,
      is_nullable,
      column_default
    FROM information_schema.columns
    WHERE table_schema = 'public' AND table_name = $1
    ORDER BY ordinal_position
  `,
    [tableName]
  );

  return {
    contents: [
      {
        uri: uri,
        mimeType: "application/json",
        text: JSON.stringify(schema.rows, null, 2),
      },
    ],
  };
});

Now when someone asks "what columns does the users table have?", the AI can read the schema resource directly instead of running a query.

Security Considerations (Don't Skip This)

Running arbitrary SQL—even read-only—against production databases is risky. Here's my security checklist:

1. Use a read-only database user:

CREATE USER mcp_readonly WITH PASSWORD 'secure_password';
GRANT CONNECT ON DATABASE mydb TO mcp_readonly;
GRANT USAGE ON SCHEMA public TO mcp_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO mcp_readonly;

2. Whitelist allowed tables:

const ALLOWED_TABLES = ["users", "orders", "products"];

function validateQuery(query: string): boolean {
  const upperQuery = query.toUpperCase();

  // Check for disallowed operations
  const forbidden = ["INSERT", "UPDATE", "DELETE", "DROP", "ALTER", "TRUNCATE"];
  if (forbidden.some((op) => upperQuery.includes(op))) {
    return false;
  }

  // Check table references against whitelist
  const tablePattern = /FROM\s+([a-zA-Z_][a-zA-Z0-9_]*)/gi;
  const matches = [...query.matchAll(tablePattern)];

  for (const match of matches) {
    if (!ALLOWED_TABLES.includes(match[1].toLowerCase())) {
      return false;
    }
  }

  return true;
}

3. Rate limit requests:

import { RateLimiter } from "limiter";

const limiter = new RateLimiter({
  tokensPerInterval: 20,
  interval: "minute",
});

server.setRequestHandler(CallToolRequestSchema, async (request) => {
  const hasToken = await limiter.tryRemoveTokens(1);
  if (!hasToken) {
    return {
      content: [
        {
          type: "text",
          text: "Rate limit exceeded. Please wait before making more queries.",
        },
      ],
    };
  }

  // ... rest of handler
});

Testing Your Server

Don't just test against Claude. Use the MCP Inspector tool for faster iteration:

npx @modelcontextprotocol/inspector node dist/index.js

This opens a web UI where you can call tools and read resources directly. Way faster than restarting Claude Desktop every time you change something.

What I'd Do Differently

After three production MCP servers, here's what I've learned:

Start with fewer tools. My first server had twelve tools. It was confusing for the AI and harder to maintain. Now I start with two or three and add more only when there's a clear need.

Log everything. MCP communication happens over stdio, which makes debugging painful. Add structured logging from day one:

import pino from "pino";

const logger = pino({
  transport: {
    target: "pino-pretty",
    options: { destination: "/tmp/mcp-server.log" },
  },
});

server.setRequestHandler(CallToolRequestSchema, async (request) => {
  logger.info({ tool: request.params.name, args: request.params.arguments }, "Tool called");

  // ... handler logic

  logger.info({ tool: request.params.name, success: true }, "Tool completed");
});

Version your tools. When you need to change a tool's behavior, add a new version instead of breaking existing prompts. The AI doesn't handle breaking changes gracefully.

The Bottom Line

MCP isn't complicated once you understand the pattern: expose tools, handle requests, return structured responses. The complexity comes from all the production concerns—error handling, security, performance—that tutorials gloss over.

The ecosystem is still maturing. Security best practices are evolving. Some enterprise teams are holding back until things stabilize more. That's reasonable.

But if you're building internal tools or prototyping AI integrations, MCP is already good enough. The standardization alone saves hours of integration work.

Start small. Build something useful. Ship it.

Found this helpful? I'm writing more about practical AI integration patterns. The next post covers building MCP servers for REST APIs—including the OAuth dance that makes everyone's life difficult.

The MCP Moment: Why the Invisible Standard Everyone's Adopting Matters for Your Business

Bilal Saeed — Mon, 22 Dec 2025 10:40:13 +0000

Every company adding AI tools right now is solving the same problem twice. Your marketing team deploys Claude. Your developers use Cursor. Your operations team tries ChatGPT. Each one needs access to your internal systems—your databases, Slack, email, customer data. So what do you do? You hire a developer to build custom integrations. Then you hire another one when you add the next AI tool. Then another for the next one. It's unsustainable, expensive, and it's about to become completely unnecessary.

Last November, Anthropic released something that seemed technical and niche: the Model Context Protocol (MCP). One year later, it's become the invisible infrastructure reshaping how enterprises connect AI to everything else. And if you haven't heard about it, you're already behind.

The Problem Nobody Talks About (Until It's Too Late)

Before MCP, there was no standard way for AI models to interact with external tools. OpenAI had function calling. Anthropic had tools. Gemini had something else entirely. Each model had its own API conventions. Each integration tool had custom specifications. If you wanted your AI assistant to access both a Slack API and a database, you weren't reusing any code—you were starting from scratch twice.

The math gets ugly fast. Ten AI applications. One hundred internal tools and data sources. You'd think that's 110 integration points. You'd be wrong. It's closer to 1,000 unique integrations—each combination of app and tool requiring its own custom bridge.

That's where the insanity lived for almost a decade of AI development.

Then Something Shifted

MCP changed the game by doing something radical: it created a standard. Not a proprietary standard locked behind one company's API key, but an actual, vendor-neutral, open-source specification that any model and any tool could implement. The Linux Foundation formalized this governance in December 2024, ensuring vendor-neutral oversight.

The adoption numbers tell the real story. MCP went from 100,000 SDK downloads in November 2024 to 97 million by April 2025. But that raw number hides what actually matters: remote MCP servers (the enterprise-grade ones) are up nearly 4x since May 2025. That's not hobbyist excitement. That's production deployment.

Today, there are over 5,800 MCP servers available. Your developers can connect to GitHub, Slack, Google Drive, Stripe, Postgres, or basically any enterprise system you use. The ecosystem is maturing so fast that by February 2025, just three months after launch, developers had already created over 1,000 MCP servers. By October 2025, that number had quintupled.

Here's what matters: OpenAI officially adopted MCP in March 2025. Google built MCP servers for their platforms. Microsoft integrated it into Windows and their AI products. This isn't a niche Anthropic thing anymore—it's industry convergence.

What This Actually Means for Enterprise

Companies investing in AI infrastructure right now have a choice, even if they don't realize it. They can build the old way—custom integration by custom integration, complexity multiplying with each new tool. Or they can adopt MCP and watch their integration complexity flatten.

The economics are straightforward. One developer builds an MCP server once. Every AI application in your company can immediately use it. Add a new AI tool? No new integration. That's not a marginal improvement. That's a fundamental shift in how AI infrastructure scales.

But here's the twist: adoption doesn't mean deployment yet. There's a security catch.

The Part Everyone's Quietly Worried About

Fast adoption created fast new problems. A researcher named Elena Cross published an article pointing out MCP's security vulnerabilities—and titled it with a joke: "The S in MCP stands for security." Tool poisoning. Silent mutations. Server shadowing. These are real attack vectors that emerged exactly because MCP's adoption outpaced its security tooling.

That's why the ecosystem responded. Cloudflare built approval workflows for MCP. Auth0 released an MCP server and published security integration patterns. New Relic launched monitoring (limited, but a start). Microsoft baked in OS-level safeguards for Windows. By mid-2025, the community was actively closing the security gap that early MCP left open.

This matters because it means the MCP infrastructure landing in production now isn't the experimental version from November 2024. It's a year of maturation, real security thinking, and enterprise governance happening in parallel with adoption.

What You Should Do Right Now

Start small. Pick one internal data source—maybe your customer database or Slack—and build an MCP server for it. Integrate it with Claude or ChatGPT. Document what you learned. The barrier to entry is genuinely low. Anthropic maintains an open-source repository with reference implementations for the tools most companies use.

Then benchmark what happens to your integration complexity as you add more AI tools. You'll quickly see whether MCP is saving you time or if your custom approach was somehow better (spoiler: it wasn't).

By end of 2025, estimates suggest 90% of enterprises will use MCP in some form. Some will do it intentionally. Most will adopt it without realizing that's what happened—it'll just be built into whatever AI platform they're using.

The organizations that move fast? They'll have their integration layer standardized before their competitors even realize it's a bottleneck.

Is your team building for the next year of AI, or the last one?

Sources

MCP Enterprise Adoption Report - Comprehensive guide to MCP adoption, market trends, and implementation strategies

Model Context Protocol: One Year Anniversary - Anthropic's official retrospective on MCP's first year, ecosystem growth, and spec updates

MCP Adoption Statistics (October 2025) - Current MCP adoption metrics, remote server growth, and deployment patterns

The MCP Ecosystem 2024-2025 - Deep dive into ecosystem growth, startups building on MCP, and future innovation

Why the Model Context Protocol Won - Analysis of MCP's unexpected rise to industry standard and what it means for AI infrastructure

MCP's Impact on 2025 - Thoughtworks analysis of MCP's effect on AI adoption, including security considerations and context engineering

Model Context Protocol (MCP) FAQs 2025 - Comprehensive technical FAQ covering MCP adoption, architecture, and enterprise implementation

Model Context Protocol - Wikipedia - Overview of MCP governance, major company adoption, and technical specifications

The Squeezing Effect: Why Your Aligned AI Model Gets Worse

Bilal Saeed — Thu, 18 Dec 2025 18:14:16 +0000

You've spent weeks optimizing your language model. You've applied preference optimization (DPO), run the alignment pipeline, and expected performance gains. Instead, your model's confidence drops across the board—even on the outputs you wanted to improve.

This isn't a bug. It's the squeezing effect, and understanding it changes how you approach AI implementation.

What's Actually Happening

When you finetune an LLM using off-policy preference optimization, the algorithm imposes two competing gradients:
A positive push on preferred responses (get better at this).
A negative push on rejected responses (get worse at this).
In theory, this should improve the margin between good and bad outputs. In practice, something counterintuitive occurs.

The negative gradient doesn't distribute the lost probability mass evenly across all other tokens. Instead, it concentrates almost all of it into whichever token already had the highest confidence. This is the squeezing effect.

Imagine a balloon filled with air. You press down on one side (the rejected response). The air doesn't escape smoothly to all corners of the room. It gets squeezed into the area with the least resistance—the highest point of the balloon.

Why This Matters

In a typical LLM, after pretraining, the distribution is highly peaked. Your model is already very confident about certain tokens—those represent the core knowledge it learned. Rejected responses typically fall into low-probability regions. When you apply a large negative gradient to something already unlikely, you don't encourage the model to explore better alternatives.

Instead, you force all probability mass toward the peak.

The result? Your model generates responses that are increasingly repetitive, stereotypical, and hallucination-prone. It's not actually learning to prefer better outputs. It's just getting more extreme—more peaked, narrower, less diverse.

Research published at ICLR 2025 demonstrates this effect across multiple model sizes and datasets. The longer you train with this approach, the worse it gets. Models finetuned for longer periods before preference optimization show stronger degradation, because the initial distribution is already peakier.

The Fix: Lift the Valley

There's a remarkably simple solution: train on both preferred and rejected responses during the supervised finetuning (SFT) phase, before running DPO.

By doing this, you shift rejected responses out of the probability valley. They move into a moderate-confidence region. When DPO applies its negative gradient, it's working on a flatter, gentler slope. The squeezing effect still occurs—it's built into how softmax works—but the damage is minimal because you're not pushing from an extreme low.

The results speak for themselves. Models trained with this approach show:

8-15% improvement in win-rate evaluations (ChatGPT + Claude3 paired comparisons)
Fewer degenerative responses (repetitive phrases, hallucinations)
Better performance across multiple model sizes
Consistent gains without additional computational overhead

Why This Matters for Your AI Implementation

If you're deploying LLMs in production—whether for customer service, content generation, document analysis, or retail automation—understanding these dynamics is critical.

Most off-the-shelf finetuning approaches use standard DPO. They assume the algorithm works as theoretically intended. But real-world model geometry introduces complications.

This isn't about choosing a better training algorithm. It's about recognizing that the geometry of your model's confidence landscape influences alignment effectiveness. A small preprocessing step—including rejected responses during SFT—costs nothing but pays dividends.

The takeaway: alignment isn't just mathematics on paper. It's substrate-specific. Your model's actual learned representations matter. The way probability mass distributes through the softmax layer matters.

When building AI systems, these details compound. Small geometric insights become large performance gaps.

The squeezing effect shows why on-policy methods consistently outperform off-policy approaches. It also explains why some implementations hit unexpected walls despite theoretically sound training pipelines.

Next time you're finetuning an LLM, remember: it's not just about the loss function. It's about where you're applying pressure and what geometry you're pushing against.

The Protocol That's Rewriting AI's Rules (And Nobody Saw It Coming)

Bilal Saeed — Tue, 16 Dec 2025 13:24:25 +0000

Thirteen months ago, Model Context Protocol didn't exist. Today, it's processing 97 million SDK downloads per month and backed by every tech giant that matters—Anthropic, OpenAI, Google, Microsoft, AWS, and Bloomberg.

That's not hype. That's adoption velocity most open standards never achieve in a decade.

MCP launched in November 2024 as Anthropic's solution to a problem everyone in AI knew existed but nobody had fixed: connecting AI models to real-world data requires custom integration for every single pairing. Want your AI to access Google Drive? Custom code. Now add Slack? More custom code. GitHub? You're building integrations full-time now.

The math didn't work. If you had 10 AI tools and 10 data sources, you needed 100 different integrations. Scale that across an enterprise and you're looking at engineering teams spending months on plumbing instead of building actual AI applications.

What Actually Changed

MCP introduced something deceptively simple: a universal standard for AI-to-data connections. Think USB-C for AI—one protocol that lets any AI application connect to any data source without custom integration work.
Here's what that looks like in practice. Before MCP, if you wanted Claude to pull a document from Google Drive and attach it to a Salesforce lead, that required custom code to connect Claude to Google Drive, more code to connect Claude to Salesforce, and logic to handle the data transfer. Every step consumed engineering time.

With MCP, developers build the integration once. Claude connects to an MCP server that exposes Google Drive and Salesforce capabilities through a standard interface. The AI can now interact with both systems using the same protocol. Add 50 more tools? Same protocol. The integration complexity doesn't compound—it flattens.

The numbers tell you how fast this caught on. MCP server downloads went from roughly 100,000 in November 2024 to over 8 million by April 2025. The community has built 5,800+ MCP servers and 300+ clients in just over a year. Major development platforms like Replit, Codeium, and Sourcegraph integrated MCP support within months of release.

The December Turning Point

In December 2024—barely a month after launch—Anthropic did something unexpected: they donated MCP to the Linux Foundation under the newly formed Agentic AI Foundation. The foundation includes Anthropic, Block, and OpenAI as co-founders, with backing from Google, Microsoft, AWS, Cloudflare, and Bloomberg.

This wasn't a PR move. Handing governance to the Linux Foundation (the organization that stewarded Kubernetes, PyTorch, and Node.js) signaled that MCP was transitioning from vendor project to neutral industry infrastructure. OpenAI officially adopted MCP in March 2025. Google DeepMind confirmed support in April 2025.

When competing AI companies agree on a standard this quickly, something fundamental is shifting.

Why Enterprises Actually Care

The market projection shows the real impact: from $1.2 billion in 2022 to an estimated $4.5 billion in 2025. Some analysts predict 90% of organizations will use MCP by end of 2025. That's not future speculation—enterprise adoption is already happening at companies like Block, Apollo, and hundreds of Fortune 500 organizations.

The reason is straightforward: MCP makes AI agents practical at scale. An agent that can autonomously pull data from Salesforce, check GitHub issues, query internal databases, and send Slack notifications doesn't require four separate custom integrations anymore. It requires one MCP implementation that connects to servers exposing those capabilities.

Development time drops. Maintenance burden shrinks. The AI can actually access the data it needs to be useful instead of being trapped behind information silos.

The Security Reality Nobody Mentions

Here's what most coverage misses: MCP's rapid adoption outpaced its security maturation. Security researchers identified multiple vulnerabilities in April 2025—tool poisoning, silent definition mutations, cross-server tool shadowing. The protocol prioritized simplicity and ease of adoption over authentication and encryption.

That's not necessarily wrong for an early-stage standard, but enterprises deploying MCP in production need to understand they're implementing it during its security hardening phase, not after it.

The Linux Foundation governance should help. Open governance typically accelerates security improvements because more eyes catch more vulnerabilities. But right now, organizations rushing to adopt MCP need solid authentication strategies, entity-level data guardrails, and comprehensive monitoring.

What This Actually Means

MCP didn't just solve a technical problem. It created the infrastructure layer that makes agentic AI deployable at enterprise scale. The agents everyone's been talking about—autonomous systems that can reason, plan, and execute tasks across multiple tools—only become practical when you solve the data connection problem.

That's what happened in 13 months. Not a prototype or proof of concept. Actual infrastructure that's processing millions of requests and backed by neutral governance under the Linux Foundation.

The question isn't whether MCP will become standard anymore. It already is. The question is how quickly organizations figure out how to implement it securely and effectively—because the ones that do have a significant AI deployment advantage over the ones still building custom integrations.

The Measurement Trap: Why 80% of Retail Automation Investments Underperform

Bilal Saeed — Thu, 11 Dec 2025 09:39:38 +0000

Retailers spent billions on automation last year. And the majority still can't explain why it worked or didn't.

Not because automation failed. Because they never decided what success looked like before spending the money.

This is the retail automation paradox. Companies invest heavily in technology while keeping success metrics fuzzy.

The Winner-Loser Gap Is Now Permanent

Top 5% of retailers achieve 31% lower fulfillment costs through integrated automation, while 83% struggle with basic omnichannel execution.

That's not a small gap. That's a structural moat.

Here's the key difference: The distinguishing characteristic of top performers isn't just that they use technology. It's that they measure its impact obsessively. Jasper's 2025 retail marketing report found that 54% of retail companies can now measure AI ROI, the highest percentage of any industry.

But measuring ROI after implementation is like checking the weather after you've left home. Too late to change your outfit.

The leaders measure first.

How Winners Start Projects

When IBN Technologies reported on automation successes, the standout cases weren't about replacing entire departments. They were about targeted, measurable improvements: A major HVAC retailer reduced sales order entry from 7 minutes to 2 minutes (66% improvement). A regional retail chain achieved 95% reduction in manual data entry. Same chain: 86% faster accounts payable approvals, 25% lower operational costs.

Notice what these cases have in common. They start with a specific problem. They measure the baseline. They implement. They track results. They adjust.

Not "automate everything" or "we need AI." Specific. Measurable. Achievable.

Why Most Retailers Fail to Measure

There are three problems:

First: Measurement Infrastructure Doesn't Exist

Most retailers don't have systems to track the impact of technology changes. They can tell you overall revenue or costs, but they can't isolate the impact of one automation project. So when you ask "did the inventory management system actually improve accuracy?" the answer is usually a guess.

Second: Pilot Program Paralysis

Retailers can automate up to 70% of routine tasks, and automating fulfillment centers reduces costs by approximately 60%. Yet most implementations remain limited in scope.

This isn't caution. It's confusion. Companies start pilots without clear success metrics. The pilot runs for months. Results are ambiguous. Leadership can't decide whether to expand. The project stalls. Another pilot starts.

Meanwhile, competitors move forward because they made a decision. Right or wrong, they acted on data.

Third: Cost Estimation Crushes Confidence

The high cost of deploying automation technologies, such as AI-driven analytics and robotic systems, remains a barrier, particularly for small and medium enterprises (SMEs). In 2024, the average cost of implementing a fully automated POS system was USD 100,000, limiting adoption in emerging markets.

When you're about to spend $100,000 on a system, you want certainty of payoff. But without measurement infrastructure, you can't be certain. So you hesitate. Or you spend and hope.

The Integration Complexity That No One Talks About

Most retail environments aren't clean. You have legacy POS systems from 2008. Modern inventory management software. Mobile apps from three different vendors. Accounting systems that don't talk to anything.
Implementing new automation means integrating with all of this chaos. And integration is where measurement breaks down. You automate one thing but it doesn't connect properly with the next system. The promised 60% cost reduction becomes 15% because you're now manually handling exceptions.

You spent $100,000 to save maybe $15,000 per year. Payback period: 6 years instead of the promised 1.5 years.

This happens constantly because companies don't measure the integration complexity before they start.

What Top Retailers Do Differently

If you can't measure the ROI of a technology investment before you make it, you're already behind. The leaders treat every implementation as a controlled experiment with clear success metrics.

Here's their process:

Identify the problem (sales order entry takes 7 minutes)
Establish the baseline (current state: 7 minutes per order)
Set the success metric (3 minutes per order)
Calculate expected ROI (if we handle 100 orders per day, that's 400 minutes saved)
Implement the solution
Track the actual results
Adjust or scale based on what happened

Not guessing. Measuring.

Retailers who can't measure ROI struggle to justify further investment, falling further behind those who can demonstrate clear returns and secure resources for expansion. Deloitte's 2025 outlook emphasizes that two-thirds of retail executives plan moderate-to-major workforce investments, but the data suggests these investments concentrate among retailers already seeing returns. This widens the gap further.

The companies seeing returns reinvest in automation. The companies not seeing returns stop investing. The gap compounds every year.

The Measurement Framework You Need Before You Spend

Before your next automation investment, ask these questions:
What is the current state? (Quantify it in minutes, errors, costs, or time)
What will success look like? (Specific number, not "better" or "more efficient")
How will we know we achieved it? (What data will we track?)
What's the baseline cost and the projected savings? (Calculate the payback period)
What could go wrong? (Integration issues, adoption resistance, technical problems)
How will we measure progress during implementation? (Monthly check-ins, KPI tracking)
If you can't answer these clearly, you're not ready to invest. You're ready to gamble.

The Real Cost of Not Measuring

Not measuring automation ROI doesn't save money. It costs money.
Companies that measure get data. They know what works. They scale what works. They stop what doesn't.

Companies that don't measure get paralyzed. They can't justify the next investment because they don't know if the last one worked. They stay stuck. Competitors lap them.

The 31% cost advantage the top 5% enjoy isn't because they have better technology. It's because they measure before, during, and after implementation. They learn fast. They adjust fast. They win.
The bottom 80% are still deciding if their last automation project was a success or a failure.

The Question You Should Ask Your Team

Don't ask "should we automate this process?" Ask "what do we need to measure to know if automation improves this process?" Everything else follows from that question.

Measure first. Automate second. Results follow.

The Self-Checkout Trap: Why Retailers Keep Betting on Technology That Costs Them Billions

Bilal Saeed — Wed, 10 Dec 2025 09:57:15 +0000

Walmart just celebrated removing self-checkout from more stores. Target limited items to 10 per transaction. Dollar General abandoned its exclusive self-checkout strategy entirely.

And yet self-checkout is still expanding.

This isn't a contradiction. It's a sign that the retail industry got locked into a technology that solves one problem (labor cost) while creating a much bigger one (theft).

The Numbers Everyone Ignores

Self-checkout shrink is estimated between 3.5% and 4%, compared with less than 1% for traditional cashiers. Let that sink in for a moment. That's not a small inefficiency. That's a systemic problem.

For a grocery retailer with $1 billion in sales, that self-checkout shrinkage translates to more than $10 billion in lost profits annually across food retailers.

The shrinkage has multiple causes, and this is important: only part of it is intentional theft. 21% of self-checkout thefts are accidental, with shoppers failing to notice when an item doesn't scan properly. But the intentional part? That's where it gets dark. 15% of self-checkout users confess to purposely stealing, with 44% admitting they're likely to repeat the theft.

That's not an edge case. That's 44% of thieves planning to steal again.

The Paradox: Consumers Love It (While It Destroys Margins)

Here's where it gets weird: 73% of consumers prefer self-checkout over traditional staffed registers. Customers genuinely like the technology. But simultaneously, 67.3% of consumers report using a dysfunctional self-service kiosk, and 41.8% of consumers who avoid self-service checkout do so because they experienced a slower checkout.

So the technology that's supposed to be faster actually isn't, most of the time. It's just more convenient on the rare occasions it works.

Retailers are trapped between two forces:

Consumer demand for self-checkout (faster perceived experience when it works).
Financial reality that self-checkout is bleeding them dry.

So what do they do? They keep investing in it because abandoning a technology millions of customers want to use looks like backward movement. Meanwhile, the theft and shrinkage quietly destroys margins.

Why Self-Checkout Is Actually Solving the Wrong Problem

The real issue self-checkout was supposed to address wasn't speed. It was labor cost.

Retailers facing wage increases, labor shortages, and rising operational costs saw self-checkout as a way to transfer the checkout burden to customers. Fewer cashiers needed. Lower labor spending. Done.

Except labor cost went down 5-10% while shrinkage went up 300-400%. The math doesn't work. Most retailers running self-checkout are operating at a net loss when you factor in the hardware, maintenance, and (most importantly) the theft.

The Technology That's Actually Solving It

Computer vision-based checkout is different. Fundamentally different.
Instead of asking customers to scan items (which creates opportunities for "accidents" and intentional theft), these systems track what customers take off the shelf in real-time. Using advanced AI, sensors, computer vision, and RFID, technology like Amazon's Just Walk Out accurately tracks item selection and automates payment when shoppers exit the store.

The results aren't incremental. Smart detection systems can identify differences between what was picked up versus what was weighed, with claimed accuracy levels hitting 99%. Early adopters of next-generation smart self-service solutions demonstrate considerable upside, with early adopters reporting an average 30% increase in sales.

Here's what's crucial: these systems don't rely on customer behavior. They monitor transactions in the background. The customer experience feels frictionless—walk in, grab, leave. But from the retailer's perspective, everything is tracked, verified, and charged correctly.

No theft opportunity. No "unexpected item in bagging area." No frustrated customers. No 3.5% shrink.

A survey from Piplsay found that a large majority of consumers who visited an Amazon Go store found the experience either "good" or "excellent," with 57% of consumers overall saying they would like to see a similar tech-enabled store near them.

Why Retailers Are Stuck on Self-Checkout

Here's the uncomfortable truth: self-checkout is the sunk cost trap of retail technology.

Retailers have already invested hundreds of millions in equipment, training, and infrastructure. Admitting it's not working means writing off those investments. It means saying "we made a mistake." It means competitors who already moved forward are now years ahead.

So instead, they do incremental fixes. Limiting items. Adding staff monitoring. Locking cases. Frustrating customers further. But they don't leap to the next generation because that leap means acknowledging the first generation failed.

The companies winning aren't the ones optimizing self-checkout. They're the ones leapfrogging to computer vision systems that actually work.

The Question Retailers Need to Ask Now

If you're a retail leader, here's the honest question: Are you defending yesterday's choice or preparing for tomorrow's winner?

Self-checkout was the innovation everyone wanted to believe in. But belief doesn't change math. The technology is costing you 3.5-4% of sales in shrinkage and creating a worse customer experience than cashiers in most cases.

Computer vision removes the customer from the theft equation entirely. It costs more upfront. It requires different infrastructure. But early adopters are seeing 30% sales increases and near-zero shrinkage.

The retailers who move first to next-gen solutions will have massive advantages on efficiency and margin. The retailers doubling down on self-checkout optimization? They're fighting on terrain that's already been conceded.

What's keeping you on yesterday's technology?

The Cashier Myth: Why Retail Automation's Real Impact Is Hidden in the Warehouse

Bilal Saeed — Tue, 09 Dec 2025 09:51:40 +0000

Everyone sees self-checkout. It's obvious. Walk into a grocery store and you notice the kiosks, the fewer cashiers, the slight awkwardness of scanning your own items. It looks like the future of retail, doesn't it?
But that's looking at the wrong numbers.

The retail automation market just crossed $20 billion. By 2030, it'll be worth $35-40 billion, growing at 12-15% annually. That's not just kiosks at checkout lanes. That's warehouse robots. AI inventory systems. Automated sorting. The stuff you don't see.

Research from Spherical Insights projects the global retail automation market growing from $27.2 billion in 2024 to $74.3 billion by 2035. That growth trajectory doesn't come from removing a few cashier positions. It comes from companies automating their entire supply chain from warehouse to shelf.

Here's What Everyone Gets Wrong

While 65% of retail cashier jobs face automation risk by 2025, that's actually the smaller story. By 2040, automation could impact up to 41 million retail jobs, with cashiers, stock clerks, and customer service roles most at risk.

Notice that: stock clerks. That's warehouse work. That's the job most people don't think about when they think about retail automation.

Automated inventory tracking systems have already reduced delivery times by 10% in Asia-Pacific markets, improving product availability. Retailers using these systems aren't just cutting costs—they're completely reshaping their operations. They're moving inventory with robots instead of people.

The Three Trends Happening Simultaneously

1. Labor costs are making automation cheaper than hiring.

Most people don't realize this, but labor shortage and rising wages are the real drivers of automation adoption. Companies aren't automating because they love technology. They're automating because hiring workers, training them, and keeping them is becoming prohibitively expensive. Automation breaks that cost curve.

2. Warehouse automation is far ahead of in-store automation.

While we're all talking about self-checkout, the real transformation is happening behind the scenes. Warehouse automation uses automated guided vehicles (AGVs) and robotic picking systems to handle picking, moving, and sorting goods, automating labor-intensive and repetitive processes.

3. The skills gap is real and immediate.

Here's where it gets uncomfortable. While 85 million jobs are expected to be displaced globally by 2025, 97 million new roles will emerge, representing net positive job creation of 12 million positions. That sounds great until you see the catch: 77% of new AI jobs require master's degrees, creating substantial skills gaps.

Translation: new jobs exist. But most displaced warehouse workers don't have the education to get them.

What Actually Happens When Retailers Automate

They don't cut locations. They cut staff. A modern warehouse that used to need 50 people to manage inventory now needs 8—plus 2 engineers to maintain the robots.

That's a net loss of 40 jobs. Sure, it creates 2 technical jobs. But those go to people with computer science degrees, not the person who's been picking orders for five years.

The companies winning this transition are the ones recognizing this gap. They're investing in retraining programs, partnering with community colleges, creating clear paths from warehouse roles into technical maintenance and oversight positions.

The companies pretending this isn't happening? They're about to get blindsided by the automation wave everyone sees coming but nobody wants to prepare for.

The Forward Question

This isn't a "will this happen" scenario. Retailers are implementing AI-powered personalization and omnichannel integration, with advanced inventory management systems minimizing human error and providing real-time inventory insights. It's happening now.

The real question is whether organizations are preparing their workforce for what comes next—or pretending this is something that'll happen to someone else's company.

What's your retail organization doing to bridge this skills gap?

Why Retailers Can't Afford to Ignore Automation Anymore

Bilal Saeed — Mon, 08 Dec 2025 13:05:25 +0000

The math is brutal. Labor costs keep climbing. Finding workers who actually show up? Harder than ever. Meanwhile, your customers want faster checkouts, smarter recommendations, and zero friction at every touchpoint.

Something's gotta give.

That's exactly why retail automation is exploding right now. The global market hit $24.36 billion in 2024 and is projected to reach $64.09 billion by 2032 a CAGR of nearly 13%. Precedence Research puts the trajectory even higher, forecasting $71.91 billion by 2034.

These aren't just big numbers on a slide deck. They represent a fundamental shift in how stores operate, from the back warehouse to the checkout lane.

The Labor Problem Nobody Wants to Talk About

Here's the uncomfortable truth: retailers can't staff their way out of this mess. Around 40% of the retail sector is already automated, and that figure is expected to hit 60-65% within the next three to four years.

Not because CEOs love robots, but because there's no alternative.
Industry experts say retailers plan to automate 70% of their daily store tasks by 2025.Think about that for a second—seven out of ten routine activities handled by systems instead of people. Inventory checks, pricing updates, restocking alerts. The repetitive stuff that burns out employees and burns through payroll.

What Customers Actually Want

Turns out, shoppers aren't just tolerating automation. They're demanding it.
Research shows 66% of global consumers prefer self-checkout options. Not "accept" or "tolerate"—prefer. When given the choice between waiting in line for a cashier or scanning items themselves, two-thirds of customers would rather do it themselves.

That's a massive signal. And smart retailers are listening.

Self-checkout kiosks are just the start. Electronic shelf labels now update prices automatically based on inventory levels, demand, and promotional campaigns. Smart carts equipped with sensors calculate totals on the fly. AI-powered chatbots handle customer inquiries around the clock, regardless of time zones or store hours.

Where the Money's Actually Going

Point-of-sale systems dominate current spending—the PoS segment captured about 45% of market share in 2024. Makes sense. The checkout experience is where friction kills conversions and patience runs thin.
But customer service automation is the fastest-growing segment. AI-driven chatbots and virtual assistants provide round-the-clock support, handling everything from product information to order status. No more "our agents are currently busy" hold music. No more limited support hours.
North America leads adoption with a market valued at over $9 billion in 2024 , driven by high labor costs and tech-savvy consumers. But Asia-Pacific is catching up fast, growing at an 11% CAGR as urbanization and organized retail expansion fuel demand across China, India, and Southeast Asia.

The Real Competitive Advantage

Here's what most retailers miss: automation isn't about replacing humans. It's about redeploying them.

When a robot handles inventory counts at 3 AM, your staff can focus on helping customers navigate complex purchase decisions. When smart shelves flag low stock automatically, employees stop wandering aisles with clipboards and start solving problems that actually need human judgment.

The goal is to improve operational efficiency, reduce costs, and enhance the overall customer experience by leveraging AI, robotics, and IoT. Everything else follows from there.

The retailers who figure this out won't just survive the next decade. They'll define it.

Retail Automation Is Finally Making Sense for Everyone

Bilal Saeed — Thu, 04 Dec 2025 09:11:01 +0000

Walk into a Target or Walmart these days and you'll notice something different. Fewer lines. More kiosks. Robots rolling down aisles scanning shelves. What felt like sci-fi five years ago is now just... Tuesday.
And here's the thing: it's not just the giants anymore.

The Numbers Don't Lie

The retail automation market hit $29 billion in 2024. By 2034? We're looking at nearly $72 billion. That's not hype—that's retailers voting with their wallets because automation actually works.

Consider what's driving this shift. Automating a distribution center can double productivity while cutting labor needs in half. Fulfillment centers are seeing 60% cost reductions. Self-checkout alone is expected to handle 40% of all retail transactions globally by 2026.

Those aren't incremental improvements. That's a fundamental rewiring of how stores operate.

It's Not About Replacing People (Mostly)

The labor shortage conversation keeps coming up for a reason. Warehouse and retail floor jobs are tough to fill and even harder to keep filled. Repetitive tasks, physical demands, high turnover—it's a cycle that's been grinding retailers down for years.

Automation breaks that cycle. Not by eliminating jobs entirely, but by shifting what those jobs look like. Instead of restocking shelves for eight hours, an associate might oversee the robot that does it while handling customer questions and solving problems that actually require a human brain.

The retailers getting this right aren't just cutting costs. They're making their remaining staff more effective and, honestly, less miserable.

What's Actually Getting Automated

Electronic Shelf Labels (ESLs) are everywhere now. No more employees walking around with pricing guns—prices update instantly across the entire store from a central system. Dynamic pricing during sales becomes trivial instead of a logistics nightmare.

Smart carts track what customers add in real time. Cashierless checkout systems like Amazon's Just Walk Out technology let shoppers grab items and leave—sensors and cameras handle the rest. Estonia already has unmanned stores where you enter with your phone and walk out with your groceries.

Behind the scenes, AI-driven inventory management predicts what needs restocking before shelves go empty. Computer vision catches misplaced products. Warehouse robots pick orders faster than human workers ever could.

The Real Winners

Big retailers have a head start, sure. They've got the capital for massive rollouts. But the cost of entry is dropping fast.
Mid-size grocers and convenience chains are implementing these technologies without breaking the bank. SaaS solutions integrate with existing POS systems, meaning you don't need to rip out your infrastructure to start automating. You can phase it in, test what works, and scale from there.

The retailers who wait too long will find themselves competing against operations running at fundamentally different efficiency levels. That's not a gap you close easily.

What This Means For Shoppers

Shorter lines. Fewer out-of-stock frustrations. Better prices (theoretically, at least—margins are margins). More personalized recommendations based on actual purchase history instead of guesswork.
The checkout experience that's annoyed shoppers for decades is finally getting fixed. Not because retailers suddenly care more, but because the technology finally makes it profitable to care.

The Bottom Line

Retail automation isn't coming. It's here. The market's tripling over the next decade, and the stores figuring it out now will dominate the ones still debating whether robots are "ready."

If you run a retail operation—any size—the question isn't whether to automate. It's what to automate first.

The AI Boom Has a $5 Trillion Problem

Bilal Saeed — Wed, 03 Dec 2025 12:12:44 +0000

Central banks don't usually sound alarms about specific technologies. When they do, it's worth paying attention.

This week, the Bank of England warned that a multi-trillion dollar spending boom in artificial intelligence infrastructure financed by debt risks unraveling given "materially stretched" stock market valuations.
That's not speculation from a tech blogger or a contrarian fund manager. That's a major central bank saying the financial plumbing underneath the AI revolution might be more fragile than it looks.

The Numbers Are Staggering

The Bank of England projects that approximately $5 trillion will be spent globally on AI infrastructure over the coming five years. Initially, Big Tech funded this build-out from their massive cash reserves. But that's changing fast.

The Bank now estimates that nearly half of the $5 trillion expected to be poured into AI infrastructure over the next five years will come from external financing, particularly through debt markets.

That shift matters enormously. When companies fund expansion with cash, a downturn hurts shareholders. When they fund it with debt, a downturn can cascade through the entire financial system.

Why This Feels Different (And Why It Might Not Be)

AI stocks have pushed some US stock valuation metrics to their highest level since the dot com bubble 25 years ago. Bank of England The comparisons are hard to ignore.

But there's a crucial difference this time. Most AI players today generate real earnings—a point emphasized by Governor Andrew Bailey, who stressed that the industry is not running purely on hope, even if not all companies will survive.

The Bank isn't predicting a crash. They're flagging a structural vulnerability. AI accounted for two-thirds of all gains in the S&P 500 this year and was credited with fueling half of U.S. economic growth in the first half of 2025.That concentration creates fragility.

The Contagion Risk

Here's what keeps regulators up at night. If material credit losses on AI lending were to occur, this could have spillovers to broader credit conditions.

It's not just about tech stocks falling. Household wealth would likely decline, consumer spending could contract, and lenders might pull back—not only from AI-focused companies but from corporate borrowers more generally.

The Bank pointed to early warning signs in credit default swaps of companies leaning on debt to fund their investments. Bloomberg Translation: the derivatives market is starting to price in higher default risk for AI-heavy borrowers.

Stage Three of Five

One investment strategist put it bluntly. "If you think of a bubble of about five stages, we're probably in stage three," said Joost van Leenders of Van Lanschot Kempen. "When you look at the fact that some of these companies are financing each other and buying each other's stocks, I think those are also signals of a bubble."
That circular dynamic—tech giants investing in each other, guaranteeing each other's debt, buying each other's chips—creates an interconnected system that could amplify a shock rather than absorb it.

What Happens Next

The AI revolution isn't going away. The technology works. The demand is real. But the financial structure supporting the build-out is increasingly leveraged, and if the projected scale of debt-financed AI infrastructure investment materializes over this decade, financial stability risks are likely to grow.

AI does not need to fail for markets to break; valuations simply need to fall.

That's the uncomfortable truth. We're not debating whether AI will transform industries—it already is. We're watching to see whether the financial architecture can handle a correction without taking the broader economy with it.

The Bank of England just said they're watching closely. So should we.

The Week AI Got Real: Jobs, Robotaxis, and $4 Trillion Valuations

Bilal Saeed — Fri, 28 Nov 2025 11:10:41 +0000

This wasn't supposed to happen this fast.
MIT dropped a study this week that put a number on something we've all been wondering: how many jobs can AI actually replace right now? Not in some distant future. Not "when the technology matures." Today.

The answer? 11.7% of the U.S. labor market—about $1.2 trillion in wages across finance, healthcare, and professional services.

Meanwhile, Uber launched fully driverless robotaxis in Abu Dhabi. And Alphabet keeps climbing toward a $4 trillion valuation like it's no big deal. Let's unpack what's actually happening.

The Jobs Nobody Thought Were at Risk

Here's what caught everyone off guard about the MIT study. Tech and IT layoffs represent just 2.2% of total wage exposure. That's the visible part—the headlines we've been reading for months.

The rest? Routine functions in human resources, logistics, finance, and office administration—areas sometimes overlooked in automation forecasts.

The researchers built something called the Iceberg Index, and the name isn't accidental. What most people see today in tech layoffs and role shifts represents only a small fraction of the broader exposure. The bulk sits beneath the surface.

What makes this different from the usual "AI will take your job" studies is the granularity. The model breaks tasks down and links them to more than 32,000 skills mapped across 923 occupations and over 3,000 counties. Tech Startups This isn't speculation—it's simulation at a level that policymakers can actually use.

Tennessee, North Carolina, and Utah have already partnered with the researchers to validate the model using their own labor data. CNBC Tennessee moved first, incorporating these insights into its official AI Workforce Action Plan this month.

Robotaxis Leave America

While we debate whether autonomous vehicles will ever be safe enough, Uber rolled out fully driverless rides in Abu Dhabi this week—its fourth autonomous vehicle market globally and the first in the Middle East.

The partnership with Chinese AV company WeRide has been building for over a year. They started with safety drivers. Now those drivers are gone. The fully driverless service operates in a 12 square mile tourist area called Yas Island, with expansion planned for other parts of the city.

This marks the first city outside the United States to host fully driverless operations on the Uber platform. And it's just the beginning. Uber and WeRide have previously shared plans to expand to 15 cities throughout the Middle East and Europe, eventually scaling to thousands of robotaxis.

Uber's strategy here is worth noting. They're not building the cars or the self-driving tech. They're partnering with companies that already have it—Waymo in the U.S., WeRide in the Middle East, Baidu in Asia—and plugging it into their existing platform. Less R&D risk, faster deployment.

Alphabet's Quiet Dominance

Google and YouTube parent Alphabet closed at another all-time high for the 13th time in November. The stock has soared more than 24% in the past month and nearly doubled over six months.

What's driving it? AI integration into search, the Gemini platform, and growing confidence that Google's TPU chips offer a credible alternative to Nvidia's expensive GPUs. Berkshire Hathaway quietly took a stake, reinforcing the narrative that Google remains a core AI infrastructure play.

But there's a catch. A U.S. court recently ruled Google's search business an illegal monopoly—though it stopped short of ordering a breakup. Regulatory risk hasn't gone away. It's just been postponed.

What This Means for Everyone Else

These stories seem disconnected, but they're not. MIT shows us which jobs are vulnerable. Uber shows us autonomous technology is ready for real-world deployment at scale. Alphabet shows us where the money is flowing.

The common thread? AI isn't waiting for permission anymore. It's shipping. In hiring decisions, in vehicles on public roads, in trillion-dollar market valuations.

For workers, the MIT study offers a strange kind of hope. The researchers frame Iceberg not as a prediction engine about exactly when jobs will be lost, but as a sandbox that states can use to prepare. It's a tool for planning, not panic.

For companies, the message is simpler: the window to treat AI as a future concern is closing. The organizations figuring this out now—whether they're ride-hailing platforms or search giants—are building the infrastructure everyone else will eventually depend on.

And for everyone watching? Pay attention to what's happening outside the headlines. The real changes aren't always the ones making the most noise.