ANTIGRAVITY LABJP
Articles/App Development
App Development/2026-07-03Advanced

Before You Let Siri Run an Agent-Written App Intent — Classify by Side Effect and Gate the Destructive Ones

Letting Siri or an assistant run an Antigravity-generated App Intent without a gate means a destructive action can fire from a single voice command. Here is how I classify intents by side effect, gate the irreversible ones, and catch missing gates before push.

antigravity412app-intents2siri2ios35swift8agent-safety2

Premium Article

On July 1st Apple announced a new intelligence framework and Xcode 27, widening how far you can connect an app's actions to Siri's assistant features through App Intents. That same week I was reading Swift that Antigravity had generated after I asked it to "add a shortcut that swaps my wallpaper collection for today's picks," and I felt a small chill. The generated PerformIntent replaced the user's entire saved collection with no confirmation whatsoever.

When I invoke it by hand, that's fine. The trouble is that this intent can now fire from Siri or an assistant, by voice, while I'm not looking at the screen. Agent-written code compiles and runs. And precisely because it runs, it can quietly become "an operation you can trigger by voice" while remaining oblivious to the weight of its own side effect. Here is how I close that gap with side-effect classification and a confirmation gate.

An intent you tap yourself is not the same as one an assistant fires

App Intents (iOS 16 and later) become callable from Siri, Shortcuts, Spotlight, and the new assistant features the moment your type conforms to a Swift protocol. The lower the implementation bar, the easier it is to overlook one question: who invokes this, and in what context?

When you tap an intent in the Shortcuts app, you know what is about to happen. Under voice or assistant invocation, parameter resolution and execution both complete before a human sees the result. By the time perform() returns .result(), the operation is done. There is no window to undo it.

I run wallpaper and relaxation apps as an indie developer, and a user's "saved collection" is the most delicate data in the app. An intent that overwrites it without confirmation was something I could not ship as-is, even though the agent had written perfectly compilable code.

The problem is not that Antigravity wrote bad code. It is that the context "this can be triggered by voice" was never in the generation prompt. So rather than blaming the generator, the receiving side needs a gate applied mechanically.

First, classify by side effect

Putting a confirmation dialog on every intent ruins the experience. Being asked to confirm every time you say "what's today's wallpaper?" is unusable. The axis is not the feature name; it is the reversibility of the side effect.

ClassDefinitionExampleConfirmAssistant invocation
Read-onlyChanges no state; idempotentShow today's pick, favorite countNoRun directly
ReversibleChanges state, but an undo existsAdd one favorite, switch themeUsually no (offer Undo)Run directly
IrreversibleCannot be undone, or affects a wide scopeBulk collection swap, delete all, purchaseRequiredOnly after confirm / hand to app

Expressing this in the type system makes the later static check easy. Make each intent declare its own side effect.

enum SideEffect {
    case readOnly       // changes no state
    case reversible     // undoable
    case irreversible   // irreversible / wide-reaching
}
 
/// Force every App Intent to declare this
protocol ClassifiedIntent: AppIntent {
    static var sideEffect: SideEffect { get }
}

Flagging intents that do not conform to ClassifiedIntent (with the script below) prevents an unclassified intent from shipping unnoticed. Classification is also a device that forces design-time thought. When you have an agent write the intent, include this conformance in the requirements and the output naturally becomes side-effect aware.

Thank you for reading this far.

Continue Reading

What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.

WHAT YOU'LL LEARN
A decision table that classifies every App Intent as read-only, reversible, or irreversible and mechanically decides whether a confirmation is required
An implementation pattern combining requestConfirmation and openAppWhenRun so destructive actions never run unconfirmed under voice or assistant invocation
A zero-dependency static check that flags agent-generated intents missing a confirmation gate before they ever reach push
Secure payment via Stripe · Cancel anytime

Unlock This Article

Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.

or
Unlock all articles with Membership →
Share

Thank You for Reading

Antigravity Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.

  • Copy-paste ready implementation code
  • New advanced guides published daily
  • $5/mo or $10 for lifetime access
View Membership →

Related Articles

App Dev2026-04-20
Building App Intents with Antigravity: Siri and Shortcuts Integration in Swift
A practical guide to implementing App Intents in iOS apps using Antigravity. Learn how to integrate Siri and the Shortcuts app, plus the pitfalls to watch for when working with Antigravity-generated Swift code.
App Dev2026-06-15
Stop Adding a Ternary Every Time a New iPhone Ships: A Table-Driven Resolution Design
Every time a new resolution arrived—iPhone Air, 17 Pro—I was bolting another screen-size ternary onto a 29-branch pile. Here is how I reshaped that into a table-driven design where adding the next device is a one-line data change, with the actual Swift from my wallpaper apps.
App Dev2026-06-12
Replacing a Decade-Old SKPaymentQueue with StoreKit 2 — Migrating 4 Wallpaper Apps with an Antigravity Agent
A field report on migrating SKPaymentQueue-based purchase code to StoreKit 2's Transaction.currentEntitlements across four wallpaper apps — what I delegated to an Antigravity agent, and the traps I only found on real devices.
📚RECOMMENDED BOOKS
Build a Large Language Model (From Scratch)
Sebastian Raschka
LLM Dev
Prompt Engineering for LLMs
Berryman & Ziegler
Prompting
AI Engineering
Chip Huyen
AI Eng
* Contains affiliate links
See all →