Blog • AI / Agent

Will Siri AI Become an AI Agent? Apple Intelligence, App Actions, APIs, and How JSON Fits

Hearing “Siri AI,” it is easy to picture a ChatGPT-style agent that picks tools and invents API calls. That is not what Apple shipped at WWDC 2026.

Siri AI is becoming a system agent: it can use personal context, see what is on screen, and run App Actions across apps. It is not an open agent. The model cannot invent REST paths, and it cannot write arbitrary JSON to your server.

This article covers:

• Which layer Apple Intelligence owns versus Siri AI
• What App Actions map to on the developer side (App Intents + App Schemas)
• How data flows through one cross-app task
• Which hop has JSON — and which hop does not
• How that compares to Function Calling / MCP agents, and how to validate action arguments in JSONNote

The answer first: a system agent, not an open agent

“Agent” is overused. Some people mean a chatty assistant. Others mean a runtime that loops on tools until the job is done. Siri AI is closer to the second, but where the tools come from is nothing like an open agent.

An open agent (ChatGPT, Claude, a home-grown runtime) usually works like this: the model reads a conversation, picks a name and arguments from a tools list, the runtime executes, then the result goes back into the chat. You write the catalog. JSON Schema is the input contract. MCP often handles discovery and execution. Another article on this site splits those four layers:

2026 AI Agent Stack: How Do LLM, MCP, Function Calling, and JSON Schema Fit Together?

Siri AI’s loop lives in the system. The user talks to Siri, or points at “this” on screen. The system-side model (on-device or Private Cloud Compute) understands the intent, then picks from the action catalog exposed by installed apps. Your app does not own the session. It is only the capability being routed to.

So the answer is not a flat yes or no. Siri AI will plan, fill slots, and do consecutive work across apps — that is already agent behavior. It will not become an open runtime where you mount an MCP server at will. Both chains touch apps, APIs, and JSON, but who owns the session and who generates arguments is not the same.

What Apple Intelligence is versus Siri AI

Split the product names first. Mix them and App Actions plus JSON have nowhere to land.

Apple Intelligence is the platform: generative models embedded in system capabilities on iPhone, iPad, and Mac. Writing, images, notification summaries, Visual Intelligence, and some inference that must leave the device all hang off this layer. Off-device requests go through Private Cloud Compute, not ordinary public-cloud logs. Official entry:

Apple Intelligence.

Siri AI is the new Siri announced at WWDC in June 2026, powered by the next generation of Apple Intelligence. Apple’s own wording: more conversational, personal context, world knowledge, on-screen awareness, and more systemwide App Actions. There is also a dedicated Siri app for revisiting conversations across devices. Newsroom:

Apple introduces Siri AI.

Developer testing started the day of WWDC across iOS 27, iPadOS 27, macOS 27, and visionOS 27. As of early September 2026 it is still in the fall OS beta cycle (developer beta 8 landed in late August). Do not treat it, at the time of writing, as a finished feature default-on for every user.

There is a third chain. Do not mix it with Siri: your app starts its own Foundation Models session. The model then runs in your process, you inject the tools, and the system will not pick “which app to open.” Framework notes:

Foundation Models.

WWDC 2026 also added Gemini as an optional external foundation model, alongside the earlier ChatGPT option. For users that is another door for world knowledge. For developers it barely changes the App Actions contract: an external model still cannot touch an Intent you did not declare.

App Actions: how Siri reaches your app

Users hear App Actions: what Siri can do to this app. Developers ship App Intents. To let Siri AI orchestrate an action, you also align it to an App Schema (assistant schema) so the system’s pretrained model recognizes the category of action.

Apple’s WWDC26 line is blunt: Siri got stronger because of Apple Intelligence; the way developers participate in Apple Intelligence is App Intents. The session

Build intelligent Siri experiences with App Schemas

folds Siri’s capabilities into three things: access your entities, take action through Intents, and understand on-screen context.

App Intents are a capability catalog

To the system agent, an app is not “open it and look around.” It is a discoverable catalog of capabilities. You declare action names, natural-language descriptions, parameter types, and results with AppIntent. Spotlight, Shortcuts, Siri, and Apple Intelligence share that catalog. When someone says “mark this invoice paid,” the system must map the utterance to your MarkInvoicePaidIntent — not let the model tap around the UI.

Docs:

App Intents

and

Integrating actions with Siri and Apple Intelligence.

App Schemas teach Siri the category

