DEV Community: Yuuki Yamashita

I Asked Claude Code Why AI Labs Suddenly Want to Slow AI Down

Yuuki Yamashita — Mon, 14 Sep 2026 01:38:18 +0000

The trigger

On September 12, 2026, three competitors, Anthropic, OpenAI, and xAI, all said roughly the same thing within hours of each other: AI development needs to slow down. Companies that fight over the same enterprise contracts and the same researchers do not usually agree on anything in public. So I opened Claude Code and asked it to walk through what was actually going on.

Round one: the nuclear weapons comparison

My first question was whether this looked like the nuclear non-proliferation playbook: the people who built the weapon are the ones who later argue loudest for controlling it.

Claude Code's answer split the comparison into what holds and what does not. What holds: the leading developer warning about the danger of what it built, and a first mover shaping the resulting regulation in a way that locks in its own position, is a real structural echo of the NPT era. What breaks down: nuclear proliferation has a physical bottleneck, uranium enrichment, that can be detected from orbit. AI capability spreads at the speed of compute and data, with no equivalent tripwire. Nuclear weapons are held specifically to never be used; frontier AI models are built specifically to be used, constantly, for profit. The incentive structures point in opposite directions.

Round two: fact-checking the essay itself

Rather than take the "slow down" framing at face value, I had Claude Code pull the actual source: Dario Amodei's essay "We Must Pace the Frontier." Worth doing, because most coverage ("AI CEOs want to slow AI down") undersells what he is actually proposing. He is explicit that pacing "does not mean halting model training." The real ask is third-party testing across four risk categories, permanent embedded evaluators inside Anthropic, and an antitrust carve-out so labs can coordinate on safety without violating competition law.

That last item is the one critics keyed in on. Chamath Palihapitiya's response on X: "Dario makes the case to stop open source and concentrate enormous technological and economic power with Anthropic." Whether or not you buy that read, it is a materially different claim than "Anthropic wants AI to be safer," and it is worth knowing both versions exist before writing a hot take.

Round three: the detail I almost missed

I asked Claude Code to check whether anything else happened around that week that might be relevant. It surfaced a threat intelligence report Anthropic had published two days earlier, on September 10: seven Chinese AI labs, including Moonshot AI (maker of the Kimi models), accused of large-scale distillation of Claude, GPT, Gemini, and Grok. The specific claim against Moonshot: roughly 300,000 requests routed to Claude over ten days through a network of over 5,000 fraudulent accounts, with Claude's answers served back to users labeled as Kimi's own. US intelligence agencies backed the concern.

Two days between that report and the "slow the frontier" essay is a short gap. Claude Code was careful not to claim a confirmed causal link, correctly, since none of the primary sources draw one. But it flagged the sequence as worth including, because both stories run on the same anxiety: capability spreading somewhere it should not.

Round four: the rumor that did not survive fact-checking

The same week, a rumor was circulating that Huawei's founder and his family had fled China. I asked Claude Code to fold that into the piece too. It refused to treat it as established, and pushed back before writing anything: the only source was a single screenshot posted to Chinese social media, the original poster had called it unverified, Huawei and Chinese authorities had not commented, and Chinese social media reaction skewed skeptical. It is in this piece as an unconfirmed rumor that circulated the same week, not as evidence of anything.

It would have been easy to let an interesting-sounding rumor slide into a paragraph about geopolitical pressure without that check. Separating what is verified from what is circulating on social media, before it goes into a draft, is the step that gets skipped most often when writing under deadline.

Takeaway

No single motive explains three competitors agreeing in public. Some of the fear about near-term AGI timelines is probably genuine. The specific regulatory ask looks a lot like regulatory capture. And the timing next to the distillation report suggests a geopolitical containment story running underneath the safety framing. All three can be true at once, which is a less satisfying headline than any one of them alone, but it is the one the primary sources actually support.

Sources: Dario Amodei, "We Must Pace the Frontier", Axios, Chamath Palihapitiya on X, CoinDesk on the Moonshot/Kimi distillation report. The Huawei rumor traces to a single unverified screenshot with no mainstream corroboration; see this Japanese-language writeup for the closest thing to a source trail.

I Tested Whether cdkd Really Deploys Faster Than cdk deploy

Yuuki Yamashita — Thu, 03 Sep 2026 15:58:25 +0000

A tool claiming "up to 15x faster than cdk deploy" showed up in my feed a while back. Drop-in replacement, it said: keep your CDK app exactly as it is, just swap cdk deploy for cdkd deploy.

I've learned to be skeptical of "Nx faster" claims. So I actually deployed something real to AWS with both tools and timed it. Short version: it really is that fast.

What cdkd actually is

cdkd deploys an existing AWS CDK app without going through CloudFormation. It calls the AWS SDK directly instead. It's built by go-to-k (Kenta Goto), an AWS DevTools Hero and CDK top contributor who also maintains cls3 (a fast S3 bucket emptier) and delstack (for cleaning up stuck CloudFormation/CDK stacks) — tools that quietly fix the annoying parts of working with AWS. cdkd feels like the biggest one yet, and I mean that as a compliment grounded in actually using it, not a throwaway one.

The mechanism is straightforward. cdkd runs the exact same CDK synth step as the CDK CLI, producing the same CloudFormation template. What changes is everything after that: instead of handing the template to CloudFormation, cdkd's own engine reads the resource dependency graph (Ref, Fn::GetAtt), builds a DAG, and fires AWS SDK / Cloud Control API calls directly, in parallel, as soon as each resource's dependencies are satisfied.

Worth saying up front: cdkd calls itself not production-ready, dev/test only. This isn't a "replace CloudFormation in prod" pitch.

I actually ran both, on real AWS

cdkd's own README backs up the 15x number with a VPC + Lambda + SQS + CloudFront benchmark. So I wrote that same stack as a CDK app and deployed it twice — DeployRaceCfn via cdk deploy, DeployRaceCdkd via cdkd deploy — to the same AWS account, same region (ap-northeast-1).

The stack:

VPC (2 AZ + NAT Gateway) with a Lambda inside it, fronted by a Function URL
CloudFront, origin set to that Function URL
SQS + EventSourceMapping + a consumer Lambda

First attempt failed. The account had hit its VPC limit (five, the default):

Resource handler returned message: "The maximum number of VPCs has been reached.
(Service: Ec2, Status Code: 400, ...)"

Other test stacks in the same account were sitting on VPCs I'd forgotten about. I tore down the cdkd stack (already measured, no longer needed) to free a slot and reran. cdkd writes a structured event log to S3 on every run (cdkd events), so even the failed attempt was easy to diagnose after the fact.

Timing compares the deploy phase only. Synth is identical work either way (same aws-cdk-lib), so I excluded it, matching how cdkd's own benchmarks are measured. The cdk deploy timeline comes from CloudFormation's DescribeStackEvents; the cdkd deploy timeline comes from cdkd events <stack> --run <id> --format json, reading the RESOURCE_STARTED / RESOURCE_SUCCEEDED events it records itself.

The numbers

	cdk deploy	cdkd deploy
Time	479.3s	95.0s
Resources created	34	33

5.0x. The one extra resource on the CloudFormation side is AWS::CDK::Metadata, a bookkeeping resource that only exists there — both sides build the same 33 real resources.

Watching cdkd deploy run, IAM roles and route tables land in a burst right at the start:

[1/33] ✓ RaceQueueE818AC65 (AWS::SQS::Queue) created
[2/33] ✓ RaceVpcIGW94C1C01D (AWS::EC2::InternetGateway) created
[3/33] ✓ RaceVpcPublicSubnet1EIPC3B3497E (AWS::EC2::EIP) created
[4/33] ✓ ConsumerFunctionServiceRole68E8FEB1 (AWS::IAM::Role) created
[5/33] ✓ MainFunctionServiceRole8C918DF0 (AWS::IAM::Role) created
...
CloudFront Distribution Distribution830FAC52 accepted (not waiting for Deployed; pass --full-wait to wait)
Deployment Summary:
  Created: 33 / Duration: 94.99s

Meanwhile cdk deploy takes 16.6 seconds just to get its first VPC. By that point cdkd already has the Lambda wired up to SQS.

Where the time actually goes

cdk deploy hands the template to CloudFormation, which creates resources one at a time. cdkd reads the same template's dependency graph itself and calls the AWS SDK / Cloud Control API directly, in parallel, as soon as dependencies clear. Cutting out the CloudFormation middleman is most of the story, but two specific waits explain most of the 384-second gap.

The NAT Gateway is the first one. cdk deploy works through the SQS/Lambda side of the graph before it gets around to waiting on the NAT Gateway to come up. cdkd hits that wait much earlier. Same AWS-side wait either way — what differs is how early in the run you eat it.

