Forem

What brings you by a conference booth?

Amara Graham — Thu, 16 Apr 2026 14:39:18 +0000

I'm thinking about in-person events more and more these days, so I'm curious - what brings you by a conference booth?

What's a good experience or design you've seen? Or when do you avoid a booth (or booths!) entirely?

LMK 😊

How AI Agent Payments Actually Work — And Where They Break

Maxim Berg — Thu, 16 Apr 2026 14:38:36 +0000

OpenAI spent months building Instant Checkout — "Buy it in ChatGPT" with Stripe, Etsy, a million Shopify merchants. By March 2026, they pivoted away. Couldn't onboard merchants, couldn't show accurate product data, couldn't handle multi-item carts. They retreated to dedicated retailer apps that redirect users to merchant websites for the actual purchase.

Two weeks later, Fortune asked: "What do you do when your AI agent hallucinates with your money?"

Nobody has a good answer yet. Here's the map of why.

The payment stack as it exists today

In the last 12 months, every major player shipped something. Here's what exists:

Payment rails:

Stripe — Agentic Commerce Suite (Dec 2025). Shared Payment Tokens: scoped, time-limited, revocable credentials for agent transactions
Visa — Intelligent Commerce Connect (Apr 2026). Single API for agent purchases, tokenization, spend controls. 30+ sandbox partners
Mastercard — Agent Pay with Agentic Tokens. First live transaction Sep 2025, all U.S. cardholders enabled by Nov
PayPal — Agent Ready (Oct 2025). Agentic payments for existing merchants with built-in fraud detection
x402 — Coinbase's open protocol for stablecoin micropayments via HTTP 402. ~97M payments on Base. The x402 Foundation launched Apr 2026 under Linux Foundation — 22 founding members including Coinbase, Stripe, Microsoft, Google, AWS, Visa, Mastercard, American Express, Shopify

Communication protocols:

MCP — donated to Linux Foundation (Dec 2025). 97M monthly SDK downloads, 10,000+ servers. Payment MCP servers from Stripe, PayPal, Worldpay, Pagos, Fipto
A2A — Google's agent-to-agent protocol. 22K GitHub stars, 150+ organizations, deployed in Azure AI Foundry and Amazon Bedrock

Agent frameworks: LangChain, CrewAI, AutoGen, OpenAI Agents SDK, Claude tool use, Gemini agents.

Every layer is covered except one.

Anatomy of an agent payment

When an AI agent spends money, here's what actually happens — step by step:

1. Intent       → Agent decides it needs something
2. Discovery    → Agent finds the tool/API/merchant
3. Selection    → Agent picks what to buy and from whom
4. ???????????? → ????????????????????????????????????
5. Payment      → Money moves
6. Confirmation → Receipt, audit log

Step 4 is the problem.

Between "I want to buy this" and "money sent" — there is no standard layer that asks: should this agent spend this amount on this thing right now?

What "no standard layer" means, specifically:

Frameworks have monitoring, not enforcement. CrewAI has iteration caps. LangChain has observability hooks. Post-hoc cost tracking exists. Pre-execution enforcement of dollar-denominated policies does not. No framework understands "$50 on food" vs "$50 on compute."
Payment processors handle fraud, not policy. "Your agent shouldn't spend more than $200/day on SaaS" isn't fraud — it's governance. Different problem, different layer.
LLM providers offer org-level caps, not per-agent controls. Your agent blowing $500 on a single API call looks identical to 500 legitimate $1 calls.

So companies reinvent Step 4 every time. Hardcoded limits. Slack approval bots. "Please don't spend too much" in the system prompt.

Where policies can't live

If you accept that governance belongs at Step 4, the next question is: who runs it?

Not in the prompt

"Please limit spending to $100 per day" in a system prompt is not a spending control. It's a suggestion.

LLMs hallucinate. They reinterpret instructions. They prioritize task completion over constraints. And with prompt injection, an attacker can override your rules entirely. Security researchers have documented patterns of gradual prompt-based escalation: agents manipulated through "clarification" messages over days or weeks, each interaction nudging the spending authorization boundary until the agent operates well beyond its original constraints.

That's not a guardrail. That's a prayer.

And the tooling layer itself is under pressure. In April 2026, OX Security disclosed RCE vulnerabilities in MCP implementations — the same protocol that Stripe, PayPal, and Worldpay use for agent payments. Anthropic disputes the severity. But both sides agree that tool-level security depends on the user correctly evaluating each action. A compromised MCP server can alter transaction amounts and redirect payments. Prompt-based spending controls and tool-level trust are separate problems.

Not in the payment processor

Stripe, Visa, and Mastercard are building excellent infrastructure. But it operates at the transaction level, not the intent level.

A processor sees: "charge $47.99, category: food_delivery." It doesn't see: "this agent has a $15/person lunch budget and already spent $120 today." Hard limits on the card can't enforce contextual business rules.

Not in the agent framework

LangChain and CrewAI control tool execution. They can intercept a function call, log it, even block it. But they don't understand financial semantics. "$50 on food" and "$50 on cloud compute" trigger the same callback. The framework doesn't know your daily food budget is $30 and your compute budget is $500.

You could build this logic inside the framework. People do. That's the "writing authentication from scratch before OAuth" problem.

Where they belong: a dedicated middleware layer

The pattern that works is a separate policy layer between intent and execution.

The agent says "I want to spend X on Y." The policy layer checks rules deterministically — not with an LLM, with code — and returns approve, deny, or escalate. Then (and only then) the payment happens.

This is the same architectural pattern as:

OAuth — doesn't live in the browser or the database. Separate auth layer
OPA — doesn't live in the app or the infrastructure. Separate policy engine
Firewalls — don't live in the OS kernel or the application. Separate network layer

Agent spending governance is infrastructure, not application logic.

What governance actually checks

A policy engine for agent spending evaluates requests against declarative rules:

Check	Question	Example
Agent status	Is this agent active?	Disabled agents can't spend
Category	Is this category allowed?	"gambling" → denied
Per-request limit	Is this single purchase too large?	$500 request, $200 limit → denied
Schedule	Is spending allowed right now?	Procurement agent outside business hours → denied
Daily limit	Has the agent hit today's cap?	$450 spent today, $500 limit, requesting $100 → denied
Weekly limit	This week's cap?	Same logic, wider window
Monthly limit	This month's cap?	Same logic, wider window
Total budget	Lifetime budget remaining?	$4,800 of $5,000 spent, requesting $300 → denied

Every check is deterministic. No LLM in the loop. The agent gets back a structured response — approved with budget remaining, or denied with a specific reason. A well-behaved agent adjusts. The enforcement must be deterministic; an LLM can translate human intent into policy JSON, but it shouldn't be in the enforcement loop.

Two types of agent spending

A distinction most articles miss. There are two fundamentally different kinds of agent purchases, and they need different payment rails but the same governance layer:

Machine-consumable resources — APIs, compute, data, cloud services. High frequency, small amounts, no physical delivery. This is where x402 shines: agent hits an API, gets a 402 response with payment instructions, pays in USDC on Base, retries with proof. Sub-second. Sub-cent.

Human-consumable goods — food delivery, SaaS subscriptions, physical products. Lower frequency, larger amounts, complex fulfillment. Stripe, Visa, Mastercard territory.

An agent ordering compute for $0.003 and ordering lunch for $15 need completely different payment rails. But the question "should this agent spend this amount right now?" is identical. A unified policy layer tracks spending across both rails in USD-equivalent and maintains one audit trail.

The liability question

If an agent spends $12,000 instead of $500, who pays? The platform? The user who set the rules? The card issuer? The merchant?

EU's PSD2 requires "strong customer authentication" — a framework that doesn't account for non-human actors. An agent can't do biometric verification. It can't confirm intent through a second device. Regulatory frameworks assume a human in the loop, and agents break that assumption.

This is why compliance teams will require governance layers before agents get payment access. Without an auditable, deterministic policy check between intent and payment, there's no answer to "who approved this?" that satisfies a regulator.

What comes next

Short term (2026): Basic policy engines. Per-agent budgets, category restrictions, time limits, approval thresholds. Companies will require this the way they require SSO — because compliance demands it. FINRA already flagged agents "acting beyond the user's actual or intended scope and authority."

Medium term (2027): Contextual policies. "Max $200/request for compute, $50 for food, unlimited for pre-approved vendors." Corporate purchasing has done this for humans for decades, but agents operate at machine speed across dozens of tools, generating hundreds of transactions per hour. An agent can't be pulled into a meeting to justify a purchase. The governance layer encodes business context upfront. Multi-agent governance follows: agent A delegates budget to agent B with scoped authority.

