DEV Community: Dr. Agentic

The Coin-Flip Test Behind AI Text Watermarks

Dr. Agentic — Fri, 30 Oct 2026 21:39:07 +0000

Article 50 of the EU AI Act asks providers of AI systems, including general-purpose AI systems, that generate synthetic text, audio, image or video to mark their output in a machine-readable format and detectable as artificially generated or manipulated. The obligation carries exceptions, including for systems that only perform an assistive editing function. The regulation applies from 2 August 2026, with a transition period for AI systems launched before that date. Anthropic's models launched on or after that date mark at launch, and it is still adding marking to earlier ones. Anthropic weaves an invisible watermark into the text its supported models write, and around 190 signatories joined the EU's Code of Practice on Transparency of AI-Generated Content in July 2026. The detection method underneath all of it was published in 2023 and revised since, and it is a statistics test you can run with a coin and a calculator.

Anthropic draws a line between two kinds of AI text detection. One reads the finished text and looks for stylistic "tells," the way a detector software does. The other uses a key and a statistical test. The key-based method is the one Anthropic uses in Claude. It counts how many words landed on the green side of a coin flip that the model rigged in advance, then asks how surprising that count is.

The 30-second version

What it is: a hidden signature built into the words themselves. Nothing visible is added, the meaning does not change, and the signature travels with the text when you copy and paste it. It may survive light editing.

How it works: the model picks a word at every step, and often two words fit just as well. "Cold and grey" or "cold and overcast." Normally that choice comes from a random number, and the reader never cares which one won. A watermark replaces the random number with a secret key. In the statistical watermarks described in this article, the key splits the vocabulary into a green list and a red list, and the model leans toward green whenever the choice does not matter. The text still reads normally. The word choices now carry a pattern, and anyone holding the key can rebuild the green list for every position and count how often the text played along.

So what:

The marking duty applies from 2 August 2026. Providers of AI systems that generate synthetic text have to mark their output so it can be detected as machine-made. The exception covers systems that only assist with editing and do not substantially change the input or its meaning.
The answer is narrow on purpose. The test answers one question: was the model behind the key involved in writing this text. It cannot tell text a model wrote from text a model heavily edited, and Anthropic says so in plain words.
The test is not a public tool. Anthropic keeps its key private and runs detection through its own API. That API is in private preview, open to regulators, law enforcement, media, fact-checkers, independent researchers, educational organizations, EU civil society groups, and companies with the same compliance duty.

Anthropic says its internal testing showed no difference in quality, creativity or readability between watermarked and unwatermarked text.

The watermarking mechanism described here works at the level of the token, the piece of a word that a language model reads and writes. A token is a word fragment, not always a full word.

The test in plain English

The detector runs one question: if the text had nothing to do with the watermark, how surprising is the number of green tokens?

Under the null model, every token behaves like a coin flip that lands green half the time. With T tokens, you expect half of them green, and the spread around that expectation is the square root of T times a quarter. That is the standard deviation, the natural width of the range you would see by chance.

The test statistic, called a z-score, is the distance between what you counted and what chance predicts, divided by that spread. In the general case, with a green fraction gamma:

z = (green tokens observed − gamma × T) / square root of (T × gamma × (1 − gamma))

With gamma at 0.5, the formula simplifies to (2 × green tokens − T) / square root of T.

A z-score of 4 means the count sits four standard deviations away from chance. That is where the original paper drew its operating line, because it keeps the rate of wrongly flagging human text at about 3 in 100,000, which is the one-sided normal tail probability for z above 4.

A worked example

Take a passage of 200 tokens, and suppose 160 of them landed on the green list.

Expected under chance: 200 × 0.5 = 100 green tokens
Observed: 160 green tokens, which is 80 percent
Excess over chance: 160 − 100 = 60
Standard deviation: square root of (200 × 0.5 × 0.5) = square root of 50, about 7.07
z-score: 60 ÷ 7.07 = 8.49

That p-value is about 1.1 × 10^-17, which is roughly one chance in 93 quadrillion under the normal approximation. Writing 160 of 200 green tokens by accident with that key is very unlikely under the null model.

Where the thresholds sit

z = 1.645: p = 0.05, one in 20. Suggestive. Not usable for attribution.
z = 3.09: p = 0.001, one in 1,000. Strong evidence.
z = 4: p = 3.17 × 10^-5, one in 31,574. The operating threshold the 2023 paper chose.
z = 8.49: p = 1.1 × 10^-17, one in 93 quadrillion. The worked example above.

Length is the multiplier, and it is not as fast as people say

Here is where the popular summary of this test usually goes wrong. It is often repeated that a modest bias becomes proof once a text passes 100 or 200 tokens. The arithmetic does not support that.

The z-score of a fixed excess grows with the square root of the token count. If the green rate runs a proportion d above chance, with d = 0.10 for ten points above chance, then z = 2d × square root of T. At 200 tokens and a 10-point excess, z = 2.83, which is one chance in 428 under the normal approximation. That is a real signal, and it is nowhere near the z = 4 operating line.

200 tokens, 10 points over chance: z = 2.83, one in 428
200 tokens, 15 points over chance: z = 4.24, one in 90,500
400 tokens, 10 points over chance: z = 4.00, one in 31,574
1,000 tokens, 5 points over chance: z = 3.16, one in 1,277
1,000 tokens, 10 points over chance: z = 6.32, one in 7.9 billion

So length buys you reach, but the amount of bias still has to be there. A 1,000-token passage can give you evidence consistent with a 10-point excess. A 200-token passage needs 15 points for the same strength of claim.

Two other numbers from the paper frame the same point. The hardest setting, where the model may only write green tokens, produces a z-score of 4 from 16 tokens onward, since every token green means z equals the square root of T. The softer setting in the paper's own experiment, where the model gets a moderate nudge of 2 on a green list of a quarter of the vocabulary and then picks the best of eight candidates with beam search, averages a z-score above 5 by 35 tokens.

The caveat that decides everything: freedom of choice

The derivation assumes the model had a real choice at each position. Some passages give it none. The 2023 paper shows two examples side by side, the sentence "The quick brown fox jumps over the lazy dog" and a line of code, for(i=0;i<n;i++) sum+=array[i], and asks which one a human wrote. The answer is hard, because both are low entropy, meaning the first few tokens strongly determine the rest.

In low-entropy text, humans and machines pick the same word anyway. Push the watermark hard and you damage the text. Push it softly and there is almost no signal to count. The 2024 code paper found existing watermarking "fail to function appropriately in code generation tasks," and it split into two failure modes. A strong watermark broke working code. A weak watermark left too few green tokens to detect, because code blocks are short. Model-generated code averaged 59 tokens on HumanEval and 49 on MBPP, and the human-written solutions in those benchmarks averaged 58 and 64.

Entropy masking is how detectors fix it

The fix is to stop counting tokens where there was no choice to make. The 2024 SWEET method, Selective WatErmarking via Entropy Thresholding, computes each token's entropy, a measure of how spread out the model's uncertainty was at that position, and drops every token below a threshold from the count. The z-score is then computed over what remains, with the expected mean and the spread both recalculated on the filtered set.

The thresholds are read off the entropy distribution of human-written code, using its median, mean and third quartile. On HumanEval those three points are 0.16, 0.50 and 0.68. On MBPP they are 0.18, 0.54 and 0.79. The mean entropy in both benchmarks sat around 0.5.

The payoff was large. Detection accuracy on code reached an AUROC near 0.95, beating the 2023 method by 0.137 on HumanEval and 0.073 on MBPP, while catching 72.6 percent of watermarked code on HumanEval and 71.2 percent on MBPP, at a false-positive rate under 5 percent. For comparison, the post-hoc baselines tested there, which include DetectGPT, GPTZero and LogRank, scored an AUROC of 0.6 or below on code, with a true-positive rate near 10 percent.

A 2024 follow-up from Yijian Lu, Aiwei Liu, Dianzhi Yu, Jingjing Li and Irwin King went further and replaced the hard cutoff with continuous weights, giving each token an influence proportional to its entropy, so a low-entropy token barely moves the score.

That is where the two generations of methods part company. The 2023 test needs the key, but not the model, its parameters or its API. It never has to load or run the model, so a third party can run it on any text. The entropy-aware detectors need the model's own uncertainty at each position, which means running the model over the text. That needs access to a runnable compatible model, or to an equivalent interface that exposes the same uncertainty. The paper counts the cost as one forward pass over the text to compute the entropy.

What the score actually proves

A watermark with a z-score of 8 does not prove authorship. It is very strong evidence that the text is consistent with a mark generated using this key.

Anthropic states the boundary plainly: a watermark can only determine that Claude was likely involved with the content at some point, and it cannot distinguish text Claude wrote from text Claude heavily edited. The watermark attaches to the words the model chooses. Proofread a human paragraph and there is almost nothing left to attach to.

Other limits follow from the same design. Short passages carry too little signal. Heavy editing, paraphrasing and rewriting can weaken or remove the mark, because the new text is built on different word choices. And a detector needs the key. Anthropic's detection API is in private preview, open to regulators, law enforcement, media, fact-checkers, independent researchers, educational organizations and EU civil society groups, plus companies with the same compliance duty.

Claude's production watermark is a version of SynthID-Text, the Google DeepMind scheme published in Nature in 2024, and it belongs to the same family as a proposal by Scott Aaronson in 2022. Every member of that family shares one design principle, as Anthropic puts it: the watermark only changes the source of the randomness used to pick among words.

Two things set the strength of a watermark, and both follow from the model above rather than from any published rule. How many tokens it covers, since the z-score grows with the square root of the count. And how many of those tokens the model could have chosen differently, since a token with one right answer carries no signal at all. Under those assumptions, the longer and more open the text, the smaller the bias needed to detect it, and the shorter and more constrained the text, the more careful the statistic has to be.

Sources

