Skip to content
Ivan Magda
Go back

The Agent Abstraction, Top to Bottom: Dynamic Profiles in Your App, Plugins in Xcode

Suggest Changes

This week we’re building two things at once. Inside our app, we’re wiring up an on-device feature with the Foundation Models framework. In Xcode, we’re letting a coding agent help us build it. Two jobs, two sets of docs, two WWDC sessions — easy to treat as unrelated. They aren’t, and once we see the idea in one place we’ve mostly seen it in the other.

The shape, in one sentence

An agent is a small set of swappable parts — some instructions, a few tools, a model — composed over one shared context. That’s the whole shape. Whether the agent lives inside our app or inside our editor, it holds, and WWDC 2026 gave it first-class APIs on both sides of the boundary at once: Dynamic Profiles in the app, plugins in Xcode. Let’s look at each, then at why they’re the same thing.

Inside the app: Dynamic Profiles

A Dynamic Profile is a declarative unit we attach to a LanguageModelSession. Instead of pinning a session to one model, one tool set, and one instruction block, we write a body that resolves to a single profile per turn and switch profiles as the app’s state changes (Composing dynamic sessions with instructions and profiles):

struct OrigamiProfile: LanguageModelSession.DynamicProfile {
    var pccModel = PrivateCloudComputeLanguageModel()
    var state: AppState

    // The builder enforces exactly one active profile per model turn.
    var body: some LanguageModelSession.DynamicProfile {
        switch state {
        case .brainstorming:
            Profile { BrainstormInstructions() }
                .model(pccModel)
                .temperature(0.9)
        case .tutorial:
            Profile { TutorialInstructions() }
                .model(pccModel)
                .reasoningLevel(.deep)
        case .explainTerm:
            Profile { JargonInstructions() }   // on-device model, to save server calls
        }
    }
}

let session = LanguageModelSession(profile: OrigamiProfile(state: appState))

The body re-evaluates before each request, and every profile shares one continuous transcript — so switching the model mid-session keeps the context intact (a profile can even thin the history it sends with a historyTransform before a small on-device model sees it). Apple’s own framing gave the game away: three profiles “look a bit like three AI agents,” and that’s the intent — profiles are the unit we build agents and skills out of (Build agentic app experiences with the Foundation Models framework, WWDC26).

Inside Xcode: plugins, skills, and ACP

Now the editor. Xcode 27’s agents run on a corpus of specialists — SwiftUI, accessibility, sizing, testing, performance — and each specialist ships as a plugin. A plugin carries skills (markdown files that teach a task), tools exposed through the Model Context Protocol, and, new this year, an agent of our choice through the Agent Client Protocol (Xcode, agents, and you, WWDC26).

Set the two lists next to each other and they rhyme term for term. A skill is a markdown capability in Xcode and a swappable instruction block in a profile. A tool is an MCP function in the editor and a Tool value in a session. A sub-agent is an ACP-brought agent in Xcode and a profile we switch to in the app. Both build from small replaceable parts over a shared context, never one monolithic prompt.

We’ve wired these joints by hand before

None of this reads as coincidence if we’ve built the primitives ourselves. The Building a Coding Agent in Swift series spent whole posts on exactly these units — subagents as context-isolated loops with restricted tools, and skill loading as markdown knowledge surfaced on demand. Doing it by hand is what makes “skill,” “tool,” and “sub-agent” stop looking like three features and start looking like joints of one design. Apple has now cast those joints as APIs. And the choice each profile makes — a cheap local model or a capable remote one — is the per-feature decision that Three Ways to Run a Model on Apple Platforms is entirely about, except a profile makes it turn by turn.

One shape, learned once

“Agent” isn’t a thing Apple shipped this year. It’s a shape — swappable instructions, tools, and models over shared context — that finally has APIs on both sides of the IDE. The real win is that the judgment transfers: what we build deciding which tools a sub-agent should see, or when to compact a transcript, is what we spend on a profile’s body and on which specialists we hand an Xcode agent. Learn it once, apply it twice. Thanks for reading!


Suggest Changes
Share this post on:

Previous Post
An Agent Framework Hiding Inside a Session: Dynamic Profiles in Foundation Models