CloudFront is the bigger one. CloudFormation's default behavior waits until the distribution reaches Deployed — full global propagation, three-plus minutes. cdkd's default returns as soon as CreateDistribution is accepted (there's a --full-wait flag if you want CloudFormation's behavior instead). Of the 479.3 seconds cdk deploy took, 183 of them — over three minutes — are spent solely on that one wait.

This might actually change how people deploy

I'll admit it: the slowness of iterating on a real AWS resource is part of why people reach for Vercel or Amplify instead. Build a VPC + Lambda + CloudFront stack in CDK and every check-your-work loop costs minutes, sometimes double digits of them.

cdkd doesn't replace CloudFormation's state management, drift detection, or rollback handling, and it says so itself. But "CloudFormation in prod, cdkd while iterating" is now a real option, not a hypothetical. A CI pipeline that rebuilds a PR environment on every push, or just the apply-then-check loop on your own machine, running five times faster is enough to make "AWS-native is slower to iterate on than Vercel or Amplify" stop being true for a chunk of use cases.

I also built an interactive replay of the actual measured timeline, plus a narrated demo video, if you want to see the two runs side by side.

cdkd is go-to-k/cdkd (Apache-2.0). Worth a star if this was useful.

Detecting Shadow AI Agents with AWS Agent Registry

Yuuki Yamashita — Tue, 01 Sep 2026 02:56:07 +0000

AWS Agent Registry (GA August 2026) gives a team a private catalog for AI agents, MCP servers, and tools — semantic search, approval workflows, CloudTrail audit trails. What it doesn't give you out of the box is a way to find the agents that were never registered in the first place.

This is a pattern for closing that gap: scan the AWS account for AgentCore runtimes, diff them against what's actually in the registry, and route anything unregistered through a real approval flow before it becomes a permanent record. I built it as Shadow Agent Hunter; this post is about the Agent Registry API details that made it work (and the ones that didn't, at first).

The three API calls that matter

Agent Registry splits into a control plane (agent-registry-control) for managing registries and records, and a data plane (agent-registry) for searching approved ones.

Finding what's already registered. list_registry_records returns every record regardless of status, so pending/draft records don't get re-flagged on a rescan either:

import boto3

control = boto3.client("agent-registry-control", region_name="us-east-1")
registered_names = set()
next_token = None

while True:
    kwargs = {"registryId": registry_id}
    if next_token:
        kwargs["nextToken"] = next_token
    resp = control.list_registry_records(**kwargs)
    registered_names.update(r["name"] for r in resp["registryRecords"])
    next_token = resp.get("nextToken")
    if not next_token:
        break

I originally reached for the provenance field here, expecting to link records back to their source AgentCore runtime ARN. Don't — create_registry_record rejects a caller-supplied provenance with ValidationException: provenance cannot be set by the caller. It's populated only by the service's own auto-detection/sync integrations, not by a plain API call. Matching on record name is simpler anyway, since names are unique within a registry.

Searching for duplicates. search_discoverable_registry_records does hybrid semantic + keyword search, ordered by relevance:

registry = boto3.client("agent-registry", region_name="us-east-1")
resp = registry.search_discoverable_registry_records(
    searchQuery=f"{runtime_name} {runtime_description}",
    registryIds=[registry_arn],
    maxResults=3,
)

There's no numeric score in the response — just an ordered list. With a small registry (say, two or three approved records), that means it always returns something, even for genuinely unrelated runtimes, because there's nothing better to rank against. This isn't a bug so much as a reminder that semantic search needs a reasonably sized corpus to actually discriminate. It's also a decent argument for keeping a human in the approval loop rather than auto-rejecting on any hit.

Writing the approval. Three sequential calls: create, submit, approve.

created = control.create_registry_record(
    registryId=registry_id,
    name=runtime_name,
    description=description,
    recordType="CUSTOM",
    recordVersion="1.0",
    descriptors={"custom": {"data": json.dumps({"runtimeArn": runtime_arn})}},
)
record_id = created["recordArn"].split("/record/")[1]  # not returned directly

# record starts CREATING and must reach DRAFT before you can submit it
for _ in range(15):
    status = control.get_registry_record(registryId=registry_id, recordId=record_id)["status"]
    if status == "DRAFT":
        break
    time.sleep(1)

control.submit_registry_record_for_approval(registryId=registry_id, recordId=record_id)
control.update_registry_record_status(
    registryId=registry_id, recordId=record_id,
    status="APPROVED", statusReason="Reviewed and approved",
)

Two things worth flagging: CreateRegistryRecordResponse only returns recordArn and status — no recordId field, so you extract it from the ARN — and creation is asynchronous, so a record submitted for approval before it leaves CREATING will fail.

Cross-referencing with AgentCore Runtime and CloudTrail

The other half of "shadow agent" detection is enumerating what's actually running, independent of the registry:

agentcore = boto3.client("bedrock-agentcore-control", region_name="us-east-1")
runtimes = agentcore.list_agent_runtimes()["agentRuntimes"]

The IAM action for this is bedrock-agentcore:ListAgentRuntimes — note the namespace is bedrock-agentcore, not bedrock-agentcore-control like the SDK package name would suggest. Getting this wrong produces a plain AccessDeniedException with no hint about the namespace mismatch.

For attribution — who deployed an unregistered runtime — CloudTrail's LookupEvents over CreateAgentRuntime gets you there, with the usual 90-day retention caveat:

cloudtrail = boto3.client("cloudtrail", region_name="us-east-1")
resp = cloudtrail.lookup_events(
    LookupAttributes=[{"AttributeKey": "EventName", "AttributeValue": "CreateAgentRuntime"}],
)
for event in resp["Events"]:
    detail = json.loads(event["CloudTrailEvent"])
    arn = detail.get("responseElements", {}).get("agentRuntimeArn")
    deployer = detail.get("userIdentity", {}).get("arn")

Infra notes

Agent Registry has no CDK construct as of September 2026 — no AWS::AgentRegistry::Registry CloudFormation resource type exists yet. I provisioned the registry and its seed records with the boto3 script above rather than CDK. AgentCore Runtime, by contrast, has a stable L2 construct (aws_bedrockagentcore.Runtime), and AgentRuntimeArtifact.fromCodeAsset() deploys straight from a local Python directory with no Docker step.

If you're running this on Vercel with OIDC federation to AWS: the OIDC provider is scoped per Vercel team, not per project. A second project under the same team hitting new iam.OpenIdConnectProvider(...) will fail deployment, since an AWS account only accepts one provider per issuer URL. Import the existing one with iam.OpenIdConnectProvider.fromOpenIdConnectProviderArn() instead of creating a second.

Result

Scanning an account with a couple of intentionally-similar and intentionally-unrelated AgentCore runtimes: the similar one surfaces a real "possible duplicate" match against an existing approved record, and approving the unrelated one produces a genuine APPROVED record you can see with list-registry-records afterward — not a mock, the actual governance workflow AWS Agent Registry ships.

The Legal Wall I Hit Building a YouTube Clone on AWS

Yuuki Yamashita — Wed, 26 Aug 2026 16:31:29 +0000

Right now I'm testing how far you can push a YouTube-style video platform built entirely on AWS. Upload, transcode, stream — EC2, S3, and CloudFront handle all of that without much drama. Then I started sketching out a comment section and a direct-message feature between users, and I stopped typing.

Wait. Does this need a government license now?

That one question sent me down a rabbit hole through Japan's Telecommunications Business Act, Copyright Act, and a law with an even longer name that regulates online platforms. None of this is legal advice — I'm not a lawyer, just a developer who got nervous enough to read the actual statutes. If you're building something for real users at scale, talk to an actual lawyer. But if you're a solo developer wondering whether your side project is quietly illegal, this is the walkthrough I wish existed.

Japan's Telecommunications Business Act: the "are you a phone company" test

Japan has a law called the Telecommunications Business Act (電気通信事業法). In the simplest possible terms: it's the law that decides whether your app is legally acting like a phone company, and if so, whether you need to tell the government about it.

There are two tracks. Article 9 requires full registration, and it only kicks in if you own and operate your own transmission lines — think an actual telecom carrier laying fiber. Article 16 requires a lighter-weight notification, and it applies to almost everyone else who runs a communications service without owning that physical infrastructure. Since your app sits on AWS rather than your own fiber network, Article 16 (notification) is the one that could apply to you, not Article 9.

Whether it actually applies comes down to one test: are you mediating communication between other people? A one-way video stream — you upload, others watch — is your own communication going out to viewers. It's not you relaying messages between two other people, so it generally falls outside the notification requirement. Add a DM feature, a live chat relay, or real-time comment broadcasting between users, though, and you start looking a lot more like a company that carries other people's messages, which is exactly what the law is watching for.