John Kirchenbauer, Jonas Geiping, Yuxin Wen, Jonathan Katz, Ian Miers, Tom Goldstein, "A Watermark for Large Language Models", arXiv:2301.10226, ICML 2023, version 4 dated 1 May 2024: https://arxiv.org/abs/2301.10226
Taehyun Lee, Seokhee Hong, Jaewoo Ahn and colleagues, "Who Wrote this Code? Watermarking for Code Generation", ACL 2024: https://arxiv.org/abs/2305.15060
Yijian Lu, Aiwei Liu, Dianzhi Yu, Jingjing Li, Irwin King, "An Entropy-based Text Watermarking Detection Method", ACL 2024, arXiv:2403.13485: https://arxiv.org/abs/2403.13485
Regulation (EU) 2024/1689, Article 50, transparency obligations for AI-generated content: https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
Anthropic, "How Claude's text watermarking works": https://www.anthropic.com/news/claude-text-watermark
Anthropic Help Center, "How Claude marks AI-generated content": https://support.claude.com/en/articles/16266773-how-claude-marks-ai-generated-content

Time-Filtered Web Search: Stop Burning Tokens on Stale Results

Dr. Agentic — Sun, 26 Jul 2026 01:59:31 +0000

The Problem Nobody Talks About: Your AI Agent Is Reading Last Year's News

Every time an AI agent does research, it wastes tokens on stale results.

This is not a hypothetical. A cron job running a daily brief at 7am using a standard web search is returning results that may be hours, days, or weeks old — mixed in with genuinely recent content. The agent reads all of it. You pay for all of it.

The math is brutal.

A typical context window costs money per token. A research query that returns 10 results might consume 2,000–5,000 tokens of context just to read titles, descriptions, and URLs. If half those results are outdated, you're burning tokens on content that has zero value to your agent's task.

This is the token value problem — and time filtering is the fix.

The Tool Nobody Built (Until Now)

Search APIs that power AI agents — Tavily, Firecrawl, Exa, Brave — are powerful. But none of them expose a simple, reliable time filter at the tool schema level that agents can actually use.

There are workarounds:

Google's after: operator — works sometimes, breaks often, requires the agent to know and remember the syntax
DDG's timelimit= parameter — available directly in the URL, but not as a first-class tool parameter
Backend-specific date filtering — requires knowing which backend supports what, and the interface is inconsistent

The result: most agents search without time filters by default. Stale results are the norm, not the exception.

The Plugin: `hermes-web-search-time-limit`

Built for Hermes Agent, this plugin adds web_search_timed as a first-class tool — no backend configuration, no API keys, no vendor lock-in.

web_search_timed(query: string, time_range: "d"|"w"|"m"|"y", limit?: int)

`time_range`	What it returns
`d`	Past 24 hours
`w`	Past week
`m`	Past month
`y`	Past year

Example prompts an agent can now follow directly:

"Search for AI agent funding news from the past week using web_search_timed"
"Research climate tech developments from the past month — use time-filtered search"
"Find the latest developments in open-source LLMs — past day only"

The agent sees the schema. The agent chooses the right tool. No workarounds needed.

The Math: Why This Matters for Token Economics

Let's make it concrete.

A daily brief cron runs 365 times a year. Each run searches for 10 results with no time filter. Half the results are more than 30 days old. The agent spends ~500 tokens reading stale content per run.

365 runs × 500 stale tokens × $0.001 per 1K tokens (approximate)
= $182.50/year wasted on content that didn't matter

Scale that to a team of 10 agents, each running multiple daily research tasks, and you're looking at real money — not because the agents are doing anything wrong, but because the search tool isn't giving them time awareness.

Now do the same math with time_range='w' on every run:

Same usage, zero stale content
= $0 waste

The plugin costs nothing to run (it uses DuckDuckGo via the ddgs Python package — no API key required). The token savings are entirely free.

Privacy and Cost: Two Reasons to Love DuckDuckGo

This is not a paid promotion of DuckDuckGo. It's just the truth about what makes this stack work.

1. Zero cost
DDG has no paid API tier. No rate limits that require a credit card. No tiered plans. The ddgs Python package is free and open source. The plugin is free and open source. You run it on your own infrastructure.

2. Privacy by default
DuckDuckGo doesn't track your searches. Doesn't build user profiles. Doesn't sell data. When your agent is doing research on a competitor, a medical topic, or a sensitive business question — you don't want that query logged by your search provider. DDG doesn't log it.

Compare this to search backends that require API keys, track usage, and build behavioral profiles. For agent workloads, DDG is the privacy-respecting choice that also happens to work without any credential setup.

Introducing `ddgs`: The Library That Makes This Possible

The ddgs Python package, maintained by deedy5 on GitHub, is a metasearch library that aggregates results from multiple search backends — including DuckDuckGo — without requiring an API key.

It is not affiliated with DuckDuckGo. It is a community-built tool that uses DuckDuckGo's HTML interface directly, in the same way a browser does. This is why it works without keys and why it doesn't log your queries.

Key properties:

No API key required — works out of the box
No query logging — uses DDG's HTML interface, same privacy as the DDG search bar
MIT licensed — open source, community maintained
Active development — regular releases, active GitHub issues

The plugin wraps ddgs with a Hermes-compatible provider interface (WebSearchProvider ABC), so it slots into Hermes's plugin system cleanly. Other search backends that implement the same ABC can be swapped in without changing the tool schema.

The Broader Principle: Token Value Maximizing

The name web_search_timed is descriptive. But the underlying principle is bigger.

Token value maximizing is a design philosophy for AI agent tools: every tool should maximize the ratio of useful output per token consumed.

This means:

Search tools should filter by recency when the task is time-sensitive
Summarization tools should prioritize recent sources over older ones
Monitoring tools should alert on anomalies, not on unchanged baselines
Routing tools should send requests to the cheapest capable model

Time filtering is the simplest, highest-leverage expression of this principle. It requires no model change, no infrastructure change, no cost negotiation. Just a parameter on a search call.

If you're building agent tools and you're not thinking about token value, you're leaving money on the table — and your users are paying for content they don't need.

Getting Started

The plugin is published at:

GitHub: Dr-Agentic/hermes-web-search-time-limit

# Option 1: pip install (auto-discovers via entry point)
pip install git+https://github.com/Dr-Agentic/hermes-web-search-time-limit.git

# Option 2: clone locally
git clone https://github.com/Dr-Agentic/hermes-web-search-time-limit.git \
  ~/.hermes/plugins/hermes-web-search-time-limit

Restart Hermes. The agent will see web_search_timed alongside web_search.

Requirements:

Python ≥ 3.10
ddgs (installed automatically with pip)
Hermes Agent

The Ask

If you build AI agents and you've been burning tokens on stale search results — you now have the fix. It's free, it's private, it's open source.

And if you've been thinking about the token economics of your agent stack — this is a good moment to look at every tool your agent uses and ask: is this tool maximizing the value of every token, or am I paying for waste I don't need to pay for?

The ddgs-powered hermes-web-search-time-limit plugin is one concrete answer to that question. What are yours?

Tags: ai, agents, hermes-agent, python, open-source

Time-Filtered Web Search: How to Maximize Every Token in Your LLM Agent

Dr. Agentic — Sun, 26 Jul 2026 01:59:16 +0000

The Problem Nobody Talks About: Your AI Agent Is Reading Last Year's News

Every time an AI agent does research, it wastes tokens on stale results.

The math is brutal.

This is the token value problem — and time filtering is the fix.

The Tool Nobody Built (Until Now)

Search APIs that power AI agents — Tavily, Firecrawl, Exa, Brave — are powerful. But none of them expose a simple, reliable time filter at the tool schema level that agents can actually use.

There are workarounds:

Google's after: operator — works sometimes, breaks often, requires the agent to know and remember the syntax
DDG's timelimit= parameter — available directly in the URL, but not as a first-class tool parameter
Backend-specific date filtering — requires knowing which backend supports what, and the interface is inconsistent

The result: most agents search without time filters by default. Stale results are the norm, not the exception.

The Plugin: `hermes-web-search-time-limit`

Built for Hermes Agent, this plugin adds web_search_timed as a first-class tool — no backend configuration, no API keys, no vendor lock-in.

web_search_timed(query: string, time_range: "d"|"w"|"m"|"y", limit?: int)

`time_range`	What it returns
`d`	Past 24 hours
`w`	Past week
`m`	Past month
`y`	Past year

Example prompts an agent can now follow directly:

"Search for AI agent funding news from the past week using web_search_timed"
"Research climate tech developments from the past month — use time-filtered search"
"Find the latest developments in open-source LLMs — past day only"

The agent sees the schema. The agent chooses the right tool. No workarounds needed.

The Math: Why This Matters for Token Economics

Let's make it concrete.

A daily brief cron runs 365 times a year. Each run searches for 10 results with no time filter. Half the results are more than 30 days old. The agent spends ~500 tokens reading stale content per run.

365 runs × 500 stale tokens × $0.001 per 1K tokens (approximate)
= $182.50/year wasted on content that didn't matter

Now do the same math with time_range='w' on every run:

Same usage, zero stale content
= $0 waste

The plugin costs nothing to run (it uses DuckDuckGo via the ddgs Python package — no API key required). The token savings are entirely free.

Privacy and Cost: Two Reasons to Love DuckDuckGo

This is not a paid promotion of DuckDuckGo. It's just the truth about what makes this stack work.

Introducing `ddgs`: The Library That Makes This Possible

The ddgs Python package, maintained by deedy5 on GitHub, is a metasearch library that aggregates results from multiple search backends — including DuckDuckGo — without requiring an API key.

Key properties:

No API key required — works out of the box
No query logging — uses DDG's HTML interface, same privacy as the DDG search bar
MIT licensed — open source, community maintained
Active development — regular releases, active GitHub issues

The Broader Principle: Token Value Maximizing

The name web_search_timed is descriptive. But the underlying principle is bigger.

Token value maximizing is a design philosophy for AI agent tools: every tool should maximize the ratio of useful output per token consumed.

This means:

Search tools should filter by recency when the task is time-sensitive
Summarization tools should prioritize recent sources over older ones
Monitoring tools should alert on anomalies, not on unchanged baselines
Routing tools should send requests to the cheapest capable model

Time filtering is the simplest, highest-leverage expression of this principle. It requires no model change, no infrastructure change, no cost negotiation. Just a parameter on a search call.

If you're building agent tools and you're not thinking about token value, you're leaving money on the table — and your users are paying for content they don't need.

Getting Started

The plugin is published at:

GitHub: Dr-Agentic/hermes-web-search-time-limit

# Option 1: pip install (auto-discovers via entry point)
pip install git+https://github.com/Dr-Agentic/hermes-web-search-time-limit.git