Long term (2028+): Adaptive policies. Anomaly detection for waste, not just fraud. Cross-org benchmarks: "agents in your industry typically spend $X on Y."

Nava just raised $8.3M to build escrow for agent transactions. SolvaPay raised €2.4M for agentic payment infrastructure. Two funded startups in one week, both solving variations of the same problem. Market forecasts range from $547M (Sanbi.ai, 2033) to $1.5T (Juniper Research, 2030). The real number depends on trust. And trust requires governance.

The firewall moment

We've been here before. Authentication before OAuth. Authorization before OPA. Network security before firewalls. Every time: "each team builds their own" → "there's a standard layer for this."

Agent spending governance is at the "each team builds their own" stage. Vendor surveys say 80% of organizations report risky agent behaviors. Take that with a grain of salt. But the direction is clear, and the payment stack is making it easier to spend every month.

The capability layer is built. The governance layer is next. Standards bodies are working on it. The question is whether it'll happen before or after the first headline-making incident.

Disclosure: I'm building an open-source approach to this at LetAgentPay — policy engine with Python/TypeScript SDKs and an MCP server — so I'm not a neutral observer. But the architectural pattern described here matters more than any single implementation. If you're building agents that spend money, I'd genuinely love to hear how you're handling governance today.

Database Subsetting for PostgreSQL: A Practical Guide (2026)

Jake Lazarus — Thu, 16 Apr 2026 14:35:00 +0000

Every team that has tried to copy production data into a dev environment has hit the same wall: production is too big, full of PII, and growing. The fix is not a bigger laptop or a faster pg_dump. It is database subsetting — extracting a small, self-contained slice of the database instead of all of it.

Subsetting is the workflow underneath almost every modern dev-data tool. It is what makes "restore production data locally" actually viable. But the term gets thrown around loosely, and the difference between a real FK-aware subset and a glorified SELECT ... LIMIT is the difference between a working dev environment and a database full of orphaned rows.

This guide is the canonical version. What subsetting is, how it works at the foreign-key level, the strategies that work for common PostgreSQL schemas, and a 2026 honest look at the tools that do it.

TL;DR: Database subsetting extracts a referentially complete slice of a PostgreSQL database by traversing foreign keys from one or more root tables. Done well, it produces a dataset 10–1000× smaller than production that still behaves like production. Done badly, it produces broken referential integrity and silent test failures. This post covers how to do it well, the strategies that fit common schemas, and the tools that handle it in 2026.

What is database subsetting?

Database subsetting is the process of extracting a representative, self-contained slice of a database instead of copying the whole thing. You start from one or more root tables — usually entities like users, accounts, or tenants — apply filters and row limits, and then traverse foreign key relationships to pull in every related row that the slice depends on.

The output is a smaller database that preserves the same schema and the same relational structure as production. Every foreign key still resolves. Every join still returns rows. The dataset behaves like production, just at 1% (or 0.1%, or 0.01%) of the size.

The point of subsetting is not to make a backup. It is to produce a dataset small enough to be useful for development, CI, and staging while still being realistic enough to surface the bugs that fake data hides.

Why teams need database subsetting

The motivation is almost always the same: pg_dump does not scale, and seed scripts do not survive contact with reality.

A full pg_dump of a mature production database is:

Too big. A 200GB database is fine on production hardware. It is unusable on a laptop, painful in CI, and a pain to refresh weekly.
Full of PII. Real emails, real names, real billing addresses end up on dev machines, in CI logs, and in artifacts. That is a compliance problem in any environment that handles customer data.
Slow to restore. A restore that takes 90 seconds today takes 8 minutes in 18 months as production grows. That cost compounds across every CI run.

We covered the full breakdown in pg_dump vs database snapshots — the headline is that pg_dump is the right tool for backups and disaster recovery, and the wrong tool for dev data.

Seed scripts have the opposite problem. They start small and stay small, so size is not an issue. But every schema migration is a chance for the seed script to break, drift, or silently produce stale data. The shapes of real data — Unicode, NULLs, accounts with hundreds of related rows — never appear in hand-written fixtures. We covered why that matters in Why Fake PostgreSQL Test Data Misses Real Bugs.

Subsetting solves both problems at once. The output is small enough to be useful and real enough to be representative.

How FK-aware subsetting actually works

Most of the difference between "good subsetting" and "bad subsetting" comes down to whether the extractor understands foreign keys. Here is what FK-aware extraction is doing under the hood.

Root tables and traversal

You pick one or more root tables. These are the entities the subset is "about" — usually users, accounts, tenants, or organizations. The extractor reads the rows that match your filter from the root tables and then walks the foreign key graph to pull in everything that depends on those rows.

If your root is users and you select 1000 rows, the extractor follows every foreign key that points at users and pulls in the matching rows from orders, subscriptions, audit_logs, and any other dependent table. It then walks one level deeper: orders has FKs to line_items and payments, so those come along. And so on, until the closure is complete.

This is the part that matters. Without traversal, you end up with 1000 users and zero orders, because nothing told the extractor to follow orders.user_id. With traversal, you get a connected subgraph: 1000 users, all of their orders, all of those orders' line items, all of the related payments.

Filters and row limits

Filters narrow the slice before traversal runs. They look like SQL WHERE clauses applied to the root tables:

from:
  - table: users
    where: 'created_at > :since AND plan = :plan'
    params:
      since: '2026-01-01'
      plan: 'team'

Row limits cap the slice in case the filter still pulls in too much. A per_table limit prevents one accidentally-huge table from blowing up the snapshot, and a total limit caps the whole extract:

limits:
  rows:
    per_table: 5000
    total: 100000

Filters and limits together are the levers that make subsetting work for any size of production database. The same config that works on 10GB of data works on 10TB — only the filter changes.

Why referential completeness matters

A subset is referentially complete when every foreign key in the extract resolves to a row that is also in the extract. If orders.user_id = 42 is in the extract but users.id = 42 is not, the subset is broken and the restore will fail with a constraint violation — or worse, succeed with constraints disabled and produce a database your app cannot read correctly.

This is the failure mode of "naive" subsetting (run SELECT * FROM users LIMIT 1000 and call it done). The extracted users table has 1000 rows. The orders table has rows pointing at user IDs that no longer exist. The restore either errors out or silently corrupts the dataset.

A real FK-aware extractor guarantees referential completeness by construction: every row in the output is reachable from a root row by following foreign keys, and every foreign key in every row resolves inside the output. There are no orphans.

This is the property that makes subsetting actually useful. Without it, you do not have a working database — you have a pile of disconnected rows.

Subsetting and anonymization

A referentially complete subset still contains real PII unless something explicitly removes it. The two operations — subsetting and anonymization — are usually run together at extraction time, before the data ever leaves production.

The reason to anonymize during extraction (not after restore) is that any post-restore approach lets real PII travel through your pipeline before the masking script runs. Real emails appear in restore logs. Real names sit on disk for the few seconds it takes the script to start. New columns added since the script was last updated never get masked at all.

The fix is to anonymize as part of the extract step, deterministically, so the same source value maps to the same fake value across every related table:

anonymize:
  mode: auto
  rules:
    - column: '*.email'
      strategy: deterministic_email
    - column: 'users.full_name'
      strategy: deterministic_name

Deterministic masking matters because joins still need to work. If jane@company.com becomes lmitchell@example.com in users but kpark@example.com in audit_logs, queries that join across tables stop returning the right rows. Determinism preserves the relationships even though every value has been replaced.

We covered the full mechanics — including the difference between masking and anonymization, what GDPR considers anonymized, and why automatic detection matters — in How to Anonymize PII in PostgreSQL for Development.

Subsetting strategies for common PostgreSQL schemas

Most production schemas fit one of three patterns. Each one has a different "right way" to subset, and getting the strategy right matters more than which tool you use.

Multi-tenant SaaS: filter by tenant_id

The most common shape. Every business object has a tenant_id (or org_id, or account_id) column, and every row in the system belongs to exactly one tenant. The natural subset is "give me all the data for one tenant" or "give me all the data for the 50 most recent tenants."

from:
  - table: tenants
    where: 'created_at > :since'
    params:
      since: '2026-01-01'
    limit: 50

The extractor then follows foreign keys from tenants to users, projects, documents, audit_logs, and everything else, naturally producing a dataset that is "the last 50 tenants and everything they own." Restore time scales with tenant size, not database size.

