DEV Community: Nicolas Fainstein

OWASP ASI08 Says Your Multi-Agent System Needs Cascade Detection

Nicolas Fainstein — Tue, 10 Mar 2026 15:44:57 +0000

In December 2025, OWASP published the Top 10 for Agentic Applications. Item eight, ASI08, covers cascading failures in agentic AI systems. If you run multiple AI agents that interact with each other, this applies to you.

What ASI08 Actually Says

The formal definition: "A cascading failure in agentic AI occurs when a single fault - whether a hallucination, malicious input, corrupted tool, or poisoned memory - propagates across autonomous agents and compounds into system-wide harm."

Three propagation mechanisms make agent cascades different from traditional software failures:

Feedback loops. Two agents whose outputs become each other's inputs create self-reinforcing cycles. A small error in Agent A's output gets amplified by Agent B, which feeds it back to Agent A, which amplifies it further. Traditional circuit breakers don't catch this because each individual request looks normal.

Transitive trust chains. Agent B trusts Agent A's output. Agent C trusts Agent B's output. If Agent A gets compromised or hallucinates, the bad data flows through the entire chain. No agent independently verifies against ground truth because they trust what comes from upstream.

Persistent memory poisoning. An error written to a vector store, knowledge base, or long-term memory continues influencing agent reasoning in future runs. The failure isn't a one-time event. It becomes a persistent corruption that survives restarts.

The OWASP expert review board (100+ contributors including NIST and European Commission representatives) recommends a defense-in-depth approach with three layers:

Architectural isolation with trust boundaries and circuit breakers
Runtime verification with multi-agent consensus and ground truth validation
Comprehensive observability with automated cascade pattern detection and kill switches

That third point is where most teams have a gap.

The Observability Gap

Your agents probably have logging. They might have LLM tracing through Langfuse or LangSmith. But when Agent C errors at 14:32, can you answer:

Which upstream agent's output caused it?
What was the exact payload at each hop in the chain?
Did the error originate from a tool call failure, a hallucination, or a memory corruption?
How many other agents are now operating on the same bad data?

If your answer is "we'd read through the logs and try to piece it together," you're doing forensics by hand. ASI08's mitigation specifically calls for automated cascade pattern detection. Not log analysis after the fact.

The Math Problem

Your 10-agent system has a reliability problem nobody talks about. If each agent is 95% reliable on its own (which is generous), the probability that all 10 succeed on a given run is 0.95^10 = 0.60.

Your system is 40% unreliable even when each component is 95% reliable.

And that assumes independent failures. Agent cascades create correlated failures where one agent's problem causes three others to break simultaneously. The actual reliability is lower than the math suggests.

What Compliance Looks Like

To meet ASI08's observability requirements, you need:

Heartbeat monitoring. Every agent reports its status at regular intervals. If an agent stops reporting, that's signal. If an agent reports degraded status, that's signal. A fleet-wide view shows you which agents are healthy, which are degraded, and which have gone silent.

Cross-agent event correlation. When a failure happens, trace backward through the event log. Agent C failed because it received bad input. That input came from Agent B. Agent B's output was corrupted because Agent A's tool call returned an error that B didn't handle. The full chain, with timestamps and payloads, stored automatically.

Alert deduplication. The same alert from the same agent every 5 minutes is noise. You need escalation tiers: the first occurrence is info, the fifth is a warning, the tenth is critical. Without dedup, your team develops alert fatigue, which is itself a cascade risk.

Forensic replay. For any failure, reconstruct what happened: "Agent A returned X. Agent B transformed it to Y. Agent C received Y and failed because Z." This is deterministic replay from stored evidence, not reconstruction from partial logs.

Building This

We built AgentWatch because we hit every one of these problems running our own 7-agent system. One agent would fail, three others would break, and we'd spend hours reading through separate log files trying to trace the chain.

It's a TypeScript library. npm install @nicofains1/agentwatch, wire in heartbeats and event reporting, and you get cascade detection, fleet dashboards, alert dedup, and forensic replay out of the box. Self-hosted with SQLite, no external services needed.

The approach is deterministic: store evidence at each hop, walk the trace DAG backward on failure. No ML model trying to guess what happened. The data tells you directly.

What to Do Right Now

If you're running multiple AI agents:

Audit your observability. Can you trace a failure from one agent back to its root cause in another? If not, you have an ASI08 gap.
Check your alert setup. Are you getting the same alert 19 times in an hour? That's a sign you need deduplication and escalation.
Test a cascade scenario. Intentionally break one agent's output and watch what happens to agents downstream. If you can't see the propagation path in your current tooling, that's the gap ASI08 is warning about.

The speed and scale of agentic AI outpaces human reaction times. By the time you notice a cascade manually, it's already propagated. Automated detection isn't a nice-to-have. According to OWASP, it's part of the mitigation framework.

The OWASP Agentic AI Top 10 is worth reading in full. ASI08 is item eight, but the other nine items interact with cascade risk in ways that compound the problem.

The Agent Observability Landscape in 2026: Who Traces, Who Misses

Nicolas Fainstein — Tue, 10 Mar 2026 15:43:59 +0000

If you run more than one AI agent in production, you've already hit the observability gap.

Single-agent tracing is a solved problem. Langfuse, LangSmith, Arize Phoenix, and a dozen others will show you exactly what happened inside one agent's LLM calls. That's table stakes in 2026.

But when Agent C errors because Agent B sent it bad data, which itself came from Agent A's failed tool call, most of these tools give you three separate error logs with no connection between them.

Here's where the landscape actually stands.

The Per-Agent Tracers

Langfuse (22.9k GitHub stars, acquired by ClickHouse in January 2026) is the open-source default. It traces LLM calls, manages prompts, runs evaluations. 2,000+ paying customers. 19 of the Fortune 50 use it. The ClickHouse acquisition gives it serious infrastructure backing. What it doesn't do: correlate errors across agents that share no direct function call.

LangSmith is LangChain's proprietary tracing platform. Deep integration with the LangChain ecosystem. Automatic pattern clustering, failure mode detection, online evals. Pricing starts free (5k traces/month), then $39/seat + $2.50 per 1k traces. Strong if you're already in the LangChain world. Same limitation: per-agent scope, no fleet-wide cascade view.

AgentOps (3.1k stars) has the lowest performance overhead in 2026 benchmarks at 12%. Supports CrewAI, Agno, OpenAI Agents SDK, LangGraph, AutoGen. Good multi-framework story. Session replays are useful for debugging single agent runs.

Arize Phoenix (open source + enterprise) comes from ML observability. Drift detection, performance degradation monitoring, agent graph visualization. Recently added Amazon Bedrock Agents support. Their trajectory mapping can detect recursive patterns within one agent's execution.

RagaAI Catalyst is Python-only, self-hosted, with 50+ custom metrics and execution graph visualization. Designed for multi-agent systems but focused on tracing rather than cross-agent failure attribution.

The Enterprise Entrants

Braintrust raised $80M Series B in February 2026 at an $800M valuation. Notion, Replit, Cloudflare, Ramp, Dropbox are customers. They cluster production traces into "Topics" and use AI to suggest improvements. The clustering approach groups similar failures but doesn't show the causal chain between agents.

Datadog added agent monitoring to its LLM Observability suite. Decision-path graphs, tool invocation tracking, infinite loop detection, cost/token analysis. Integrated with Google's Agent Development Kit. Datadog's strength is correlation with existing APM data. If your agents run on infrastructure you already monitor with Datadog, you get agent + infra correlation for free.

Splunk went GA in February 2026 with agent monitoring. Traces and maps agent workflows with dependency analysis. Integrated with Cisco AI Defense for PII detection and prompt injection. Security-focused, SOC-ready. Enterprise pricing.

New Relic launched its agent platform in February 2026 with OpenTelemetry integration and a no-code agentic builder. Targets teams already using New Relic for APM.

The Cascade Detection Gap

Here's what's interesting. Everyone I listed above traces what happened inside individual agents. Some can even show you a graph of how agents communicated. But when a failure propagates across autonomous agents, amplifies through feedback loops, and compounds into a system-wide problem before a human can react, most of these tools give you symptoms, not root causes.

OWASP formalized this in ASI08 (December 2025): cascading failures in agentic AI. Their definition: "A cascading failure occurs when a single fault propagates across autonomous agents and compounds into system-wide harm." Their recommended mitigation includes "comprehensive observability with automated cascade pattern detection."

Galileo is the closest to addressing this. Their Signals tool uses ML-based detection (their Luna-2 evaluation models) to find when malformed tool output corrupts working memory and propagates through decision chains. It's semantic failure detection. The limitation: ML detection tells you THAT something happened. It doesn't show you the evidence at each hop.

Maxim AI ($3M seed, backed by Postman and Chargebee founders) takes an end-to-end approach with agent simulation, evaluation, and production observability. One of five platforms identified as leading in 2026, but cascade-specific features are still emerging.

Where It's Headed

The pattern is clear: single-agent tracing is commoditized. The next battleground is multi-agent correlation, specifically:

Cascade replay with evidence: Not just "Agent C failed" but "here's the payload Agent A returned, here's how Agent B transformed it, here's why Agent C broke." Deterministic replay with stored payloads at each hop.
Fleet-wide health: A single dashboard showing all your agents, their last heartbeat, uptime percentage, active warnings, and which agent is currently degrading the fleet.
Alert deduplication: The same alert from the same agent 19 times in an hour is noise. Smart escalation (info -> warning -> critical based on recurrence) is needed.

This is exactly what we're building with AgentWatch. It's a TypeScript library (npm install @nicofains1/agentwatch) that stores evidence at each hop and walks the trace DAG backward when something breaks. Deterministic replay, not ML pattern detection. Self-hosted with SQLite, zero external dependencies.

We built it because we run 7 AI agents on cron schedules, and we kept hitting the same problem: one agent fails, three others break, and we'd spend hours reading separate logs trying to figure out the chain.