A plain App Intent can already show up in Shortcuts. For Siri AI to call it in natural language, you mark the Intent, Entity, and Enum with an assistant schema — photos.openAsset, notes.createNote, and so on. The schema has a fixed argument shape. Xcode checks the match at compile time.

That is the largest gap versus an open agent. Open-agent tool names are yours. Siri AI tool names must land in a domain vocabulary Apple already trained. Pick a more “creative” action name and the system may never select it.

@AppIntent(schema: .finance.markInvoicePaid)
struct MarkInvoicePaidIntent: AppIntent {
    @Parameter var invoice: InvoiceEntity
    @Parameter var paidAt: Date

    func perform() async throws -> some IntentResult {
        try await InvoiceService.markPaid(
            id: invoice.id,
            paidAt: paidAt
        )
        return .result()
    }
}

There is no JSON in that snippet. Siri hands you typed parameters. You do the work in perform(). If you need the network, the domain service encodes JSON next.

Do not start testing from Siri. Apple ships AppIntentsTesting so you can invoke an Intent in isolation, pass arguments, and assert the result. Then check the shape in Shortcuts. Only then give Siri the end-to-end path. Reverse that order and it feels like “the model is being random,” when the schema never matched.

Data flow of one cross-app task

String the layers with one request. The user sees “potluck Friday, you bring salad” in Messages, points at that text, and tells Siri: put it in Notes, then add lettuce and olive oil to the shopping list.

1. 1
   Screen context enters the system

   Through onscreen awareness, Siri knows “this” is a message. Your views must connect to an App Entity so the system can resolve the reference — not guess at pixels.

2. 2
   The model only plans and picks

   The system model splits the utterance into two steps: a create action in Notes, an add-item action in Shopping. It does not invent URLs or write SQL.

3. 3
   Fill arguments against the schema

   Title, date, and item names become typed values. If a slot is missing, Siri asks again. The contract on this step is the assistant schema, not your OpenAPI document.

4. 4
   Each app runs perform()

   Notes and Shopping each run their own Intent. HTTP JSON appears only if that work must sync to a server.

5. 5
   Results return to the system session

   Siri composes the reply from Intent results. Cross-app entity handoff can use Transferable instead of dumping a full JSON document into the conversation.

The usual traps on this path: an Intent that does everything; a description so broad the model fires on every request; or perform() returning a full order JSON and blowing the system context window. Return a summary. Fetch detail with a second action by id.

JSON’s three roles on this chain

Swift types are the compile-time contract. JSON is the runtime contract. The Siri hop can have no JSON at all. The moment the action leaves the process — backend, file, test fixture, another agent — the shape must become language-agnostic text.

JSON plays at least three roles. Mix two of them and you get “it parses, but every field is wrong.”

Layer one is the easiest to skip. Xcode’s App Intents Console prints invocations and arguments. You need to write that same call as a JSON object or debugging has no replay. Layer two is where billing and auth actually happen. Layer three is already common in 2026: the same markPaid serves Siri and an internal Claude agent.

JSON Schema does not replace App Schema. App Schema is the domain contract for the system model. JSON Schema is the data contract for your backend, tests, and external models. Fields should align. Do not imagine Siri will read your OpenAPI file. Why the AI side needs this contract at all:

Why does AI need JSON Schema?

What to compare with Function Calling / MCP

Compare one thing: what the decision is serialized into.

In an open agent, the model API returns JSON: the chosen tool name plus arguments that fit parameters. The runtime validates, then executes. MCP puts the same shape on inputSchema / structuredContent. Details:

Why do AI Agents need JSON Schema? From tool calling to structured output.

{
  "type": "function",
  "function": {
    "name": "mark_invoice_paid",
    "description": "Mark one invoice as paid.",
    "parameters": {
      "type": "object",
      "required": ["invoice_id", "paid_at"],
      "properties": {
        "invoice_id": { "type": "string" },
        "paid_at": { "type": "string", "format": "date-time" },
        "amount_cents": { "type": "integer", "minimum": 0 },
        "currency": { "type": "string", "enum": ["USD", "CNY", "EUR"] }
      },
      "additionalProperties": false
    }
  }
}

Siri AI has no such JSON. The equivalent is @AppIntent(schema:) plus @Parameter. The model is still “pick an action, fill slots.” Only the serialization format became a typed system call.

So do not wrap an App Intent in another layer of “make Siri output JSON.” Extra prompting does not make the system more stable; it just removes type checking from your debug path. The stability you want happens after perform(): can the object the domain service received encode losslessly into the arguments object above?