The anti-pattern here is filtering on a child table directly (SELECT * FROM documents WHERE tenant_id IN (...)). You end up with documents whose owning users were not pulled in, and the joins break.

Time-windowed: last N days of activity

When you do not have a clean tenant boundary (or you want to capture cross-tenant traffic), filter by recency. Pick a root table that represents activity — events, orders, sessions — and grab the last 30 days:

from:
  - table: orders
    where: 'created_at > :since'
    params:
      since: '2026-03-08'

Traversal pulls in the related users, products, and line items. The result is a snapshot that captures whatever shapes of data are flowing through the system right now, including recent edge cases like new payment methods or feature flags that only enabled in the last week.

This strategy is particularly good for catching regressions, because the subset always reflects the latest production patterns. Refresh weekly and you are testing against last week's data shapes, not last quarter's.

Customer-scoped: one specific account for repro

When a customer reports a bug you cannot reproduce, the fastest path to a fix is usually a snapshot of just their account. Pick the customer as a root and traverse:

from:
  - table: accounts
    where: 'id = :account_id'
    params:
      account_id: 'acct_01HXYZ...'

The output is a tiny, FK-complete database containing exactly that customer's data — anonymized so you can share it with the team, restore it locally, and reproduce the bug in seconds. This is the workflow that justifies subsetting on its own for most teams: a 30-second restore beats half a day of "can you give me your steps again?"

We dig into the broader workflow in the local development use case.

Tools that do PostgreSQL subsetting in 2026

The market has shaken out a bit since 2024. Here is the honest 2026 picture.

	Basecut	Tonic.ai	Delphix	OSS Snaplet fork	Hand-rolled SQL
FK-aware traversal	Yes	Yes	Yes	Yes	DIY
Anonymize at extract time	Yes	Yes	Yes	Yes	No (post-restore)
Referential completeness guaranteed	Yes	Yes	Yes	Yes	DIY
Auto-detects common PII	Yes	Yes	Yes	Yes	No
Config format	YAML	GUI + config	GUI + agents	TypeScript	SQL / shell
Hosted option	Yes (free tier)	Self-host + hosted	Enterprise self-host	Self-host only	N/A
Actively maintained	Yes	Yes	Yes	No active upstream	N/A
Best for	Teams wanting CLI + YAML, free tier	Enterprise procurement	Large enterprise	Self-hosters with bandwidth	Tiny schemas, stopgaps

A few notes that the table cannot capture.

Basecut is the actively maintained CLI-first option. YAML config, FK-aware traversal, deterministic masking, and a free tier that covers small teams. Built for the same workflow Snaplet pioneered. We cover the details on the Snaplet alternative page.

Tonic.ai is the heavyweight commercial option. Strong for enterprise procurement and SOC 2 paperwork, heavier than most teams want for "just give me dev data." Full Tonic comparison.

Delphix is the legacy enterprise player. Powerful, but the operational model assumes a dedicated platform team. Full Delphix comparison.

The open-source Snaplet fork is on GitHub and viable if you have engineering bandwidth to self-host and own maintenance indefinitely. There is no active upstream. Context here.

Hand-rolled pg_dump plus SQL scripts is what most teams default to before they have evaluated anything. It works at small schemas and breaks quietly as they grow. The full breakdown is in pg_dump vs database snapshots, and the broader "stop writing seed scripts" argument is in Replace Seed Scripts with Production Snapshots.

If you are evaluating from scratch, the honest order of operations is: pick the simplest tool that will work for your schema today, and make sure it handles referential completeness and at-extract anonymization. Everything else is detail.

How to subset a PostgreSQL database

Here is the minimum viable workflow with Basecut, end to end. The same five steps apply to any FK-aware tool — the syntax is just different.

1. Pick your root tables

Identify the entities your subset is "about." For multi-tenant SaaS this is usually tenants or accounts. For a marketplace it might be users or listings. For an event-driven system it might be events or orders. Pick the table whose rows naturally pull in everything else through foreign keys.

2. Write a config

A Basecut config defines roots, filters, limits, and anonymization rules in YAML:

version: '1'
name: 'dev-snapshot'

from:
  - table: tenants
    where: 'created_at > :since'
    params:
      since: '2026-01-01'
    limit: 50

limits:
  rows:
    per_table: 5000
    total: 100000

anonymize:
  mode: auto

mode: auto handles common PII columns (emails, names, phones, addresses) without explicit rules. Add explicit rules later if you have unusual fields like JSONB blobs or free-text notes.

3. Create a snapshot

Run the create command against a production read replica:

basecut snapshot create \
  --config basecut.yml \
  --source "$PRODUCTION_READ_REPLICA_URL"

Basecut traverses foreign keys from your root tables, pulls in every dependent row, anonymizes PII inline, and writes a versioned, referentially complete snapshot. Real PII never leaves production.

4. Restore wherever you need it

Same snapshot, any target:

# Local dev
basecut snapshot restore dev-snapshot:latest \
  --target "$LOCAL_DATABASE_URL"

# Staging
basecut snapshot restore dev-snapshot:latest \
  --target "$STAGING_DATABASE_URL"

# CI runner
basecut snapshot restore dev-snapshot:latest \
  --target "postgresql://postgres:postgres@localhost:5432/test_db"

The restore is fast because the subset is small, and safe because the data is already anonymized. We cover the CI flavor specifically in PostgreSQL test database in GitHub Actions and the staging flavor in setting up a staging database.

5. Refresh on a schedule

A snapshot from three months ago is only as good as the data shapes from three months ago. Schedule weekly refreshes so :latest always points at fresh data:

basecut snapshot create --config basecut.yml --source "$PRODUCTION_READ_REPLICA_URL"

Run it from a cron job, a CI workflow, or — on the team plan — a Basecut agent that handles scheduling for you. Existing restore commands keep working unchanged because they reference :latest.

That is the whole loop. Most teams get a working subset config in an afternoon and roll it out across local, CI, and staging over the following sprint.

When subsetting is not the right answer

Subsetting is the right default for development data, but it is not the right tool for every job. Skip it when:

You need an exact copy of production for migration rehearsal. Use pg_dump or a logical replication snapshot. Subsetting is a slice, not a forensic copy.
Your schema is genuinely tiny. If you have five tables and 10MB of data, subsetting is overkill. A pg_dump plus a quick masking script is fine until the schema grows.
You have a strict requirement for full row-level fidelity. Some compliance scenarios mandate a full copy with controlled access rather than a representative subset. Subsetting is a fit for the development workflow, not for forensic or audit use cases.

For everything else — local dev, CI test data, staging refreshes, customer repros, and onboarding — subsetting is the workflow worth investing in. It is the difference between "we have realistic dev data" and "we have a database we can actually develop against."

If you want to see whether subsetting fits your schema, the Basecut free tier covers most small teams. Install the CLI, point it at a read replica, and you can have a first FK-complete, anonymized snapshot in a few minutes.

Try Basecut free →

How to Get AI Market Analysis On-Chain: Backtested Patterns Delivered to Your Smart Contract

Pythia Oracle — Thu, 16 Apr 2026 14:32:39 +0000

What if your smart contract could receive AI-generated market intelligence — not just a price, but a pattern analysis with confidence scores, indicator snapshots, and historical accuracy data — delivered on-chain through Chainlink?

That's what Pythia Visions does. This post walks through the architecture, the on-chain interface, and a full Solidity example that reacts to AI analysis automatically.

The Problem: Smart Contracts Are Blind to Market Context

Price oracles tell your contract that BTC is $72,000. They don't tell you:

Is this a capitulation sell-off or a normal dip?
What do RSI, EMA, Bollinger Bands, and VWAP say right now?
What happened historically when this exact pattern appeared?
How confident should you be in a recovery?

For any of this, you'd need to run your own off-chain pipeline — data sources, indicator computation, pattern detection, historical backtesting. Most builders don't have the time or infrastructure for that.

Pythia Visions solves this by running the full analysis pipeline off-chain and delivering structured, AI-calibrated results on-chain via Chainlink.

What a Vision Contains

A Vision is a structured payload fired on-chain when a historically significant pattern is detected. Here's what arrives in the VisionFired event:

Field	Type	Example
`tokenId`	`bytes32`	`keccak256("BTC")`
`patternType`	`uint8`	`0x11` (CAPITULATION_STRONG)
`confidence`	`uint8`	`86` (AI-calibrated, 55-89 range)
`direction`	`uint8`	`1` (BULLISH)
`price`	`uint256`	BTC price at detection (18 decimals)
`payload`	`bytes`	ABI-encoded: indicators, analysis, feeds

The payload bytes decode to a full analysis package:

