Dynamic Island Live Activity for an AI Agent in SwiftUI

Why is an AI agent the perfect Live Activity?

Because a Live Activity exists for exactly one thing: a task that takes a while and that the user wants to glance at without opening the app. A food delivery, a flight, a workout, and now an agent grinding through a multi-step job, “researching 3 of 7 sources,” “writing the report,” “done.” ActivityKit was built for this shape, and an autonomous agent is one of the most natural fits the API has seen: long-running, state-changing, worth watching, not worth babysitting.

The honest framing before the build: a Live Activity is a remote-controlled status display, not a place the agent runs. The agent runs on your server (or in the main app); the Live Activity reflects its state. Everything good about this feature comes from treating it as a tiny, push-updated mirror of work happening elsewhere, and everything broken comes from trying to make it do more.

What are the surfaces, and what fits each?

A Live Activity renders in several places at once, each with a brutal space budget, and designing for the smallest is the discipline:

Surface	Space	What the agent shows
Dynamic Island compact	A few characters each side	An icon + the step count (3/7)
Dynamic Island expanded	A small card on long-press	Current step, progress, a stop control
Lock Screen	A banner-sized card	Step label, progress bar, elapsed time
Minimal (shared island)	One tiny glyph	Just “alive” state

The Live Activities guidance is explicit that these are glanceable, not interactive dashboards. So the agent’s status compresses to its essence: which step, how far along, and is it still going. The compact Dynamic Island, where you have room for an icon and maybe “3/7,” forces the clarity that makes the whole thing work, and if the status cannot survive that budget it is the wrong thing to surface.

How do the updates actually arrive?

Two channels, and choosing right is the make-or-break decision. A Live Activity updates either from the app while it is running, or remotely via a special ActivityKit push notification (a push to the activity’s own token, not a normal alert). For an agent doing minutes of server-side work with the app backgrounded, remote push is the only real option: the server advances the agent, and each meaningful state change pushes an update to the Live Activity token.

The constraints that shape the design are real and worth stating plainly:

• Update budget. iOS rate-limits Live Activity pushes; a token-burning update on every micro-step gets throttled. Push on meaningful transitions (step changed, blocked, done), not on every tick, the same update-budget honesty as the Dynamic Island music visualizer keyed to real state.
• Duration limits. Live Activities have a maximum lifetime (hours, then the system ends them), so a genuinely long agent job needs a graceful “still working, open the app for detail” end state rather than a silent disappearance.
• The 4 KB payload. Activity push payloads are tiny (4,096 bytes), so you send state, not content: “step 4, label X, 57%,” never the agent’s actual output.

What can the user actually do from it?

Less than the “AI agent” framing tempts you toward, and that restraint is correct. Live Activities support a small set of interactive buttons (via App Intents), so a single honest control fits: Stop. An agent the user can halt from the Lock Screen is genuinely useful and genuinely scoped; an agent they are expected to steer, approve, or chat with from a Live Activity is the feature fighting the surface. Deep interaction belongs in the app, and the Live Activity’s job is to pull them there at the right moment (done, blocked, needs input) by being tappable into the full agent view.

That tap-through is the real interaction model: the Live Activity is the ambient signal, the app is the workspace, the same companion-not-miniature split that governs every glanceable surface. The agent’s full screen, the task timeline, the step detail, the approval gates, comes as a free VP0 design, so an agent build wires the ActivityKit token and the push updates onto a real workspace UI, with the Live Activity as its lock-screen shadow. The deeper “show substance, not theater” discipline for agent progress is the same one in the AI agent thinking animation: the status must reflect real work, never a fake spinner.

Key takeaways: a Live Activity for an AI agent

• The agent runs elsewhere; the Live Activity mirrors its state: a remote-controlled status display, not a runtime.
• Design for the compact Dynamic Island first: step count and alive-state in a few characters; if it does not fit there, it is the wrong status to surface.
• Remote ActivityKit push is the channel for server-side agent work, on meaningful transitions only, within the rate limit and the 4,096-byte payload.
• One honest control: Stop: deep interaction belongs in the app, which the Live Activity taps through to.
• Respect the duration limit: long jobs need a graceful “open the app” end state, not a silent disappearance.

Frequently asked questions

How do I build a Dynamic Island Live Activity for an AI agent? Use ActivityKit to define an activity whose state is the agent’s progress (current step, count, status), run the agent on your server, and push updates to the activity’s token on meaningful transitions. Design for the compact Dynamic Island first and tap through to the full app. A free VP0 design supplies the agent workspace the Live Activity shadows.

How does a Live Activity update while the app is closed? Through a special ActivityKit push notification sent to the activity’s own push token, not a normal alert. Your server advances the agent and pushes each state change, within the iOS rate limit and a 4,096-byte payload, so you send compact state rather than the agent’s output.

Can the user control the agent from the Live Activity? Only lightly: Live Activities support a few App Intent buttons, so one honest control like Stop fits. Steering, approving, or chatting with the agent belongs in the app, which the Live Activity taps through to; a control-heavy Live Activity fights the glanceable surface.

What are the limits on Live Activities? They are rate-limited on updates (push on meaningful transitions, not every tick), capped at a maximum lifetime of hours before the system ends them, and restricted to a 4,096-byte push payload. Design for graceful end states and compact state rather than continuous streaming of content.

Where should the agent actually run? On your server or in the main app, never in the Live Activity, which is only a status mirror. The Live Activity reflects state pushed to its token; treating it as where the work happens is the design mistake the whole feature is built to avoid.