The choice is concrete. Users already on Apple devices, actions that fit a system catalog: Siri AI. Actions reused by Android, the web, or an internal Slack bot: Function Calling plus MCP. Do not draw both chains as one “universal agent” diagram just to say you have an agent.

What the JSON looks like at your HTTP API

Should the Intent hit the network? Short actions can finish inside perform(). Once you have auth, pagination, or idempotency, perform() only validates parameters and calls your domain service; the service sends the JSON request.

Below is the payload when “mark invoice paid” hits the backend. Field names are typical of an internal billing system. The numbers are examples, not a real bank API.

{
  "action": "invoices.markPaid",
  "source": "siri-ai",
  "idempotency_key": "inv_1842:paid:2026-09-09",
  "arguments": {
    "invoice_id": "inv_1842",
    "paid_at": "2026-09-09T02:14:00Z",
    "currency": "USD",
    "amount_cents": 12800
  }
}

With this object you can answer three questions: who triggered it, whether it can replay, and whether the money matches. Missing idempotency_key means one Siri retry marks the invoice paid twice. If amount_cents becomes a string, every report downstream drifts.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": ["action", "source", "idempotency_key", "arguments"],
  "properties": {
    "action": { "const": "invoices.markPaid" },
    "source": { "type": "string", "enum": ["siri-ai", "shortcuts", "app"] },
    "idempotency_key": { "type": "string", "minLength": 8 },
    "arguments": {
      "type": "object",
      "required": ["invoice_id", "paid_at"],
      "properties": {
        "invoice_id": { "type": "string", "minLength": 1 },
        "paid_at": { "type": "string", "format": "date-time" },
        "amount_cents": { "type": "integer", "minimum": 0 },
        "currency": { "type": "string", "enum": ["USD", "CNY", "EUR"] }
      },
      "additionalProperties": false
    }
  },
  "additionalProperties": false
}

The system agent does not need your REST path. It needs Intent success or failure. You need the path, because audit and retries live at the API layer. Design Intent parameters as a field set that can be written as a JSON object and the open-agent adapter gets much cheaper.

Validate Action arguments in JSONNote

The slow part is rarely the Swift macro. It is two calls whose JSON does not match: Siri retried with an extra field, Shortcuts dropped an enum, an internal agent wrote amount_cents as 128.00. JSONNote stays in the browser:

1. 1
   Format one call first

   Paste the object from the App Intents Console or backend logs into the JSON formatter to strip indent and syntax noise.

2. 2
   Pin required fields with a schema

   Paste the draft on the JSON Schema page and confirm action, idempotency_key, and invoice_id are still there.

3. 3
   Diff a Siri call against an open-agent call

   Use JSON Diff to see whether source flipped from siri-ai to mcp, and whether arguments drifted.

4. 4
   Share only when a colleague needs it

   Use Hash sharing to put a sample (never secrets) in the URL fragment. The server never receives that data.

FAQ

Is Siri AI an AI Agent?

It is a system agent, not an open agent. It can pick actions, fill arguments, and chain work across apps, but the catalog is pinned by App Intents and App Schemas. The model cannot invent APIs.

Are App Actions and App Intents the same thing?

Not one product name. App Actions is the user- and system-facing phrase: what Siri can do to an app. Developers ship App Intents, then align them to an App Schema so Siri recognizes the category of action.

Will Siri hit my REST API directly?

No. Siri only calls Intents you declared. Your perform() method then makes its own HTTP calls. The system agent wants success or failure semantics; billing, auth, and retries live at your API layer.

Apple uses Swift types. Why still write JSON Schema?

Swift types cover compile time. Once an action leaves the process — backend calls, logs, test replay, reuse by an external agent — the shape must become language-agnostic JSON. Schema checks that hop, not the Siri hop.

Should I use Siri AI or build my own Function Calling agent?

If users are already on iPhone and the action fits a system catalog, use Siri AI. If the action must cross clouds, platforms, or your own model choice, use Function Calling plus MCP. The same domain functions can serve both chains; only the adapter changes.

Summary

Siri AI will become an agent — the agent inside the operating system, not an open runtime where you mount tools at will.

Apple Intelligence supplies the model. App Actions (App Intents + App Schemas) supply orchestratable actions. JSON is the contract after those actions leave the device.

Design Intent parameters as fields that can be written as a JSON object, then hang the same Schema on the Siri chain and the Function Calling chain. Models and system entry points will keep changing. Validation is the moat from demo to production — format, validate, and diff that JSON locally in JSONNote. Nothing needs to be uploaded.

← Back to blog