Indicator snapshot — RSI, EMA gap, ATR, Bollinger position, VWAP distance, rate of change
Pattern metadata — historical accuracy, average return, sample size, data span
AI analysis — 2-3 sentence explanation of what's happening
Feeds to watch — which Pythia Feeds to monitor for confirmation (with thresholds)

The Patterns (Backtested 2017-2026)

Six patterns validated against years of BTC history, covering four categories:

Pattern	Category
`CAPITULATION_STRONG`	Severe sell-off with multiple confirming indicators
`CAPITULATION_BOUNCE`	Sell-off with early reversal signals
`EMA_DIVERGENCE_STRONG`	Strong trend divergence with momentum confirmation
`EMA_DIVERGENCE_SNAP`	Trend divergence approaching snap-back threshold
`BOLLINGER_EXTREME`	Price at extreme statistical deviation
`OVERBOUGHT_CONTINUATION`	Strong momentum with continuation bias

Each Vision carries its confidence score and the historical accuracy range for the detected pattern — your contract gets the full context to decide how to act.

Browse available Visions at pythia.c3x-solutions.com/visions.

The On-Chain Interface

PythiaVisionRegistry

Deployed on Polygon mainnet at 0x39407eEc3Ba80746BC6156eD924D16C2689533Ed.

interface IPythiaVisionRegistry {
    /// @notice Emitted when AI detects a backtested pattern
    event VisionFired(
        bytes32 indexed tokenId,
        uint8   patternType,   // 0x11 = CAPITULATION_STRONG, etc.
        uint8   confidence,    // AI-calibrated, 55-89
        uint8   direction,     // 1 = BULLISH
        uint256 price,         // 18 decimals
        bytes   payload        // ABI-encoded full analysis
    );

    /// @notice Subscribe to Visions for a token. Free — no LINK.
    function subscribe(bytes32 tokenId) external;

    /// @notice Unsubscribe
    function unsubscribe(bytes32 tokenId) external;

    /// @notice Check subscription status
    function isSubscribed(address subscriber, bytes32 tokenId)
        external view returns (bool);
}

Visions are free. subscribe(keccak256("BTC")) — that's it. No LINK, no fees, no expiry.

The VisionFired events are public. Anyone can read them from the event log. Subscription is optional on-chain registration — useful for contracts that want to filter or for future automation.

Pattern Type Codes

// BTC pattern types
uint8 constant CAPITULATION_STRONG   = 0x11;
uint8 constant CAPITULATION_BOUNCE   = 0x10;
uint8 constant EMA_DIVERGENCE_STRONG = 0x21;
uint8 constant EMA_DIVERGENCE_SNAP   = 0x20;
uint8 constant BOLLINGER_EXTREME     = 0x30;
uint8 constant OVERBOUGHT_CONT      = 0x40;

Reading Visions in Your Contract

The simplest integration: listen for VisionFired events and act on the structured fields.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.19;

import "./interfaces/IPythiaVisionRegistry.sol";

contract SimpleVisionReader {
    IPythiaVisionRegistry public immutable visionRegistry;
    bytes32 public constant BTC = keccak256("BTC");

    uint8   public lastPattern;
    uint8   public lastConfidence;
    uint256 public lastPrice;
    uint64  public lastTimestamp;

    event VisionReceived(uint8 pattern, uint8 confidence, uint256 price);

    constructor(address _visionRegistry) {
        visionRegistry = IPythiaVisionRegistry(_visionRegistry);
    }

    /// @notice Call once after deployment — free, no LINK needed
    function subscribe() external {
        visionRegistry.subscribe(BTC);
    }

    /// @notice Called by a relay bot when VisionFired is detected
    function onVision(
        uint8 patternType,
        uint8 confidence,
        uint256 price
    ) external {
        lastPattern    = patternType;
        lastConfidence = confidence;
        lastPrice      = price;
        lastTimestamp   = uint64(block.timestamp);
        emit VisionReceived(patternType, confidence, price);
    }

    /// @notice Other contracts read this to check for active signals
    function hasRecentVision(uint64 maxAge) external view returns (bool) {
        return lastTimestamp > 0 &&
               block.timestamp - lastTimestamp <= maxAge;
    }
}

Deploy on Polygon mainnet with _visionRegistry = 0x39407eEc3Ba80746BC6156eD924D16C2689533Ed.

Full Example: Vision-Driven Vault Guard

The real power of Visions is the feeds-to-watch field. Each Vision tells you which Pythia Feeds to monitor for confirmation — with specific thresholds.

For example, a capitulation Vision might include feeds like btc_RSI_1H_14 (watch for oversold exit), btc_VWAP_24H (watch for VWAP reclaim), and btc_EMA_1H_20 (watch for EMA reclaim) — each with a specific condition and threshold tailored to the current market state.

The VisionVaultGuard contract automates this loop:

Vision fires (free) — AI says "BTC capitulation detected, 86% confidence"
Contract auto-subscribes to the recommended Pythia Events (paid LINK) — "tell me when RSI crosses above 35"
Events fire when thresholds are hit — confirmation arrives on-chain
Contract transitions to CONFIRMED — other contracts/bots read the state and act

State machine:

  IDLE → ALERT → WATCHING → CONFIRMED → IDLE
         (vision   (events     (enough        (auto-reset
          fires)    subscribed)  confirmations)  after cooldown)

Here's the core of the contract (full source at pythia-oracle-examples):

contract VisionVaultGuard is ConfirmedOwner {
    enum State { IDLE, ALERT, WATCHING, CONFIRMED }

    IPythiaEventRegistry    public eventRegistry;
    IPythiaVisionRegistry   public visionRegistry;
    bytes32 public constant BTC = keccak256("BTC");

    State public state;
    uint8 public requiredConfirmations = 1;

    struct FeedWatch {
        string  feedName;    // e.g. "btc_RSI_1H_14"
        uint8   condition;   // 0=ABOVE, 1=BELOW
        int256  threshold;   // 8 decimals
    }

    /// @notice Relay bot calls this when VisionFired event is detected
    function processVision(
        uint8 patternType,
        uint8 confidence,
        uint8 direction,
        uint256 price,
        FeedWatch[] calldata feeds,
        string[] calldata meanings
    ) external onlyOwner {
        // Store vision data, transition to ALERT
        // ...

        // Auto-subscribe to each recommended feed as a Pythia Event
        for (uint256 i = 0; i < feeds.length; i++) {
            uint256 cost = eventRegistry.getCost(eventDays);
            LINK.approve(address(eventRegistry), cost);
            uint256 eventId = eventRegistry.subscribe(
                feeds[i].feedName,
                eventDays,
                feeds[i].condition,
                feeds[i].threshold
            );
            // Track subscription for confirmation matching
        }

        // Transition: ALERT → WATCHING
    }

    /// @notice Bot reports when a confirmation Event fires
    function reportConfirmation(uint256 eventId, int256 value) external onlyOwner {
        // Match eventId to tracked subscription, mark as fired
        // If enough confirmations → transition to CONFIRMED
    }

    /// @notice Other contracts read this
    function isActionReady() external view returns (bool) {
        return state == State.CONFIRMED &&
               block.timestamp < lastVision.receivedAt + confirmedTimeout;
    }
}

This creates a Vision → Event → Action loop where:

Visions (free) provide the intelligence — what happened and what to watch
Events (paid LINK) provide the triggers — when confirmations arrive
Your contract acts only when both the pattern AND the confirmations align

Full contract with 26 passing Hardhat tests: 06_VisionVaultGuard.sol

Deploying on Polygon Mainnet

Pythia Vision Registry: 0x39407eEc3Ba80746BC6156eD924D16C2689533Ed
Pythia Event Registry:  0x73686087d737833C5223948a027E13B608623e21
LINK Token:             0xb0897686c545045aFc77CF20eC7A532E3120E0F1

For the VisionVaultGuard, fund the contract with LINK (for Event subscriptions). Visions themselves are free.

AI-Assisted Development

Explore Visions and Feeds programmatically:

pip install pythia-oracle-mcp

Works with Claude, Cursor, Windsurf, or any MCP-compatible AI tool. Ask:

"What patterns does Pythia Visions detect for BTC?"
"Show me the VisionFired event interface"
"What feeds should I watch after a capitulation signal?"

Or use LangChain:

pip install langchain-pythia

from langchain_pythia import PythiaToolkit

toolkit = PythiaToolkit()
tools = toolkit.get_tools()
# 7 tools: feeds, tokens, events, visions info, and more

Why This Architecture

Why not just put AI on-chain?

