Mental Model & Principles
Start with the job
you need done.
Before choosing a model or a framework, work out what a good result requires: the right information, appropriate actions, and a way to check the outcome.
- Understand
the work↓ - Identify what
it requires↓ - Decide how
to build it
What would a capable
teammate need?
A person can understand the request immediately and still lack what they need to carry it out. Start by making those requirements visible.
“Arrange a 30-minute meeting for
Maya, Arun, and me next week.”
The right meeting exists.
A suitable 30-minute event appears on the right calendars.
Know what fits.
Current availability, time zones, and scheduling preferences.
Be able to do the work.
Read availability, propose a time, and create the event.
Verify the result.
Correct people and time, plus evidence that creation succeeded.
What can the system do with what it has?
Keep the task and the model the same. Add the support the job requires, one step at a time.
The request
Task understoodThe system can interpret or clarify the request. It has no evidence of a shared available time.
+ Current information
A slot can be proposedCalendar availability and time zones make a shared slot identifiable. A proposal does not create an event.
+ Authorized access
Booking can be attemptedThe app can allow a specific booking action. Sending the request still leaves its outcome unconfirmed.
+ Returned result
The outcome can be checkedThe booking service returns the event details. Check the people and time before reporting success.
One excerpt of the week · all times shown in UTC
Tuesday · 10:30–11:00 UTC
Maya · Arun · YouIn the authorized stage, all three have allowed this booking on their calendars. Event creation does not imply that attendees have accepted an invitation.
What needs to be known at this step?
Some facts arrive with the request. Others change, live elsewhere, or do not exist until an action finishes. Connect each question to a source and a moment.
Give each part the right job.
Where does AI help?
AI may help interpret a flexible request or explain a choice. Ordinary software rules can find overlapping slots and enforce allowed hours.
Interpret the preference;
ask if it is ambiguous.
Compare time intervals and apply constraints.
A good outcome can be a question.
Missing a preference? Ask. Outside the system’s authority? Stop or hand over. Build these outcomes into the workflow.
Three failures. Three different fixes.
More information solves only some problems. Find where the work went wrong.
Missing facts
Arun’s calendar was never read.
Improve access to information.Wrong decision
The calendars were correct; the chosen slot overlapped a meeting.
Examine rules and reasoning.Unsuccessful action
The time was suitable; the booking service rejected the request.
Handle the failure. Check state.Try it on your feature.
Write these five lines before you choose the architecture. An unanswered item is a design question.
Outcome wanted: ______________________________
Decisions needed: ____________________________
Information and source: ______________________
Allowed actions: _____________________________
Evidence of success: _________________________