Schedule a Meeting — Agentic CRD Example

Why is this a Capability MLE? It has an independent purpose (a meeting gets arranged), a determinable outcome (confirmed, or rejected with a reason), and it stays meaningful regardless of who or what resolves availability and confirms the time.

What does this example teach? That an agent taking control of a capability's flow (execution mode agent-primary-using-software) does not require a different capability, different contracts, or looser rules — only an explicit approval boundary before the agent's proposal becomes a committed calendar write.

Evidence status: illustrative / synthetic — written to demonstrate the model, not extracted from a real scheduling system.

Identity and core meaning

NameSchedule a meeting

DefinitionEnable a requester to have a meeting arranged with one or more other participants, resulting in a mutually available time being found and confirmed on the relevant calendars, or an intelligible reason why it could not be scheduled.

Capability purposeEnable a meeting between people to be arranged without the requester manually coordinating availability.

Meaningful outcomeA meeting is confirmed and placed on the calendars of all required participants, or the request is rejected or deferred with an identifiable reason.

IncludesResolving the intended participants; determining collective availability within stated constraints; proposing and confirming a time; placing the event on calendars; communicating the outcome.

ExcludesCreating participant contact records; rescheduling or canceling an existing meeting; the organizational calendar-permission system itself.

Interaction Contract MLEs

Request a meeting

Actor: Requester — a person, or an agent acting on a person's behalf.
Command / intent: Propose a meeting with named participants within given constraints (duration, timeframe, purpose).
Policies / invariants: A duration and at least one participant are required.
Transition: No request → pending scheduling attempt.
Result: Pending attempt acknowledged.
Events / effects: MeetingRequested

Resolve participant availability

Actor: The scheduling capability's own realization (agent or software).
Command / intent: Determine which time windows are available for all required participants within the requested constraints.
Policies / invariants: Only calendars this capability is authorized to read may be consulted.
Transition: Pending attempt → one or more candidate times, or a no-availability outcome.
Result: Candidate time(s), or an identifiable no-availability reason.
Events / effects: AvailabilityResolved

Confirm meeting time

Actor: The requester, or an authorized participant if confirmation authority is delegated.
Command / intent: Select and confirm one candidate time.
Policies / invariants: A meeting must not be placed on a calendar this capability is not authorized to write to.
Transition: Candidate time(s) → confirmed meeting.
Result: Confirmed meeting placed on calendars, or an expiry/decline outcome.
Events / effects: MeetingConfirmed, MeetingSchedulingFailed

Rules and defaults

Rules / invariants

A meeting must not be confirmed on a calendar the capability is not authorized to write to. Example.

Recommended defaults

If no single candidate time satisfies every participant's stated constraints, surface the closest partial match rather than only reporting failure. Example.

Unknown / unresolved

Exact availability-data source and freshness.
Participant-authorization model.
Conflict-resolution policy when constraints contradict.
Time-zone handling.

Two operational realizations — the point of this example

Realization A — agent-assisted scheduling assistant

Execution modeagent-primary-using-software

ExposureAgent, tool

Rationale / intentLet an agent interpret intent ("find 30 minutes with Markus next week") and operate tools directly, instead of the requester manually checking calendars.

Implementation requirementThe agent MUST obtain requester (or delegated-participant) confirmation before any candidate time is written to a calendar — the agent proposes, it does not unilaterally commit. This is the approval boundary that keeps agent-primary control distinct from unchecked agent autonomy.

Implementation referencesContact-resolution tool; availability-lookup tool; calendar-creation tool.

Realization B — traditional scheduling UI

Execution modesoftware-primary

ExposureUI

Rationale / intentA deterministic calendar-picker UI where the requester reviews a grid of participant availability and clicks to confirm — the same Confirm meeting time contract, no agent involved.

Optional: agentic mappings

Element	Kind	Relationship	Notes
Scheduling assistant	skill	realizes-capability	Realization A only.
contact-resolution tool	tool	supports-contract	Supports Request a meeting.
availability-lookup tool	tool	supports-contract	Supports Resolve participant availability.
calendar-creation tool	tool	supports-contract	Supports Confirm meeting time; Realization A only — Realization B writes the calendar entry directly from the UI.

Why this example matters

The earlier examples show a capability can be customer-facing, internal, or extracted from real multi-realization software. None of them puts an agent in control of the flow. This one does — while showing the exact boundary that keeps that safe: the agent may resolve availability and propose a time on its own, but confirming a meeting on someone's calendar is gated behind an explicit approval step, stated as an implementation requirement, not left as an assumed default.