Running an LLM on-chain is impossible. But the output of an AI — a confidence score, a pattern classification, a set of indicator values — is just data. Data that Chainlink already knows how to deliver.

Pythia's approach:

Mechanical detection (free, deterministic) decides IF something fires
AI calibration (one cheap API call) adds nuance to HOW confident we are
Chainlink delivery (trustless) gets it on-chain

The AI is one step in the middle — not the foundation. If AI is down, Visions still fire with mechanical defaults. The patterns are the product; AI makes them better.

Why backtested patterns?

Every pattern in production has been validated against years of BTC history. Patterns that looked strong on shorter windows but degraded on full history were dropped. Data decides what ships.

What You Can Build With This

Risk management layers — pause lending/vault operations when high-confidence capitulation is detected
Automated DCA strategies — increase position size when AI confidence is above 80%
Alert systems — relay Vision data to Telegram/Discord bots for trading teams
Portfolio rebalancing — shift allocations based on detected market regime
Keeper-style bots — watch for VisionFired events and execute strategies across protocols

Summary

Pythia Visions deliver AI-calibrated market intelligence on-chain via Chainlink
6 backtested BTC patterns covering capitulations, divergences, extremes, and momentum
Free subscription — subscribe(keccak256("BTC")), no LINK
Structured payload: pattern type, confidence, indicators, analysis, feeds-to-watch
VisionVaultGuard example: automated Vision → Event → Action loop
Mainnet contract: 0x39407eEc3Ba80746BC6156eD924D16C2689533Ed

The intelligence is live. The patterns are firing. What you build on top is up to you.

Explore: pythia.c3x-solutions.com/visions | MCP: pip install pythia-oracle-mcp | Examples: github.com/pythia-the-oracle/pythia-oracle-examples

Migrate your Drools rules to OrqueIO DMN

Ghofrane WECHCRIA — Thu, 16 Apr 2026 14:32:22 +0000

Introduction

In a business process, decision-making is essential because it defines the logic that guides the execution of activities. Historically, this logic was externalized into rule engines such as Drools, separating decision-making from orchestration. However, in today’s environments where transparency and collaboration are key, this separation reveals its limitations: rules often remain hidden in technical files, difficult to understand and maintain.
To address these challenges, organizations now seek more integrated approaches. This is exactly what OrqueIO DMN offers: a model in which decisions and processes are brought together within the same ecosystem, providing consistency, clarity, and traceability.

1.OrqueIO — The future of open-source orchestration

Before introducing DMN, it’s important to present the execution platform.
OrqueIO is a 100% open-source fork of Camunda, ensuring the long-term future of BPMN automation, maintaining full compatibility with existing workflows while extending and modernizing the engine.

What OrqueIO brings:

100% open-source and fully compatible with your current BPMN/DMN models, connectors, scripts, and APIs
Ongoing maintenance and guaranteed security updates, ensuring long-term reliability and stability
New, practical features for daily use, including improved Cockpit monitoring and native DMN integration
Enhanced performance and engine stability, even under high load
Expert technical support, transparent and reliable — with no vendor lock-in

In summary, OrqueIO enables organizations to preserve their existing investments while adopting a modern, sustainable, and open orchestration platform — an environment where integrated decision logic with DMN naturally thrives.

2. The limitations of Drools

Excessive separation from the BPMN process:
The rules are stored in .drl files, often isolated in a separate project or module, which scatters business logic and makes it difficult to understand the relationship between decisions and the process.

Maintenance complexity:
This separation between the rule engine and the process leads to difficulties in maintaining overall system consistency over time.

Barrier for business teams:
The rules are written in technical languages such as DRL or MVEL, requiring development skills.
Non-technical users cannot read or modify these rules without IT involvement.

Lack of traceability and transparency:
Drools does not natively provide decision traceability (which rules were applied and why).
This makes audits and regulatory compliance much more difficult.

Rigid update cycle:
Any modification to a rule requires a full redeployment of the engine or application module, slowing down update cycles and reducing responsiveness.

Limits in agility and governance:
The Drools model does not encourage collaboration between business and IT teams, nor does it provide clear governance of decision rules integrated into BPMN processes.

3. OrqueIO DMN: a unified, readable, and open-source approach

OrqueIO natively integrates the DMN standard (Decision Model and Notation), enabling the unification of process logic (BPMN) and decision logic within the same platform.
Whereas Drools externalizes rules into a separate rule engine, OrqueIO provides an integrated, visual, and transparent approach within a recognized open-source automation ecosystem.

Clear and accessible rule representation
In OrqueIO, decisions are modeled as DMN decision tables.
Each row represents a rule, and each column represents a condition or an output.
This visual format is understandable to both business users and developers, replacing the DRL or MVEL source code used in Drools.
Business analysts can define, adjust, and validate decision logic without heavy reliance on technical teams.

Native BPMN ↔ DMN Integration
In OrqueIO, a Business Rule Task can directly invoke a DMN decision table from within the same project.
No external connectors, no complex integration: the process and the decision belong to the same executable model.
This results in a decision logic that is coherent, centralized, and fully traceable across the entire workflow.

Built-in traceability and audit
Every decision execution is automatically logged.
Teams can easily review:

which rules were evaluated,
the input values,
and the resulting outputs.

This greatly simplifies audits, gap analysis, regulatory compliance, and continuous improvement.

A complete and consistent ecosystem
OrqueIO provides a unified environment combining:

BPMN for process orchestration,
DMN for decision logic,
Cockpit for monitoring and analysis.

Everything is centralized, extensible, interoperable, and designed to enhance collaboration between business teams and IT.

4. Why migrate to OrqueIO DMN?

The transition from Drools is not just a tool replacement —
it is the adoption of a more agile, readable, and collaborative decision model.

Centralization of decisions and processes
Decisions are no longer isolated in a separate technical module.
They coexist with business processes within the same execution environment, ensuring a unified and coherent view of the system’s behavior.

Simplified maintenance
Modifying a rule no longer requires redeploying the application.
A simple update to the DMN decision table is enough to adjust the business logic, reducing delivery cycles and improving operational responsiveness.

Enhanced collaboration
Business teams design and adjust rules, while developers focus on integration and robustness.
The result: fewer misunderstandings, fewer back-and-forth steps, and greater overall efficiency.

Monitoring and transparency
With the Cockpit interface, every executed decision is observable, explainable, and interpretable.
This transparency simplifies optimization, control, and regulatory compliance.

Below is a comparison table summarizing the main differences between Drools and OrqueIO:

5.Concrete example of the transition: from Drools to OrqueIO DMN

We want to apply discounts based on:

the customer type (Standard, Premium, VIP)
the order amount (orderAmount)

Drools version (Before)
This .drl file contains the rules, written in Drools syntax

import io.orqueio.bpm.exemple.dmn.model.Order;

rule "Standard < 100"
    when $o : Order(clientType == "Standard", orderAmount < 100)
    then $o.setDiscount(0);
end

rule "Standard 100..500"
    when $o : Order(clientType == "Standard", orderAmount >= 100 && orderAmount <= 500)
    then $o.setDiscount(5);
end

rule "Standard >= 500"
    when $o : Order(clientType == "Standard", orderAmount > 500)
    then $o.setDiscount(8);
end

rule "Premium < 100"
    when $o : Order(clientType == "Premium", orderAmount < 100)
    then $o.setDiscount(10);
end

rule "Premium 100..500"
    when $o : Order(clientType == "Premium", orderAmount >= 100 && orderAmount <= 500)
    then $o.setDiscount(15);
end

rule "Premium >= 500"
    when $o : Order(clientType == "Premium", orderAmount > 500)
    then $o.setDiscount(20);
end

rule "VIP < 500"
    when $o : Order(clientType == "VIP", orderAmount < 500)
    then $o.setDiscount(20);
end

rule "VIP 500..1000"
    when $o : Order(clientType == "VIP", orderAmount >= 500 && orderAmount < 1000)
    then $o.setDiscount(25);
end

rule "VIP >= 1000"
    when $o : Order(clientType == "VIP", orderAmount >= 1000)
    then $o.setDiscount(30);
end

Implementation with DMN in OrqueIO

With DMN, the decision logic is defined in the form of a decision model, in which we explicitly describe:

which data serves as inputs to the decision,
which conditions are applied,
and which result must be produced.

This model can be edited visually, either as a table or as a diagram, which allows business teams to understand and adjust the logic more easily.

At the same time, that same logic is stored in a standard DMN XML file, which is used by the engine for execution.
The graphical view and the XML view are simply two representations of the same model, always kept in sync.

