Use these notes to review a concept or read at your own pace. The interactive workspace above adds predictions, editable code, and actual run results.
IDEA 1
A time estimate is a constraint you can inspect
Represent time as integer minutes from the start of a fictional afternoon. A block from 0 to 30 contains 30 usable minutes. A task with duration 20 occupies a half-open interval: it includes its start and finishes at its end, so another task may begin exactly then.
The task's duration is an estimate supplied by the exercise. The planner must not shrink it to make the schedule look better. A deadline is the latest permitted finish, and a gap between allowed blocks is unavailable time, even if the planner would find it convenient.
Fit a task into a real gap
- Available block. The first 30 minutes are available for work.
- Task. A 20-minute outline must finish by minute 25.
- Check. The finish must fit both the block and deadline.
- Reserve. Advance this block's cursor so the next task cannot overlap.
Authored classroom schedule; minutes are offsets, not access to a real calendar.
Two bounds on one finish
const finish = cursor + task.minutes;
const fits = finish <= block.end && finish <= task.deadline;The same candidate finish is checked against two different constraints. Meeting a deadline does not prove that the time block has enough space, and fitting a block does not prove timely completion.
Think it through: A task fits from minute 20 to 40, but its deadline is 35. What should the planner do?
IDEA 2
Propose, then independently check the schedule
Our baseline sorts tasks by deadline and tries the earliest available block with enough remaining space. This is a simple greedy workflow: it makes one local choice at a time without exploring every possible schedule. It is useful to inspect, but it does not guarantee the largest possible number of scheduled tasks.
After planning, separate tools check overlaps and deadlines. An unscheduled task remains in the output with a reason. That gives the learner a concrete next move: change an estimate or available block and rerun, rather than trust a claim that everything is handled.
Leave a visible trail of decisions
- Order. Earlier deadlines receive the first attempt at a slot.
- Propose. Keep each task's exact start and end.
- Verify. Check the finished draft against independent fixture rules.
- Explain gaps. Retain work that could not fit before its deadline.
This deterministic planner proposes a draft; it does not do homework or change a calendar.
Respect a blocked period
const blocks = [{ start: 0, end: 20 }, { start: 35, end: 60 }];
// No placement may cross the unavailable interval [20, 35).Separate allowed blocks encode the unavailable interval. The planner tries each block without joining them into one larger slot. A 30-minute task fits neither block even though their total duration exceeds 30.
Think it through: Why keep an unscheduled list?
Put it into practice
Return a proposed schedule, unscheduled task IDs and reasons, and independent overlap/deadline checks.
- Read the task estimates, deadlines, and separate allowed blocks.
- Run the starter: its placeholder prevents any task from being placed.
- Insert the two finish constraints in the placement condition.
- Run all cases and inspect the independent checks after planning.
- Increase one task's minutes in the experiment and identify what no longer fits.
Your next experiment: Increase sketch from 25 to 26 minutes. Which exact boundary stops it fitting?
A useful study draft shows its assumptions, verifies its intervals, and leaves infeasible work visible.
Key terms
- Greedy workflow
- A method that makes one locally suitable choice at a time without exploring all possible combinations.
- Half-open interval
- A time range that includes its start and excludes its end, allowing the next task to begin exactly when it finishes.
Sources and scope
Original Stemtiq teaching, reviewed 2026-09-14. The named researchers and organizations do not endorse this course. Classroom cases are authored exercises, not published findings.
MDN Web Docs: JavaScript Guide
Updated 7 November 2025
Functions, objects, conditions, loops, and asynchronous code provide the programming foundations for an agent controller.
Ordinary JavaScript rules do not imply that a language model is running. An execution environment may support only part of the language or its host APIs.
Anthropic: Building effective agents
19 December 2024
Distinguish fixed workflows from model-directed actions; start simply, use tool observations as feedback, and set stopping conditions.
The article notes that its tooling landscape has changed. Its patterns do not establish that a more autonomous or complex system is better for every task.
Anthropic: Demystifying evals for AI agents
9 January 2026
Define tasks, trials, and graders; inspect both execution records and final outcomes; repeat trials when model behavior varies.
A score depends on its cases and grading rules. Repeating a deterministic classroom case does not measure the variability of a live model.