---
name: Make several agents agree first
description: >-
  Teach an advanced Edge FDE to require weighted votes, a judge, or escalation
  before an Apple on-device app acts, using Dynamic Profiles and multiple
  LanguageModelSession values.
---
# Make several agents agree first

Use this course to stop a single session from taking a costly action alone.
Keep the words simple. Be honest: a Dynamic Profile switches one active
configuration inside one session. Parallel agreement needs more than one
session.

## End-to-end agent recipe

1. Start with [lesson 01](01-one-session-is-not-enough.llms.md). Name the cost of a single-session action and the gate that must sit in front of side effects.
2. Use [lesson 02](02-profiles-and-sessions.llms.md) for Dynamic Profiles versus several `LanguageModelSession` values.
3. Use [lesson 03](03-weighted-voting.llms.md) for weighted votes in app code.
4. Use [lesson 04](04-judge-and-escalation.llms.md) for a judge session and a human or safer fallback.
5. Use [lesson 05](05-gate-the-action.llms.md) to block tools until consensus passes.
6. Keep these links exact: [Pause and resume long AI jobs](../on-device-durable-workflows/), [Stop prompt attacks and leaks](../on-device-guardrails/), and [Talk to tools with MCP](../on-device-mcp-server-client/).
7. Cite [WWDC26 session 242](https://developer.apple.com/videos/play/wwdc2026/242/) and [Foundation Models](https://developer.apple.com/documentation/foundationmodels) when a source is needed.
8. Use the human HTML pages for the reader. Use the `.llms.md` briefs for agent steps and acceptance checks.

## Constraints

- Plain spoken English for a non-native reader.
- Literal sentences. No metaphor, no flourish, no quizzes.
- Do not use em dashes.
- Use no Mermaid. Build progressive `.flow` diagrams in HTML.
- Target iOS 27 or later, or macOS 27 or later, and Xcode 27.
- Teach in Swift with Dynamic Profiles and several LanguageModelSession values. Do not use Python for votes or the judge.
- Dynamic Profiles: one active Profile at a time. Use Apple's names baton-pass and phone-a-friend as API patterns, then explain them in literal words.
- Do not invent a Foundation Models vote API.

## Key concepts

- One session can draft. It should not alone approve a costly action.
- Dynamic Profiles switch one active seat. Parallel votes need several sessions.
- Weighted votes, a judge, and escalation are app code, not a Foundation Models vote API.
- Side-effect tools check a gate before they run.

## Takeaways

- You can run weighted votes across several sessions and tally in Swift.
- You can stop on split or escalate and show a person before money moves.
- You can keep side-effect tools off voter sessions.

## Acceptance checks

- Every human lesson HTML has **Key concepts** and **Takeaways** sections before lesson-nav. The course home has the same two headings for the whole course.
- Five human lessons exist with the requested basenames.
- Five matching `.llms.md` briefs exist and link to their human HTML pages.
- Every human lesson has its Agent brief link and the three sibling-course links.
- The course index lists all five lessons, the course SKILL.md, and all five briefs.
- Diagrams are progressive HTML `.flow` elements. There is no Mermaid, no em dash, and no quiz.

## Environment setup

Xcode 27 on a Mac. SwiftUI app, iOS 27 or macOS 27. Add Foundation Models. The vote and judge types are app code, not a project you must run.