In the BPMN diagram, you simply add a Business Rule Task:

Calling a decision does not require any complex configuration.
In the BPMN diagram, a simple Business Rule Task is enough.
You only need to specify the decision reference (the ID defined in the DMN model), and the engine takes care of the evaluation.No additional technical configuration is required.
The decision is executed automatically when the BPMN flow reaches the decision task.

Conclusion

Migrating from Drools to OrqueIO DMN is more than a modernization effort — it is a strategic shift toward transparency, agility, and collaboration. By bringing decision logic closer to BPMN processes, organizations eliminate silos, simplify maintenance, and empower business teams to directly contribute to the evolution of rules. The result is a unified, traceable, and adaptable system where decisions are easier to understand, update, and audit.

With OrqueIO DMN, your business logic becomes clearer, your delivery cycles faster, and your governance stronger. This transition enables organizations to move from rigid rule engines to an integrated decision model that supports continuous improvement and operational efficiency.

🌐 Learn more about OrqueIO
📂 Explore the example Order Process from the OrqueIO webinar

How to Separate Cron Success and Failure in Your Daily Logs

anicca — Thu, 16 Apr 2026 14:31:36 +0000

TL;DR

Cron work is easier to debug when you separate execution success from delivery failure, discovery failure, and configuration failure. That was the main signal in today's diary.

This article shows a simple way to keep daily logs in those four buckets so you can recover faster later.

Prerequisites

A daily diary or ops log
Cron jobs that produce artifacts or traces
A habit of not collapsing every failure into one vague note

Step 1: Log execution success by itself

Start with the jobs that actually completed.

app-metrics succeeded
mau-tiktok hook fetch, trim, and stitch succeeded
reelclaw widget demo generation and direct post succeeded

Keep this section short and factual.

Step 2: Log delivery failure separately

A job can succeed internally and still fail at the delivery layer.

Postiz DNS failure

This tells you the work was produced, but the handoff broke.

Step 3: Log discovery failure separately

Search and existence checks are a different class of problem.

rg unavailable
missing SKILL.md
missing directory reference

These failures happen before the actual job logic.

Step 4: Log configuration failure separately

Broken paths and wrong references deserve their own bucket.

missing SKILL.md
missing directory reference

That makes it obvious that the issue is wiring, not content.

Key Takeaways

Lesson	Detail
Do not mix categories	Execution success, delivery failure, discovery failure, and configuration failure should stay separate
Write only facts	Keep the log grounded in what you actually saw
Faster follow-up	Clear buckets make the next investigation much faster

What changed after our IVR started pulling data from the CRM

Jack Morris — Thu, 16 Apr 2026 14:30:33 +0000

Last year we rebuilt the IVR for a mid-size financial services company. Around 2,500 inbound calls a day, mix of existing customers and new leads, five departments handling everything from account inquiries to collections.

The original IVR had been running for three years. It worked. Calls got answered, menus got navigated, people eventually reached a human. Nobody was complaining loudly enough for it to become a priority.

Then someone pulled the actual numbers, and the picture wasn't great.

How the old IVR worked

Every caller got the same experience regardless of who they were. You'd hear a welcome message, sit through five menu options, pick one, and wait in a queue. If you picked wrong, you'd get transferred and wait again.

Agents had zero context when the call connected. The first 20-30 seconds of every call was spent on "can I get your name and account number?" Even for callers who'd been customers for years. Even for someone who called yesterday about the same issue.

The IVR had no idea who was calling. It couldn't. It was a standalone system with no connection to anything else in the business.

Here's what the numbers looked like:

Average handle time per call was around 4 minutes 40 seconds
Roughly 35-40 seconds of that was just identification and account lookup at the start
Call abandonment rate sat around 12%, mostly people dropping off during menu navigation or hold queues
Overdue accounts were going through the full standard menu before reaching collections. Some of them never got there they'd pick the wrong option, land in general support, and get transferred. The transfer added another 2-3 minutes to those calls
New leads from marketing campaigns were treated identically to everyone else. No priority routing, no personalized greeting, no assignment to the rep who was running the campaign

The support team had gotten used to it. That's how phones work, right? Caller comes in, you ask who they are, you pull up the account. Standard stuff.
We thought there was a better way.

The core idea
The concept was straightforward. Before the IVR plays its first word, it checks the caller's phone number against the CRM. If there's a match, the system now knows who's calling, what their account status is, who their assigned rep is, and whether they have any open tickets.

That data changes everything about how the call gets handled.

Instead of a one-size-fits-all menu, the IVR can make routing decisions based on actual business context. An overdue account doesn't need to hear about sales promotions. A VIP customer shouldn't wait in the general queue. A brand new lead who filled out a web form five minutes ago should hear their own name and get connected to the right rep immediately.

The IVR stops being a dumb phone tree and starts acting like a front desk that actually recognizes people when they walk in.

What we built
We used Asterisk as the IVR platform with Kamailio handling SIP routing in front of it. The CRM was Salesforce. Between Asterisk and Salesforce, we set up a small caching service backed by Redis so the IVR wasn't hammering the Salesforce API on every single call.

When a call comes in, the IVR queries the cache layer with the caller's phone number. If there's a recent record, it comes back in about 30-50 milliseconds. If not, the cache layer queries Salesforce, stores the result, and returns it. Either way, the IVR has CRM data before the caller hears anything.

We normalized all phone numbers to E.164 format on both sides. This turned out to be a bigger deal than expected about 40% of initial "caller not found" results were just formatting mismatches between how Asterisk received the number and how Salesforce stored it. Same person, same number, different format. Easy fix once we found it, but it was the single biggest source of lookup failures early on.

The whole lookup-to-greeting path takes under 200 milliseconds. No dead air, no awkward pause before the welcome message.

The five routing paths
After the CRM lookup, every call falls into one of five buckets:
Overdue accounts skip the menu entirely. The system routes them straight to the collections queue. The agent's screen already shows the account details, outstanding balance, and payment history before they even pick up the call. No "can I get your account number," no transfers, no wasted time.

VIP customers get a personalized greeting using their name and connect directly to their assigned account manager. If that person is unavailable, they go to a priority queue with shorter wait times. They never hear the standard five-option menu.

Active regular accounts get the standard menu but with a difference. The agent already has their account pulled up when the call connects. That 30-40 second identification ritual at the start of every call just disappears.

New leads hear a different greeting. Something like "Hi [Name], thanks for reaching out to us." They get routed to the sales rep assigned to that lead in Salesforce. If the lead came from a specific campaign, the rep knows that too before answering.

Unknown callers - people whose number isn't in the CRM - get the original standard menu. Nothing changes for them. The system degrades gracefully instead of breaking.

What changed in the numbers

We measured everything we could over the first 90 days. Some of the improvements were expected, some caught us off guard.

Handle time dropped by about 18%: The biggest contributor was eliminating the account identification step at the start of calls. When the agent already has the account on screen, the conversation starts with the actual issue immediately. Across 2,500 daily calls, those saved seconds add up fast.

Call abandonment went from 12% down to around 7%: Two things drove this. First, eliminating the dead air gap that happened when API lookups were slow (we solved that with the caching layer). Second, callers who got routed directly to the right place didn't have to navigate menus and wait in the wrong queue before getting transferred.

Collections contact rate improved noticeably: Overdue accounts were actually reaching the collections team now instead of getting lost in the general menu. Before, some of those callers would pick "general inquiries," sit in a queue, explain their situation, get transferred to collections, and sit in another queue. A lot of them gave up halfway through. Direct routing removed that entire detour.

New lead response time got faster: Marketing was running paid campaigns that drove phone calls. Previously, those callers were treated like everyone else. Now they were recognized and connected to the right sales rep within seconds. The sales team said it made a real difference in conversion conversations when the rep could greet someone by name and reference the specific thing they'd inquired about.

Agent satisfaction, surprisingly: We didn't measure this formally, but the feedback was consistent. Agents said not having to ask "who am I speaking with" on every call made their job feel less repetitive. Having context before the conversation started let them focus on solving the problem rather than playing detective for the first minute.

The problems we didn't expect

It wasn't all smooth. A few things caught us off guard.

Multiple accounts tied to one phone number: More common than we anticipated, especially with business lines. A single number might be associated with three different accounts in Salesforce. We solved this by defaulting to the most recently active account and giving the caller a quick confirmation: "We found your account under [Company Name]. Press 1 if that's correct, press 2 to search by account number." Worked fine, but we hadn't planned for it initially.

