THE WORLD IS NOT STANDING STILL.RSS
BIG CHANGE.
BIG CHANGE, one tap away
BIG CHANGE, one tap away

Make room for the big picture.

Add BIG CHANGE to your home screen or desktop. It opens in its own window, with the latest stories when you’re online.

iPhone & iPad
Open bigchange.ai in Safari. Tap Share, then Add to Home Screen. Turn on Open as Web App if shown, then tap Add.
Android
Open bigchange.ai in Chrome. In the browser menu, choose Install app or Add to Home screen.
Desktop
In Chrome or Edge, use the install icon in the address bar or the browser’s app menu. In Safari on Mac, choose File → Add to Dock.
All briefings

Follow the change ·

The day,
in perspective.

What happened in AI and robotics — and the change behind it. A reading path through 36 stories from BIG CHANGE.

Ordered using RADAR attention, story opens and likes. Excerpts from our published reporting; open a story for the full context and sources. Dates in UTC.

Original story: guide

Turn agent output into a reviewed action register

Build a typed OpenAI Agents SDK result from your own notes, review its source evidence and meaning, then pass the accepted result to a local Markdown action register with hash readback.

The big change

What changed: The OpenAI Agents SDK accepts a Pydantic output_type, so an application can ask an agent for a defined result and check it again before using it. This example adds source citations and a versioned contract around that result.

Why it matters: A developer connecting an agent to another work step can stop malformed, incomplete or unsupported output before it becomes an action list. A reviewer still has to judge whether the quoted notes actually support every task, owner and date, and whether the model omitted anything.

What to watch: The decision point is the consumer boundary. This recipe produces a local triage register only after approval of the exact run, source and candidate. A later task-system import would need its own authority, retry policy and destination readback.

Read the full story
—
Back to the briefing
Original story: guide

Build and check a reusable Claude Design system

Create a reusable Claude Design system from approved brand assets, review its rules, test a new design and verify who can use it.

The big change

What changed: Claude’s current chat and Artifacts route lets an authorized owner create reusable design rules from approved brand references. The generated system still needs review before team use.

Why it matters: Comparing and correcting its rules, then testing a new design, gives the owner a way to check whether the saved system carries the intended brand into actual work.

What to watch: The owner still needs to verify inheritance in that design, asset and font rights, accessibility checks and the final sharing audience. An attractive first output does not settle those questions.

Read the full story
—
Back to the briefing
Original story: guide

Fix and verify one failing repository check with an AI Goal

Set a bounded Claude Code or Codex CLI Goal for one existing failing check, then verify the original command and final diff before accepting a repair.

The big change

What changed: The documented /goal commands keep a stated objective active across turns, so the assistant can inspect a failure, make a scoped change and check again without a new instruction from you after every turn.

Why it matters: You can define the original failing command, permitted files and protected behavior before the loop starts. That gives successive attempts the same acceptance target.

What to watch: A Goal status or model verdict cannot prove the repair. Read the real check output and final diff, and make the decision to accept the change yourself.

Read the full story
—
Back to the briefing
Original story: guide

Delegate one Claude Code coding task from Opus to Haiku and verify the result

A documented Claude Code workflow for sending one bounded coding change from an Opus parent to a project Haiku subagent, checking the actual model and diff, and interpreting usage without assuming a saving.

The big change

What changed: A project agent file can request model: haiku for a named coding worker while the parent session uses Opus.

Why it matters: The parent can review a smaller worker task, but the developer still decides whether the diff meets the original acceptance check.

What to watch: Model overrides, organization policy, permissions, review and retry work can change the actual model and total usage. Verify them before claiming a cost benefit.

Read the full story
—
Back to the briefing
Original story: guide

Give two agents the same reviewed memory record

Store one source-approved typed memory record, supply its exact reviewed bytes to two authorized agent sessions, then verify a conditional update and resolve conflicts.

The big change

What changed: A reviewed, typed JSON memory can persist in a Managed Agents store. The application checks its source and exact stored bytes, freezes one private snapshot, then sends those same approved bytes to two separate authorized sessions without a memory-store attachment.

Why it matters: A later store edit cannot change the inputs already constructed for those sessions.

What to watch: Source accuracy, user authorization and answer quality still require separate checks.

Read the full story
—
Back to the briefing
Original story: guide

Keep one contact record in Obsidian and check a Codex answer

Create one permissioned contact record and index in Obsidian, then ask Codex a narrow question and check both an answer and an absent fact against the file.

The big change

What changed: Desktop Codex supports local folders, so a person can bring an existing Markdown vault into a Codex project. Obsidian's notes remain readable files in that folder.

Why it matters: You can keep the record and its source details in a file you can inspect, then ask Codex a narrow question and compare its reply with the file.

What to watch: A local vault does not mean model processing stays on your device. Permission to process another person's details, Codex's actual file access, and every answer still need checking.

Read the full story
—
Back to the briefing
Original story: guide

Make and check Pomelli campaign creatives from a product

Use a reviewed Pomelli Business Profile and checked Catalog item to make campaign creatives, review the brief and assets, then verify downloaded files before approval.

The big change

What changed: Pomelli's documented product route connects a reviewed Business Profile and Catalog item to an editable Campaign brief, generated images with text and downloadable files.

Why it matters: The owner can correct the brief before Confirm and edit individual assets after generation. Those are two separate chances to catch a wrong product claim or offer before use.

What to watch: An approved brief and a creative that looks right in Pomelli do not establish that the downloaded file is accurate or usable. Open the file and verify its facts, product depiction, rights and destination fit before anyone posts it.

Read the full story
—
Back to the briefing
Original story: guide

Create an owner-approved DESIGN.md for Claude Code

Write a visual specification from approved brand decisions, then use it for two small Claude Code edits and inspect both diffs and renders.

The big change

What changed: The owner can author a versioned visual specification from approved decisions and give Claude Code that exact file before a bounded edit.

Why it matters: A single checked source makes the color, type and layout rules available for comparison with two actual revisions, while the owner decides whether either result is acceptable.

What to watch: The file must be read completely before each edit. Its presence in the project, a path mention or Claude's assurance does not prove it was loaded or followed.

Read the full story
—
Back to the briefing