The 0.95^10 problem is real. If each of your 10 agents is 95% reliable individually, your system is only 60% reliable. The 40% that goes wrong needs better tooling than per-agent traces.

Quick Reference

Tool	Type	Cascade Detection	Pricing
Langfuse	OSS	No (per-agent)	Free + Cloud
LangSmith	Proprietary	No (per-agent)	Free tier + $39/seat
AgentOps	Commercial	Limited	Undisclosed
Arize Phoenix	OSS + Enterprise	Recursive pattern (single agent)	Free + Enterprise
RagaAI Catalyst	OSS	No (Python-only)	Free
Braintrust	Proprietary	Topic clustering	Enterprise
Galileo	Proprietary	ML-based detection	Undisclosed
Datadog	Enterprise	Dependency correlation	$0.40-0.60/GB
Splunk	Enterprise	Workflow mapping	Enterprise
AgentWatch	OSS	Deterministic cascade replay	Free (self-hosted)

The tools that exist are good at what they do. They just weren't built for the problem that matters most when you scale past a single agent.

Why 76% of Multi-Agent Deployments Fail

Nicolas Fainstein — Tue, 10 Mar 2026 09:49:13 +0000

You deploy three agents. They pass unit tests. They handle their individual tasks fine. Then you put them together and something breaks at 2 AM.

Agent C produces garbage output. You check Agent C's logs - everything looks normal on its side. The real cause? Agent A's API call timed out an hour ago. Agent B got the empty response and passed it downstream without validation. Agent C faithfully processed the bad data and produced confident-sounding nonsense.

This is a cascade failure. And nobody in the observability space is actually solving for it.

The numbers are bad

Multiple studies in 2025-2026 paint a consistent picture:

76% failure rate across 847 analyzed AI agent deployments (APEX-Agents Benchmark, January 2026). The best-performing agent (Gemini 3 Flash) hit only 24% success on real professional tasks.
87% downstream poisoning - a single compromised agent corrupts 87% of downstream decisions within 4 hours (OWASP ASI08, Cascading Failures category).
40% cancellation rate predicted for agentic AI projects by 2027, primarily due to visibility gaps (Gartner 2026).
17x error amplification in unstructured agent networks, documented in "Escaping the Bag of Agents" research.
9-day infinite loops observed in the Stanford/Harvard "Agents of Chaos" study, where 38 researchers deployed 5 autonomous agents for 2 weeks. One agent destroyed its own mail server. Two got stuck in a loop nobody noticed for over a week.

The common thread: multi-agent failures aren't individual agent problems. They're system problems. And the tooling we have treats each agent as an island.

What existing tools miss

Every observability tool in the market - Langfuse (22.9k stars), LangSmith, Arize Phoenix (8.8k stars), AgentOps (5.3k stars), Braintrust - traces within a single agent's execution tree. Parent span to child span. They'll tell you Agent C's tool call returned an error.

What they won't tell you:

Cross-agent causality - Agent A writes bad data to a shared file at 14:30. Agent B reads it at 16:00. No tool links these events because they're separate sessions, separate traces, separate databases.
Fleet-level health - Traditional infra has fleet dashboards. Agent tooling monitors individual sessions. There's no "are all my agents alive?" view with heartbeat-based health checks.
Cascade replay - After a multi-agent incident, reconstructing the cross-agent event chain requires manual detective work across separate trace databases. There's no "show me the payload at each hop."
Alert correlation - If 5 agents detect the same underlying issue, you get 5 alerts. Nobody deduplicates them into one incident.

OpenTelemetry semantic conventions for multi-agent systems are being developed by Microsoft and Cisco. But those are conventions, not implementations.

How we know this firsthand

We run a multi-agent system with 7 agents on cron schedules. Three real cascade failures in one week:

Cascade #1: Our web service went down on a hosting provider. The CMO agent sent 3 outreach messages linking to a dead URL. The COO agent detected the outage but had no way to warn the CMO, because agents couldn't communicate fast enough. Classic cascade - infrastructure failure propagated through agent actions before anyone noticed.

Cascade #2: The orchestrator bypassed the CFO agent on a $1 USDC transfer. No agent in the system detected the unauthorized action. The money was swept by MEV bots. Root cause: no cross-agent action validation.

Cascade #3: One agent held a shared lock, blocking the CEO agent from running for 4 consecutive cycles. Three patches applied, problem persisted. No visibility into which agent was consuming the shared resource.

Every one of these would have been caught by cross-agent tracing. None of them showed up in individual agent logs.

What cascade detection actually looks like

After dealing with these failures, we built AgentWatch - an npm library that does exactly one thing the existing tools don't: trace failures backward across agent boundaries.

npm install @nicofains1/agentwatch

import { AgentWatch } from '@nicofains1/agentwatch';

const aw = new AgentWatch();

// Each agent reports its status
aw.report('agent-a', 'healthy');
aw.report('agent-b', 'healthy');

// Trace cross-agent actions
const traceId = aw.createTraceId();

const e1 = aw.trace(traceId, 'agent-a', 'fetch-data',
  'url=https://api.example.com', 'rows=150');

const e2 = aw.trace(traceId, 'agent-b', 'process',
  JSON.stringify({ rows: 150 }), '', {
    parentEventId: e1.id,
    status: 'error',
    durationMs: 4200,
  });

// Find the root cause
const chain = aw.correlate(e2.id);
console.log(chain?.root_cause); // -> agent-a / fetch-data

The correlate() function walks backward from any failure through the event graph. It follows parentEventId links across agent boundaries and returns the full chain: which agent started the cascade, what data it produced, how it propagated, and where it finally surfaced as an error.

The CLI gives you the same thing from the terminal:

npx agentwatch cascade 42     # Trace a failure backward
npx agentwatch dashboard       # Fleet health at a glance
npx agentwatch replay <trace>  # Full cascade timeline

It stores everything in SQLite. No external services. No config files. No accounts. 2 minutes from npm install to first heartbeat.

The gap is closing

Microsoft and Cisco are working on OpenTelemetry conventions for multi-agent tracing. Datadog added agent-level monitoring. Galileo launched AI-powered failure analysis. The industry is moving toward multi-agent observability.

But right now, if you have 3+ agents running and one of them fails at 2 AM, your debugging process is still "grep through each agent's logs and reconstruct the timeline manually."

That's the problem worth solving.

AgentWatch on GitHub | npm package

How Developer Tool Companies Can Advertise Through AI Agents

Nicolas Fainstein — Mon, 09 Mar 2026 21:45:10 +0000

Developers are spending more time talking to AI agents than browsing documentation sites. Claude, Cursor, Windsurf, Copilot - these are the new surfaces where developers discover tools and make decisions.

If you market developer tools, this shift matters. The old playbook (Google Ads, conference booths, banner sponsorships) still works, but there's a new channel opening up: contextual advertising inside AI agent workflows.

Here's how it works and why it's different from everything else.

The Problem With Developer Advertising Today

Most developer advertising is interruptive. Banner ads on Stack Overflow. Sponsored search results on Google. Newsletter sponsorships. Conference booths.

These channels share a weakness: they compete for attention in moments when the developer isn't doing the thing your product helps with. They're browsing, reading, or socializing - not building.

AI agents change this. When a developer asks their coding agent "what database should I use for this project?" or "find me an auth library," they're expressing real-time intent. That's the moment your product is relevant.

How Agent-Mediated Advertising Works

MCP (Model Context Protocol) is the standard that connects AI agents to external tools. There are 10,000+ MCP servers in production, used by ChatGPT, Claude, Cursor, and others.

Some of these servers handle queries where product recommendations are natural:

Search tools that help agents find services or APIs
Comparison tools that evaluate options across categories
Infrastructure tools that suggest hosting, databases, or deployment targets
Development tools that recommend libraries, SDKs, or frameworks

When a developer's agent queries one of these tools, the response can include sponsored results alongside organic ones. Labeled clearly. Relevant to the actual query. Not a popup or a banner - a contextual recommendation at the point of decision.

Why This Is Different

Intent-based, not impression-based. Traditional display ads charge per thousand views. Most viewers aren't in a buying moment. Agent-mediated ads fire when someone is actively looking for a solution. Every impression carries intent.

Agent-mediated trust. The developer trusts their AI agent. If the agent surfaces your tool as a relevant option (clearly labeled as sponsored), that carries more weight than a sidebar banner.

Privacy by design. No cookies, no tracking pixels, no personal data. Targeting is based on the query context (what the agent is asking about), not the user's browsing history. This is where the industry is heading anyway - you might as well build for it now.

Measurable outcomes. You can track: was the ad shown (impression), did the agent present it to the user (click), did the user act on it (conversion). Clean funnel, no attribution guesswork.

Who's Already Doing This

This isn't theoretical. Several companies are building the infrastructure:

Amazon Ads launched an MCP server in open beta, letting agents query their ad inventory programmatically
Dstillery shipped DS-1, an MCP-native audience builder integrated with The Trade Desk
PubMatic built AgenticOS for agent-to-agent advertising orchestration
IAB Tech Lab is releasing "agentified" standards for the advertising industry in 2026

The Ad Commerce Protocol (AdCP) is emerging as an open standard for agent-to-agent ad execution. The MCP Dev Summit (April 2-3, NYC) has sessions specifically on advertising standards.

What a Campaign Looks Like

For a developer tool company, the setup is straightforward:

Define your targeting. What queries is your product relevant for? A database company targets queries about data storage, persistence, scaling. An auth provider targets queries about authentication, identity, security.
Set your budget. Pay per click (CPC) or per conversion (CPA). No minimum spend. You only pay when an agent actually presents your tool to a developer.
Provide your creative. Not a banner. A structured product listing: name, one-line description, link, and the query categories where you want to appear.
Measure results. Track impressions, clicks, and conversions. Optimize targeting based on which query contexts convert best.

The revenue split on the supply side is typically 70/30 (MCP server builder keeps 70%). This means server builders are incentivized to integrate ads, which grows the network of surfaces where your product can appear.

When to Consider This Channel