Stale CRM data causing wrong routing: An account marked as "overdue" in Salesforce that had actually just made a payment would still get routed to collections until the CRM record updated and the cache expired. We shortened the cache duration for accounts with recent status changes and added a webhook listener that invalidated the cache when certain Salesforce fields were modified. Took some back and forth to get right.

Agents trusting the screen pop too much: Because the system was accurate 97% of the time, agents started skipping verbal verification entirely. Usually fine, but occasionally the caller was using someone else's phone. We added a soft verification prompt to the agent script for sensitive transactions (payments, account changes) even when the screen pop was populated.

What I'd tell someone considering this

If your IVR handles more than a few hundred calls a day and your business logic depends on who the caller is, the CRM integration is worth doing. The impact on handle time and routing accuracy alone probably justifies the build.

But don't call the CRM API directly from the IVR for every single call. It seems like the obvious approach, and it works in testing, but it won't survive production call volumes. Put a caching layer between them. You'll avoid latency spikes, rate limit issues, and token management headaches.

And spend time on phone number normalization before anything else. It's not glamorous work, but mismatched number formats will quietly tank your lookup accuracy. We lost about two weeks troubleshooting "caller not found" results that turned out to be nothing more than formatting inconsistencies.

The whole project from planning to production took about 6 weeks. If we did it again knowing what we know now, we could probably cut that to four.

I work with the VoIP engineering team at Hire VoIP Developer we build custom IVR Systems and telephony systems, and CRM integrations are a regular part of that work. If you've done something similar, especially with a CRM other than Salesforce, I'd be curious how you handled the data sync and caching side.

I Built an AI News Desk for My MMA Site. Here's What Actually Worked.

Paul N — Thu, 16 Apr 2026 14:29:01 +0000

My first prompt was: "You are a sports journalist. Write a 400-word article about this UFC event." A friend texted me "bro this reads like a bot wrote it." Three published pieces in. Fair.

The Stack

GidStats.com runs on a custom CMS with structured fight data across UFC, PFL, LFA, DWCS. The news pipeline sits on top of that. Playwright scrapes official promotion feeds, a webhook fires a Claude API call with relevant database stats as context, output lands in staging for review before anything goes live.

The Prompt

You need to specify what to avoid as precisely as what to produce. Mine has a 75-term banned-words list - "delve," "nuance," "tapestry" and everything else that screams AI. Explicit sentence structure instructions. Style references: ESPN MMA, The Athletic, Bloody Elbow.

Structured fighter data gets injected before the generation instruction. Records, finish rates, physical attributes. The model can't hallucinate stats it's already been given, and MMA fans will fact-check you.

Review

Early on I reviewed for accuracy. Wrong question. The right question is "would I actually read this MMA news?" I rebuilt the checklist around that: does the first sentence pull you into the second, does the fight analysis say something tactical rather than obvious.

What It Can't Do

Breaking news at speed - the pipeline isn't a 10-minute turnaround. Anything emotionally weighted: injuries, retirements. The model produces something flat where a human voice is the whole point.

What I'd Do Differently

Start with the voice problem, not the infrastructure. I spent two months on scraper architecture before solving what the output should sound like. Get one piece reading exactly right, reverse-engineer the prompt, then build the pipes. Also: inject structured data as context, always. Model memory is wrong often enough to matter.

ElastiCache Pricing Breakdown: Where the Money Actually Goes

Rick Wise — Thu, 16 Apr 2026 14:29:01 +0000

ElastiCache looks straightforward on the bill. You pick a node type, maybe add a replica for high availability, and move on. Then the invoice arrives and the number is bigger than the mental math suggested.

The gap usually comes from one of five places: engine choice, replication topology, extended support surcharges, idle clusters, or oversized nodes nobody ever right-sized. Let's break down exactly how ElastiCache charges — and where teams get surprised.

Three Engines, Three Price Points

ElastiCache supports three engines: Valkey, Redis OSS, and Memcached. They don't cost the same.

Valkey is 20% cheaper than Redis OSS and Memcached for node-based clusters, and 33% cheaper on ElastiCache Serverless. This isn't a promotional rate — it's the permanent pricing structure AWS launched with Valkey.

For context, a cache.r7g.xlarge in us-east-1:

Engine	Hourly Rate	Monthly (730 hrs)
Valkey	$0.3496	~$255
Redis OSS	$0.437	~$319
Memcached	$0.437	~$319

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

That's a $64/month difference per node on a single instance type. Multiply that across a 12-node cluster and you're looking at $768/month — just from engine choice. If you're running Redis OSS and don't need Redis-specific features that Valkey doesn't support, the migration saves real money.

Node-Based Pricing: You Pay Whether the Cache Is Hit or Not

ElastiCache charges per node-hour from the moment a node is launched until it's terminated. Partial hours are billed as full hours. There is no scale-to-zero.

A few common node types and what they cost:

Node Type	Memory	Hourly Rate	Monthly (730 hrs)
cache.t3.micro	0.5 GiB	$0.017	~$12
cache.m5.large	6.38 GiB	$0.156	~$114
cache.r7g.xlarge	26.32 GiB	$0.437	~$319
cache.r6g.16xlarge	419.09 GiB	$5.254	~$3,835

Prices shown for Redis OSS / Memcached in us-east-1, On-Demand. Valkey is 20% lower.

The important thing to internalize: a cache.t3.micro sitting idle costs the same $12/month as one handling thousands of requests per second. The meter runs on time, not usage.

AWS recommends reserving 25% of a node's memory for non-data use (replication buffers, OS overhead, etc.), so the usable capacity of a cache.r7g.xlarge is roughly 19.74 GiB, not 26.32 GiB.

Replication Multiplies the Bill

Most production deployments use replication for high availability. With Redis OSS or Valkey, you configure a replication group with a primary node and one or more replica nodes per shard.

Every replica is a full node charged at the same hourly rate.

A three-shard cluster with one replica per shard using cache.r7g.xlarge (Valkey):

3 shards × 2 nodes per shard = 6 nodes
6 × $0.3496/hr = $2.10/hr → ~$1,531/month

Add a second replica for read scaling:

3 shards × 3 nodes per shard = 9 nodes
9 × $0.3496/hr = $3.15/hr → ~$2,297/month

Plus, multi-AZ replication generates cross-AZ data transfer at $0.01/GiB in each direction. For a high-throughput cache doing 100,000 requests/second with 500-byte objects, that's roughly 167 GiB/hour of traffic. If 50% crosses AZ boundaries, that's an extra $0.84/hour — about $613/month in data transfer alone.

Teams often enable multi-AZ replication on dev and staging environments where a single node would be fine.

Serverless: Simpler, But Not Always Cheaper

ElastiCache Serverless removes the node sizing decision entirely. You pay for two things:

Data stored — billed in GB-hours
ElastiCache Processing Units (ECPUs) — a unit combining vCPU time and data transferred

Dimension	Valkey	Redis OSS	Memcached
Data storage	$0.084/GB-hr	$0.125/GB-hr	$0.125/GB-hr
ECPUs	$0.0023/M	$0.0034/M	$0.0034/M
Minimum data stored	100 MB	1 GB	1 GB

Prices shown for us-east-1.

A simple GET or SET transferring under 1 KB consumes 1 ECPU. A command transferring 3.2 KB consumes 3.2 ECPUs. Commands that use more vCPU time (like SORT or ZADD) consume proportionally more.

Serverless can be cheaper for spiky workloads because you don't over-provision for peaks. But for stable, high-throughput workloads, node-based clusters are often significantly cheaper. AWS's own Example 2 shows a spiky workload costing $2.92/hour serverless vs. $5.66/hour on-demand nodes — but for steady traffic, the math can flip the other way.

The minimum charge matters too. A Serverless cache for Redis OSS or Memcached is metered for at least 1 GB of data stored — roughly $91/month minimum even if you're storing almost nothing. Valkey's 100 MB minimum brings that floor down to about $6/month.

Extended Support: The Surcharge Nobody Budgets For

When a Redis OSS or Memcached engine version reaches end-of-life, AWS continues providing security patches through Extended Support — at a steep premium.

Period	Surcharge
Year 1–2 after EOL	80% premium on node-hour rate
Year 3 after EOL	160% premium on node-hour rate

A cache.m5.large running Redis 5 (EOL January 31, 2026) at $0.156/hour becomes:

Year 1–2: $0.156 + ($0.156 × 80%) = $0.281/hour (~$205/month)
Year 3: $0.156 + ($0.156 × 160%) = $0.406/hour (~$296/month)

That's nearly triple the base cost by year three. Teams that don't track engine versions can drift into Extended Support without realizing their bill just jumped 80%.