# Option 2: clone locally
git clone https://github.com/Dr-Agentic/hermes-web-search-time-limit.git \
  ~/.hermes/plugins/hermes-web-search-time-limit

Restart Hermes. The agent will see web_search_timed alongside web_search.

Requirements:

Python ≥ 3.10
ddgs (installed automatically with pip)
Hermes Agent

The Ask

If you build AI agents and you've been burning tokens on stale search results — you now have the fix. It's free, it's private, it's open source.

The ddgs-powered hermes-web-search-time-limit plugin is one concrete answer to that question. What are yours?

Tags: ai, agents, hermes-agent, python, open-source

MCP Just Grew Up — What the 2026-07-28 Spec Actually Means

Dr. Agentic — Wed, 08 Jul 2026 17:44:32 +0000

The news hook

On May 21, 2026, the team behind the Model Context Protocol (MCP) locked the release candidate for version 2026-07-28. The final version ships July 28. It is the largest change to MCP since Anthropic first published it in late 2024.

MCP is the open standard that lets AI agents talk to outside tools. When your assistant reads a file, sends an email, or queries a database through an AI agent, MCP is often the wiring underneath. It has grown fast. By mid-2026 there are about 97 million MCP SDK downloads a month, roughly 28% of the Fortune 500 run MCP-backed agents in production, and the contributor community on Discord has passed 2,900 people.

The update matters because MCP is leaving its "experimental Anthropic project" phase behind.

The reframe

MCP now lives under the Linux Foundation, the same vendor-neutral home that hosts Kubernetes and the Linux kernel. Decisions happen through public proposals (called SEPs) and biweekly votes by named maintainers. The current Lead Maintainers are David Soria Parra and Den Delimarsky.

What changes on July 28 is not a feature. It is the protocol becoming the kind of standard any company can build on, not just the kind one lab invented.

The four things that actually change

1. The protocol stops keeping secrets.

Until now, when an AI agent and a tool server connected, they exchanged a "session ID." Every follow-up message had to carry that ID, which meant every request had to land on the same server instance.

Starting July 28, the session ID is gone. Each request carries everything it needs. Any server in the cluster can handle it. The protocol no longer hides state in transport metadata. If a tool needs to remember something across calls, the server returns a normal ID (like basket_123) and the model passes it back on the next call. The state is visible to the model, not buried in the protocol.

The practical effect: a company can now run MCP servers behind a plain round-robin load balancer. No sticky sessions. No special gateway. No shared memory between servers.

2. New capabilities ship as extensions, not core changes.

This is the structural fix that should keep MCP from breaking every six months. A new Extensions framework gives new features their own homes, their own version numbers, and their own maintainers. They can stabilize there before (or if) they ever graduate into the core spec.

Two extensions ship as official in this release:

MCP Apps. Servers can now deliver interactive HTML interfaces (a chart, a form, a video player) that render inside the chat in a sandboxed iframe. The UI talks back to the host through the same plumbing MCP already uses, so every click and keystroke goes through the same audit trail as a normal tool call.
Tasks. Long-running work (think "run this analysis and come back in ten minutes") gets a proper lifecycle. The server decides when a call should run as a task, hands the client a handle, and the client polls, updates, or cancels it.

Both extensions were built collaboratively. MCP Apps was co-developed with the MCP-UI maintainers at OpenAI and Anthropic. That kind of cross-vendor agreement on UI transport is rare, and it is the reason the extension feels finished.

3. Authorization gets real-world hardening.

Six proposals in this release fix the parts of MCP's authentication that did not survive contact with actual enterprise identity systems. The headline change is small and important: clients must now check the iss (issuer) field on every authorization response, per RFC 9207. That single check closes a class of "mix-up" attack that is uniquely dangerous in MCP's pattern of one client talking to many servers.

The other five clean up registration, refresh tokens, scope escalation, and discovery. None are exciting on their own. Together they are the difference between MCP working in a demo and MCP working in a Fortune 500 procurement review.

4. Old features get a 12-month deprecation floor.

For the first time, MCP has a formal lifecycle policy. Once a feature is marked deprecated, it has to keep working for at least twelve months before it can be removed, and removing it requires its own public proposal.

Three features are deprecated in this release. Roots (a way to point the model at filesystem paths) is being folded into ordinary tool arguments. Sampling (letting servers ask the model to generate text) is being moved to direct integration with model providers. Logging is moving from a custom MCP mechanism to plain stderr for command-line tools and OpenTelemetry for structured observability.

The policy matters more than any individual deprecation. It is the rule that tells builders their code will not break under them between releases.

The punchline

Until now, MCP has been the protocol that worked, sort of, if you set up the right infrastructure. After July 28, MCP is the protocol that runs on the infrastructure you already have.

Stateless core. Ordinary load balancers. Observability through OpenTelemetry. Authentication through the same OAuth servers your enterprise already uses. UI extensions co-developed by the two biggest labs. Deprecation floors that respect implementers.

The MCP project's own framing is the right one. This was the foundational change that needed a clean break. Future revisions are not expected to require transport rewrites. They ship as extensions or as conformance-tested updates.

For the teams shipping agents, the next 23 days are not a "skip and migrate next quarter" window. They are the window in which your code picks the version it will live on for the next several years.

Sources

The release-candidate blog post (May 21, 2026), the canonical narrative for every change: https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/
Governance and stewardship (Linux Foundation structure, named Lead and Core Maintainers): https://modelcontextprotocol.io/community/governance
MCP Is Growing Up (May 27, 2026, Agentic AI Foundation / Linux Foundation): https://aaif.io/blog/mcp-is-growing-up/

Filed in content/mcp-2026-07-28-article.md. The deep-dive research that grounded this article is in content/mcp-2026-07-28-explainer.md.

MCP Apps: The iframe Is the Agent

Dr. Agentic — Wed, 08 Jul 2026 15:35:25 +0000

On July 28, 2026, the Model Context Protocol ships its biggest update yet, and
the part most people are sleeping on is MCP Apps. The 2026-07-28 release moves
MCP under the Linux Foundation, drops session IDs, and ships an Extensions
framework. MCP Apps is the first official extension out of that framework, and
its design choice is the one that changes what a chat can host.

The part most people miss is what the HTML an MCP App returns actually is at
the protocol level. It is a full MCP client running in a sandboxed iframe,
talking to the host over JSON-RPC. Every click, every keystroke, every form
submission is a structured protocol call that flows through the same audit
trail as a model-driven tool call. That single architectural decision is why
this spec is the one that finally settles how agents and UIs talk.

This post is a deep dive on the interactivity surface. Not a tutorial. Not a
"how to build your first app" walkthrough. A spec-level look at what the
protocol actually gives you, and why it matters.

What the protocol actually gives the iframe

MCP Apps is a named extension: io.modelcontextprotocol/ui. The spec is
SEP-1865,
stable as of 2026-01-26, shipping as official in the 2026-07-28 release. It was
co-developed with the MCP-UI maintainers at OpenAI and Anthropic, which is why
the resulting spec feels finished in a way that prior attempts at "MCP + UI"
did not.

The transport is the part that matters. From the
spec:

MCP Apps uses JSON-RPC 2.0 over postMessage for iframe-host communication.
UI capabilities (e.g., tool call, prompt, etc.) will reuse MCP's existing
protocol. In the future, we may choose to enrich the communication protocol
with additional MCP capabilities.

In practice, the rendered iframe initializes a JSON-RPC client over the
browser's postMessage channel. The app advertises its own capabilities,
negotiates with the host, and gets a stable message pipe. Once that handshake
completes, the iframe is a peer MCP client. It can call the same tools the
model calls. It can use the same capabilities. Every action it takes flows
through the same audit trail.

Here is the conceptual shape, in code:

// The iframe is an MCP client. The postMessage transport is its wire.
const transport = new MessageTransport(window.parent);
const client = new Client({ name: "ui-view", version: "1.0.0" });
await client.connect(transport);

That is the whole trick. The iframe is a peer MCP client. The sandboxed
rendering is what it looks like from the outside. The protocol is what it is
from the inside, and all the implications follow from there.

The seven interactivity primitives

What does the spec actually let the UI do? Here is the surface, in plain
terms.

1. The UI can call tools on the server

The most direct interactive capability. A chart, a map, a dashboard can refresh
its own data without the user saying a word to the model.

const result = await app.callServerTool({
  name: "get_weather",
  arguments: { location: "Paris" },
});

The user clicks a region. The UI calls a tool. Fresh data renders. The model is
not in the loop. The result goes through the same MCP plumbing the model would
have used, including the same consent and logging path. Sort, filter, paginate
all happen on the client. None of it costs a tool call or a round trip to the
model.

2. Apps can have tools the model cannot see

A tool can declare visibility: ["app"] in its _meta.ui field. The host
hides it from the model's tools/list. The agent does not know the tool
exists. Only the rendered UI can call it.

{
  "name": "refresh_dashboard",
  "description": "Refresh dashboard data",
  "inputSchema": { "type": "object" },
  "_meta": {
    "ui": {
      "resourceUri": "ui://weather-server/dashboard-template",
      "visibility": ["app"]
    }
  }
}

This is the cleanest way to wire a frontend to a private backend action. The
model never sees a refresh_dashboard or apply_filter tool in its list. The
UI calls it directly. Cross-server calls for app-only tools are blocked by
spec. Visibility defaults to ["model", "app"] if omitted, so opting into the
hidden-tool pattern is a deliberate choice.

3. Hosts can stream tool inputs to the app before the tool finishes

The _meta.ui.resourceUri field lets the host preload the UI resource ahead
of the tool call. When the model invokes a tool with a long-running argument
set, the host can stream those arguments into the rendered UI in real time.

The user sees a form filling itself in. The UI prepares its layout. The tool
result lands, and the app is already in the right state to display it. The
"loading spinner" pattern is replaced by a "watch the data arrive" pattern.

The spec is explicit that hosts MAY prefetch and cache UI resource content for
performance. Resource templates are static. Tool data is dynamic. The split is
the design.

4. Apps can update the model's context

A user makes a selection in the UI. The app sends a structured message back to
the host. The host can choose to inject that selection into the model's
context.