If you're the only one who can upload, you're basically fine

Here's the scorecard for a video app where you're the only content creator — think a personal portfolio site that happens to look like YouTube.

Telecommunications Business Act notification isn't required, because you're not relaying anyone else's communication. The Information Distribution Platform Act (more on that below) doesn't apply either, since there's no user-generated content for anyone to complain about. Japan's Act on the Protection of Personal Information technically applies the moment you add user accounts or store watch history, but for a small non-commercial project, a basic privacy policy covers you in practice.

If this describes your project, you can build it, ship it, and move on — the same way you'd treat any other side project.

The moment strangers can upload, the rulebook gets thicker

Turn on user uploads for everyone, and you've built a real user-generated-content platform. That changes things.

The Telecommunications Business Act question gets murkier once you add DMs or chat, but realistically, the enforcement risk for a small side project is close to zero — call it a legal gray zone rather than a hard stop.

The law that actually matters here is Japan's Information Distribution Platform Act (情報流通プラットフォーム対処法), which took effect on April 1, 2025. It's the successor to what used to be called the Provider Liability Limitation Act, and at its core it requires any platform hosting user content to have a way for people to report defamatory or copyright-infringing material and get it taken down. If you're running a UGC service, you need this regardless of size — but in practice, for a solo project, that requirement is satisfiable with a single email address people can send takedown requests to.

The obligations scale up hard once you're huge. If your platform averages more than 10 million senders a month, or 20 million total, the government designates you a "large-scale specified telecommunications service provider" and you owe additional obligations like publishing your takedown response record. As of April 2025, the companies actually carrying that designation are Google, LY Corporation (LINE Yahoo), Meta, and TikTok. A solo developer isn't getting anywhere near that threshold, which is why the lightweight version — one inbox, checked occasionally — is a realistic bar to clear.

There's also a quieter risk: if your platform lets anyone upload anything, someone eventually will upload something they don't own the rights to. If your code is open source on GitHub, that's a separate reputational problem worth thinking about even before the legal one.

The real trap was copyright law

After all that, the thing that actually surprised me wasn't the telecom law or the platform law. It was copyright.

Japan's Copyright Act defines "the public" in a way that's broader than it sounds. Article 2, paragraph 5 states that "the public," for purposes of this law, includes "specific and numerous persons" — not just strangers off the street. In plain English: even if everyone who can see your content is someone you personally know and approved individually, if that group gets large enough, the law can treat it the same as posting it publicly. There's no hard headcount in the statute, but the widely cited rule of thumb among Japanese IP lawyers is that once you're past roughly 50 people, you're squarely in "many" territory, and past legal disputes have used numbers like 300+ as clearly qualifying.

Then there's Article 23, covering the public transmission right. For anything automatically deliverable over a network — which covers basically all web and app content — this right also covers something Japanese law calls "making transmittable" (送信可能化). That means the right is triggered the moment content becomes available for someone to access, whether or not anyone has actually clicked play yet. "Nobody's actually watched it, so I'm fine" doesn't hold up as a legal argument under this framework.