Backup Storage and Data Transfer

Two cost categories that don't appear under the main "ElastiCache" line:

Backup storage: $0.085/GiB per month for all regions. No data transfer charges for creating or restoring backups. This is generally small unless you're snapshotting large clusters frequently.

Data transfer:

Path	Cost
Same AZ (EC2 ↔ ElastiCache)	Free
Cross-AZ (same Region)	$0.01/GiB each way
Cross-Region (Global Datastore)	$0.02/GiB

The cross-AZ charge is easy to miss because it shows up as EC2 data transfer on the bill, not ElastiCache. You're only charged for the EC2 side — there's no ElastiCache data transfer charge for traffic in or out of the node itself.

Data Tiering: The Cost Saver Most Teams Don't Know About

R6gd nodes combine memory and NVMe SSD, automatically moving least-frequently-accessed data to SSD. You get nearly 5× the total storage capacity compared to memory-only R6g nodes.

AWS's example: a 1 TiB dataset needs 1 cache.r6gd.16xlarge node ($9.98/hour) vs. 4 cache.r6g.16xlarge nodes ($21.01/hour) — a 52% cost reduction.

The trade-off: SSD-resident data has slightly higher latency on first access. If your workload regularly accesses less than 20% of the dataset, data tiering is worth evaluating.

Data tiering is not available with ElastiCache Serverless.

Reserved Nodes: Up to 55% Off

If your ElastiCache usage is stable, reserved nodes offer steep discounts:

Commitment	Discount vs. On-Demand
1-year, No Upfront	Up to 48.2%
1-year, Partial Upfront	Up to 52%
3-year, All Upfront	Up to 55%

Reserved nodes are size-flexible — you can apply the discount across different node sizes within the same family. If you buy a reservation for cache.r7g.xlarge, it can cover cache.r7g.large nodes proportionally.

One useful detail: Redis OSS reservations automatically apply to Valkey nodes in the same family and region. Since Valkey is 20% cheaper, you get 20% more value from existing reservations after migrating.

The Real Problem: Idle Caches

Here's what actually burns money: caches nobody is using.

ElastiCache has no scale-to-zero for node-based clusters. A cache with zero hits costs exactly the same as one handling millions of requests. This is the pattern we see most often:

A team provisions a cache for a microservice, then the service is deprecated
Dev/staging caches left running after the project ends
A "temporary" cache for a migration that became permanent infrastructure
A replicated cluster in non-production where a single node would suffice

A three-node cache.r7g.xlarge cluster running idle for a year at Valkey on-demand rates: $9,186 wasted.

Over-Provisioned Caches Are Nearly as Bad

Beyond idle caches, oversized nodes are the second biggest source of waste. Teams pick a large node type during initial setup, the workload stabilizes at a fraction of capacity, and nobody revisits the sizing.

A cache.r6g.xlarge running at 6% CPU with active connections is doing real work — but it's doing it on a node that's 3–4× larger than needed. Downsizing from cache.r6g.xlarge to cache.r6g.large can cut costs by 40–50% with no performance impact.

How to Spot the Waste

Check these CloudWatch metrics for each cluster:

CacheHits: Zero for 14+ days means nothing is reading from this cache
CurrConnections: Zero means nothing is even connecting
EngineCPUUtilization: Consistently under 10% with active connections means the node is oversized

Quick CLI inventory of all your ElastiCache clusters:

aws elasticache describe-cache-clusters \
  --show-cache-node-info \
  --query 'CacheClusters[*].{
    ClusterId:CacheClusterId,
    Engine:Engine,
    EngineVersion:EngineVersion,
    NodeType:CacheNodeType,
    NumNodes:NumCacheNodes,
    Status:CacheClusterStatus
  }' \
  --output table

If any of those clusters show an engine version approaching EOL, you're on the clock for an Extended Support surcharge.

CloudWise detects idle ElastiCache clusters by analyzing CloudWatch cache hit metrics over 14 days, flags oversized nodes running under 10% CPU, and alerts you when clusters are approaching or already incurring Extended Support surcharges. Three detectors, one scan.

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

The Most Wildfire-Prone Zip Codes in America — What USFS Data Shows

Metra — Thu, 16 Apr 2026 14:28:52 +0000

Climate change has made wildfire risk a major concern for homeowners across the western US. I pulled data from the US Forest Service and NIFC to build a risk lookup tool for every zip code in America.

The Highest-Risk Areas

Using USFS Wildfire Risk to Potential Structures data:

California dominates the high-risk list, but it's not alone:

Parts of Colorado (particularly the Front Range foothills)
Oregon and Washington (especially the eastern slopes)
Montana and Idaho (wildland-urban interface areas)
Arizona (Prescott, Flagstaff areas)
Texas (central hill country)

Why This Matters for Homeowners

Wildfire risk directly affects:

Home insurance premiums — some areas have seen 200-400% increases
Property values — high-risk areas are starting to see price adjustments
Insurability — some carriers are dropping coverage entirely in extreme-risk zones
Mitigation requirements — defensible space rules, fire-resistant materials

What the Data Shows

The tool I built combines:

USFS fireshed assessments — risk scores based on vegetation, terrain, and fire history
Historical fire data — from NIFC incident records
Community risk ratings — composite scores accounting for exposure and vulnerability

Each zip code page shows the risk level, contributing factors, nearby area comparisons, and what the score means for insurance.

Check Your Zip Code

Free at wildfire-risk.pages.dev — enter any US zip code to see the wildfire risk assessment. Data from USFS and NIFC.

Built with Astro and Cloudflare Pages as part of a series of free tools from government data.

Risk data from USFS Wildfire Risk to Potential Structures assessments. For official guidance, consult your local fire department and insurance provider.

Same Job, Different City: The Salary Gaps Are Bigger Than You Think

Metra — Thu, 16 Apr 2026 14:28:48 +0000

What if the same job pays twice as much just by crossing a state line? I pulled official Bureau of Labor Statistics salary data for 30 occupations across 20 major US cities to find out.

The Biggest Pay Gaps

Using BLS Occupational Employment and Wage Statistics (OEWS) data, here are some salary differences that stood out:

Software Developers:

San Francisco: $160,000+ median
Dallas: ~$110,000 median
Same job title, same skills, 45% pay difference

Registered Nurses:

California metros consistently pay $30,000-40,000 more than Southern cities
But California's cost of living eats most of that difference

Accountants:

New York: ~$95,000 median
Atlanta: ~$72,000 median
A 30% gap for the same certification

But Salary Alone Is Misleading

Raw salary numbers don't tell the whole story. That's why I built a take-home pay calculator that factors in:

Federal taxes (2026 brackets by filing status)
State income tax (0% in Texas/Florida vs 13%+ in California)
401(k) contributions (pre-tax deductions)
Cost of living context (rent as % of take-home pay)

A $160K salary in San Francisco with 13% state tax and $3,200/month rent leaves you with roughly the same disposable income as $110K in Dallas with 0% state tax and $1,700/month rent.

The Data

I used the BLS OEWS survey, which covers:

Median salary, 25th and 75th percentiles
Entry-level and senior salary estimates
Employment counts per metro area

The tool covers 600+ job-city combinations. Every page has the tax calculator so you can adjust for your personal situation.

Try It

Free at salary-by-city.pages.dev — search by job title or city. The take-home calculator adjusts for filing status, state tax, and 401(k). No signup needed.

All salary data from BLS OEWS May 2024 release. Tax calculations use estimated 2026 federal brackets.

ZeroID: Identity Infrastructure for Autonomous AI Agents

Kunal Kumar — Thu, 16 Apr 2026 14:28:34 +0000

Building Autonomous AI agents is getting easier
Knowing which agent did what, on whose authority, and with what permissions is still messy.

We’ve been working on ZeroID, an open-source identity layer for AI agents that gives every agent its own cryptographically verifiable identity, supports agent-to-agent delegation, and enables real-time revocation.

Why this matters for AI agent developers who want to run their autonomous agents in production:

No more shared service-account style access
Sub-agents get scoped, downscoped credentials
Every action can carry an auditable delegation chain
Better fit for MCP servers, tool-calling agents, and multi-agent workflows
Under the hood, ZeroID is built around OAuth 2.1, RFC 8693 token exchange, and WIMSE/SPIFFE-style identities.

If you’re building agentic systems and thinking about auth, delegation, trust, or audit-ability, do checkout:
Repo: https://github.com/highflame-ai/zeroid

We would love your feedback. If you like it, do consider starring us 🤗