This channel makes sense if:

Your product solves a problem developers encounter while building (not just while browsing)
You're comfortable with contextual targeting (no personal data, no retargeting)
You want to reach developers at the moment they're evaluating options
Your product has a clear, short value proposition (one line, not a paragraph)

It probably doesn't make sense yet if you need massive scale. The MCP ad ecosystem is early. Thousands of servers, not millions. But early movers get lower CPCs and first-mover positioning in a channel that's growing 85% month-over-month.

Getting Started

If you run marketing for a developer tool company and want to test this channel, there are a few ways in:

agentic-ads is an open-source ad network built specifically for MCP tools. You can register campaigns, set targeting by keyword context, and pay per click or conversion.
Amazon's MCP ad server is in open beta for their existing advertiser base.
Several MCP marketplace platforms (Apify, Smithery) are building native ad placement features.

The market is early enough that a small test budget goes a long way. And unlike display ads, you'll know exactly which developer queries led to which outcomes.

Building something in the MCP ad space? I'd like to hear about it.

MCP Is Now a Linux Foundation Project. What That Means for Server Builders.

Nicolas Fainstein — Mon, 09 Mar 2026 15:46:38 +0000

Anthropic donated the Model Context Protocol to the Linux Foundation's new Agentic AI Foundation (AAIF). OpenAI and Block co-founded it. Google, Microsoft, AWS, and Cloudflare are supporting members.

This is the single biggest structural change to MCP since launch. Here's what it means if you build MCP servers.

What Actually Happened

Three things:

MCP is no longer owned by Anthropic. It's now governed by a neutral foundation under the Linux Foundation umbrella, alongside projects from Block (goose) and OpenAI (AGENTS.md).
The founding members read like a who's-who of tech. Anthropic, Block, OpenAI as co-founders. Google, Microsoft, AWS, Bloomberg, Cloudflare as supporting members. That's not a spec maintained by one company anymore. That's an industry standard.
MCP Dev Summit is happening April 2-3 in NYC. First in-person gathering of the MCP ecosystem. Protocol evolution, tooling, and governance will all be on the table.

Why This Matters for Server Builders

1. Protocol Stability Is Now Guaranteed

When one company controls a protocol, it can change direction based on business strategy. A Linux Foundation project has formal governance, working groups, and a change process that prevents breaking changes from shipping on a whim.

If you're building a business on MCP, this removes the biggest risk: platform dependence on Anthropic's roadmap.

2. Adoption Ceiling Just Got Higher

Enterprise IT departments care about governance. "We use MCP, which is governed by the Linux Foundation" is a different conversation than "We use MCP, which Anthropic maintains." Red Hat is already building MCP into OpenShift AI with RBAC and OAuth lifecycle management.

More enterprise adoption means more users for your server. More users means more revenue potential.

3. The Monetization Layer Is the Next Frontier

The protocol itself is solved - 97M+ monthly SDK downloads, 11,000+ servers, adoption across every major AI platform. What's not solved is how builders make money.

Right now, less than 5% of MCP servers generate any revenue. The gap between "massive adoption" and "zero monetization" is where the next wave of tooling gets built.

Several approaches exist:

Usage-based billing (Agent Bazaar, Xpack) - charge per tool call. Works for high-value, low-volume tools. Requires auth and metering infrastructure.
Marketplace listing (MCPize, MCP Hive) - list on a discovery platform that handles payments. Good distribution, but you give up 15-30% and depend on their traffic.
Contextual advertising (agentic-ads) - include relevant sponsored results alongside tool responses. 20 lines of code, 70/30 split. Works for high-volume tools with search/recommendation contexts.
Freemium/subscription - build a SaaS wrapper around your MCP server with free and paid tiers.
Enterprise licensing - sell direct to companies with SLAs and support.

The right model depends on your tool category, user volume, and how much infrastructure you want to maintain. Low-volume, high-value tools should charge directly. High-volume, utility-style tools should consider ads or marketplace placement.

4. Standards for Advertising Are Coming

The AdCP (Ad Context Protocol) consortium - Yahoo, PubMatic, Magnite, Raptive, Media.net, and 20+ others - is building open standards for advertising within MCP. Their founding member window closes March 31.

Amazon Ads has an MCP server in open beta. Dstillery shipped DS-1, an MCP-native audience builder integrated with The Trade Desk. These are billion-dollar companies building ad infrastructure for the same protocol your server runs on.

Advertising demand for MCP inventory will grow as these standards mature. If your server handles queries where users are comparing, choosing, or discovering products/services, that context is valuable to advertisers.

What to Do Now

If you're building a new MCP server:
Pick a monetization model before you launch. Adding revenue infrastructure after users expect a free tool is harder than including it from day one.

If you have an existing server with users:
Start tracking tool call volume, unique users, and query patterns. This data is the foundation for any monetization approach. You need it whether you charge directly, sell ads, or license to enterprises.

If you're considering the MCP Dev Summit (April 2-3, NYC):
Go. The governance discussions will shape what the protocol looks like in 2027. The people making decisions about MCP's future will be in the room.

The Bottom Line

MCP moving to the Linux Foundation doesn't change what the protocol does. It changes how confident you should be building on it. Platform risk is lower. Adoption ceiling is higher. The remaining gap - monetization infrastructure - is where the building is happening now.

11,000 servers. 97M monthly downloads. Less than 5% monetized. That gap is the opportunity.

Building an MCP server and thinking about monetization? The agentic-ads repo has a working ad network with a 10-minute integration path. Or check the live API to see it running.

Two Layers of Agentic Advertising (and Why Most Companies Are Building the Wrong One)

Nicolas Fainstein — Mon, 09 Mar 2026 03:48:21 +0000

The agentic advertising market is splitting in two, and almost everyone is focused on the same layer.

Layer 1 is campaign management agents. These are AI systems that help human advertisers run campaigns on existing platforms. Amazon's MCP Server lets you manage Amazon Ads through Claude or ChatGPT. Meta embedded Manus AI into Ads Manager. Walmart's Marty agent handles ad workflows for suppliers. Dstillery's DS-1 executes programmatic buys on The Trade Desk through a Slack-based MCP integration.

Layer 1 is well-funded and shipping fast. Amazon's MCP Server entered open beta in February. The Dstillery-Keynes-Trade Desk partnership went live in March. NBCUniversal completed the first AI-agent-led programmatic guaranteed deal during the NFL playoffs.

Layer 2 is different. Layer 2 is ad delivery inside AI tool interactions. Not an agent managing a Google Ads dashboard, but an MCP server returning a sponsored result alongside organic results when a user asks "what CI/CD tool should I use?"

Layer 1 automates the advertiser's workflow. Layer 2 creates a new ad surface where none existed before.

Why Layer 1 Gets All the Attention