The counterweight is Article 30, the private-use exception. Using copyrighted material within a genuinely private circle — yourself, your family, people you live with — is exempt. Courts have described the boundary as "an extremely limited circle of personal relationships." A 2022 Supreme Court case involving JASRAC (Japan's music licensing body) and music schools is a good real-world illustration: the court found that a teacher performing music for students, one at a time, still counted as a "public" performance, because the audience rotated through an effectively unlimited stream of students over time. The lesson generalizes: an audience made of individually-approved people can still add up to "public" if it's large enough or churns enough.

Passwords don't automatically make something private

I went into this assuming that if I gated content behind a login and personally approved every viewer, I was safely inside the private-use exception. That turned out to be only half true.

What decides the boundary isn't whether there's a password. It's who's on the other side of it, and how many of them there are. Family and people you live with land solidly inside the private-use exception — courts have consistently protected that "extremely limited circle." Once you're individually approving friends and acquaintances, the calculus shifts: the more people you add, and the less close the relationship, the more likely a court would call that group "specific and numerous" rather than private, regardless of whether you technically required a password to get in. A login screen controls access technically. It says nothing about whether the underlying use is legally private.

The uncomfortable implication is that "approve anyone who asks" as a growth strategy — the design pattern, not any specific headcount — reads legally closer to "public" than "private," because the pool has no real ceiling.

One important caveat, since a reader flagged this after the Japanese version of this post went semi-viral on X: all of this only matters if the content isn't fully yours to begin with. If you personally shot, wrote, and own every frame of what you're distributing, the public-transmission and private-use analysis above is close to irrelevant — copyright belongs to the creator, and you're free to distribute your own original work to as many people as you want. Where this actually bites is content that includes someone else's copyrighted material without permission: a recording that happens to pick up background music, a clip of broadcast TV, a screen recording that captures someone else's copyrighted app or footage. The moment third-party material is baked into what you're distributing, the "how many people, how close are you to them" analysis above is what determines your exposure.

Add payments or age gates, and yet more laws show up

Everything above covers just the core of a video platform. Add features, and you pick up more regulatory surface.

The moment you're storing watch history or account data, Japan's Act on the Protection of Personal Information kicks in — a privacy policy that states your purpose of use is the baseline expectation. If minors might realistically use your service, the Act on Development of an Environment that Provides Safe and Secure Internet Use for Young People brings in expectations around age verification and filtering. And if you add tipping, subscriptions, or ad revenue sharing — anything that moves money — the Payment Services Act and the Act on Specified Commercial Transactions apply separately.

For a personal, non-commercial project, this tier is "know it exists, revisit it if you add the feature" rather than something to solve up front.

So what does a solo developer actually need to do

The pattern that emerged after all this reading: the real dividing line isn't "can other people upload," it's "is this actually public." A fully private deployment — access-controlled, URL not shared anywhere — falls inside the private-use exception with real room to spare. Even if a video you personally recorded happens to capture copyrighted material in the background, keeping it to private viewing is generally fine.

The moment you deploy publicly, or post the URL on a blog where anyone can find it, you've crossed into public transmission, and the private-use exception no longer covers you — even if you're the only person who ever uploaded anything, placing unlicensed third-party material there can be infringing.

Three things made this manageable for a solo project. First, keep access genuinely locked down — authentication plus a URL you don't publish — if you want to stay inside the private-use exception. Second, for anything you do deploy publicly or show in a GitHub README, use only material you made yourself or that's explicitly license-free; no copyrighted broadcast footage, no commercial music tracks. Third, add a line to your README or terms of service stating the app is intended for the creator's personal use and isn't designed for uploading third-party copyrighted material — it won't prevent a determined bad actor, but it's a reasonable statement of intent if the question ever comes up.

Building something like automated audio fingerprinting to detect infringing uploads is overkill for a single-user, access-controlled personal project. Locking down access and being deliberate about demo content covers the realistic risk at this scale.

Closing thought

I genuinely expected video streaming to be a solved, boring technical problem by now. I did not expect to spend this much time in statute text. The good news is that a personal, single-user version of this project needs essentially no legal paperwork. The part that actually changed my mental model was realizing that "I put a password on it" doesn't automatically mean "this is private" under Japanese copyright law — that one took a re-read to sink in.

Still testing how far this goes on AWS. More to come if there's more to find.

Autonomy for $20, a Human Above It: A Pattern for AI Agents That Spend Money

Yuuki Yamashita — Wed, 26 Aug 2026 08:27:21 +0000

At some point every "agentic" product roadmap runs into the same uncomfortable question: what happens when the agent needs to actually spend money, not just recommend an action to a human who then clicks a button? Recommending is easy to sandbox. Spending isn't. And the usual answers — "just require approval for everything" or "just trust the agent" — both fail in an obvious way. Approve-everything means the agent isn't really autonomous, it's a slow suggestion box. Trust-the-agent means the first bad prompt injection or hallucinated tool call has a direct line to your bank balance.

I wanted to see what a middle position actually looks like in code, not in a slide. So I built a small agent, sera-gate-agent, that pays multi-currency invoices for you and enforces a rule most people would agree with intuitively: small payments go through on their own, larger ones stop and wait for a person.

The trigger: a protocol that treats a keypair as a login

The settlement side runs on Sera, an on-chain FX protocol with an MCP server (sera-mcp) released under MIT specifically so agents can call it. What made me want to build on it wasn't the currency coverage, it was the auth model: there's no signup form. You generate a keypair, sign an EIP-712 message with it, and that signature is your API key request. A human finds this mildly inconvenient. An agent finds it exactly as convenient as an auth flow can be — no page to navigate, no CAPTCHA, no session cookie, just a key it already has.

That detail is what made "give the agent a wallet" feel like a natural next step rather than a stunt. If the whole point of an agent is that it acts without a human driving each click, an auth system built around clicking a human through steps is already fighting the premise.

The design: one number, one gated function

The rule I wanted was simple enough to say in one sentence: under $20, the agent executes on its own; over $20, it issues an approval card and a human has to click "approve" in a browser before anything moves. The part that took actual thought wasn't the rule, it was making sure the rule couldn't be talked around.

The threshold check itself is almost embarrassingly small:

def decide_auto_or_approval(amount_usd):
    threshold = Decimal(os.environ.get("SERA_GATE_AUTO_THRESHOLD_USD", "20"))
    return "AUTO" if amount_usd <= threshold else "REQUIRE_APPROVAL"

What matters more is where it's called from. The underlying protocol exposes tools that actually move funds — execute a swap, send a transfer, pay an invoice directly. None of those are given to the language model. The only thing the model can call is a wrapper function, and that wrapper is the only code path that's allowed to reach the real execution tools. The threshold check lives inside that wrapper, not in a prompt instruction telling the model to "please ask before spending more than $20."

That distinction is the whole point, and it's easy to gloss over. A system prompt is a request. A model that's very good at following instructions will follow it correctly almost all the time — but "almost all the time" is a bad security property for something that moves money, whether the failure mode is prompt injection, a weird edge case in tool output, or the model just deciding the instruction doesn't apply this time. Removing the tool from the model's reachable set removes the failure mode instead of making it rarer.

I also didn't want the agent-side threshold to be the only backstop. Sera has its own server-side policy preset that caps what any single API key can move per transaction and per day, independent of anything my code does. I keep that ceiling well above my $20 agent-side threshold, so it's a true second layer rather than a duplicate of the first — if my code has a bug, or the signing key leaks, there's still a hard ceiling that doesn't route through my logic at all.

What this generalizes to

None of this is specific to on-chain payments. The same shape applies to an agent that can issue refunds, send emails to customers, delete records, or push a deploy: pick a dimension the org already has intuitions about (dollar amount, blast radius, reversibility), pick a threshold, and make the boundary a property of which functions are reachable rather than a property of what the model has been told. The dollar threshold is just the easiest one to make legible in a demo, because everyone already has an intuition for what $20 versus $5,000 means.

The uncomfortable part, and I don't think there's a clean answer to it, is that the threshold is still a judgment call, and it's a judgment call about how much you trust a system that doesn't get tired, doesn't get talked into things the way a person does, but also doesn't have the context a person has for "this specific invoice looks off." Setting it too low turns the agent back into a suggestion box. Setting it too high means the day it's wrong, it's wrong at a scale a human never got the chance to catch. I don't think that number should be static — the next version of this probably ties it to something like payee history or a running risk score instead of a flat constant — but getting the enforcement boundary right, structurally, felt like the part worth building first.

sera-gate-agent runs on Sepolia testnet today, built on AWS Bedrock AgentCore Runtime and Strands, with a Next.js front end for the approval cards a human actually clicks through.

Amazon Leo vs Starlink: The 2026 Satellite Internet Race

Yuuki Yamashita — Thu, 20 Aug 2026 18:09:22 +0000

Project Kuiper quietly became Amazon Leo in November 2025. Enterprise beta opened on April 8, 2026. So the natural question: how close is Amazon actually getting to Starlink?

Short answer: not close at all. And Amazon just missed a federal deadline in the process.

The numbers, side by side

Metric	Amazon Leo	Starlink
Satellites in orbit	~345-400 (Aug 2026)	~10,020 (Apr 2026)
Subscribers	Not yet public (enterprise beta only)	10M+
Countries served	5 targeted for mid/late 2026 launch	150+
Consumer pricing	Not yet announced	$50-120/mo (Residential)
Standard hardware	Not yet announced (aiming smaller/cheaper)	$499 ($199 for Mini)
Launch method	Atlas V / Falcon 9 / Ariane 6 (outsourced)	Falcon 9 (in-house, reusable)
FCC status	Missed the 50% deployment target, waiver carries a spectrum-priority penalty	N/A

The snapshot dates don't line up exactly (Starlink's count is from April, Amazon Leo's from August), but the order of magnitude tells the story either way.

The satellite count isn't even in the same order of magnitude

As of April 2026, Starlink had 10,020 satellites in orbit versus 241 for Amazon Leo. By August 2026 Amazon Leo had climbed to roughly 345-400 satellites after a string of launches. Starlink is still ahead by more than 20x.

Subscriber numbers tell the same story. Starlink serves over 10 million subscribers across 150+ countries. Amazon Leo isn't selling to consumers yet — it's still in enterprise beta, with residential service targeted for mid-2026 in five countries: the US, Canada, the UK, France, and Germany.

Amazon actually missed its FCC deadline

This is the part that surprised me most.

Amazon's FCC authorization for its 3,236-satellite constellation came with a condition: launch 50% (1,616 satellites) by July 30, 2026, or risk losing priority status. Actual count at the deadline: 331 satellites — about 20% of target.

The FCC granted a waiver, but not for free. Under the terms of the extension, any Gen1 satellite launched after July 30 temporarily loses the spectrum priority status Amazon earned in earlier FCC processing rounds, until March 30, 2028, or until it hits the 50% mark, whichever comes first. In a business where orbital slots and spectrum priority are genuinely scarce, that's a real cost, not just a paperwork inconvenience.

Why the gap exists: nobody owns Amazon's rocket

SpaceX runs Starlink and also builds the rocket that launches it. Falcon 9 is reusable, flies constantly, and SpaceX controls its own launch cadence end to end. That vertical integration is the actual root of Starlink's lead.

Amazon Leo has no equivalent. It buys launches from Atlas V, Falcon 9, and Ariane 6, and depends on other companies' schedules. Vulcan Centaur and Blue Origin's New Glenn are coming online too — Blue Origin being Bezos-founded but organizationally separate from Amazon — with a target of 20+ missions in 2026 and 30+ in 2027. Still nowhere near Starlink's cadence.

Where Amazon Leo could still win

The one card Starlink genuinely can't match: native AWS integration. A company already running workloads on AWS can get satellite backhaul into its own AWS region as part of one coherent stack. Starlink has no cloud platform to offer alongside it.

The engineering also reflects a later start. Amazon Leo uses optical inter-satellite links and a custom baseband chip called Prometheus, and flies at a lower inclination (30-51°) that concentrates coverage on populated mid-latitudes rather than the wider polar coverage Starlink offers.

Starlink, for reference

Pricing as of 2026: Residential $50-120/mo, Roam $50-165/mo, Mini $30/mo plus $199 hardware, Business from $250/mo. Standard hardware holds steady at $499.

The more interesting move is T-Satellite, Starlink's direct-to-cell partnership with T-Mobile: $10/month, free on higher-tier plans, works across 60+ phone models regardless of carrier. No military or first-responder discount currently exists on the core service.

Bottom line

On raw numbers, this isn't a race yet — it's a head start plus a company still finding its footing. Amazon has committed more than $10 billion to closing the gap, and the AWS integration angle is real. Whether it matters depends entirely on whether Amazon Leo can fix its launch cadence before the spectrum penalty clock runs out in March 2028.

Sources

I Rebuilt YouTube on AWS Alone (and Hit Every Wall)

Yuuki Yamashita — Tue, 18 Aug 2026 15:54:36 +0000

It started as a simple question: how is YouTube actually built? One thing led to another, and a few hours later I had a single-user, self-hosted video platform running in production on AWS — after redesigning the auth layer from scratch mid-build, chasing down an "exec format error," and discovering that avoiding a NAT Gateway didn't actually save me any money. Here's the whole story, including the parts that didn't work the first time.

What YouTube is actually made of

Before writing any code, I wanted to understand what I was copying. Roughly:

Upload and transcoding: uploaded video gets converted into 144p through 4K/8K across multiple codecs, processed by a huge fleet of parallel workers
CDN: Google Global Cache — dedicated caching nodes placed directly inside ISP networks — plus adaptive bitrate streaming
Metadata: Vitess (a sharding layer over MySQL) and Bigtable/Spanner
Recommendations: a two-stage candidate generation + ranking ML system
Content ID: audio/video fingerprinting to detect copyright infringement
Ads: backed by Google Ad Manager

Can AWS alone reproduce it?

Most of the functional skeleton maps cleanly onto managed AWS services: S3 for upload, MediaConvert for transcoding, CloudFront for delivery, DynamoDB for metadata, OpenSearch for search, Personalize for recommendations. That part is genuinely achievable.

A few pieces aren't:

Content ID has no AWS-managed equivalent. You'd need a third-party SaaS like Audible Magic or ACRCloud, or roll your own fingerprinting with something like Chromaprint against a reference database you'd also have to build
ISP-embedded caching — CloudFront has a global edge network, but nothing at the density of nodes sitting inside individual ISPs
Ad auctions at Google Ad Manager's scale aren't something you build yourself; you'd hand this off to an existing ad network

For a personal project, I decided not to build Content ID or ad serving at all. That decision turned out to be tied directly to a legal question I hadn't expected to spend time on.

The legal research I didn't expect to do

Building a video-sharing app in Japan, even a personal one, touches a surprising number of regulations, so I checked before writing any infrastructure code.

First, the Telecommunications Business Act. One-way video distribution generally doesn't require registration, since you're not "mediating someone else's communication." Add a comment section or DMs between users, though, and that changes.

Second, the Act on the Limitation of Liability for Damages of Specified Telecommunications Service Providers (Japan's provider-liability law, recently renamed to something closer to "platform accountability act"). Any platform accepting user-generated content is expected to run a takedown-request contact point; cross a large-user threshold (10M+ monthly users in Japan) and heavier obligations kick in.

Third — and this is the one that actually shaped the design — Article 30 of the Copyright Act, the private-use reproduction exception. Keep something fully private, accessible only to yourself, and it falls under private use. Make it public and it becomes "transmission to the public" (公衆送信), where that exception no longer applies. I also checked whether gating access behind a login would be enough to stay private if I let a few people in. It isn't automatically: under Japanese copyright law, "the public" includes "a specific but numerous group," so the real question isn't whether there's a login screen, it's how many people, and how close a relationship. Family-sized is safe; a wider circle of friends risks crossing into "specific but numerous."

Given all that, I decided the app would support exactly one user — me. No sign-up, no invite flow. That sidesteps the Telecommunications Business Act and the platform-liability law entirely, and keeps everything inside the private-use exception.

The plan

Single user only, no sign-up
AWS only (I use Vercel for most other projects, but not this one)
No Content ID, no ad serving
Upload → S3 → MediaConvert (transcode to HLS) → CloudFront
Web UI on ECS Fargate + ALB + CloudFront (App Runner was already off the table — AWS stopped accepting new App Runner services)

I wrote the CDK for VPC, S3, DynamoDB, a Lambda to kick off MediaConvert jobs, ECS, CloudFront, and Cognito. So far, so normal.

Cognito's ALB integration needs HTTPS, and I didn't have a domain

My first pass at auth used the ALB's native authenticate-cognito listener action — no app code needed, ALB handles the redirect to Cognito's hosted UI for you. Clean, until deploy:

Resource handler returned message: "Actions of type 'authenticate-cognito' are supported only on HTTPS listeners"

That action only works on HTTPS listeners, which means an ACM certificate, which means a real, DNS-verifiable domain — something this project didn't have. Buying a domain just for this felt like the wrong trade, so I moved authentication into the app itself instead, using Next.js's proxy.ts.

Moving auth to the app ran straight into "no NAT Gateway"

I reconfigured the Cognito App Client as a public client (no secret) and switched to PKCE for the authorization code exchange, so the browser could talk to Cognito directly instead of routing through the ALB's constraints.

Redeployed, logged in, and got a 500 on the callback:

⨯ [TypeError: fetch failed] {

      at ignore-listed frames {
    code: 'ETIMEDOUT',

The ECS task had no path to the internet. To keep costs down I'd built the VPC with interface endpoints instead of a NAT Gateway — but there's no VPC endpoint for Cognito's Hosted UI/OAuth domain (*.auth.<region>.amazoncognito.com). The container simply couldn't reach it.

The fix was to move the token exchange itself into the browser. The only thing that actually needs to happen server-side is JWT verification (fetching the JWKS), which is covered by the cognito-idp VPC endpoint. The browser already has internet access, so it can talk to Cognito's token endpoint directly. That change got login working without ever adding a NAT Gateway.

Forgot to pin the CPU architecture, container wouldn't start

Redeployed again, and this time the ECS task crash-looped indefinitely. CloudWatch Logs had exactly one line to offer:

exec /usr/local/bin/docker-entrypoint.sh: exec format error

Building the Docker image on an Apple Silicon Mac produces an arm64 image. Fargate defaults to x86_64. Nothing about the mismatch surfaces until the container tries to actually execute. Setting runtimePlatform to ARM64 on the FargateTaskDefinition fixed it. I also turned on the ECS deployment circuit breaker at the same time — without it, a failing deployment can take up to three hours to be reported as failed, and I'd already lost about 40 minutes not noticing.

The health check was hitting the login redirect

Next failure: the ALB health check was pointed at /, which — like every other route — goes through the app's auth gate. An unauthenticated health check gets a 302, the ALB reads that as unhealthy, and the deployment fails outright. Added a dedicated /api/health route that skips the auth check, and that was that.

Video played, but the manifest path was broken

Deployment finally succeeded, upload worked, MediaConvert finished the job — and the video was just a black rectangle.

The cause: MediaConvert's completion event returns outputGroupDetails.playlistFilePaths as a full s3://bucket/key URI, not a bucket-relative key. I'd been storing that value directly as manifestKey, so the app's /${manifestKey} template produced a broken /s3://bucket/... path. Since I already control the output prefix at job-creation time, I switched to deriving the key deterministically instead of trusting the event payload. Don't take an AWS event field at face value if you can compute the same thing yourself.

CloudFront's signed cookies ignored my wildcard

To lock down /renditions/* (the actual video files) behind CloudFront's Key Group, I used @aws-sdk/cloudfront-signer's getSignedCookies with a url + dateLessThan — the "canned policy" form — expecting a wildcard path to cover everything under it. It didn't:

{"error":"AccessDenied","message":"Access denied"}

(Along the way I also discovered this AWS account already had a CloudFront Public Key from a different project, and my first debugging attempt had grabbed the wrong Key Pair ID entirely — worth checking aws cloudfront list-public-keys before assuming there's only one.)

The actual fix was switching to an explicit custom policy — passing policy with a JSON statement whose Resource includes the wildcard — rather than the canned url/dateLessThan shortcut. The SDK happily accepts a wildcard in the canned form; CloudFront just doesn't honor it the same way.

Deleting a video brought it back from the dead

With everything working, I added delete. It's supposed to be a simple DynamoDB + S3 cleanup, but it hit two separate bugs.

First, IAM: grantWrite/grantDelete only cover object-level actions (s3:PutObject*, s3:DeleteObject*), not the bucket-level s3:ListBucket that ListObjectsV2 needs during cleanup. Adding grantRead fixed it.

Second, and more interesting: deleting a video that was still processing let the MediaConvert-completion Lambda fire after deletion, calling UpdateItem on a videoId that no longer existed. DynamoDB's UpdateItem creates the item if it's missing — so the "deleted" video would silently reappear, partially populated. Adding ConditionExpression: 'attribute_exists(videoId)' made that update a no-op instead of a resurrection.

The security group I "locked down" wasn't actually locked down

I wanted the ALB reachable only through CloudFront, so I restricted its security group to CloudFront's managed prefix list (pl-58a04531). Deployed, checked the actual rule set, and found this:

{
  "IpRanges": [{"CidrIp": "0.0.0.0/0", "Description": "Allow from anyone on port 80"}],
  "PrefixListIds": [{"PrefixListId": "pl-58a04531"}]
}

Both rules were live at once. The culprit was the ALB listener's open property, which defaults to true and silently adds its own 0.0.0.0/0 ingress rule regardless of what you've configured on the security group yourself. Setting open: false on addListener removed it. This is the kind of gap you only catch by actually reading the deployed state back from the AWS CLI — the CDK code alone looked correct.

Avoiding a NAT Gateway didn't actually save money

Once things were stable, I priced out the fixed monthly cost:

Item	Monthly (approx.)
5x VPC interface endpoints	~$50.40
ALB	~$20–23
ECS Fargate (0.25 vCPU / 0.5GB, ARM64)	~$8.90
Secrets Manager	$0.40
Total	~$83

I'd built five interface endpoints specifically to avoid a NAT Gateway (roughly $44.60/month in Tokyo, plus data processing). Adding them up, the endpoints cost about the same as the NAT Gateway would have — sometimes more. Consolidating to a single NAT Gateway would save maybe $5–6/month at the cost of a single point of failure, which is a fine trade for a personal, single-user app. I ended up leaving the endpoint-based setup as-is; the savings weren't worth the churn.

What's actually running

Login via Cognito with PKCE, one user account, no sign-up flow
Upload → S3 → Lambda → MediaConvert → HLS
CloudFront with signed cookies gating the video files themselves
Delete, a Japanese/English toggle, and a dark, YouTube-ish UI

The code is public on GitHub, including the README section explaining, in plain terms, why multi-user upload was never on the table.

Mobile

The part that actually took the time

None of the individual fixes here were hard once I knew what was wrong. What took the time was reading logs — exec format error, AccessDenied, InvalidKey — each one terse, each one caused by something completely different. Past a certain point, building on managed AWS services stops being about writing code and starts being about getting fast at figuring out why something isn't working.

AWS Instance Store: Built to Disappear, On Purpose

Yuuki Yamashita — Fri, 14 Aug 2026 05:32:58 +0000

Instance Store gets introduced in almost every AWS storage comparison the same way: "NVMe SSD physically attached to the host, faster than EBS, but the data disappears when the instance stops." That last clause usually reads like a warning label. Most guides then walk you straight into the safe, well-worn use cases — Cassandra nodes that don't mind losing a replica, Spark shuffle space, a scratch disk for sorting temp files. All correct, all a little boring.

What if the disappearing part isn't the catch, but the whole point?

Two workloads make that case surprisingly well: blockchain nodes doing a fast state sync, and compute jobs that touch data you'd rather not still have lying around tomorrow. They don't look related at first. One is about speed, the other about disappearance. But they're actually the same trick told twice — you get a disk that works blazingly fast for a short, defined burst, and then erases itself as a side effect of you being done with it. You're not fighting the ephemerality. You're renting it.

What instance store actually promises

Worth being precise here, because the security argument later depends on it. Instance store data does not persist through a stop, a terminate, a hibernate, or an underlying host failure. It does persist through a plain reboot, since that keeps you on the same physical host. AWS documents that the storage is not accessible to whoever gets the host next, which is the property that makes both ideas below work at all.

What instance store is not: a certified secure-erase mechanism. If your compliance framework requires a documented, auditable wipe procedure — HIPAA, PCI-DSS, that kind of thing — "the disk went away when I stopped the instance" is not a control you can point an auditor at. Keep that distinction in mind as you read the rest of this, because the two ideas here are architectural thought experiments, not a substitute for whatever your compliance team actually needs signed off.

Idea one: the node that only exists to catch up

Syncing a blockchain node from genesis, or even from a recent snapshot, is an I/O-bound slog. You're writing and reading state data continuously for hours, sometimes days, and once the node is caught up, most of that historical grind stops mattering — what you actually want going forward is a warm, synced node.

The usual move is to provision an instance with a big EBS volume, let it sync, and keep paying for that volume indefinitely. Instance store flips the framing: treat the sync itself as the disposable part. Spin up an instance with local NVMe, let it rip through the sync at NVMe speeds instead of network-attached-storage speeds, and once it's caught up, snapshot the resulting state to S3 or EBS. The instance that did the syncing was never meant to be the long-term home for that data — it was a sprinter, not a warehouse. If it dies mid-sync, you weren't attached to it anyway; you just launch another one and let it catch up again, ideally from a recent checkpoint instead of genesis.

This is basically the render-farm mentality applied to sync jobs: the compute is consumable, the output is what you keep. It also pairs naturally with Spot — losing a spot instance mid-sync is annoying, not catastrophic, precisely because you never treated its disk as the source of truth.

Idea two: compute that isn't supposed to remember anything

Now the other direction. Imagine a batch job that has to touch something sensitive for a few minutes — decrypting a payload, running a one-off transformation on data you were only ever supposed to process, not retain. The usual anxiety with EBS-backed compute is the tail: did the volume get deleted on termination, did a snapshot get left behind by accident, is there a stray AMI somewhere with that data baked in.

Instance store sidesteps most of that tail by construction. Launch the instance, do the job, terminate it. There's no volume to remember to delete, because there was never a persistent volume to begin with. The "forgetting" isn't a cleanup step you have to remember to run — it's what happens automatically when the job's done and you walk away. It's less "secure deletion" and more "the environment was never built to have a memory."

I'll be upfront that this is the idea I'd stress-test hardest before trusting it with anything actually regulated. It's a genuinely nice property for internal tooling, dev/test data that's sensitive but not audited, or a proof of concept where "the disk goes away" is a reasonable enough story. It is not, on its own, a story you'd want to tell a security auditor for anything under a real compliance regime — that needs KMS-backed encryption, documented key destruction, and probably a paper trail instance store just doesn't produce.

The thread connecting them

Both ideas lean on the same underlying shift: stop treating the disk's short lifespan as a constraint to architect around, and start treating it as the reason the architecture works. The blockchain sync node is fast because nobody's paying the tax of durable storage during the grind. The confidential job is simple because nobody has to remember to clean up after it. In both cases the disappearing act isn't a workaround — it's doing actual work.

None of this replaces the orthodox use cases. Cassandra nodes, EMR clusters, and CI runners are still the bread and butter of instance store, and for good reason — they're proven, well-documented, and nobody's going to ask you hard questions about why you picked them. But it's worth remembering that "the data goes away" is a spec, not a bug report, and specs can be designed around on purpose. Sometimes the most interesting infrastructure decision is picking the tool that forgets on schedule, and building the rest of the system to expect exactly that.

How to Pause an AI Agent for Human Approval Without a WebSocket

Yuuki Yamashita — Thu, 13 Aug 2026 15:54:18 +0000

If an AI agent needs a human to approve something mid-task, the instinct is usually to reach for a websocket, a message queue, or some kind of push notification service to bridge the backend and the frontend. I ended up not needing any of that. One DynamoDB row, polled from both sides, does the whole job. I built this for SubSentry, an agent for AWS's Agents for Humans Hackathon that renews clean subscriptions on its own and asks a human before touching anything that looks like a price hike, a duplicate charge, or an unrecognized merchant. This post is about the mechanism underneath that "asking," not the subscription-tracking part.

The shape of the problem

An agent tool call that needs human approval has to do two contradictory things at once. It has to actually block, because the agent's next step depends on the answer, and it has to somehow let something completely separate (a browser tab, a Slack bot, a CLI) deliver that answer whenever a human gets around to it, which could be five seconds or five minutes later. The backend process and the thing collecting the human's decision don't share memory, don't share a request, and in my case run on entirely different platforms (Bedrock AgentCore Runtime for the agent, Vercel serverless functions for the UI).

The trick is to stop thinking of it as backend-talks-to-frontend at all. Neither side needs to know the other exists. They both just need to agree on one row.

The row as a mailbox

Here's the actual store, trimmed slightly:

def request_approval(*, subscription_id, suggested_action, reasons, amount_usd, ttl_seconds=120):
    approval_id = str(uuid.uuid4())
    now = time.time()
    entry = {
        "approval_id": approval_id,
        "subscription_id": subscription_id,
        "status": "PENDING",
        "suggested_action": suggested_action,
        "reasons": reasons,
        "amount_usd": amount_usd,
        "created_at": str(now),
        "expires_at": str(now + ttl_seconds),
        "decision": None,
    }
    _dynamo_put(entry)
    return entry


def wait_for_decision(approval_id, *, poll_sec=1.0):
    while True:
        entry = get_approval(approval_id)
        if entry["status"] != "PENDING":
            return entry
        if time.time() > float(entry["expires_at"]):
            entry["status"] = "EXPIRED"
            _dynamo_put(entry)
            return entry
        time.sleep(poll_sec)

The agent's tool calls request_approval, gets back an approval_id, and immediately calls wait_for_decision on it, which just sits there polling DynamoDB once a second. That's the entire "block" side. It's a plain Python while True loop, nothing fancier, because AgentCore Runtime is already paying for a long-running invocation, so there's no reason to make the waiting clever.

The other side never has to know it's being waited on

The frontend's job is smaller than it sounds: read rows where status = PENDING, render them as cards, and when a human clicks Approve or Reject, write the decision back. Here's the write, as a DynamoDB UpdateItem call from a Next.js API route:

const r = await ddb().send(
  new UpdateCommand({
    TableName: TABLES.approvals,
    Key: { approval_id: id },
    UpdateExpression: "SET #s = :d, decision = :d, #r = :r, decided_at = :t",
    ExpressionAttributeNames: { "#s": "status", "#r": "reason" },
    ExpressionAttributeValues: { ":d": body.decision, ":r": body.reason ?? "", ":t": String(Date.now() / 1000), ":pending": "PENDING" },
    ConditionExpression: "attribute_exists(approval_id) AND #s = :pending",
    ReturnValues: "ALL_NEW",
  })
);

The ConditionExpression is doing more work than it looks like. It means two people can't both approve the same card and have it silently double-apply, and it means a decision can't land on a row that already expired. If the condition fails, DynamoDB throws ConditionalCheckFailedException, which the route turns into a 409. No locking, no transactions, just a condition on a single-item write.

And that's the whole contract. The agent doesn't call an API on the frontend. The frontend doesn't call an API on the agent. A CLI can write the same UpdateItem and it works identically, which is why agent.py approve <id> from a terminal resolves the exact same pending card as clicking Approve in the browser. Neither side was written with the other in mind, they just both read and write the same table with the same status field.

Where this breaks if you're not careful

The failure mode I actually hit wasn't in this mechanism, it was one level down. Strands dispatches multiple tool calls from the same agent turn concurrently, and my first pass at local storage (before I had a real DynamoDB table wired up) was a plain read-JSON-modify-write with no locking. Two tool calls landing at nearly the same instant would both read the file, both append their own entry in memory, and whichever one wrote last won, silently dropping the other's write. I found it because a local .approvals.json file had two writes visibly tangled together mid-file, not because a test failed cleanly.

The fix was five lines, a threading.Lock around the read-modify-write section:

with _LOCK:
    data = _local_load()
    data[approval_id] = entry
    _local_save(data)

DynamoDB's per-item UpdateItem doesn't have this problem at all, since each write targets one item atomically. The bug only existed because my local dev fallback was reinventing a worse version of what DynamoDB gives you for free. Worth remembering next time a "just write it to a JSON file for now" shortcut feels harmless.

Why not just use a websocket

I did consider it, mostly out of habit. But a websocket needs a persistent connection on both ends, which means something has to stay alive to hold it, and AgentCore Runtime invocations and Vercel serverless functions are both built around not staying alive longer than they have to. Polling a table every one to three seconds costs nothing worth optimizing at this scale, and it means either side of the system can restart, redeploy, or die completely mid-wait and the other side won't even notice, because the DynamoDB row is the only thing that has to survive.

If you want to see the whole thing running, live demo and code are here:

Live demo: https://sub-sentry-xi.vercel.app
Code: https://github.com/yama3133/sub-sentry

Built for AWS's Agents for Humans Hackathon. #AgentsforHumans

Giving Claude Code a Voice (and a Face)

Yuuki Yamashita — Thu, 13 Aug 2026 03:44:12 +0000

I spend a lot of time waiting on Claude Code. Not idle waiting — I tab away, work on something else, and come back later. The problem is "later" is a guess. A run that finishes in 40 seconds and one that's still going 20 minutes later look identical from another window: nothing happens until I check.

So I gave it a voice. Specifically, Zundamon's voice — a free, widely used Japanese character voice from VOICEVOX — plus a small character that shows up in the corner of my screen when there's something to say.

What it actually does

Claude Code has hooks that fire on specific events: when a turn ends (Stop), when a subagent finishes (SubagentStop), and when the CLI is waiting on me for longer than a few seconds (Notification). Each of those now runs a small Python script that sends a short line of text to a background daemon sitting in my menu bar. The daemon asks VOICEVOX to synthesize it, plays the result, and pops up a borderless little window with Zundamon and a speech bubble.

The daemon also remembers which of four display modes I picked: always on screen, only visible while actually talking, voice-only with no window at all, or fully muted. That choice is saved to a config file so it survives a restart.

None of this touches the network beyond localhost — the hook script, the daemon, and VOICEVOX Engine all talk to each other over 127.0.0.1.

The part that actually took the time

Wiring the pipeline together was the easy afternoon. Making it not sound broken took a lot longer, and most of the bugs were the kind you only notice by actually listening or actually looking.

English text came out mangled. The first version just piped my last message straight into VOICEVOX. It's a Japanese-only engine, so anything in English got sounded out phonetically and wrong — SubagentStop came out as something closer to "sa-ba-jento-sutoppu" than anything recognizable. I ended up stripping Markdown, keeping only the first sentence of a message (Claude's replies tend to open with a clean summary), and running the rest through a small hand-built glossary that swaps known English terms for their katakana reading before anything unknown gets dropped. That second part — silently dropping unknown English rather than mangling it — was a deliberate trade-off. It's less informative than reading everything, but it sounds like a voice instead of a glitch.

That fix had a side effect I didn't catch right away: the same regex that stripped stray English letters was also eating plain digits, since [A-Za-z0-9] was too broad. Task counts and port numbers just silently disappeared from what got spoken. Tightening the pattern to only match tokens that start with a letter fixed it without touching how English gets filtered.

A single kanji read wrong. The word 角 (corner) is genuinely ambiguous in isolation — it can be read kado or kaku depending on context, and VOICEVOX's default analysis picked the wrong one for how I was using it. VOICEVOX Engine exposes a real dictionary API for exactly this (/user_dict_word), so I registered the correct reading. It didn't take effect. Turned out the default word type is "proper noun," and the built-in dictionary entry for a plain corner apparently wins over a proper-noun override in that grammatical position. Re-registering it as a common noun with a higher priority fixed it immediately.

Failures were completely silent. At some point during testing, VOICEVOX had quietly crashed. The hook still fired, the bubble still popped up with the right caption — and nothing played. No error anywhere, because the exception was being caught and swallowed. I added a log line and a recovery path: if synthesis fails, relaunch the engine, wait for it to come back up, and retry once. A crash now costs a few seconds of silence instead of going unnoticed for the rest of the day.

The window was flush with the corner. The character wasn't. I pinned the floating window to (0, 0) — the literal bottom-right corner of the screen — and the character's feet still hovered above the edge with a visible gap. The window position was correct; I checked. What wasn't correct was the source artwork: the PNG had transparent padding baked in below the feet, so the visible pixels stopped short of the canvas edge. Cropping the artwork to its actual bounding box before resizing fixed it — no code change to the window logic at all.

Where it ended up

A menu-bar daemon, four display modes, a self-healing connection to VOICEVOX, a growing glossary for English terms, and a corrected dictionary entry for one very specific kanji. It's a small tool, and I don't think any single piece of it was hard. What was hard was that every failure mode was invisible by default — wrong pronunciation, dropped digits, a dead engine, a mispositioned character — and the only way to catch any of it was to actually sit there and listen, or take a screenshot and zoom in.

If you're building something similar: budget real time for the boring verification loop, not just the integration. That's where all of this actually lived.

Building a Real-Time Earthquake Alert PWA with AI Agents

Yuuki Yamashita — Wed, 12 Aug 2026 06:44:20 +0000

Japan sits on four tectonic plates. Most people who live here carry that fact quietly in the back of their mind, and every so often it stops being background noise. On July 28, 2026, an earthquake hit Kumamoto and people lost their lives. I want to say that plainly before anything else in this post: my thoughts are with the people who were killed and the people still living with what that day did to their homes and their sense of safety. Everything technical that follows exists because of days like that one.

I build small AI-agent side projects most weekends, and this time I wanted to build something that actually mattered to me personally rather than something clever for its own sake: a real-time earthquake alert app. Text only, no map to stare at, just "something is happening, here's where, here's how strong." I built it end to end — WebSocket ingestion on AWS, a Strands Agent on Amazon Bedrock AgentCore Runtime writing the alert copy in six languages, a PWA on Vercel that plays a different alert sound depending on severity. Then, while I was still testing it, an actual earthquake swarm started in Kumamoto and the app got tested by real data whether I liked it or not. More on that below.

What it does

The rules are simple on purpose:

Shows anything of shindo (Japanese seismic intensity) 1 or higher
Shindo 5-weak and above, Earthquake Early Warning (EEW), and tsunami warnings get a red, emphasized card
A map of Japan appears only for those emphasized cases, with the affected prefectures highlighted — no map at all for routine shindo 1-2 reports, because most of the time a map adds noise, not signal
Everything is offered in Japanese, English, Chinese, Korean, Russian, and Arabic, with right-to-left layout for Arabic
Push notifications work even when the browser tab is closed, using a real audio file rather than the browser's default ping

None of this is exotic technology. What made it interesting to build was how many small, real-world details turned out to matter.

Architecture

A Fargate task in ap-northeast-1 holds a persistent WebSocket connection to P2P Earthquake Information, a free, community-run relay of Japan Meteorological Agency (JMA) data. When a message comes in, the connector filters it, normalizes it into a common shape, and hands the structured data to a Strands Agent running on Amazon Bedrock AgentCore Runtime. The agent's only job is to turn "maxScale: 45, areas: [Wajima, Suzu], tsunami: advisory" into a short, calm headline and summary — in all six languages, in a single call. The result gets written to DynamoDB and pushed to every subscribed browser over Web Push. On the other side, a Next.js PWA on Vercel reads events through a small API Gateway/Lambda layer and renders the live feed.

I picked Fargate for the connector specifically because a WebSocket listener needs to stay alive, and Lambda's execution model doesn't fit that. Everything else — the API routes, the event storage, the translation — is about as serverless as I could make it.

The parts that didn't work on the first try

The EEW payload lied to me by omission. I assumed the areas array in a P2P quake "555" message (Earthquake Early Warning) would contain municipality-level shindo estimates, the way the finalized "551" earthquake info does. It doesn't. It's peer relay counts inside the P2P network itself — completely unrelated to the earthquake. My first build rendered a wall of "undefined (shindo 1)" entries in production before I caught it and rewrote that part to only pull real detail from the confirmed 551 message that (usually) follows.

A SigV4 signature bug cost me most of an evening. I'm calling AWS API Gateway from a Vercel function using OIDC federation — no static AWS keys, just a role Vercel assumes per request. Requests without a query string worked fine. Requests with one (?limit=30) came back 403 every time. IAM policy simulation said "allowed." Assuming the role manually from my own machine and signing the exact same request worked. The difference turned out to be embarrassingly simple: I'd built the query string directly into the request path instead of passing it through the signer's dedicated query field, so the signature covered a URL that didn't match what actually went out over the wire.

ARM64 vs x86_64. I build the connector's Docker image on an Apple Silicon Mac. Fargate defaults to x86_64. The container built fine, pushed fine, and then died on startup with exec format error. One line (runtimePlatform: { cpuArchitecture: ARM64 }) fixed it, but it took a failed deployment to notice.

A chicken-and-egg secret. The Fargate task reads its VAPID (Web Push) keys from Secrets Manager. If you let CDK create that secret fresh, it initializes with a random placeholder value, and the container crashes trying to parse it as JSON before you ever get a chance to set the real keys. The fix was to create the secret with real values first, then have CDK import it instead of creating it.

iOS wouldn't let audio play. Mobile Safari and Chrome (both WebKit under the hood on iOS) block audio.play() unless it's called synchronously inside a real user gesture. A push notification arriving is not a user gesture, no matter how you slice it. The fix is a small trick: play a near-silent sound the moment the user taps "enable notifications," which unlocks the audio element for later programmatic playback in that same tab.

A timezone bug that hid inside a feature I was proud of. I added a safety feature: if an EEW alert isn't followed by confirmed earthquake details within 10 minutes, quietly relabel it "unconfirmed" instead of leaving it looking urgent forever. It shipped, and it did nothing. The bug: P2P's timestamps look like 2026/08/12 10:40:03, already in JST, with no timezone marker. Passed straight into new Date() inside a UTC-timezone container, that string gets interpreted as UTC — silently shifting every event nine hours into the future. now - eventTime was permanently negative, so the 10-minute check never once fired. I only found it because real alerts sat "urgent" for over an hour and someone (me) asked "why hasn't this changed."

Then a real swarm showed up

While I was mid-build, Kumamoto started experiencing a real earthquake swarm — dozens of quakes over more than sixteen hours, several strong enough to trigger EEW. My test app, still very much a work in progress, started receiving genuine alerts back to back. It was uncomfortable in a way a synthetic load test never is: I was watching a tool I'd built for exactly this situation get exercised by the real thing while I was still finding bugs in it. It's also the reason the "unconfirmed" feature and the timezone bug above both got fixed in the same afternoon — nothing motivates a fix like watching your own notification fire for the fourth time in twenty minutes with no idea if it's real.

What I'd tell past me

Test with real, messy, live data as early as possible. Every bug above — the EEW payload shape, the SigV4 query string, the timezone parsing — was invisible in my own mocked test data and obvious the moment real traffic hit it. Mocks are useful for exercising code paths, but they can't tell you that your assumptions about a third-party API's shape are wrong, and they definitely can't tell you your timestamp parsing silently breaks in a specific timezone.

The stack, if it's useful to anyone building something similar: AWS Fargate, Amazon DynamoDB, Amazon API Gateway, AWS Lambda, Amazon Bedrock AgentCore Runtime running a Strands Agent, Next.js on Vercel with OIDC federation for keyless AWS access, and Web Push with VAPID for notifications.

It's a small app. It won't stop an earthquake. But if it gets one person a few extra seconds of warning, or tells someone in a language other than Japanese that the shaking they just felt was real and roughly how strong, that's the whole point of having built it.

Schrödinger's Payment: An AI Agent for Duplicate Charges

Yuuki Yamashita — Tue, 11 Aug 2026 15:13:24 +0000

Amazon Web Services published a piece a few weeks ago called From Connected to Resilient: Cloud-Native Payment Connectivity on AWS. It's a deep dive into hardening AWS PrivateLink and Resource Gateway for payment networks that speak ISO 8583 over long-lived TCP sessions. Not exactly light reading, but one detail stuck with me: a Network Load Balancer's idle timeout for TLS listeners is fixed at 350 seconds, and if your client's TCP keepalive interval is longer than that, the NLB will quietly kill the connection. Neither side gets an error. The client just... stops hearing back.

The article frames this as a resilience problem, and it is one. But I kept thinking about it from the other side. If a payment request goes out and the connection dies before the response comes back, what does the client actually know? Nothing. The charge might have gone through. It might not have. Until someone checks, both are simultaneously true.

That's a physics joke I couldn't resist building.

Schrödinger's Payment

I built a small app that reproduces this exact failure mode and then makes you live in it. You set an idle timeout and a keepalive interval, send a payment, and watch a heartbeat animation play out in real time. If the keepalive pulses arrive often enough, the connection survives and you get a clean ACK. If they don't, the connection resets right on schedule, and the payment falls into superposition. The backend, unaware anyone left, keeps processing and commits the charge anyway. The client just never finds out.

Turn the keepalive interval up past the idle timeout and you get to watch the reset happen.

The interesting part isn't the outage

Anyone who's built a retry mechanism knows the fix for "did my request actually go through": idempotency keys. Retry with the same key, and a well-built server returns the original result instead of charging twice. I built that path first, and it works exactly as expected.

The part I actually wanted to explore was what happens when the client doesn't retry cleanly. Say the mobile app restarted, or the request got routed through a different channel, and it generates a brand-new idempotency key for what is, to a human, obviously the same purchase. Now the server sees two different keys, the same order, and has to guess whether this is a legitimate second attempt or someone about to get charged twice.

I didn't want to hardcode that guess as a rule. So instead of a simple "same amount within N seconds = safe," the app hands the situation to Claude through Amazon Bedrock's Converse API. It gets the full record: both attempts, their amounts, timestamps, and any note the retrying party attached. Then it has to decide whether to block it as a duplicate, allow it as a distinct transaction, or, if it isn't confident either way, hand the decision to a human instead of guessing.

That last option turned out to be the whole point. When I retried with the same amount and no explanation, the agent blocked it outright at 85% confidence, citing the identical amount and a two-second gap. But when I changed the retry amount and added a note like "customer isn't sure if the amount was right, asked to double check," it stopped short and asked for a human instead. The amount mismatch could mean a legitimate correction, but the short elapsed time and unacknowledged first attempt kept it from being sure. That's roughly the judgment call a fraud analyst makes, minus the human.

Where it actually broke

I deployed the first version to Vercel and ran through the same flow with curl to sanity-check it end to end. Sending a payment and retrying with a new key worked as a pair of requests. Then I called the approve endpoint right after, and got back "no record pending approval found." The record I'd just created, seconds earlier, was gone.

The app's ledger, standing in for the payment backend's source of truth, lives as an in-memory Map in a Node process. That's fine locally, where next dev runs everything as one long-lived process. On Vercel, /api/pay, /api/resolve, /api/approve, and /api/ledger each compile into their own serverless function. They don't share memory at all; I'd built four backends that couldn't talk to each other and only noticed because I happened to test the full sequence with curl instead of clicking through the UI once and calling it done.

I merged all four into a single dynamic route, /api/action/[type], so at least they'd be the same function. That closes most of the gap, since a single function's warm instance does hold state between requests, but it isn't a real fix. Vercel doesn't guarantee that every request lands on the same warm instance. A genuinely production-grade version of this would need actual persistent storage: Vercel KV, DynamoDB, anything that isn't a Map in Lambda memory. For a demo meant to show off reasoning, not infrastructure, I decided that was an honest place to stop. The live version is a simulation, not a payment backend.

Try it

The demo runs in English and Japanese, and it's live at schrodinger-payment.vercel.app. It's a Next.js app with API routes calling Claude through Amazon Bedrock's Converse API, deployed on Vercel with a scoped IAM user that can only invoke Bedrock models and nothing else. Every screenshot above was captured against the real deployment, agent reasoning included. Nothing here is scripted.

If you've read the AWS article this is riffing on, Pattern A (three-layer keepalive alignment) is the one this whole thing reproduces. Patterns B through D, covering graceful maintenance windows and tenant isolation, are still on my list to turn into something equally over-engineered.