How this path works
What this solves
This version treats scheduling as a supervised delegated workflow. Codex is not simply giving advice; it is working through a small scheduling process with tools, rules, and approval gates. The human still approves the final action.
Best fit
Use this when scheduling is frequent, messy, and worth delegating. This is not the first version to build if the team only needs one meeting a month. It is for people who repeatedly coordinate groups, review meetings, project calls, or leadership sessions.
The core idea
Codex works from a small scheduling workspace. That workspace contains the team list, scheduling rules, a script or connector that can check Outlook availability, and a log of recommendations. You ask in plain English. Codex runs the checker, interprets the results, drafts the invite text, and asks you to approve the next step.
Step 1 - Create the scheduling playbook
Write a plain-English playbook that Codex can follow. Include who is normally required, who can be optional, normal working hours, preferred days, protected focus time, lunch rules, meeting lengths, and what to do when no perfect slot exists. Keep this short and explicit. The playbook is the agent's operating manual.
Step 2 - Create the team file
Create a simple file with the eight attendees: name, email, role, required or optional, and any known preference. A layman version can be a spreadsheet. A technical version can be a small JSON or CSV file. The important thing is that Codex is not guessing who belongs in the meeting.
Step 3 - Give Codex a safe tool
Codex needs a way to check availability. The safest first version is a read-only availability checker using Microsoft Graph free/busy data. It should read calendars, calculate candidate slots, and write results to a local file. It should not send invites or edit calendars in the first version.
Step 4 - Ask in plain English
Use a request like: Find 45 minutes next week for the full team. Avoid Monday morning and anything after 15:30. Prefer Tuesday to Thursday. Give me the best three options and explain any trade-offs.
Step 5 - Let Codex run the process
Codex reads the playbook, checks the team file, runs the availability checker, reviews the returned slots, and explains the recommendation. A good answer should say which slot is best, why it is best, what the backups are, and whether any attendee creates a constraint.
Step 6 - Approval before action
Codex should then ask for approval. In the first deployment, approval means it drafts the invite title, agenda, attendee list, and message for you to paste into Outlook. In a later deployment, approval could allow Codex to create a draft invite or hold a slot, but it should still stop before sending unless you explicitly permit it.
Step 7 - Keep an audit trail
Every run should record the request, date range, attendees, recommended slot, backup slots, and final human decision. This matters because scheduling decisions can affect people. The agent should be explainable.
What to expect
The experience should feel like asking a capable coordinator: here is the problem, here are the constraints, find the best options, and prepare the next action. The value is not just speed. It is that the coordination work can move while you focus elsewhere.
Guardrails
Keep calendar access read-only at first. Do not allow automatic sending. Store secrets outside the content files. Do not expose private meeting subjects unless the organisation has approved that level of access. Prefer free/busy status over full calendar detail where possible.
Failure points
The agent is only as good as the playbook and permissions. If rules are vague, it may suggest socially awkward times. If permissions are missing, it cannot check calendars. If approval gates are skipped, it becomes risky.
What good looks like
A strong run ends with a short recommendation: Best slot: Wednesday 10:00-10:45 because all required attendees are free and it sits inside core hours. Backup one: Thursday 14:00-14:45. Backup two: Friday 09:30-10:15. Draft invite prepared; awaiting approval.