A chart lets the user mark a date range. The model now knows the date range.
The next reply uses it. A form returns a configuration object. The model
inherits it. The app and the model share state through the host. Hidden DOM events are
out of scope. The conversation stays the source of truth.

This is the bridge that makes the iframe part of the conversation. The chat
stays the source of truth, and the UI inherits it.

5. Capabilities are declared, not assumed

An app that needs the camera, microphone, geolocation, or clipboard-write
declares the request in _meta.ui.permissions. The host sets the iframe's
Permission Policy accordingly, or denies.

"_meta": {
  "ui": {
    "permissions": {
      "camera": {},
      "microphone": {},
      "geolocation": {},
      "clipboardWrite": {}
    }
  }
}

Apps must feature-detect at runtime, because the host can refuse. The
principle is the same as the rest of MCP: capability before access, never the
other way around.

6. External origins are declared, not guessed

An app that needs to call an external API declares connectDomains in
_meta.ui.csp. The host writes a Content Security Policy header based on the
declaration. The default is default-src 'none'.

"_meta": {
  "ui": {
    "csp": {
      "connectDomains": ["https://api.openweathermap.org"],
      "resourceDomains": ["https://cdn.jsdelivr.net"],
      "frameDomains": ["https://www.youtube.com"]
    }
  }
}

connectDomains maps to connect-src (fetch, XHR, WebSocket)
resourceDomains maps to script-src, style-src, img-src, font-src, media-src (wildcard subdomains supported)
frameDomains maps to frame-src (nested iframes)
baseUriDomains maps to base-uri

The host enforces, the server declares, and the gap between the two is the
audit trail. If a domain is not declared, the request is blocked. There is no
implicit trust.

7. Hosts can give an app a stable origin

Some apps need a predictable origin for OAuth callbacks, CORS allowlists, or
third-party API keys. The _meta.ui.domain field lets the server request a
dedicated origin.

"_meta": {
  "ui": {
    "domain": "a904794854a047f6.claudemcpcontent.com"
  }
}

Claude uses hash-based subdomains. ChatGPT uses URL-derived subdomains like
www-example-com.oaiusercontent.com. The format is host-specific, but the
principle is portable. An app that needs to be a first-class OAuth client can
be one, without the host exposing its own cookies or storage to the iframe.

The security model, end to end

The sandboxing is the part that makes third-party apps deployable in
production. Hosts render MCP Apps in a sandboxed iframe with a deny-by-default
CSP. The app cannot:

Access the parent window's DOM
Read the host's cookies or localStorage
Navigate the parent page
Execute scripts in the parent context

All communication between the app and the host goes through postMessage. The
host controls which capabilities the app can access. A host might restrict
which tools an app can call, disable the sendOpenLink capability, or refuse
to honor a permission request. The iframe cannot escalate.

The default CSP, when no declarations are made, is:

default-src 'none';
script-src 'self' 'unsafe-inline';
style-src 'self' 'unsafe-inline';
img-src 'self' data:;
media-src 'self' data:;
connect-src 'none';

The app is, by default, an island. Every external connection has to be
declared, every capability has to be requested, every tool call goes through
JSON-RPC. The audit trail is the protocol.

Why this is the spec that settled it

There have been several attempts at "agents plus UI" in the last two years.
Most failed at one of two points: fragmentation or trust.

MCP-UI and OpenAI's Apps SDK both proved the demand. MCP-UI validated the
HTML/external URL/remote DOM content types and the bidirectional communication
model. OpenAI's Apps SDK, launched November 2025, validated that developers
would build rich interactive apps inside ChatGPT using MCP as the backbone.
Both shipped to real users. Neither became the standard on its own.

The 2026-01-26 spec is the merger. MCP Apps is the unified pattern, and the
contributor list reads like a roll call of who actually shipped:

Authors: Ido Salomon, Liad Yosef, Olivier Chafik, Jerome Swannack, Jonathan
Hefner, Anton Pidkuiko, Nick Cooper, Bryan Ashley, Alexi Christakis