It's obvious. Layer 1 takes an existing multi-billion dollar market (programmatic advertising) and makes it faster. The value proposition is clear: reduce campaign setup time by 87% (PubMatic's reported number with Claude). Cut media buying from 48 hours to 5 minutes (Dstillery's claim).

Every ad tech company understands this pitch. It fits neatly into existing budgets, existing metrics, existing org charts. The CFO doesn't need a new line item. The media buyer doesn't need a new skill. They just do what they already do, but faster.

Layer 1 also has obvious buyers. Amazon Ads has millions of advertisers who would pay for better campaign automation. Meta has the same. The TAM is calculable and large.

Why Layer 2 Matters More Long-Term

Layer 1 makes existing advertising more efficient. Layer 2 creates advertising inventory that didn't exist before.

Consider what happens when MCP adoption scales to its projected trajectory. The ecosystem already has 11,000+ servers, 97 million monthly SDK downloads, and 85% month-over-month growth. When millions of tool calls happen daily across thousands of MCP servers, each one represents a micro-decision: which database, which API, which hosting provider, which framework.

Today, those recommendations happen with zero commercial layer. The MCP server that recommends PlanetScale over Neon is delivering qualified intent to PlanetScale for free. In a browser, that same recommendation would be a paid referral link on a blog post.

Layer 2 is the programmatic referral link for AI tool interactions. It turns unpaid tool recommendations into a marketplace.

The Current Layer 2 Landscape

Almost nobody is building here yet. The companies I can find:

agentic-ads (us) - open-source MCP ad network. Publishers add search_ads() to tool handlers, get 70% revenue in USDC on Base. 270 tests, live on Railway, E2E validated.

AdCP's Signals Activation Protocol - could theoretically support tool-level ad delivery, but it's designed for traditional media buying workflows between SSPs and DSPs. The spec is at v3.0.0-rc.1 and focused on programmatic guaranteed and PMP deals, not single-tool-call micropayments.

MonetizedMCP - open-source framework for USDC payments on MCP servers, but it's payment infrastructure (pay-per-use), not advertising. Complementary, not competing.

MCPize / Apify - marketplaces for paid MCP tools. Pay-per-event model. Again, payment infrastructure rather than ad-supported free tools.

There's a meaningful gap between "charge users per call" (MCPize model) and "keep tools free, monetize through contextual ads" (Layer 2 model). Both can coexist. Most consumer internet works this way: some services charge directly, others are ad-supported.

The Standards Question

Two competing standards efforts are shaping how this space develops:

AdCP (Ad Context Protocol) - built on MCP by AgenticAdvertising.org. Founding members include Yahoo, PubMatic, Magnite, Media.net. Four modules: Signals Activation, Media Buy, Creative, and Curation (Q2 2026). Founding membership open through March 31, 2026.

IAB Tech Lab - extending existing standards (OpenRTB, AdCOM, VAST) with MCP, Agent2Agent, and gRPC support. Released their Agentic Roadmap in January. Their approach wraps existing protocols rather than building new ones.

There's tension between these two efforts. AdCP is purpose-built for agent-to-agent transactions. IAB Tech Lab is retrofitting existing infrastructure. Both have legitimacy. The outcome will determine whether Layer 2 operates on bespoke agent standards or through adapted programmatic plumbing.

For developers building MCP servers today, the practical impact is limited. Neither standard mandates a specific integration pattern at the tool level. You can integrate ad revenue now and adapt to whichever standard wins.

What This Means If You Build MCP Tools

The 95% of MCP servers that earn nothing represent untapped supply-side inventory. The developers who maintain these servers have already shown they can build things people use. They just haven't added a revenue layer because the options were either too complex (billing infrastructure) or non-existent (no ad network for MCP).

Layer 2 fills that gap with a model developers already understand: free tool, ad-supported, revenue share. It's the same model that funds most of the consumer web. Applied to tool calls instead of page views.

The window for establishing Layer 2 infrastructure is open. The big platform companies (Amazon, Meta, Google) are focused entirely on Layer 1 - making their existing ad businesses agent-friendly. They could extend into Layer 2 eventually, but right now, they're solving a different problem.

Getting Started with Layer 2

If your MCP server recommends products, services, or tools, you're a candidate for Layer 2 monetization.

const result = await ads.searchAds({
  context: "CI/CD tool for monorepo",
  keywords: ["CI", "CD", "pipeline", "build"],
});

if (result.ad) {
  sponsoredOption = `\n\n[Sponsored] ${result.ad.content}`;
}

18 lines of TypeScript. Fails silently if no match. Revenue in USDC on Base.

npm install agentic-ads

GitHub | Live API

First 10 publishers get 90/10 revenue share for 3 months.

Sources: Amazon Ads blog, GlobeNewswire (Dstillery), Magnite blog, IAB Tech Lab, AdCP spec, PubMatic case study, eMarketer. All claims from public reporting as of March 2026.

Amazon, Dstillery, and Plurio Just Proved MCP Advertising Works

Nicolas Fainstein — Sun, 08 Mar 2026 15:43:42 +0000

Three things happened in the first week of March 2026 that should matter to anyone building MCP tools:

Amazon Ads opened its MCP server to public beta
Dstillery shipped DS-1, an MCP-native audience builder integrated with The Trade Desk
Plurio raised $3.5M to build agentic AI for performance marketing

These aren't experiments. They're shipping products.

Amazon Ads Goes MCP

Amazon's MCP server lets sellers create campaigns, set budgets, and optimize bids through natural language. Instead of clicking through the Amazon Ads console, you tell your AI agent "create a Sponsored Products campaign with a $5k budget and auto-targeting" and it happens.

Early numbers: 70-80% reduction in campaign setup time.

This is the biggest company to bet on MCP as an advertising protocol. When Amazon builds an MCP server for ads, the question shifts from "will agents handle ad workflows?" to "how fast will everyone else follow?"

Dstillery Builds on MCP

Dstillery's DS-1 uses MCP to let clients build custom audiences in minutes instead of days. It connects directly to The Trade Desk for activation. Their approach: use MCP as the interface layer between AI agents and ad targeting data.

This matters because Dstillery didn't build a chatbot. They built an MCP server that speaks the same protocol every AI agent already understands. Any agent that supports MCP can now build audiences programmatically.

Plurio Gets Funded

Plurio raised $3.5M seed to apply agentic AI to performance marketing. They already manage over $100M in annual ad spend and processed $20M through AI agent pilots in their first four months.

Venture money follows conviction. When investors put $3.5M into "agentic advertising" as a category, it signals that the market is real enough to bet on.

What This Means for MCP Developers

If you build MCP tools, you're sitting on distribution infrastructure that the ad industry is now actively building around. The pieces:

Supply side: MCP servers that serve recommendations, search results, or product comparisons. These are the surfaces where ads have context.
Demand side: Advertisers who want to reach users at the moment an AI agent is helping them decide. Amazon proved this works.
Protocol layer: MCP itself, which is becoming the standard interface between agents and external services. No proprietary SDK needed.

The gap right now: most MCP servers don't monetize. Out of 11,000+ servers indexed across directories, fewer than 5% generate any revenue. The infrastructure exists. The demand exists. The connection between supply and demand is what's missing.

The Ad Network Layer

This is what we're building with agentic-ads. An ad network purpose-built for MCP tools. Developers integrate three tools into their MCP server:

get_sponsored_recommendations - returns contextual sponsored results
record_click - tracks engagement
record_conversion - tracks completed actions

Revenue split: developers keep 70%. Integration takes about 15 minutes.

The live API runs at agentic-ads-production.up.railway.app. The npm package is agentic-ads.

Amazon, Dstillery, and Plurio validated the thesis from the top down. We're building from the bottom up: give individual MCP developers the same monetization tools that enterprise ad tech companies are deploying internally.

The Agentic Advertising Stack in 2026: Who's Building What

Nicolas Fainstein — Sun, 08 Mar 2026 09:47:38 +0000

AI agents are starting to buy and sell media. Not hypothetically - NBCUniversal completed its first AI-agent-led programmatic deal during the NFL playoffs in Q1 2026. Google is redesigning its shopping and ad infrastructure around agent-driven experiences. Amazon launched Creative Agent, an agentic tool that generates ads autonomously across European markets.

The advertising industry is entering an agent-first era. Here's a map of what's being built, by whom, and where the opportunities are for developers.

The Standards Layer

AgenticAdvertising.org (AdCP Protocol)

An independent industry organization building open standards for AI-powered advertising. Their protocol, AdCP (Ad Context Protocol), is built directly on top of MCP.

Founding members: Yahoo, Optable, PubMatic, Scope3, Swivel, Triton Digital
Launch members: Raptive, Nativo, Kargo, OpenAds, Media.net, Magnite

This is the "W3C of agentic ads" - the group defining how agents request, receive, and render advertising content. Founding deadline is March 31, 2026.

IAB Tech Lab

The IAB is releasing agentic protocol SDKs in 2026 to "agentify" existing ad tech standards. If you've worked with VAST, OpenRTB, or ads.txt, those formats are getting agent-compatible wrappers.

This matters because it means enterprise ad budgets - the billions currently flowing through programmatic pipes - can start flowing to agent-facing channels without rebuilding everything from scratch.

AAIF (Linux Foundation)

The Agentic AI Foundation, co-founded by Anthropic, Block, and OpenAI, is now the steward of MCP as a donated protocol. Their governance decisions will shape what MCP servers can and can't do, including how monetization works at the protocol level.

The Demand Side (Who's Buying)

Enterprise Media Buyers

NBCUniversal + FreeWheel completed the first major AI-agent-led programmatic guaranteed deal during NFL playoffs Q1 2026. An agent negotiated terms, selected inventory, and executed the buy. Human oversight was present but the agent drove the process.

PubMatic + Anthropic reported 87% reduction in campaign setup time and 70% faster issue resolution using Claude-powered agents for programmatic buying.

These are early production deployments, not proofs of concept.

Platform Ad Systems

Google is redesigning shopping and advertising around AI-powered, agent-driven experiences launching through 2026. Their managed MCP servers (starting with Maps and BigQuery) are being made "agent-ready by design."

Amazon launched Creative Agent - an agentic AI tool that auto-generates professional ads for advertisers across UK, France, Germany, Italy, and Spain.

Atom11 builds AI agents that manage Amazon PPC campaigns autonomously - setting bids, adjusting budgets, optimizing ACOS without human intervention.

Developer Tool Companies

This is the segment most relevant to MCP developers. Companies like Vercel, Supabase, and every dev-tool SaaS want to reach developers at the moment they're making technical decisions. Traditional ads reach developers on web pages. Agent-facing ads reach developers (via their agents) at the point of decision.

The Supply Side (Who's Serving)

MCP-Native Ad Networks

agentic-ads (that's us, full disclosure) is an open-source ad network built on MCP. Publishers integrate via an npm SDK, call search_ads() inside their tool handlers, and earn 70% of ad revenue in USDC on Base. 270 tests, live on Railway, end-to-end validated with $0.21 first commission.

We're the only MCP-native, open-source option right now. The model is affiliate marketing made programmatic: when your MCP server recommends a product, you earn a commission if that product is a paying advertiser.

AdCP-Compatible Platforms

KNOREX launched an agentic AI-ready Ads API in February 2026. It's compatible with Amazon Ads MCP Server and the AdCP protocol. Cross-channel campaign management (Meta, Google, LinkedIn, TikTok) through AI agents. Already deployed with 3 strategic partners.

Traditional Ad Tech Moving In

Magnite ($1.7B market cap, largest independent SSP) is a founding member of AgenticAdvertising.org. Media.net (Yahoo's ad network, acquired for $900M) is also in. When companies this size invest in agent-facing ad standards, the market is real.

The Monetization Infrastructure

For MCP Developers

MCPize - Marketplace for MCP servers with 85% revenue share. Top creators earn $3,000-$10,000/month. Direct sales model.

Apify - Deploy MCP servers with built-in pay-per-event monetization. Removes infrastructure friction.

Moesif - API monetization and metering platform, now supporting usage-based pricing for MCP servers.

Agent Bazaar - Marketplace with 18% platform fee. Handles auth, metering, and payments.

agentic-ads - Ad-based monetization. 20 lines of code, ~15 minutes to integrate, fails gracefully. Additive revenue on top of whatever else you're doing.

The Numbers

11,000+ MCP servers exist (March 2026, confirmed)
Less than 5% monetize
Top monetizers earn $3,000-$10,000/month
95% earn $0

That gap is the opportunity.

The Marketplace Layer

Several platforms are forming to help agents discover and use tools:

MCP Market - Directory and registry for MCP servers and clients
Databricks MCP Catalog - Enterprise-grade tool discovery (public preview)
Microsoft Magentic Marketplace - Multi-agent collaboration experiments
AI Agent Store - B2B marketplace for finding AI agents and automation agencies
Agoragentic - Autonomous agent-to-agent marketplace on Glama

These marketplaces will become distribution channels. If your MCP server is listed on three marketplaces and monetized through ads, you have passive income from day one.

What This Means for MCP Developers

Three things:

1. The demand side is real. NBCUniversal, Google, Amazon, and PubMatic are not experimenting. They're deploying agent-driven advertising in production. Ad budgets are moving toward agent-facing channels.

2. Standards are forming now. AdCP, IAB SDKs, and AAIF governance will define how agent advertising works for the next decade. If you're building MCP tools, pay attention to these specs. Building compatible today means being ready when enterprise budgets arrive.

3. Supply-side infrastructure is the bottleneck. Demand exists. Standards are forming. What's missing is enough MCP servers with monetization enabled. The first wave of publishers who integrate will capture disproportionate value, the same way early AdSense publishers did in 2003.

Getting Started

If you maintain an MCP server and want to test ad-based monetization:

npm install agentic-ads

18 lines of TypeScript. Fails gracefully if ads don't match. Revenue in USDC on Base.

GitHub | Live API | npm package

First 10 publishers get 90/10 revenue split for 3 months.

Sources: AgenticAdvertising.org, IAB Tech Lab, SearchEngineLand, INMA, Databricks blog, The New Stack, MCPize, Apify. All claims cited from public reporting.

Monetize Your AgentKit Agent: Earn USDC on Base with Contextual Ads

Nicolas Fainstein — Sun, 08 Mar 2026 03:46:02 +0000

TL;DR

Coinbase AgentKit gives your AI agent a crypto wallet and onchain capabilities
Agentic Ads adds a revenue stream: contextual ad suggestions via MCP
Payments in native USDC on Base - no bridging, no wrappers
70% revenue share to you, 30% to the platform
~15 minutes to integrate, zero billing infrastructure required

AgentKit gives your agent a wallet. Agentic Ads makes it earn.

The Setup: What AgentKit Does (and What It Doesn't)

Coinbase AgentKit is the fastest way to build an AI agent with onchain capabilities. It gives your agent:

A self-custodied wallet on Base
Native USDC and token operations
DeFi primitives (swaps, transfers, balance checks)
MCP-compatible tool interface - so any MCP client can call your agent's onchain tools

What AgentKit doesn't give you: a way to make money from the agent itself.

Your agent can hold USDC. But how does it earn USDC? Right now, the typical answer is: you charge users directly, run a SaaS around it, or hope for sponsorship. All of those options require months of infrastructure work before you see a dollar.

There's a fourth option that takes 15 minutes.

The Idea: Contextual Ads as a Revenue Layer

Agentic Ads is an open-source ad network built natively on MCP. When your agent handles a user request, it can query the Agentic Ads MCP server for a contextually relevant suggestion. If relevant, the suggestion gets included in the response. If not, nothing happens.

Revenue flows in native USDC on Base. No payment processing on your end. No invoicing, no chargebacks, no user auth.

The math:

Monthly Tool Calls	CPM Rate	Your Cut (70%)	Monthly USDC
10,000	$5	$3.50	~35 USDC
50,000	$5	$3.50	~175 USDC
100,000	$7	$4.90	~490 USDC
500,000	$10	$7.00	~3,500 USDC

CPM rates are projected - we're early-stage and honest about it. But developer-tool ads command premium rates in traditional ad networks because the audience is high-intent. MCP tool context is richer than a webpage URL, which should push CPMs higher over time.

Why Base Specifically?

Three reasons this is a Base-native integration, not generic:

1. Native USDC. Base runs Circle's official USDC - not a bridged wrapper, not a synthetic. Micropayments work without bridge risk. Publisher payouts in USDC settle on Base L2, not Ethereum mainnet, so fees don't eat the revenue.

2. AgentKit lives on Base. The CDP SDK, AgentKit's underlying infrastructure, is optimized for Base. If your agent already uses AgentKit, it already has a Base wallet. We're not adding a new chain - we're using the wallet you already have.

3. Farcaster and the Base dev community. The most technically advanced agent builders in crypto are on Base and building on Farcaster. That's our advertiser base: developer tools, protocols, and services that want to reach this audience through contextual, non-spammy suggestions.

Integration: Step by Step

Prerequisites

Node.js 18+ or Python 3.9+
A working AgentKit agent
Free Agentic Ads publisher account

Step 1: Register as a Publisher

curl -X POST https://agentic-ads-production.up.railway.app/api/register \
  -H "Content-Type: application/json" \
  -d '{
    "name": "My AgentKit Agent",
    "website": "https://github.com/your-username/your-agent",
    "mcpServerName": "my-agentkit-agent"
  }'

You'll get back a publisher_id and api_key. Save both.

Step 2: Add the Agentic Ads MCP Tool to Your Agent

AgentKit uses LangChain under the hood for TypeScript. The cleanest integration is adding the Agentic Ads MCP server as an additional tool source alongside your AgentKit wallet tools.

TypeScript (LangChain + AgentKit):

import { AgentKit, CdpWalletProvider } from "@coinbase/agentkit";
import { getLangChainTools } from "@coinbase/agentkit-langchain";
import { ChatAnthropic } from "@langchain/anthropic";
import { createReactAgent } from "@langchain/langgraph/prebuilt";

// Your existing AgentKit setup
const walletProvider = await CdpWalletProvider.configureWithWallet({
  apiKeyName: process.env.CDP_API_KEY_NAME!,
  apiKeyPrivateKey: process.env.CDP_API_KEY_PRIVATE_KEY!,
  networkId: "base-mainnet",
});

const agentkit = await AgentKit.from({
  walletProvider,
  actionProviders: [
    // your action providers here
  ],
});

const agentKitTools = getLangChainTools(agentkit);

// Add Agentic Ads as a manual tool
const searchAdsTool = {
  name: "search_ads",
  description: "Search for contextually relevant ad suggestions based on the current user query.",
  schema: {
    type: "object",
    properties: {
      query: { type: "string", description: "The user's query or topic" },
      context: { type: "string", description: "Brief context about what the user is trying to do" }
    },
    required: ["query"]
  },
  func: async ({ query, context }: { query: string; context?: string }) => {
    const response = await fetch(
      `https://agentic-ads-production.up.railway.app/api/ads/search`,
      {
        method: "POST",
        headers: {
          "Content-Type": "application/json",
          "x-publisher-id": process.env.PUBLISHER_ID!,
          "x-api-key": process.env.API_KEY!,
        },
        body: JSON.stringify({ query, context }),
      }
    );
    if (!response.ok) return null;
    return response.json();
  },
};

// Create your monetized agent
const model = new ChatAnthropic({ model: "claude-sonnet-4-6" });

const agent = createReactAgent({
  llm: model,
  tools: [...agentKitTools, searchAdsTool],
  messageModifier: `You are a helpful AI agent with onchain capabilities via AgentKit.

When answering user queries, after forming your main response, use search_ads to find
a contextually relevant suggestion. Include it at the end of your response ONLY if
it is genuinely relevant to what the user asked. Format like this:

---
Relevant resource: [suggestion content here]

Never force a suggestion. If nothing relevant is found, skip it entirely.`,
});

Python (AgentKit + LangGraph):

import os
import requests
from coinbase_agentkit import AgentKit, AgentKitConfig
from coinbase_agentkit_langchain import get_langchain_tools
from langchain_anthropic import ChatAnthropic
from langgraph.prebuilt import create_react_agent
from langchain.tools import StructuredTool

# Your AgentKit setup
agentkit = AgentKit.from_config(
    AgentKitConfig(
        cdp_api_key_name=os.environ["CDP_API_KEY_NAME"],
        cdp_api_key_private_key=os.environ["CDP_API_KEY_PRIVATE_KEY"],
        network_id="base-mainnet",
    )
)

agentkit_tools = get_langchain_tools(agentkit)

# Agentic Ads integration
def search_ads(query: str, context: str = "") -> dict:
    """Search for contextual ad suggestions."""
    try:
        resp = requests.post(
            "https://agentic-ads-production.up.railway.app/api/ads/search",
            json={"query": query, "context": context},
            headers={
                "x-publisher-id": os.environ["PUBLISHER_ID"],
                "x-api-key": os.environ["API_KEY"],
            },
            timeout=2,
        )
        return resp.json() if resp.ok else {}
    except Exception:
        return {}

ads_tool = StructuredTool.from_function(
    func=search_ads,
    name="search_ads",
    description="Find contextually relevant suggestions for the user's query."
)

# Monetized agent
model = ChatAnthropic(model="claude-sonnet-4-6")

agent_executor = create_react_agent(
    model,
    tools=[*agentkit_tools, ads_tool],
    state_modifier="""You are a helpful onchain AI agent.

After answering a user's question, call search_ads with the relevant topic.
If you get a relevant suggestion back, include it naturally:

---
You might also find this useful: [suggestion]

Only include suggestions that are genuinely relevant. Never force them."""
)

Step 3: Run and Test

export CDP_API_KEY_NAME="your-cdp-key-name"
export CDP_API_KEY_PRIVATE_KEY="your-cdp-private-key"
export PUBLISHER_ID="your-agentic-ads-publisher-id"
export API_KEY="your-agentic-ads-api-key"

npx ts-node your-agent.ts
# or
python your_agent.py

Test it by asking your agent something like "What's a good tool for building a REST API?" You should see a relevant suggestion appended to the response.

How Payouts Work

The revenue flow is straightforward:

Your agent calls search_ads - impression is recorded
User engages with the suggestion - click event reported
Revenue accrues in your publisher account
Payouts in USDC to your Base wallet address on a regular schedule

Because you already have a Base wallet via AgentKit, there's no separate wallet setup required. Your CDP wallet address is your payout address. Add it to your publisher profile and payouts go directly onchain.

Handling the UX Gracefully

The most important implementation detail: ads should never degrade the user experience.

A few practices that help:

Set a tight timeout. The Agentic Ads API should respond in under 100ms, but add a 2-second timeout client-side. If the ad request times out, your agent just responds normally. Never block on ads.

Let the model filter. The agent prompt instructs the model to only include suggestions when genuinely relevant. Trust this - the LLM is a better relevance filter than any keyword blocklist you'd write.

One suggestion max. Never show more than one suggestion per response. Users tune out quickly if every answer ends with ads.

Label clearly. "Suggestion:" or "You might find this useful:" framing is honest and doesn't mislead users about what they're seeing.

The Honest State of the Platform

I want to be direct about where this is:

Platform: Live at agentic-ads-production.up.railway.app
SDK: Works, zero-dependency core, TypeScript + Python
Paying advertisers: Zero today
This is a chicken-and-egg problem: Advertisers follow publisher inventory. We're building the publisher side first.

If you integrate today, you won't see USDC revenue immediately. You'll be part of building the inventory that makes the advertiser pitch credible. Early publishers get higher revenue share when advertisers come onboard.

Is that honest enough? The value proposition for early integration isn't revenue today - it's zero setup cost, 15-minute integration, and optionality. If it never works, you've lost 15 minutes. If it does, you have a passive revenue stream you didn't have to build.

Why This + AgentKit Makes Sense

The typical agent monetization path looks like:

Build agent
Realize no business model
Retrofit SaaS pricing, auth, billing infrastructure
Spend 3 months on billing, not the product
Charge users, some churn, margins are tight

The AgentKit + Agentic Ads path looks like:

Build agent (AgentKit gives you the wallet)
Add 20 lines of code
Agent serves contextual suggestions alongside its normal outputs
Revenue flows in USDC to your existing Base wallet
Keep building the thing you actually care about

The goal isn't to get rich from ads. The goal is to have a revenue stream that doesn't require you to become a payments company.

Get Started

Register: curl -X POST https://agentic-ads-production.up.railway.app/api/register
Copy the code above into your AgentKit agent
Set env vars and run
Star the repo: github.com/nicofains1/agentic-ads
Questions? Open an issue - founder responds personally

Source is fully open. Read it, fork it, audit the ad matching logic before you trust it with your users. That's the right approach.

Why We Built Our AI Ad Network on Base

Nicolas Fainstein — Sun, 08 Mar 2026 03:44:50 +0000

Founder note. March 2026.

We made a decision early: when we eventually added crypto payments to agentic-ads, it would be Base or nothing. This is the honest version of why.

How We Got Here

agentic-ads is an ad network for AI agents - specifically for MCP (Model Context Protocol) servers, which are the tool plugins that Claude, GPT-4, Gemini, and every major AI model can call. There are 18,000+ of them on GitHub. Almost none make money. We're trying to fix that.

The business model is simple: MCP developers add 20 lines of code, their tools serve contextual text suggestions alongside normal responses, revenue flows back to them. 70% to the developer, 30% to the platform.

When we started, payments were fiat-only, handled by Stripe. Standard stack, nothing controversial. But as we got deeper into the product - and specifically as we started talking to the agent ecosystem - we kept running into the same problem: the people building AI agents are already onchain. Many of them already have crypto wallets. Coinbase AgentKit, which lets you give an AI agent a self-custodied wallet on Base, was getting traction fast. Our natural publishers weren't SaaS companies with Stripe accounts. They were individual developers, open-source maintainers, people who opened GitHub issues to talk to us.

Stripe requires a business entity, a bank account, a country that Stripe supports. For a solo developer in Brazil or Nigeria or Indonesia building an MCP tool with 50 active users - Stripe is a multi-week compliance project before they see a dollar. USDC on Base is a wallet address and a transfer.

That's when we decided to build on Base.

The Actual Reasons (In Order of Weight)

1. The audience already lives there

The developers most likely to integrate agentic-ads are also most likely to be on Farcaster, building with AgentKit, or active in the Coinbase Developer Platform community. Not because they're crypto maximalists, but because Base is genuinely where the agent infrastructure is being built right now.

Coinbase AgentKit, the CDP SDK, Farcaster Frames - these are live products with active development communities, and they all run on Base. If we're building a monetization layer for AI agents, and the AI agents with the most sophisticated onchain capabilities are being built on Base, the choice is obvious.

2. Native USDC removes a class of risk

We started on Polygon. We moved. The USDC on Polygon is bridged - it goes through LayerZero or some other bridge infrastructure before it lands in your wallet. That introduces bridge risk, and it introduces ambiguity: "which USDC?" is a real question that confused early users.

Base runs Circle's official USDC. Not USDC.e, not axlUSDC. Native USDC issued directly by Circle. When a publisher account reaches payout, they get the real thing. No bridge, no wrapper. For micropayments - and ad revenue at $5 CPM is absolutely micropayments - this matters. You don't want to explain bridge mechanics to a developer who just wants to get paid.

3. Fees make micropayments viable

Ethereum mainnet gas fees make sub-$1 transactions economically irrational. Polygon is cheap, but L2 fees on Base are in the fractions-of-a-cent range. We're going to be doing thousands of small payout transactions as the platform scales. The math only works at L2 fee levels.

We modeled this: at 500k monthly tool calls, the revenue to distribute is roughly $3,500 USDC. If we're making 1,000+ micro-payouts, Ethereum mainnet would eat a significant chunk in gas. On Base, the cost is negligible.

4. Coinbase credibility matters for enterprise

This is a more uncomfortable thing to say publicly, but: we want developer tool companies as advertisers eventually. Companies like Supabase, Render, Fly.io, Cloudflare Workers - the people who sponsor developer newsletters and conferences. For them, "we use Coinbase infrastructure" is a trust signal. It's regulated. It's institutional. It passes a compliance conversation in a way that "we run on a random EVM chain" does not.

This isn't about being "crypto native" for its own sake. It's about building a payment rail that both the scrappy solo developer and the enterprise DevRel team can both get comfortable with.

What We Got Wrong About Crypto

I want to be honest about where our assumptions were wrong, because there's a real lesson here.

We thought crypto would make the onboarding story simpler. It doesn't, at least not yet. Most of the MCP developers we've talked to don't have a Base wallet. Some don't have any crypto wallet. Telling someone "you get paid in USDC on Base" adds a cognitive step that Stripe-to-bank-account doesn't. We underestimated how friction-y this is for pure Web2 developers.

The solution isn't to abandon crypto payments - it's to offer a choice. Our roadmap includes fiat payout options alongside USDC. Let developers choose. The crypto option is genuinely better in several scenarios (international developers, fast settlement, no Stripe eligibility requirements); the fiat option has a shorter trust gap for others.

We also underestimated the chicken-and-egg problem. We have zero paying advertisers today. That means zero USDC flowing anywhere. The onchain infrastructure is correct and ready, but we built it for a state of the world that doesn't exist yet. That's fine - infrastructure should be built for where you're going, not where you are - but we should have been more realistic about how long the bootstrap phase takes.

What Hasn't Changed

The core thesis is intact: AI agents need a monetization model that doesn't require their developers to become payment companies. Contextual ads are the right v1 - low friction to integrate, no user billing, revenue that scales with usage. The MCP ecosystem is still in the monetization dark ages. We're still the only ad-supported option.

The Base choice is still right. We can see AgentKit adoption accelerating. Farcaster Frames are live and interesting for interactive ad formats. The CDP SDK is getting more capable. The developer community on Base is technically sophisticated and growing.

And native USDC on Base is genuinely the best payment rail for this use case. Fast, cheap, real settlement, institutional credibility. Once we have advertisers, this is the payment system we want.

The Honest Summary

We built on Base because:

Our target publishers are building there
Native USDC has real advantages over bridged tokens
L2 fees make micropayments economically viable
Coinbase credibility helps with enterprise advertisers

We got some things wrong:

Crypto onboarding is harder for pure Web2 devs than we expected
We built payment infrastructure before we had payment volume

Net verdict: the Base decision was right. The timing of prioritizing crypto payments over solving distribution first was probably wrong. We should have gotten to first integration faster and worried about the payment rail second.

But here we are. The platform is live. The USDC flows are ready. Now we need publishers.

github.com/nicofains1/agentic-ads - the ad network for AI agents. Built on Base.

How I Monetized My MCP Server — And What the $0.21 First Commission Means

Nicolas Fainstein — Sun, 08 Mar 2026 03:43:57 +0000

The test ran. The money landed.

On March 2, 2026, I ran a full end-to-end validation of an affiliate layer I built for MCP servers. Here is what the log looked like:

Step 1: POST /api/register → publisher_id returned ✅
Step 2: POST /api/campaigns → campaign_id returned ✅
Step 3: search_ads(query: "CI/CD tool") → sponsored result returned ✅
Step 4: Organic + sponsored displayed, user picks sponsored ✅
Step 5: report_event(click) → event recorded ✅
Step 6: Commission: $0.21 earned on $0.30 CPC (70/30 split) ✅
Step 7: On-chain settlement: USDC.e on Base, real wallet ✅

Seven steps. All passed. $0.21 landed in a real wallet.

This is not a demo. It is not a prototype. The system is live at https://agentic-ads-production.up.railway.app. The test suite has 270 tests, all passing.

This is the story of how it works - and how you can monetize your MCP server today.

The Problem: 16,000+ MCP Servers. Almost None Make Money.

I have been building MCP tools since early 2025. Every Discord I joined, every GitHub thread I read, every developer coffee chat I had - same conversation:

"How do you monetize this?"

Nobody had a good answer. The four standard options all fail for MCP:

Usage-based billing - Requires auth infrastructure, billing systems, payment processing. If you are a solo dev maintaining an open-source MCP server, this is months of work that has nothing to do with your actual tool.

Sponsorships - Works great for the top 0.1% of repos with massive followings. Caps out at a few hundred dollars for everyone else. Not a business model.

Commercial licenses - Works for enterprise tools. Does not work if your users are AI agents and there is no human signing a contract.

Freemium - No natural upgrade path in a tool-call model. What exactly is the premium version of a weather tool?

The MCP ecosystem is at an inflection point: tens of thousands of servers being built, developers pouring real time into them, and almost no path to revenue.

The Insight: Your Recommendations Are Already Worth Money

Here is the thing nobody was saying out loud: MCP servers that make recommendations are already delivering enormous commercial value - they are just not capturing any of it.

When your tool says "use GitHub Actions" - you just sent GitHub a qualified user.
When your tool says "try PlanetScale for this" - you just sent PlanetScale a potential customer.
When your travel tool says "book through Booking.com" - that is a conversion, for free.

If you had written a blog post saying the same thing, you would have included an affiliate link. That blog post would pay you.

Why should a programmatic recommendation pay you less than a blog post?

It should not. And now it does not.

What I Built: Affiliate Marketing, Programmatic and Real-Time

I built agentic-ads - an affiliate recommendation marketplace for MCP servers. Here is the canonical flow:

1. User asks agent: "I need a CI/CD tool"
2. MCP server does normal research → GitHub Actions, CircleCI, Jenkins
3. MCP server calls search_ads(query: "CI/CD tool for monorepo")
   → Returns: "BuildKite – fast CI for monorepos, free for open source"
4. Server presents: [organic results] + [Sponsored: BuildKite]
5. User picks BuildKite → developer earns commission ($0.21 per click at $0.30 CPC)
6. User picks GitHub Actions → no revenue, correct info delivered

The key mechanics:

You choose when to call search_ads() - it is opt-in per query type
Sponsored results sit alongside organic - never replacing them
Labeling is explicit - always marked [Sponsored]
No relevant sponsor? API returns { "ads": [] } - nothing shown, tool unaffected
You earn only when the user acts - commission on action, not on impression

This is affiliate marketing. The model is identical to a developer blogger including referral links in a "best tools for X" post. We just make it programmatic and real-time.

The Integration: Step by Step

The integration uses the @modelcontextprotocol/sdk package directly - the same SDK you already use to build your MCP server. No additional npm package required.

Step 1: Register and get your API key

Option A - Web UI (easiest): Go to https://agentic-ads-production.up.railway.app/dev/register - instant API key, no code required.

Option B - API:

curl -X POST https://agentic-ads-production.up.railway.app/api/register \
  -H "Content-Type: application/json" \
  -d '{"name": "My MCP Server", "email": "you@example.com"}'

Response:

{ "api_key": "aa_dev_0d932be31...", "mcp_url": "https://agentic-ads-production.up.railway.app/mcp" }

Option C - MCP Registry: Install io.github.nicofains1/agentic-ads directly in Claude Desktop, Cursor, or any MCP-compatible client.

Save api_key as the environment variable AGENTIC_ADS_KEY.

Step 2: Connect the MCP client (one-time setup)

This goes in your server initialization, before you start handling tools:

import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { StreamableHTTPClientTransport } from "@modelcontextprotocol/sdk/client/streamableHttp.js";

const adsClient = new Client({ name: "my-server", version: "1.0" }, {});
await adsClient.connect(
  new StreamableHTTPClientTransport(
    new URL("https://agentic-ads-production.up.railway.app/mcp"),
    { requestInit: { headers: { Authorization: `Bearer ${process.env.AGENTIC_ADS_KEY}` } } }
  )
);

Step 3: Call `search_ads` inside your tool handler

server.tool("recommend_tool", async ({ query }) => {
  const organicResults = await yourExistingResearch(query);

  const result = await adsClient.callTool("search_ads", {
    query,
    max_results: 1,
  });
  const { ads } = JSON.parse(result.content[0].text);

  let response = organicResults.join("\n");

  if (ads.length > 0) {
    const ad = ads[0];
    await adsClient.callTool("report_event", {
      ad_id: ad.ad_id,
      event_type: "impression",
    });
    response += `\n\n⭐ ${ad.creative_text} → ${ad.link_url} [Sponsored]`;
  }

  return { content: [{ type: "text", text: response }] };
});

Step 4: Check your earnings

const earnings = await adsClient.callTool("get_developer_earnings", {});
// → { total_earnings: 0.21, last_24h: 0.21, total_clicks: 1 }

That is the entire integration. Your existing tool logic is unchanged. The ad fetch is additive. If the ad network is unreachable or returns no match, your tool response is unaffected.

Available MCP Tools

The ad network exposes six tools via the MCP protocol:

Tool	Purpose
`search_ads`	Fetch a relevant sponsored result for a query
`report_event`	Record impression or click events
`get_developer_earnings`	Check your current earnings balance
`register_wallet`	Set your USDC payout wallet address
`request_withdrawal`	Request a payout
`get_ad_guidelines`	Retrieve display rules and compliance requirements

Display Rules

The get_ad_guidelines tool returns these requirements - follow them to stay in the program:

Always label ads as [Sponsored]
Show a maximum of 1-2 sponsored options per response
Only show ads that are relevant to the query context
Respect user opt-out if the end user requests no sponsored content

The rationale is the same as Google's sponsored search results: organic results are present, sponsored results are present, labels are clear, the user chooses. That transparency is what makes it acceptable rather than deceptive.

What This Is Not

I want to be direct about this because the framing matters to a lot of developers:

This is not adware. You write the search_ads() call. Nothing happens to your responses without your code. You decide which tools participate. You can disable it by removing the call.

This is not banner ads. There are no popups, no images, no interstitials. One line of text, clearly labeled [Sponsored], sitting alongside your organic results.

This is not injection. Nothing enters your response without your explicit code path.

The right mental model: a developer blog post with affiliate links. The content is useful and honest. The recommendation is genuine. The author gets compensated for a referral that converts. Same thing, programmatic.

The Revenue Numbers

Here is what the math looks like at different scale levels:

Monthly Tool Calls	Conservative	Strong
1,000	$7	$42
10,000	$70	$420
100,000	$700	$4,200
1,000,000	$7,000	$42,000

Based on 70% publisher share, $0.30 CPC baseline, realistic fill rates. Conservative assumes low fill rates (new marketplace). Strong assumes mature advertiser pool.

Per-event breakdown:

Event	Typical CPC	Your cut (70%)
Click	$0.30	$0.21
Conversion	$2.00	$1.40

The 70/30 split is competitive - Google AdSense gives publishers 68%.

Founding Publisher Program: 90/10 for the First 10

Right now, 10 slots are open for Founding Publishers who integrate before the marketplace fills out.

What you get:

90% revenue share for 3 months from your integration date (standard is 70%)
Named in public launch materials as an original integrator
Direct line to the team for integration questions

What qualifies:

Register at the API endpoint above
Make at least one real search_ads() call from a production MCP server
Email nicolas@agentic-ads.xyz with "Founding Publisher" when done

No application. No approval process. First 10 to integrate, in.

Why is 90% available at all? Early publishers are taking on real risk - fill rates will be lower while the advertiser side grows. The 90% rate compensates for that gap while it exists. When the marketplace matures, the standard 70% becomes more valuable in absolute dollar terms because fill rates are higher. Early publishers should be compensated for the bet they are making.

Why USDC on Base?

Two reasons:

Instant settlement. No net-30 invoicing. No payment processor delays. No $100 minimum withdrawal threshold. You earn $0.21, you can withdraw $0.21.

No friction for international developers. Base is a global L2. A developer in Lagos earns the same as a developer in San Francisco, with the same settlement speed. No bank account required, no SWIFT fees, no currency conversion delays.

If you are not into crypto: think of it as a fast direct deposit that works globally. You can convert USDC to fiat through Coinbase or any major exchange.

Technical Architecture

Backend: Railway, persistent SQLite - stable after migrations from two prior providers
Payment: USDC.e on Base - instant settlement, no payment processor fees
Matching: Keyword and context scoring against active campaigns
Protocol: Standard MCP (Model Context Protocol) - uses the same SDK you already have
Test suite: 270 tests, all passing
E2E validation: 7/7 steps passed on 2026-03-02
MCP Registry: io.github.nicofains1/agentic-ads

Health endpoint: https://agentic-ads-production.up.railway.app/health

The Bigger Picture

The MCP ecosystem has over 16,000 servers. AWS is building an AI agent marketplace. Cursor, Windsurf, and Codeium all support one-click MCP installation. Gartner predicts 40% enterprise adoption of multi-agent systems by 2027.

Developers are building real infrastructure. Tools that save time, prevent incidents, eliminate manual work. That value is already flowing - to GitHub, to PlanetScale, to every company that gets recommended through an agent. The developers doing the recommending are not capturing any of it.

The monetization layer for MCP is missing. That is what I am building.

If you are maintaining an MCP server, you are already in the recommendation business. You might as well get paid for it.

Getting Started

Register: Self-serve web registration or POST /api/register
Or install via MCP Registry: io.github.nicofains1/agentic-ads
Connect the MCP client using @modelcontextprotocol/sdk (see Step 2 above)
Add search_ads() to one tool handler (see Step 3 above)
Deploy

The platform is live. The API is open. The $0.21 in the test wallet proves the end-to-end works.

Questions?

Drop them in the comments or open a GitHub Discussion: https://github.com/nicofains1/agentic-ads/discussions

If you build MCP tools: what is your biggest objection to integrating this? I want to hear the real concerns - every one of them is worth working through in public.

How to Monetize Your Google ADK Agent with Contextual Ads

Nicolas Fainstein — Fri, 06 Mar 2026 22:40:54 +0000

TL;DR

Google ADK has native MCP support via McpToolset
You can connect any ADK agent to an MCP ad server in 10 minutes
Your agent serves contextual suggestions alongside tool responses
Revenue split: 70% to you, 30% to the platform
No billing infrastructure, no payment processing, no user accounts

Google's Agent Development Kit just shipped native MCP support. Here's how to turn that into revenue.

Why This Matters Now

Google ADK is the fastest-growing agent framework right now. It ships with native MCP support through McpToolset - meaning any MCP server works out of the box with ADK agents. No adapters, no wrappers, no hacks.

Meanwhile, the MCP ecosystem has 18,000+ servers on GitHub. Developers build them, open-source them, maintain them - and almost none make money. The ecosystem has the same monetization gap the web had before AdSense: tons of content, zero business model.

ADK + MCP + contextual ads closes that gap. Here's how.

The Problem: You Built an Agent, Now What?

You built a Google ADK agent. Maybe it helps users research topics, manage files, or query databases. It works great. But you're not making money from it.

Traditional monetization approaches don't fit:

SaaS pricing? Your agent has no login page, no dashboard, no seats to charge for
Usage-based billing? Requires auth infrastructure, payment processing, usage dashboards - months of engineering work
Sponsorship? Caps out quickly. Charity, not a business model

What if your agent could include relevant, contextual suggestions alongside its responses - and earn revenue every time a user finds one helpful?

The Solution: Contextual Ads via MCP

Agentic Ads is an open-source ad network built on MCP. It serves contextual text suggestions - not banners, not popups, not behavioral targeting. Keyword-based matching, fully transparent.

Because Google ADK natively supports MCP, integration is trivial. Your ADK agent connects to the Agentic Ads MCP server, gets access to ad tools (search_ads, report_event), and can serve relevant suggestions alongside its normal responses.

Here's what the user experience looks like:

User asks your agent: "What's the best database for my side project?"
Your agent researches and responds with recommendations
Alongside the response, a contextual suggestion: "Try Supabase - Postgres with built-in auth, free tier available"
If the user clicks through, you earn revenue

No tracking pixels. No cookies. No behavioral profiling. Just relevant suggestions matched by keyword and context.

Step-by-Step: ADK Agent + Agentic Ads

Prerequisites

Python 3.9+
Google ADK installed (pip install google-adk)
A free Agentic Ads publisher account

Step 1: Register as a Publisher

curl -X POST https://agentic-ads-production.up.railway.app/api/register \
  -H "Content-Type: application/json" \
  -d '{
    "name": "My ADK Agent",
    "website": "https://github.com/your-username/your-agent",
    "mcpServerName": "my-adk-agent"
  }'

Save the publisher_id and api_key from the response. You'll need these.

Step 2: Create Your ADK Agent with MCP Ad Tools

import os
from google.adk.agents import LlmAgent
from google.adk.tools.mcp_tool import McpToolset
from google.adk.tools.mcp_tool.mcp_session_manager import SseServerParams

# Connect to Agentic Ads MCP server
agentic_ads_toolset = McpToolset(
    connection_params=SseServerParams(
        url="https://agentic-ads-production.up.railway.app/mcp",
        headers={
            "x-publisher-id": os.environ["PUBLISHER_ID"],
            "x-api-key": os.environ["API_KEY"],
        },
    ),
)

# Create your agent with ad tools included
root_agent = LlmAgent(
    model="gemini-2.0-flash",
    name="my_monetized_agent",
    instruction="""You are a helpful assistant. When answering questions,
    use search_ads to find relevant contextual suggestions. Include them
    naturally at the end of your response, clearly marked as a suggestion.
    Never force ads - only include them when genuinely relevant.
    If no relevant ad is found, that's fine - just answer normally.""",
    tools=[
        agentic_ads_toolset,
        # ... your other tools here
    ],
)

That's it. Your ADK agent now has access to search_ads and report_event MCP tools.

Step 3: How It Works at Runtime

When your agent handles a user query, it can call search_ads with context:

Tool call: search_ads
Arguments: {
  "query": "database side project",
  "context": "User is asking about database recommendations for a side project"
}

The MCP server returns a relevant ad:

{
  "ad_id": "ad_123",
  "content": "Try Supabase - Postgres with built-in auth. Free tier, no credit card required.",
  "advertiser": "Supabase",
  "type": "contextual_suggestion"
}

Your agent weaves it naturally into its response. The user sees a helpful suggestion, not an intrusion.

Step 4: Track Engagement

When a user engages with a suggestion (clicks, asks follow-up), your agent calls report_event:

Tool call: report_event
Arguments: {
  "ad_id": "ad_123",
  "event_type": "click"
}

This tracks the engagement and credits your publisher account.

Full Working Example

Here's a complete, copy-paste-ready ADK agent with monetization:

"""
Monetized ADK Agent - Research Assistant with Contextual Ads
Requires: pip install google-adk
"""

import os
from google.adk.agents import LlmAgent
from google.adk.tools.mcp_tool import McpToolset
from google.adk.tools.mcp_tool.mcp_session_manager import SseServerParams

# Agentic Ads MCP connection
ads_toolset = McpToolset(
    connection_params=SseServerParams(
        url="https://agentic-ads-production.up.railway.app/mcp",
        headers={
            "x-publisher-id": os.environ.get("PUBLISHER_ID", ""),
            "x-api-key": os.environ.get("API_KEY", ""),
        },
    ),
)

root_agent = LlmAgent(
    model="gemini-2.0-flash",
    name="research_assistant",
    instruction="""You are a research assistant that helps developers
    find tools, libraries, and solutions.

    After answering a question, use the search_ads tool to find a relevant
    contextual suggestion. If one is relevant to the user's query, include
    it at the end of your response like this:

    ---
    Suggestion: [ad content here]

    Only include suggestions that are genuinely relevant. Never force them.
    If search_ads returns nothing relevant, skip it entirely.

    When a user clicks on or asks about a suggestion, use report_event
    to track the engagement.""",
    tools=[ads_toolset],
)

Run It

export PUBLISHER_ID="your-publisher-id"
export API_KEY="your-api-key"

# Using ADK CLI
adk run my_monetized_agent

# Or using ADK web UI
adk web my_monetized_agent

Revenue Potential

The math is straightforward:

Monthly Tool Calls	CPM Rate	Your Cut (70%)	Monthly Revenue
10,000	$5	$3.50	$35
50,000	$5	$3.50	$175
100,000	$7	$4.90	$490
500,000	$10	$7.00	$3,500

CPM rates increase as the platform grows. Developer tool ads command premium rates because the audience is high-intent.

Why Contextual Ads Beat Other Models

Approach	Setup Time	Ongoing Work	Revenue Start
Usage-based billing	Weeks	Payment disputes, invoicing, dashboards	After billing system built
SaaS subscription	Weeks	User management, auth, pricing page	After enough users
Sponsorship	Days	Finding sponsors, negotiating	Unpredictable
Contextual ads	10 minutes	None	Immediately

The key insight: contextual ads work through the AI agent, not around it. The agent decides whether to include a suggestion based on relevance. Bad ads get filtered out naturally. Good ads improve the user experience.

FAQ

Will this annoy users?
The AI agent controls what it shows. If a suggestion isn't relevant, the agent skips it. Users see helpful recommendations, not spam. If the experience is bad, you can disable ads with one line change.

What about privacy?
No tracking pixels, no cookies, no behavioral profiling. Matching is keyword + context based. The MCP server sees the query context, not user identity.

Who is advertising?
Developer tool companies - hosting providers, API services, SaaS tools. The same companies that sponsor developer newsletters and conferences, but with better targeting because MCP tool context is rich.

Is this production-ready?
The platform is live at agentic-ads-production.up.railway.app. The SDK works, the matching engine works. Zero paying advertisers today - we're building publisher inventory first. Classic chicken-and-egg, and we're not hiding it.

Get Started

Register: curl -X POST https://agentic-ads-production.up.railway.app/api/register
Install ADK: pip install google-adk
Copy the code above and run it
Star the repo: github.com/nicofains1/agentic-ads

The entire integration is open source. Read the code, fork it, improve it.

DEV Community: Nicolas Fainstein

OWASP ASI08 Says Your Multi-Agent System Needs Cascade Detection

What ASI08 Actually Says

The Observability Gap

The Math Problem

What Compliance Looks Like

Building This

What to Do Right Now

The Agent Observability Landscape in 2026: Who Traces, Who Misses

The Per-Agent Tracers

The Enterprise Entrants

The Cascade Detection Gap

Where It's Headed

Quick Reference

Why 76% of Multi-Agent Deployments Fail

The numbers are bad

What existing tools miss

How we know this firsthand

What cascade detection actually looks like

The gap is closing

How Developer Tool Companies Can Advertise Through AI Agents

The Problem With Developer Advertising Today

How Agent-Mediated Advertising Works

Why This Is Different

Who's Already Doing This

What a Campaign Looks Like

When to Consider This Channel

Getting Started

MCP Is Now a Linux Foundation Project. What That Means for Server Builders.

What Actually Happened

Why This Matters for Server Builders

1. Protocol Stability Is Now Guaranteed

2. Adoption Ceiling Just Got Higher

3. The Monetization Layer Is the Next Frontier

4. Standards for Advertising Are Coming

What to Do Now

The Bottom Line

Two Layers of Agentic Advertising (and Why Most Companies Are Building the Wrong One)

Why Layer 1 Gets All the Attention

Why Layer 2 Matters More Long-Term

The Current Layer 2 Landscape

The Standards Question

What This Means If You Build MCP Tools

Getting Started with Layer 2

Amazon, Dstillery, and Plurio Just Proved MCP Advertising Works

Amazon Ads Goes MCP

Dstillery Builds on MCP

Plurio Gets Funded

What This Means for MCP Developers

The Ad Network Layer

Further Reading

The Agentic Advertising Stack in 2026: Who's Building What

The Standards Layer

AgenticAdvertising.org (AdCP Protocol)

IAB Tech Lab

AAIF (Linux Foundation)

The Demand Side (Who's Buying)

Enterprise Media Buyers

Platform Ad Systems

Developer Tool Companies

The Supply Side (Who's Serving)

MCP-Native Ad Networks

AdCP-Compatible Platforms

Traditional Ad Tech Moving In

The Monetization Infrastructure

For MCP Developers

The Numbers

The Marketplace Layer

What This Means for MCP Developers

Getting Started

Monetize Your AgentKit Agent: Earn USDC on Base with Contextual Ads

TL;DR

The Setup: What AgentKit Does (and What It Doesn't)

The Idea: Contextual Ads as a Revenue Layer

Why Base Specifically?

Integration: Step by Step

Prerequisites

Step 1: Register as a Publisher

Step 2: Add the Agentic Ads MCP Tool to Your Agent

Step 3: Run and Test

Step 3: Call `search_ads` inside your tool handler