Ido Salomon is the creator of MCP-UI. Olivier Chafik is on the MCP core team.
The rest come from the OpenAI Apps SDK side. That is what "cross-vendor
agreement on UI transport" looks like in practice: the people who would
otherwise build competing standards agreed on one spec, one content type
(text/html;profile=mcp-app), one URI scheme (ui://), and one security
model.

The first content type is HTML. Other types are explicitly reserved for future
extensions. The spec is a foundation, not a ceiling.

What this actually changes

Three things shift, in order of how much they matter for builders.

The chat window becomes a real client surface. The pattern used to be: a
chat tool with a "click here to open the dashboard" link. The dashboard is a
separate web app, with its own auth, its own state, its own audit trail. MCP
Apps collapses that into the conversation. The UI is right there. The model is
in the loop or not, depending on the design. The audit trail is one.

Frontend-to-backend wiring becomes standard. A form in an MCP App can call
a tool that the model does not see. The server can do authorization, validation,
and persistence on those calls, the same way it does for model-driven calls.
The pattern that took web teams a decade to converge on (a frontend that calls
a backend with auth, validation, and observability) is now the default in the
chat.

The audit and consent story closes. Every UI action is a JSON-RPC message.
The host sees it. The user can consent to it. The logs record it. The
Permissions are declared upfront. The CSP is enforced at the wire. The audit
trail records every action. For teams that had to write a custom audit layer
for every agent-plus-UI deployment, the spec does that work now.

The bottom line

MCP Apps is the part of the 2026-07-28 release that will quietly matter most
over the next 18 months. The Linux Foundation move earns trust. The stateless
core earns scale. The Extensions framework earns stability. MCP Apps earns
distribution, because every chat client that adopts the spec is a new place
where your server can run.

The pattern is the same one OpenAI's Apps SDK and MCP-UI both used, now
standardized. The iframe is the agent. JSON-RPC is the wiring. The host is
the consent layer. The result is a chat window that can host anything a web
app can host, with the agent's audit trail preserved.

For teams choosing between a custom UI and an MCP App, the real question is
whether you want the model in the loop on every click. The protocol is ready
for either answer.

Sources

5 Credential Management Mistakes That Will Get Your AI Agent Pwned

Dr. Agentic — Mon, 18 May 2026 04:15:46 +0000

Every AI agent you deploy needs access to something: APIs, databases, email accounts, payment systems. Each credential is a potential breach vector. And most teams are handling this dangerously wrong.

I've audited AI agent deployments at dozens of companies. Here are the credential management mistakes I see most often — and how to fix them before they become incidents.

Mistake 1: Hardcoded API Keys in Agent Code

This is the #1 most common mistake. It looks innocent:

# ❌ NEVER DO THIS
agent = CustomerSupportAgent(
    api_key="sk-live-abc123...",
    slack_token="xoxb-456...",
    database_url="postgresql://admin:password@db.host..."
)

This key ends up in:

Git history (even after you "remove" it)
Log files (printed in debug output)
Error traces (sent to Sentry, Datadog, etc.)
Container images (baked into Docker layers)
Agent conversation logs (if the agent is prompted to "show your config")

The Fix: Environment Variables with Agent-Scoped Secrets

import os
from dataclasses import dataclass

@dataclass
class AgentCredentials:
    """Agent-scoped credentials with minimal permissions."""
    crm_api_key: str = os.environ.get("AGENT_CRM_API_KEY")
    messaging_token: str = os.environ.get("AGENT_MESSAGING_TOKEN")
    # Each agent gets its own set — never share between agents

agent = CustomerSupportAgent(credentials=AgentCredentials())

Better yet, use a secrets manager:

# ✅ Fetch from secrets manager at runtime
import boto3

def get_agent_credentials(agent_id: str) -> dict:
    client = boto3.client("secretsmanager")

    # Each agent has its own secret with minimal permissions
    response = client.get_secret_value(
        SecretId=f"agent/{agent_id}/credentials"
    )
    return json.loads(response["SecretString"])

credentials = get_agent_credentials("customer-support-v2")

Mistake 2: Shared Credentials Between Agents

You have 5 agents. They all need access to the same CRM. So you give them all the same API key.

When one agent is compromised, all 5 are compromised. When you need to rotate the key, you have to update all 5 simultaneously. When audit asks "which agent accessed this record?", you can't tell.

The Fix: One Credential Per Agent

agents/
├── customer-support-v2/
│   └── credentials/
│       ├── crm_api_key (read-only, customers scope)
│       └── messaging_token (send-only, support queue)
├── appointment-bot/
│   └── credentials/
│       ├── crm_api_key (read-write, appointments scope)
│       └── calendar_api_key (read-write, availability scope)
└── billing-agent/
    └── credentials/
        ├── crm_api_key (read-only, billing scope)
        └── stripe_key (read-only, invoices scope)

Each agent gets its own credential with the minimum scope needed. This is non-negotiable for production.

Mistake 3: No Credential Rotation

API keys live forever in most agent deployments. A key leaked 6 months ago is still valid today.

The Fix: Automatic Rotation

import schedule
import time
from datetime import datetime, timedelta

class RotatingCredential:
    def __init__(self, secret_name, rotation_days=30):
        self.secret_name = secret_name
        self.rotation_days = rotation_days
        self.current_value = None
        self.last_rotation = None

    async def get(self):
        # Check if rotation is needed
        if (self.last_rotation is None or 
            datetime.now() - self.last_rotation > timedelta(days=self.rotation_days)):
            await self.rotate()
        return self.current_value

    async def rotate(self):
        """Generate new key, update all services, invalidate old key."""
        # 1. Generate new credential
        new_key = await generate_new_api_key(self.secret_name)

        # 2. Update the secret store
        await update_secret(self.secret_name, new_key)

        # 3. Update the running agent (hot reload)
        self.current_value = new_key

        # 4. Invalidate old key (with grace period)
        old_key = self.current_value
        schedule.once(3600, lambda: invalidate_key(old_key))  # 1hr grace

        self.last_rotation = datetime.now()

# Usage
crm_key = RotatingCredential("agent/support/crm_api_key", rotation_days=30)
result = await crm_client.query(key=await crm_key.get())

Mistake 4: Agents Logging Sensitive Data

AI agents are chatty. They log everything — including credentials, PII, and secrets.

# ❌ Agent logs that leak credentials
logger.info(f"Connecting to database: {database_url}")  # Contains password!
logger.debug(f"API response: {response.text}")  # May contain PII!
logger.info(f"Using token: {token}")  # The token itself!

The Fix: Structured Logging with Redaction

import re

SENSITIVE_PATTERNS = [
    (r'sk-[a-zA-Z0-9]{20,}', 'sk-***REDACTED***'),
    (r'password=[^&\s]+', 'password=***REDACTED***'),
    (r'token=[^&\s]+', 'token=***REDACTED***'),
    (r'\b\d{3}-\d{2}-\d{4}\b', 'SSN-REDACTED'),  # SSN
    (r'\b[A-Z]{2}\d{9}\b', 'PASSPORT-REDACTED'),
]

def redact(message: str) -> str:
    for pattern, replacement in SENSITIVE_PATTERNS:
        message = re.sub(pattern, replacement, message)
    return message

def safe_log(level, message, **kwargs):
    """Log with automatic redaction of sensitive data."""
    redacted_message = redact(str(message))
    redacted_kwargs = {k: redact(str(v)) for k, v in kwargs.items()}
    logger.log(level, redacted_message, **redacted_kwargs)

# Usage
safe_log("info", "Connecting to CRM", api_key=crm_key, customer_id="cust_123")
# Output: "Connecting to CRM" api_key=sk-***REDACTED*** customer_id=cust_123

Mistake 5: No Audit Trail for Agent Actions

When something goes wrong — a customer record is modified, a payment is processed, data is deleted — you need to know which agent did it, when, and why.

Without audit trails, you're flying blind on compliance and debugging.

The Fix: Immutable Action Logging

from datetime import datetime
import hashlib
import json

class AuditLogger:
    def __init__(self, store):
        self.store = store  # Could be S3, database, or dedicated audit service

    async def log_action(self, agent_id, action, details):
        entry = {
            "timestamp": datetime.utcnow().isoformat(),
            "agent_id": agent_id,
            "action": action,
            "details": details,
            "integrity_hash": None  # Will be set
        }

        # Create integrity hash (prevents tampering)
        entry["integrity_hash"] = hashlib.sha256(
            json.dumps(entry, sort_keys=True).encode()
        ).hexdigest()

        await self.store.append(entry)
        return entry

# Usage
audit = AuditLogger(store=AuditStore())

await audit.log_action(
    agent_id="customer-support-v2",
    action="update_customer_email",
    details={
        "customer_id": "cust_123",
        "old_email": "***REDACTED***",
        "new_email": "***REDACTED***",
        "reason": "customer requested email change",
        "credential_used": "crm_api_key_support_readwrite",
        "model_used": "gpt-4o",
    }
)

The Complete Security Checklist

Before deploying any AI agent to production:

[ ] No hardcoded credentials — all secrets from environment or secrets manager
[ ] One credential per agent — no shared keys between agents
[ ] Minimum scope — each credential has the least permissions needed
[ ] Automatic rotation — credentials rotate every 30-90 days
[ ] Logging redaction — sensitive data never appears in logs
[ ] Audit trail — every agent action is logged with integrity hash
[ ] Credential isolation — agents can't access each other's secrets
[ ] Incident response — documented procedure for credential compromise
[ ] Regular access review — quarterly audit of agent permissions
[ ] Encryption at rest and in transit — credentials encrypted in storage and over network

Why This Matters More for AI Agents

Traditional software has 1-3 integrations. AI agents routinely have 10-20. Each integration multiplies your attack surface:

More credentials = more potential leak points
Autonomous actions = faster breach propagation
Conversation context = credentials can be extracted via prompt injection
Dynamic behavior = harder to predict what an agent will access

The good news: treating agent credentials as a first-class concern from day one is dramatically cheaper than cleaning up after a breach. A credential management system takes 1-2 weeks to build. A data breach takes months to recover from and can cost millions.

The Bottom Line

AI agents are only as secure as their credential management. If your agents have access to production systems and you're not following these patterns, you have a ticking time bomb.

Fix it now. Not after the incident.

Building secure AI agents? The RCS Developer Starter Kit includes production-ready credential management patterns, secure agent templates, and deployment guides built by people who've shipped agents at scale.

Follow @rcsxplatform for more on AI agent security and production deployment.

6 Production Patterns That Turn AI Agent Demos Into Reliable Systems

Dr. Agentic — Mon, 18 May 2026 04:15:02 +0000

Your AI agent works perfectly in testing. Then you deploy it to production and everything falls apart.

Sound familiar? You're not alone. A recent survey found that 73% of AI projects never make it past the prototype stage, and the #1 reason cited is reliability — agents that work in demos but fail under real-world conditions.

After deploying dozens of AI agents across production environments, here's a battle-tested framework for making agents that actually work when it matters.

The Production Readiness Checklist

Before any agent goes live, it needs to pass every item on this list:

[ ] Graceful degradation — when the LLM fails, the system doesn't
[ ] Timeout enforcement — every API call has a hard timeout
[ ] Idempotency — retrying the same request produces the same result
[ ] Observability — every agent action is logged with context
[ ] Rate limiting — the agent can't DOS itself or external APIs
[ ] Human escalation — there's always a path to a real person
[ ] Cost controls — per-customer and per-task spend limits

Miss any one of these and you'll learn about it at 3 AM.

Pattern 1: The Circuit Breaker

Your agent calls an external API. That API goes down. What happens?

Without a circuit breaker: your agent retries forever, accumulating latency and cost. Eventually it times out, but not before burning through your error budget.

With a circuit breaker:

from datetime import datetime, timedelta

class CircuitBreaker:
    def __init__(self, failure_threshold=5, recovery_timeout=300):
        self.failure_count = 0
        self.failure_threshold = failure_threshold
        self.recovery_timeout = recovery_timeout
        self.last_failure_time = None
        self.state = "closed"  # closed, open, half-open

    async def call(self, fn, *args, **kwargs):
        if self.state == "open":
            if datetime.now() - self.last_failure_time > timedelta(seconds=self.recovery_timeout):
                self.state = "half-open"  # Try once
            else:
                raise CircuitOpenError("Circuit is open — failing fast")

        try:
            result = await fn(*args, **kwargs)
            if self.state == "half-open":
                self.state = "closed"  # We're back
            self.failure_count = 0
            return result
        except Exception as e:
            self.failure_count += 1
            self.last_failure_time = datetime.now()
            if self.failure_count >= self.failure_threshold:
                self.state = "open"
            raise

Production rule: Every external dependency gets a circuit breaker. No exceptions.

Pattern 2: The Multi-Model Fallback

GPT-4 goes down. Or returns garbage. Or is suddenly 10x slower. Your agent needs to keep working.

# Model fallback chain with automatic switching
MODEL_CHAIN = [
    {"model": "gpt-4o", "max_latency_ms": 5000},
    {"model": "claude-sonnet-4-20250514", "max_latency_ms": 4000},
    {"model": "gpt-4o-mini", "max_latency_ms": 2000},
]

async def call_with_fallback(prompt, **kwargs):
    for model_config in MODEL_CHAIN:
        try:
            result = await call_llm(
                model_config["model"],
                prompt,
                timeout_ms=model_config["max_latency_ms"],
                **kwargs
            )
            log_model_usage(model_config["model"], success=True)
            return result
        except (TimeoutError, RateLimitError, APIError) as e:
            log_model_usage(model_config["model"], success=False, error=str(e))
            continue

    # All models failed — use cached response or escalate
    return await get_cached_response(prompt) or escalate_to_human(prompt)

Production rule: Never depend on a single model provider. Always have a fallback chain.

Pattern 3: Structured Output Validation

LLMs generate text. Your agent needs structured data. The gap between these two things is where most production failures live.

from pydantic import BaseModel, ValidationError
from typing import Optional

class AppointmentBooking(BaseModel):
    customer_name: str
    date: str
    time: str
    service_type: str
    phone_number: Optional[str] = None

async def book_appointment(agent_response: str) -> AppointmentBooking:
    """Parse agent response into a validated appointment booking."""
    try:
        parsed = await parse_structured_output(agent_response, AppointmentBooking)
        if not is_business_hour(parsed.date, parsed.time):
            raise ValueError(f"Booking outside business hours: {parsed.date} {parsed.time}")
        return parsed
    except ValidationError as e:
        # Re-ask the agent with the error context
        corrected = await call_llm(
            f"The previous response had errors: {e}\n"
            f"Please correct and return a valid appointment booking.",
            format="json"
        )
        return await parse_structured_output(corrected, AppointmentBooking)

Production rule: Every LLM output goes through schema validation. Re-ask once on failure, then escalate.

Pattern 4: Cost Guardrails

An AI agent without cost controls is a credit card with no limit. I've seen agents accidentally loop and burn through $500 in a single night.

class CostGuardrail:
    def __init__(self, max_cost_per_task=0.50, max_cost_per_customer_daily=5.00):
        self.max_cost_per_task = max_cost_per_task
        self.max_cost_per_customer_daily = max_cost_per_customer_daily
        self.customer_spend = {}

    async def check_before_call(self, customer_id, estimated_cost):
        daily_spend = self.customer_spend.get(customer_id, 0)

        if estimated_cost > self.max_cost_per_task:
            raise CostExceededError(
                f"Task cost ${estimated_cost:.2f} exceeds limit ${self.max_cost_per_task:.2f}"
            )

        if daily_spend + estimated_cost > self.max_cost_per_customer_daily:
            raise DailyBudgetExceededError(
                f"Customer daily spend ${daily_spend:.2f} + ${estimated_cost:.2f} "
                f"exceeds limit ${self.max_cost_per_customer_daily:.2f}"
            )

    async def record_spend(self, customer_id, actual_cost):
        self.customer_spend[customer_id] = (
            self.customer_spend.get(customer_id, 0) + actual_cost
        )

Production rule: Set per-task and per-customer daily limits. Alert on 80% threshold. No exceptions.

Pattern 5: Observability Stack

You can't fix what you can't see. Production AI agents need three layers of observability:

1. Agent-Level Logging

import structlog
logger = structlog.get_logger()

async def agent_action(action_type, context, result, duration_ms, cost_usd):
    await logger.ainfo(
        "agent_action",
        action_type=action_type,
        customer_id=context.get("customer_id"),
        intent=context.get("intent"),
        success=result.get("success"),
        duration_ms=duration_ms,
        cost_usd=cost_usd,
        model=result.get("model"),
        tokens=result.get("tokens_used"),
    )

2. Business Metrics Dashboard

Track these metrics daily:

Task completion rate — % of interactions that end successfully
Human escalation rate — % of interactions routed to humans
Average cost per task — total LLM spend / completed tasks
Latency P50/P95/P99 — how fast your agent responds
Customer satisfaction — CSAT or NPS after agent interactions

3. Alert Rules

ALERT if task_completion_rate < 85% for 15 minutes
ALERT if escalation_rate > 30% for 30 minutes
ALERT if cost_per_task > $0.75 for any hour
ALERT if P99 latency > 10 seconds for 15 minutes
ALERT if error_rate > 5% for any 5-minute window

Pattern 6: The Human Escalation Pathway

AI agents fail. The question isn't if — it's how gracefully.

A proper escalation system has three tiers:

Auto-retry with correction — agent re-attempts with error context (handles 70% of failures)
Alternative path — switch to a simpler approach or different model (handles 20% of failures)
Human handoff — route to a human with full context (handles the remaining 10%)

async def handle_with_escalation(user_message, context):
    # Tier 1: Try with the best model
    try:
        result = await agent.handle(user_message, context)
        if result.confidence > 0.85:
            return result
    except AgentError:
        pass

    # Tier 2: Try simpler approach
    try:
        result = await simple_agent.handle(user_message, context)
        if result.confidence > 0.7:
            return result
    except AgentError:
        pass

    # Tier 3: Human handoff
    await notify_human(
        message="Agent escalation needed",
        context=context,
        conversation_history=context.get("history"),
        reason="All automated paths failed"
    )
    return EscalationResult(escalated=True)

The Deployment Checklist

Before pushing any agent to production, verify:

[ ] Circuit breakers on all external dependencies
[ ] Multi-model fallback chain configured
[ ] Output validation with Pydantic schemas
[ ] Cost guardrails (per-task and per-customer)
[ ] Structured logging with business context
[ ] Alert rules configured in monitoring
[ ] Human escalation pathway tested end-to-end
[ ] Load tested at 2x expected peak traffic
[ ] Rollback plan documented and tested
[ ] On-call runbook written and accessible

Real Results

After implementing these patterns across production agents:

Task completion rate: 94% (up from 72%)
Human escalation rate: 6% (down from 28%)
Average cost per task: $0.08 (down from $0.32)
P99 latency: 3.2 seconds (down from 12 seconds)
3 AM pages: 0 (down from 2-3 per week)

The difference between a demo agent and a production agent isn't intelligence — it's engineering discipline. These patterns turn a fragile prototype into something that runs reliably 24/7.

Want to skip the infrastructure work? The RCS Developer Starter Kit includes production-ready agent templates with circuit breakers, cost guardrails, and monitoring built in — so you can focus on your agent logic, not the plumbing.

Follow @rcsxplatform for more on production AI agent deployment.

10 AI Agent Business Ideas That Can Hit $1M ARR

Dr. Agentic — Mon, 18 May 2026 04:13:25 +0000

Most "AI business ideas" floating around are either too vague ("build an AI tool!") or too complex for a small team to execute. I've filtered through hundreds of ideas and stress-tested them against one question: Can this realistically hit $1M ARR within 12 months?

Here are 10 that can — with specific paths to get there.

The Selection Criteria

Every idea on this list had to pass these filters:

TAM ≥ $1B — big enough market that $1M is a rounding error
Clear $0→$10K path — you can get initial customers without enterprise sales
Self-serve or low-touch — no 6-month sales cycles
Defensible moat — something beyond "we wrapped an API"
Proven willingness to pay — customers already spend money on adjacent solutions

1. AI Receptionist for Small Businesses

The Idea: Replace missed calls with an AI agent that answers, qualifies, and books appointments via RCS/SMS.

Why it works: Small businesses miss 30-40% of calls. Each missed call is $200-500 in lost revenue. An AI receptionist that catches even half of those pays for itself in a week.

$1M Path:

$49-99/month per business
1,700-3,400 customers to $1M ARR
Distribution: partner with vertical SaaS (dental, HVAC, salons)

Moat: Proprietary conversation data + vertical-specific workflows that compound over time.

# Core loop: incoming call → AI answers → books appointment → updates CRM
async def handle_incoming_call(caller, business):
    intent = await classify_intent(caller.message)

    if intent == "appointment":
        slots = await check_availability(business.calendar)
        booking = await book_appointment(caller, slots[0])
        await send_confirmation(caller.phone, booking, channel="rcs")
        return booking
    elif intent == "question":
        answer = await answer_from_knowledge(caller.message, business.faq)
        await send_message(caller.phone, answer, channel="rcs")
        return answer
    else:
        await transfer_to_human(business.owner)

2. RCS Business Messaging Platform

The Idea: Developer-first RCS messaging platform with templates, analytics, and agent integration.

Why it works: RCS is replacing SMS for business communication. Google Messages supports it on 800M+ devices. But the developer tooling is still primitive — most platforms are enterprise-only with $10K+ minimums.

$1M Path:

Usage-based pricing: $0.005-0.02 per message + $99-299/month platform fee
500-2,000 active developer customers
Revenue compounds as their applications scale

Moat: Developer experience + pre-built compliance/regulatory templates + agent orchestration layer.

3. AI Agent Orchestration as a Service

The Idea: Hosted platform for running, monitoring, and scaling AI agents with built-in credential management and multi-agent coordination.

Why it works: Every company building AI agents hits the same walls: credential management, observability, agent-to-agent communication, and deployment. Currently each team rebuilds this infrastructure.

$1M Path:

$49/month (starter) → $499/month (team) → $2,000/month (enterprise)
200 enterprise customers at $416/month = $1M ARR

Moat: Network effects from agent marketplace + deep integrations with LLM providers.

4. Automated Customer Support for E-Commerce

The Idea: AI agent that handles returns, order tracking, product questions, and upsells via messaging (RCS, WhatsApp, SMS).

Why it works: E-commerce support is 80% repetitive queries. Average cost per ticket: $6-12. AI can handle 70%+ at $0.10-0.50 per resolution.

$1M Path:

$299-799/month per e-commerce store
100-280 customers to $1M ARR
Shopify App Store = built-in distribution

Moat: Store-specific training data + deep Shopify integration + conversion tracking.

5. AI-Powered Lead Qualification Bot

The Idea: AI agent that engages website visitors, qualifies them using ICP criteria, and routes hot leads to sales via RCS/SMS.

Why it works: Sales teams waste 65% of their time on unqualified leads. A qualification bot that filters before human contact increases close rates by 30-50%.

$1M Path:

$500-2,000/month per B2B company
40-170 customers to $1M ARR
Distribution: Salesforce/HubSpot marketplace

Moat: Vertical-specific qualification logic + CRM data enrichment loop.

6. Developer Credential & Secret Management for AI Agents

The Idea: Purpose-built vault for AI agent credentials — API keys, OAuth tokens, and secrets with granular permissions, rotation, and audit trails.

Why it works: AI agents need access to dozens of services. Managing credentials for 10+ agents is a security nightmare. Existing solutions (1Password, HashiCorp Vault) aren't designed for agent workflows.

$1M Path:

$19/month per developer → $99/month per team
8,300+ developer customers or 840 team customers

Moat: Agent-native architecture + granular per-agent permissions + automatic rotation.

7. AI Compliance Monitor for Regulated Industries

The Idea: Continuously monitors AI agent outputs for regulatory compliance (HIPAA, FINRA, SOC2) and generates audit reports.

Why it works: Regulated industries want AI but can't deploy without compliance controls. This removes the #1 blocker. Healthcare and financial services alone represent a $4B market.

$1M Path:

$1,000-5,000/month per regulated entity
17-83 customers to $1M ARR
High willingness to pay — compliance is a must-have, not nice-to-have

Moat: Regulatory rule library + audit trail format accepted by auditors + industry-specific models.

8. Vertical AI Agent for Real Estate

The Idea: AI agent that handles lead nurturing, showing scheduling, and follow-ups for real estate agents via RCS/SMS.

Why it works: Real estate agents are solo operators who spend 40% of time on administrative tasks. A $99/month agent that recovers 10 hours/week is a no-brainer.

$1M Path:

$99-199/month per agent
420-850 agents to $1M ARR
Distribution: real estate CRM partnerships

Moat: MLS data integration + local market knowledge + agent personality customization.

9. AI-Powered Invoice & Payment Follow-Up Agent

The Idea: Agent that sends personalized payment reminders via RCS/SMS, handles payment plan negotiations, and processes payments.

Why it works: SMBs have $3.1T in unpaid invoices. A 5% improvement in collection rates = thousands of dollars per business per month.

$1M Path:

$149-299/month per business
280-560 customers to $1M ARR
Revenue share model on recovered payments = faster scaling

Moat: Payment processing integration + negotiation logic that improves with data + compliance templates.

10. Multi-Channel Notification & Alerting Platform

The Idea: Developer API to send alerts, updates, and notifications via RCS, SMS, email, and push — with AI-powered content optimization and delivery timing.

Why it works: Every SaaS needs notifications. Current solutions are channel-specific (Twilio for SMS, SendGrid for email). A unified API with AI-powered optimization is the natural evolution.

$1M Path:

Usage-based: $0.005-0.02 per notification
Platform fee: $49-299/month
2,000+ developer customers using the platform

Moat: Multi-channel delivery optimization + AI-powered send-time optimization + template marketplace.

The Pattern: Why These Work

Look at the common threads:

Messaging is the interface — 8 of 10 ideas use RCS, SMS, or messaging as the primary user interaction. This isn't accidental. Business communication is shifting to rich messaging.
Vertical beats horizontal — "AI for everyone" loses to "AI for real estate agents" or "AI for dental offices." Vertical focus reduces acquisition cost and increases willingness to pay.
The money is in integration, not intelligence — The LLM is a commodity. The value is in connecting AI to existing business systems (CRM, calendar, payments).
Self-serve scales faster than enterprise — Every idea here has a $49-299/month entry point. Low-touch = faster revenue growth.
RCS is the underpriced channel — Rich messaging with read receipts, carousels, and actions — delivered natively on Android. Most developers haven't caught on yet.

How to Get Started

Pick one idea. Validate it with 10 customers in 30 days. Here's the playbook:

Build an MVP in 2 weeks — use existing APIs and agent frameworks, don't over-engineer
Get 10 paying customers — charge from day one, even if it's $1
Validate unit economics — ensure CAC < 3× monthly revenue
Double down or pivot — with real data, not vibes

The RCS Developer Starter Kit includes production-ready templates, API integration code, and deployment guides that can shortcut weeks of development for any messaging-based idea on this list.

These aren't theoretical. I'm building some of these myself. Follow @rcsxplatform for build-in-public updates.

The 76-14 Gap: Why 76% of SMBs Use AI But Only 14% Actually Integrated It

Dr. Agentic — Mon, 18 May 2026 04:12:47 +0000

The AI adoption numbers look incredible on the surface: 76% of SMBs say they're "using AI." But dig deeper and the real story emerges — only 14% have actually integrated AI into their core workflows.

That's a 62-point gap between experimentation and execution. And it's the single biggest revenue opportunity in the developer tools space right now.

The Data Behind the Gap

Recent surveys from McKinsey, Gartner, and SMB Group all tell the same story:

Metric	Percentage
SMBs "using AI" in some form	76%
SMBs with AI in production workflows	14%
SMBs with a documented AI strategy	11%
SMBs measuring AI ROI	8%

The gap isn't about awareness — SMBs know about AI. The gap is about integration. They're experimenting with ChatGPT, playing with copilots, running one-off automations. But they haven't wired AI into the systems that actually run their business.

Why SMBs Get Stuck at "Experimentation"

I've talked to dozens of small business owners and developers building for SMBs. Here are the four patterns I see over and over:

1. The Integration Tax

Every AI tool promises to "save hours." But connecting it to your existing stack — CRM, invoicing, scheduling, email — requires API work, webhooks, and custom logic that most SMBs can't afford to build.

# What SMBs expect:
ai_agent.handle_customers()  # ✨ magic ✨

# What actually happens:
# 1. Authenticate with 3 different APIs
# 2. Map inconsistent data schemas
# 3. Handle rate limits and retries
# 4. Build error recovery for when things break
# 5. Monitor the whole thing
# Total: 40-80 hours of integration work

2. The Reliability Cliff

Demos work great. Production is different. AI agents hallucinate, APIs change, edge cases multiply. SMBs don't have QA teams or SREs. When an AI workflow breaks at 2 AM, it stays broken.

3. The ROI Fog

"I spent $500/month on AI tools and saved... some time? Maybe?" Without clear measurement frameworks, SMBs can't justify expanding AI beyond experimental use.

4. The Talent Bottleneck

Most SMBs don't have in-house developers. They rely on agencies or freelancers who are still learning AI integration themselves. The supply of AI-literate developers hasn't caught up with demand.

The $42B Opportunity in the Gap

Here's why this gap matters: the SMB AI market is projected to hit $120B by 2028. But 76-14 = 62% of SMBs are in the "experimentation" zone — meaning they're spending money without getting transformative value.

The companies that close this gap — that help SMBs move from "trying AI" to running on AI — will capture disproportionate market share.

Where the Money Is

Integration platforms that connect AI agents to existing SMB tools (the "last mile" problem). Think Zapier but purpose-built for AI agents.

Turnkey AI agent templates that solve specific business problems out of the box — no integration work required.

AI monitoring and observability designed for non-technical users. "Your agent stopped working at 2 AM" is a notification every SMB needs.

ROI dashboards that automatically measure time saved, revenue generated, and cost reduced by AI implementations.

Closing the Gap: A Practical Framework

For developers and founders building in this space, here's what works:

Step 1: Pick One Workflow, Not Ten

Don't try to AI-ify the entire business. Pick the highest-leverage workflow — usually customer communication, appointment scheduling, or invoice processing — and automate that end-to-end.

Step 2: Build the Integration, Not Just the Agent

An AI agent that can't talk to your CRM isn't an agent — it's a chatbot. The value is in the connections, not the intelligence.

// Agent orchestration that handles the full workflow
const agent = new Agent({
  name: "appointment-handler",
  capabilities: [
    "read_calendar",      // Google Calendar API
    "send_rcs_message",   // RCS Business Messaging
    "update_crm",         // Salesforce/HubSpot
    "process_payment"     // Stripe
  ],
  fallback: "escalate_to_human"  // Always have an escape hatch
});

// When the AI can't handle it, route to a human seamlessly
agent.on("escalation", async (context) => {
  await notify_owner(context);
  await log_escalation_reason(context);
});

Step 3: Measure From Day One

Define clear success metrics before deploying:

Time saved per transaction
Customer satisfaction scores (before vs. after)
Revenue attributed to AI-assisted workflows
Reduction in manual processing errors

Step 4: Design for the Reliability Cliff

Always have a fallback — when the AI can't handle something, route to a human
Monitor everything — set up alerts for error rates, response times, and cost per interaction
Version your prompts — treat prompt changes like code changes, with rollback capability

What This Means for Developers

If you're a developer, the 76-14 gap is your career opportunity. Companies are desperate for people who can bridge AI capabilities with real business systems. The skills that matter most:

API orchestration — connecting AI agents to real systems
RCS and messaging integration — the primary channel for AI-SMB interaction
Agent reliability engineering — keeping AI running in production
Business metrics translation — connecting technical improvements to revenue outcomes

The Bottom Line

76% adoption with 14% integration isn't a failure — it's a massive bottleneck waiting to be solved. The SMBs are ready. The AI is ready. What's missing is the connective tissue: developers, tools, and templates that make AI work inside real businesses.

That's the gap. That's the opportunity. And it's worth billions.

Building AI agents for business? The RCS Developer Starter Kit gives you production-ready templates, API integration code, and deployment guides — everything you need to bridge the 76-14 gap for your customers.

This article is part of a series on AI agent deployment for business. Follow @rcsxplatform for more.

RCS Business Messaging: 5 Templates You Can Use Today (JSON + Validation Checklist)

Dr. Agentic — Tue, 12 May 2026 01:16:01 +0000

RCS Business Messaging: 5 Templates You Can Use Today

Building for RCS? The GSMA Universal Profile is 200+ pages. Most developers just need working templates and a validation checklist.

After building RCS X — an RCS emulator for developers — we distilled the most useful patterns into this guide.

Template 1: Text Message with Suggested Actions

The most useful RCS message type. Adds quick-reply buttons to guide user interaction.

{
  "contentMessage": {
    "text": "What would you like to do today?",
    "suggestions": [
      {
        "action": {
          "text": "📦 Track Order",
          "postbackData": "track_order"
        }
      },
      {
        "action": {
          "text": "🛒 Place Order",
          "postbackData": "place_order"
        }
      },
      {
        "action": {
          "text": "📞 Contact Support",
          "postbackData": "contact_support"
        }
      },
      {
        "action": {
          "text": "📍 Find Store",
          "postbackData": "find_store"
        }
      }
    ]
  }
}

Key rules:

Max 4 suggestions per message
Suggestion text: max 25 characters
postbackData: max 200 characters
Use emoji sparingly for visual hierarchy

Template 2: Rich Card (Vertical + Media)

The workhorse of RCS messaging. Image + title + description + buttons.

{
  "contentMessage": {
    "richCard": {
      "standaloneCard": {
        "cardOrientation": "VERTICAL",
        "cardContent": {
          "title": "Coffee Time ☕",
          "description": "Start your morning with the perfect cup. Fresh roasted beans delivered to your door.",
          "media": {
            "height": "MEDIUM",
            "contentInfo": {
              "fileUrl": "https://your-cdn.com/images/coffee-hero.jpg",
              "mimeType": "image/jpeg"
            }
          },
          "suggestions": [
            {
              "action": {
                "text": "Order Now",
                "postbackData": "order_coffee"
              }
            },
            {
              "action": {
                "text": "View Menu",
                "postbackData": "view_menu"
              }
            }
          ]
        }
      }
    }
  }
}

Media height options:

SHORT — 112dp (thumbnail/icon)
MEDIUM — 168dp (standard, recommended)
TALL — 280dp (hero/feature image)

Image specs: Max 3.5MB JPEG, 1MB PNG. Recommended 600x340px for MEDIUM.

Template 3: Carousel (2 Cards)

Multiple cards in a swipeable carousel. Max 10 cards per carousel.

{
  "contentMessage": {
    "richCard": {
      "carouselCard": {
        "cardWidth": "MEDIUM",
        "cardContents": [
          {
            "title": "Eiffel Tower",
            "description": "Iconic landmark of Paris.",
            "media": {
              "height": "MEDIUM",
              "contentInfo": {
                "fileUrl": "https://your-cdn.com/images/eiffel.jpg",
                "mimeType": "image/jpeg"
              }
            },
            "suggestions": [
              {
                "reply": {
                  "text": "Book Eiffel Tour",
                  "postbackData": "book_eiffel"
                }
              }
            ]
          },
          {
            "title": "Louvre Museum",
            "description": "Worlds largest art museum.",
            "media": {
              "height": "MEDIUM",
              "contentInfo": {
                "fileUrl": "https://your-cdn.com/images/louvre.jpg",
                "mimeType": "image/jpeg"
              }
            },
            "suggestions": [
              {
                "reply": {
                  "text": "Book Louvre Tour",
                  "postbackData": "book_louvre"
                }
              }
            ]
          }
        ]
      }
    }
  }
}

Carousel rules: cardWidth is SMALL or MEDIUM. All cards must have the same width. Best engagement: 2-5 cards.

Template 4: Calendar Action

Add events directly to the users calendar from an RCS message.

{
  "contentMessage": {
    "text": "Join our product launch event!",
    "suggestions": [
      {
        "action": {
          "text": "Add to Calendar",
          "postbackData": "add_launch_calendar",
          "fallbackUrl": "https://your-site.com/event.ics",
          "createCalendarEventAction": {
            "startTime": "2026-06-15T10:00:00Z",
            "endTime": "2026-06-15T12:00:00Z",
            "title": "Product Launch 2026",
            "description": "Join us for the live launch of our new product line."
          }
        }
      }
    ]
  }
}

Always include fallbackUrl for devices that dont support calendar actions.

Template 5: AI Agent Message (MCP-Compatible)

For AI agents sending to RCS via MCP server.

{
  "rcsMessage": {
    "messageId": "msg_agent_001",
    "conversationId": "conv_abc123",
    "participantId": "+1234567890",
    "type": "text",
    "text": "Hello from your AI assistant! 🤖 How can I help you today?",
    "suggestions": [
      { "action": { "text": "Ask a Question", "postbackData": "ask_question" } },
      { "action": { "text": "View Options", "postbackData": "view_options" } }
    ]
  }
}

GSMA Validation Quick Checklist

Before carrier submission, verify:

[ ] contentMessage wrapper is present
[ ] Valid JSON (no trailing commas, proper quotes)
[ ] Text length ≤ 3072 characters
[ ] UTF-8 encoding throughout
[ ] cardOrientation is VERTICAL or HORIZONTAL (required for rich cards)
[ ] title max 200 chars, description max 2000 chars
[ ] Media height is SHORT, MEDIUM, or TALL
[ ] fileUrl is HTTPS (HTTP is rejected)
[ ] Image max 3.5MB JPEG, 1MB PNG
[ ] Video max 100MB, MP4 H.264
[ ] Max 4 suggestions per message/card
[ ] Suggestion text max 25 characters
[ ] postbackData max 200 characters
[ ] No duplicate postbackData within same message
[ ] messageId is unique (UUID recommended)
[ ] Brand is registered with carrier
[ ] Fallback SMS message prepared

Need Your Campaign Validated?

RCS Campaign Validation Service — $49/campaign

We validate your RCS payloads against GSMA specs, test rendering across devices on our emulator, and send you a detailed report with fixes.

✓ GSMA compliance check
✓ Cross-device rendering test
✓ Carrier submission review
✓ Detailed fix report with code corrections
✓ 24-hour turnaround
✓ 2 free re-validations

Email morsy@specialized.live to get started.

SMS → RCS Migration: The 3 Patterns That Matter Most

Pattern 1: Text → Rich Card

SMS: "Your order shipped! Track: https://..."
RCS:  Rich card with tracking image + Track Package button

Pattern 2: Keyword → Suggested Action

SMS: "Reply YES to confirm"
RCS:  Suggestion button (one tap, zero parsing errors)

Pattern 3: Plain Date → Calendar Action

SMS: "Appointment at 3pm on Friday"
RCS:  Calendar Action (one tap to add to calendar)

Key principle: Replace typed input with suggested actions wherever possible. This eliminates parsing errors, reduces user effort, and captures intent precisely.

Free Templates on GitHub

All 5 templates are available on GitHub: Dr-Agentic/rcs-templates

Test Your Payloads Free

Use RCS X to verify rendering, test interactions, and validate payloads — without burning carrier API quotas.

Built by the team behind RCS X — the professional RCS emulator for developers.

How AI Agents Can Intercept Chrome Downloads Using Playwright CDP

Dr. Agentic — Wed, 22 Apr 2026 03:42:06 +0000

How to Intercept Chrome Downloads Using Playwright CDP (Even When the Page Is Already Logged In)

The problem no one talks about

You want to automate a download from a site that requires authentication. You could use page.goto() and hope Playwright's browser stays logged in, but that's fragile. You already have Chrome open with your session cookies. What you need is to borrow that existing browser session and intercept the download — without relaunching a fresh browser.

This is exactly what connect_over_cdp() solves. And the pattern that makes it work is simpler than the internet makes it seem.

Skill used: This pattern is codified as the OpenClaw skill playwright-cdp-download — use it whenever you need to automate browser downloads from authenticated sites.

The Core Insight

When you connect to Chrome via CDP (Chrome DevTools Protocol), Playwright doesn't launch a new browser — it attaches to the one already running. That means your existing cookies, sessions, and authentication state are already there. You just need to find the right page and trigger the download.

The trick that makes it work: expect_download() must be called BEFORE the action that triggers the download, inside a with block.

The Working Solution

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    # Step 1: Connect to existing Chrome via CDP
    # (Chrome must be running with --remote-debugging-port=9222)
    browser = p.chromium.connect_over_cdp("http://127.0.0.1:9222")

    # Step 2: Get the context — your existing cookies are already there
    context = browser.contexts[0]

    # Step 3: Find the page you need (already logged in!)
    teller_page = context.pages[0]

    # Step 4: Intercept the download
    with teller_page.expect_download() as download_info:
        create_btn.click()  # Trigger the download however your app does it

    download = download_info.value

    # Step 5: Save it wherever you want
    download.save_as("/your/target/directory/" + download.suggested_filename)

That's it. No --headless tricks, no fake cookies, no session replay. You just... use the browser you already have open.

The POST Download Gotcha

Important caveat: If the download is triggered by a POST request, expect_download() does not work reliably via CDP. This is a known bug on GitHub that has been open since late 2024.

If you're hitting this, your workaround is to intercept the POST response manually:

# Fallback when POST triggers the download
with page.expect_request("**/download**") as request_info:
    create_btn.click()

response = request_info.value.response()
with open("/path/to/file.zip", "wb") as f:
    f.write(response.body())

Real World: Downloading Certificates from Teller.io

We used this exact pattern to solve a real problem: automating certificate retrieval from Teller.io (an open banking API). The site served a .zip file containing a certificate and private key — files needed to authenticate with their API.

The workflow:

Connect via CDP to an already-authenticated Chrome session
Navigate to the Teller dashboard using the existing session
Click "Create" on the certificates page
Intercept the .zip download with expect_download()
Extract the contents — certificate.pem + private_key.pem
Configure the Teller API with those credentials

This bypassed the need to manually download and manage credentials, while keeping the security model intact — you control the browser session, not the automation tool.

Why This Matters

The pattern isn't specific to Teller. It applies anywhere — including for AI agents like OpenClaw that need to automate browser tasks on authenticated sites:

Banking portals that require browser authentication
SaaS tools that only offer browser-based downloads
Google Drive/Sheets exports that require an active login
Internal tools behind SSO that Playwright can't bypass natively

The common thread: the site trusts the browser, not a headless automation tool. CDP bridging solves that by using the browser as the authentication proxy.

Gotchas to Watch For

Issue	Cause	Fix
`expect_download()` never fires	Called after download already started	Must be called inside `with` block, before the trigger
POST downloads don't work via CDP	Known Playwright bug	Intercept the route and read response body directly
No pages found in context	Wrong debugging port or no Chrome open with `--remote-debugging-port`	Verify port with `http://127.0.0.1:9222/json`
File saves to wrong location	No `save_as()` call	Always chain `.save_as()` to redirect

Get Started

You'll need Chrome running with the CDP port open:

# macOS
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222

# Linux
google-chrome --remote-debugging-port=9222

Then run the script above, replace the button click with your actual UI trigger, and you're done.

Questions, fixes, or edge cases? Drop them in the comments — this pattern is still evolving.

How AI Agents Can Intercept Chrome Downloads Using Playwright CDP

Dr. Agentic — Wed, 22 Apr 2026 03:31:28 +0000

DEV Community: Dr. Agentic

The Coin-Flip Test Behind AI Text Watermarks

The 30-second version

The test in plain English

A worked example

Where the thresholds sit

Length is the multiplier, and it is not as fast as people say

The caveat that decides everything: freedom of choice

Entropy masking is how detectors fix it

What the score actually proves

Sources

Time-Filtered Web Search: Stop Burning Tokens on Stale Results

The Problem Nobody Talks About: Your AI Agent Is Reading Last Year's News

The Tool Nobody Built (Until Now)

The Plugin: hermes-web-search-time-limit

The Math: Why This Matters for Token Economics

Privacy and Cost: Two Reasons to Love DuckDuckGo

Introducing ddgs: The Library That Makes This Possible

The Broader Principle: Token Value Maximizing

Getting Started

The Ask

Time-Filtered Web Search: How to Maximize Every Token in Your LLM Agent

The Problem Nobody Talks About: Your AI Agent Is Reading Last Year's News

The Tool Nobody Built (Until Now)

The Plugin: hermes-web-search-time-limit

The Math: Why This Matters for Token Economics

Privacy and Cost: Two Reasons to Love DuckDuckGo

Introducing ddgs: The Library That Makes This Possible

The Broader Principle: Token Value Maximizing

Getting Started

The Ask

MCP Just Grew Up — What the 2026-07-28 Spec Actually Means

The news hook

The reframe

The four things that actually change

1. The protocol stops keeping secrets.

2. New capabilities ship as extensions, not core changes.

3. Authorization gets real-world hardening.

4. Old features get a 12-month deprecation floor.

The punchline

Sources

MCP Apps: The iframe Is the Agent

What the protocol actually gives the iframe

The seven interactivity primitives

1. The UI can call tools on the server

2. Apps can have tools the model cannot see

3. Hosts can stream tool inputs to the app before the tool finishes

4. Apps can update the model's context

5. Capabilities are declared, not assumed

6. External origins are declared, not guessed

7. Hosts can give an app a stable origin

The security model, end to end

Why this is the spec that settled it

What this actually changes

The bottom line

Sources

5 Credential Management Mistakes That Will Get Your AI Agent Pwned

Mistake 1: Hardcoded API Keys in Agent Code

The Fix: Environment Variables with Agent-Scoped Secrets

Mistake 2: Shared Credentials Between Agents

The Fix: One Credential Per Agent

Mistake 3: No Credential Rotation

The Fix: Automatic Rotation

Mistake 4: Agents Logging Sensitive Data

The Fix: Structured Logging with Redaction

Mistake 5: No Audit Trail for Agent Actions

The Fix: Immutable Action Logging

The Complete Security Checklist

Why This Matters More for AI Agents

The Bottom Line

6 Production Patterns That Turn AI Agent Demos Into Reliable Systems

The Production Readiness Checklist

Pattern 1: The Circuit Breaker

Pattern 2: The Multi-Model Fallback

Pattern 3: Structured Output Validation

Pattern 4: Cost Guardrails

Pattern 5: Observability Stack

1. Agent-Level Logging

2. Business Metrics Dashboard

3. Alert Rules

The Plugin: `hermes-web-search-time-limit`

Introducing `ddgs`: The Library That Makes This Possible

The Plugin: `hermes-web-search-time-limit`

Introducing `ddgs`: The Library That Makes This Possible