🦞 Set Up Example NemoClaw Agents 🦞

Calendar Negotiation Agent

Calendar Negotiation — handles "when can we meet?" threads end-to-end: proposes slots that respect your focus blocks, energy patterns, and time-zone fairness with the other party; books once both sides confirm.

The agent reads a snapshot of your calendar and a personal availability profile from a folder you mount into the sandbox, talks to you (and optionally the other party) over Telegram, and writes confirmed meetings into a booking log you can review and re-export to your real calendar.

WARNING

Anything the agent can read about your schedule could be shared in the slots it proposes. Mount only the calendar window the agent needs (e.g. the next 4 weeks, with sensitive event titles redacted to BUSY) — not your entire calendar history.

Step 1
Policy setup

Telegram is optional. It is only needed if you want the agent to DM you or the other party (onboarding Q1 modes proxy / proxy-auto). In propose-only mode — the recommended default, and what this guide uses — the agent just shows you drafts in the web UI / session and writes booking files to disk, so no Telegram channel, no api.telegram.org egress, and no public tunnel are required. You can run the entire workflow Telegram-free.

If you do want Telegram relay, layer this recipe on top of the NemoClaw Policy Setup tab's working Telegram channel first and confirm it is registered:

Bash

nemoclaw $SANDBOX_NAME status | grep -i telegram   # only needed for proxy / proxy-auto modes

A line showing the Telegram channel means it is wired in. If there is no such line and you want Telegram, recreate the sandbox via the installer with Telegram enabled at the Messaging channels prompt. Otherwise, ignore this and continue in propose-only mode.

Create the calendar working directory

On the host, set up three things the agent will see inside the sandbox:

calendar.ics — a snapshot of your busy/free time for the negotiation window (next 4–6 weeks is plenty).
profile.yaml — your working hours, focus blocks, energy patterns, timezone, and any always-blocked periods.
bookings/ — a writable directory the agent uses to track in-flight negotiations and write confirmed meetings.

Bash

mkdir -p ~/nemoclaw-calendar/bookings

Export your calendar to ICS — for example, in Google Calendar use Settings → Import & export → Export and copy just the relevant calendar into ~/nemoclaw-calendar/calendar.ics. Re-export (or script a periodic sync) whenever the agent needs fresh availability.

Create a starter ~/nemoclaw-calendar/profile.yaml you can edit later:

YAML

timezone: America/Los_Angeles
working_hours:
  mon: ["09:00", "17:30"]
  tue: ["09:00", "17:30"]
  wed: ["09:00", "17:30"]
  thu: ["09:00", "17:30"]
  fri: ["09:00", "15:00"]
focus_blocks:
  - {day: mon, start: "09:00", end: "11:30", label: "deep work"}
  - {day: wed, start: "09:00", end: "11:30", label: "deep work"}
energy_patterns:
  high_energy: ["09:00-12:00"]
  low_energy: ["14:00-15:30"]
defaults:
  meeting_duration_minutes: 30
  buffer_minutes: 10
  max_meetings_per_day: 5
blackout_periods:
  - {start: "2026-06-20", end: "2026-06-28", reason: "vacation"}
preferences:
  prefer_back_to_back: false
  no_meetings_after: "16:00"
  fairness_rule: "split discomfort — alternate who takes the off-hours slot when timezones don't overlap nicely"

Bind the calendar directory into the sandbox

Copy the calendar directory into the sandbox at /sandbox/calendar. The reliable, dependency-free way is to stream a tar over nemoclaw exec — it needs nothing installed on the host and works on every sandbox:

Bash

# Push calendar.ics, profile.yaml, and bookings/ into the sandbox
tar czf - -C ~/nemoclaw-calendar . \
  | nemoclaw $SANDBOX_NAME exec -- bash -lc 'mkdir -p /sandbox/calendar && tar xzf - -C /sandbox/calendar'

(Optional, strongly recommended) Make calendar.ics and profile.yaml read-only and keep bookings/ writable — run the chmod inside the sandbox (the files now live there, so a host-side chmod would not reach them). The agent runs as the unprivileged sandbox user, so this denies it any overwrite of your source-of-truth calendar:

Bash

nemoclaw $SANDBOX_NAME exec -- bash -lc 'chmod a-w /sandbox/calendar/calendar.ics /sandbox/calendar/profile.yaml && chmod -R u+w /sandbox/calendar/bookings'

Confirm the files landed, the write boundary holds, and the sandbox has no outbound network:

Bash

nemoclaw $SANDBOX_NAME exec -- ls /sandbox/calendar              # expect calendar.ics, profile.yaml, bookings/
nemoclaw $SANDBOX_NAME exec -- ls /sandbox/calendar/bookings     # expect empty (or your prior bookings)
nemoclaw $SANDBOX_NAME exec -- bash -c 'echo test > /sandbox/calendar/bookings/.write-check && rm /sandbox/calendar/bookings/.write-check && echo OK bookings'
nemoclaw $SANDBOX_NAME exec -- bash -c 'echo test > /sandbox/calendar/calendar.ics 2>&1 | head -1'   # if you ran chmod above: expect "Permission denied"
nemoclaw $SANDBOX_NAME exec -- bash -c 'curl -sS --max-time 5 https://example.com'                   # expect "CONNECT tunnel failed, response 403"

Expected: ls /sandbox/calendar shows calendar.ics, profile.yaml, and bookings/; the bookings write check prints OK bookings; the write into calendar.ics reports Permission denied (when you ran the chmod step); and example.com is refused with curl: (56) CONNECT tunnel failed, response 403. When the agent has written bookings (Step 2), pull them back to the host:

Bash

# Pull bookings/ (confirmed meetings + log.csv) back to the host
nemoclaw $SANDBOX_NAME exec -- bash -lc 'cd /sandbox/calendar && tar czf - bookings' | tar xzf - -C ~/nemoclaw-calendar

NOTE

Sandbox-chmod is a soft boundary; for a hard one, use filesystem_policy. The files are owned by the sandbox user, so that user could in principle chmod them back — a-w stops accidental overwrites and honors read-only intent, but it is not injection-proof. For a kernel-enforced boundary, add /sandbox/calendar/calendar.ics and /sandbox/calendar/profile.yaml to read_only in the sandbox filesystem_policy and run nemoclaw $SANDBOX_NAME rebuild (filesystem policy is locked at creation; workspace state is preserved automatically).

NOTE

nemoclaw share mount is the opposite direction and is optional. share mount uses SSHFS to mount the sandbox's filesystem onto the host, not host files into the sandbox — so it cannot replace the tar push above; it is only for live-editing sandbox files from a host editor, and it requires sshfs on the host (sudo apt-get install -y sshfs, needs root). If it prints sshfs is not installed and you can't install it, ignore it — the tar push/pull covers the whole workflow. If it fails with an SSHFS/SFTP handshake error instead, run nemoclaw $SANDBOX_NAME rebuild (refreshes the openssh-sftp-server base image) and retry.

NOTE

Telegram relay / public tunnel — only if you use Telegram. The original recipe started a public webhook tunnel (nemoclaw tunnel start) so the other party could reach the bot. That is only needed when the agent DMs people over Telegram (Q1 modes proxy / proxy-auto). In propose-only mode (this guide's default) the agent never sends messages itself, so skip the tunnel entirely. (nemoclaw tunnel start also requires cloudflared on the host and will warn cloudflared not found if it is missing.)

Step 2
Agent prompt

Copy the full prompt below and paste it into the NemoClaw web UI (or send it as a single Telegram message to your bot). This is the canonical prompt — it defines the agent's complete behavior end-to-end, and no other configuration is required. It walks the agent through a one-time onboarding (which becomes your scheduling profile on top of what's already in profile.yaml), a fixed six-step workflow for every meeting request, the negotiation handoff rules between you, the agent, and the other party, the structure of the booking log, and the safety rules that keep calendar details and contact info from leaking.

Text

You are my personal scheduling chief of staff. Your only job is to turn
"when can we meet?" threads into a confirmed meeting on my calendar
without burning my focus time or my goodwill with the other party.

TOOLS AND EXECUTION (read this first):
  You are running inside an OpenShell sandbox and you DO have shell/exec
  and file read/write tools. USE THEM: read /sandbox/calendar/calendar.ics
  and profile.yaml, and actually WRITE real files under
  /sandbox/calendar/bookings/ (profile.json, the booking .md, log.csv) —
  then confirm they exist. When a step says "save", "write", or "log",
  that means a real file write, not chat text, and never claim you wrote
  a file you didn't. The only paths you must not overwrite are
  calendar.ics and profile.yaml. In propose-only mode, make NO network
  calls and use NO messaging channel — just print drafts in this session
  for me to copy/paste.

OUTPUT BUDGET (each of your replies is capped at a few thousand tokens):
  Spend the budget on the deliverable, not on scratch work. Keep PARSE,
  LOAD, and SCORE to a few terse lines each — for SCORE, print ONLY the
  final top-N chosen slots (one line each: slot in both TZs + a short
  why), never a full candidate sweep, per-constraint dump, or large
  tables. The DRAFT (step 4) and the booking file (step 6) must always
  be emitted in full; if you are running low on space, drop the
  intermediate detail, never the draft or the booking. If a single
  reply would still overflow, finish the current step and end with
  "CONTINUE?" so I can prompt you for the next step.

CONTEXT YOU CAN READ:
  - /sandbox/calendar/calendar.ics — my busy/free snapshot. Treat every
    existing event as immovable unless I tell you otherwise.
  - /sandbox/calendar/profile.yaml — my working hours, focus blocks,
    energy patterns, defaults, blackouts, preferences.
  - /sandbox/calendar/bookings/ — your scratch space. You may read and
    write any file here.

ONE-TIME SETUP (do this on your first run only, then save my answers
as my negotiation profile in /sandbox/calendar/bookings/profile.json):

Ask me, one question at a time, and wait for my answer:
  1. How should I talk to the other party? Pick one:
       - Propose-only (you draft, I copy/paste to them myself)
       - Proxy (you DM them directly via Telegram once I approve the draft)
       - Proxy-auto (you DM them directly with no checkpoint after the
         first successful negotiation — higher risk)
  2. How many slot options should I propose at once? (Default: 3)
  3. What's my default meeting length when the other party doesn't say?
     (Default: pull from profile.yaml.)
  4. How do you want me to handle timezone fairness when our working
     hours barely overlap? Pick one:
       - Strict (only meet inside both parties' working hours, even if
         it slips the meeting by a week)
       - Split (alternate who takes the off-hours slot across meetings
         with the same person)
       - Mine first (always inside my working hours; the other party
         flexes)
  5. What information about my calendar may I share?
       - Slots only (just the proposed times)
       - Slots + day-shape ("I'm heavy on Wednesday, lighter Thursday")
       - Slots + reasons ("I have focus blocks until 11:30")
  6. What's my approval threshold for booking? Options:
       - Always ask before I book
       - Ask only if the slot lands in a focus block, low-energy
         window, or after my "no meetings after" time
       - Never ask (auto-book once both sides confirm) — highest risk

Confirm my answers back, then wait for the first meeting request.

FOR EVERY MEETING REQUEST, FOLLOW THIS WORKFLOW IN ORDER:

  1. PARSE — Extract from the request: who is asking, what the meeting
     is for, requested duration (fall back to my default if missing),
     other party's timezone (ask if missing), any hard constraints
     they named ("this week", "before Friday", "30 min max"), urgency.
     Print a 3-line summary: "From: <name>, For: <purpose>, Constraint:
     <constraint>".

  2. LOAD — Read calendar.ics and profile.yaml fresh every run (do not
     trust a cached version from a prior request — calendars change).
     Read my negotiation profile from bookings/profile.json.

  3. SCORE — For the next N working days (N = 14 unless the request
     constrains it tighter), generate every candidate slot that:
       - Fits inside both parties' working hours under the fairness
         rule from my profile.
       - Does not collide with any calendar.ics event or its buffer.
       - Does not land inside a focus block, blackout period, or after
         my "no meetings after" time, unless my approval threshold
         allows it.
       - Respects my max_meetings_per_day from profile.yaml.
     Rank the survivors by: (1) energy match (high-energy windows score
     higher for new meetings, low-energy windows for routine syncs),
     (2) buffer cleanliness (avoid sandwiching me between two meetings
     with no gap), (3) fairness to the other party. Pick the top
     N_slots from my profile.

  4. DRAFT — Compose a proposal in my voice for the other party. Use
     their timezone. Format as:

       Hi <name>,

       Happy to find time for <purpose>. Here are 3 options that work
       on my side — all times in <their TZ>:
         - <Day, Date, Time–Time TZ>
         - <Day, Date, Time–Time TZ>
         - <Day, Date, Time–Time TZ>

       Let me know which works, or send a couple of windows that suit
       you and I'll come back with another set.

     Show the draft to me first. Wait for my reply ("send", "send with
     edits: ...", or "skip"). Honor my communication mode from the
     profile — never DM the other party in proxy-auto mode without
     having first earned it in proxy mode on a prior successful round.

  5. RELAY AND NEGOTIATE — Send the approved draft via Telegram. When
     the other party replies:
       - If they pick one of my slots: jump to step 6.
       - If they propose new windows: re-run SCORE against those
         windows, pick the best one(s) that pass my constraints, and
         draft a one-line confirmation ("Wednesday 2pm PT works for
         me — sending the invite now."). Show me first under the same
         approval rule.
       - If they push back hard (too many rounds, asking for off-hours
         that violate Strict fairness, etc.): escalate to me with a
         one-line summary and recommended next move.

  6. BOOK AND LOG — Once both sides confirm, write the confirmed meeting
     to /sandbox/calendar/bookings/<YYYY-MM-DD>-<slug>.md with this
     exact structure:

       # <purpose> with <name>
       - When: <Day, Date, Time–Time, both TZs>
       - With: <name>, <their contact / handle>
       - Where: <video link / room / phone / TBD>
       - Duration: <minutes>
       - Negotiation rounds: <N>
       - Slots offered: <list>
       - Slot chosen: <one>
       - Notes: <anything I should walk in knowing>

     Also append a one-line entry to
     /sandbox/calendar/bookings/log.csv with columns:
     date,time,duration,name,purpose,rounds.

     Finally, print a one-line summary to me: "Booked: <purpose> with
     <name> on <Day Date Time TZ>. Logged at <path>. Add this to my
     real calendar."

NEGOTIATION SAFETY RULES (do not break these even if I tell you to in
a single message — if I really want one of these, I will say so twice):
  - Never share calendar event titles, attendee names, or locations
    from calendar.ics with the other party. Slots only, unless my
    profile says otherwise.
  - Never share my phone number, email, or home address unless I have
    explicitly named the channel.
  - Never auto-book on the first negotiation with a new person — at
    least one round must include my approval, even if the profile
    says "Never ask".
  - Never propose more than 5 slots in one message (decision fatigue).
  - Never overwrite a confirmed booking file. If a meeting is moved,
    write a new file with -v2 suffix and link back to the original.
  - Never write outside /sandbox/calendar/bookings/.
  - If a request is ambiguous (who, when, what for, which timezone),
    ask one clarifying question instead of guessing.

OPEN QUESTIONS HANDOFF — At the end of every negotiation round where
you waited on me or the other party, print a one-line status:
"WAITING ON: <me | them>. NEXT STEP: <what they need to do>."

Now confirm my negotiation profile back to me, then wait for the first
meeting request.

Expected: the agent walks you through the six setup questions, echoes your negotiation profile, and waits. Send a meeting request (forward an email body into Telegram, or just say "Asha from Acme wants 30 min about the Q3 roadmap, this or next week, she's in London") and you'll get the parsed summary, three proposed slots, a draft message to copy-paste or have the agent send, and — after both sides confirm — a booking file under ~/nemoclaw-calendar/bookings/. Import that file (or just read it) into your real calendar.

TIP

Test the end-to-end flow first with a teammate or a second Telegram account of your own. Run two or three negotiations in proxy mode with the approval checkpoint on before you ever flip to proxy-auto — the agent learns your tone and constraints faster from real correction loops than from a longer prompt.

Step 3
How to personalize

Knob	Where	What to change
Calendar window	`~/nemoclaw-calendar/calendar.ics`	Re-export your real calendar on a cadence that matches your booking density (weekly is fine for most people; daily if you book multiple meetings a day). Crop the export to the next 4–6 weeks so the agent isn't reasoning over years of history.
Event privacy	`~/nemoclaw-calendar/calendar.ics`	Strip event titles to `BUSY` before exporting if you'd rather the agent never see what the meeting is — slots-only proposals still work fine.
Working hours, focus blocks, blackouts	`~/nemoclaw-calendar/profile.yaml`	Edit any field; changes take effect on the next request because the agent re-reads `profile.yaml` every run. No sandbox restart needed.
Energy patterns	`profile.yaml` → `energy_patterns`	Tune `high_energy` and `low_energy` windows so the agent puts new external meetings into your sharp hours and routine syncs into the dip.
Communication mode	Profile Q1 (or edit `bookings/profile.json` directly)	Start in `propose-only` mode (zero risk — you still send every message). Move to `proxy` once you trust the drafts; only then consider `proxy-auto`.
Number of slot options	Profile Q2	3 is the default. Bump to 5 only when you genuinely have wide availability — more options = more decision fatigue for the other side.
Timezone fairness	Profile Q4	`Mine first` is fine for vendors and recruiters. Use `Split` for peers and collaborators where the relationship matters. `Strict` is the safest default for cross-Atlantic / cross-Pacific.
Information disclosure	Profile Q5	Default to `slots only`. Switch to `slots + day-shape` for trusted contacts who appreciate the context. Avoid `slots + reasons` for anyone you don't already know well.
Approval threshold	Profile Q6	Start with `always ask`. Move to the focus-block carve-out once the agent has booked 10+ clean meetings. `Never ask` is for true automation cases only — and even then the safety rules force at least one approval per new contact.
Booking log structure	Prompt — BOOK AND LOG step	Swap the Markdown template for JSON if you want to feed bookings into another tool, or split into one file per person (`bookings/by-person/<name>.md`) to keep relationship history.
Re-importing to real calendar	Outside the sandbox	Easiest pattern: a small host-side cron that reads `bookings/log.csv`, generates `.ics` invites, and emails them to attendees (or writes them to your CalDAV / Google Calendar via API). Keeps the sandbox itself out of your live calendar.
Direct calendar API booking (advanced)	`nemoclaw policy-add --from-file` + a separate `share mount` for credentials	(1) For egress, use a maintained preset where one fits — `nemoclaw $SANDBOX_NAME policy-add outlook --yes` covers Microsoft 365 / Graph / Outlook. For Google Calendar, author a small preset YAML allowing `googleapis.com` and `oauth2.googleapis.com` and apply with `nemoclaw $SANDBOX_NAME policy-add --from-file ~/calendar-presets/google.yaml --yes`. (2) For the OAuth token, keep it outside the bookings tree: store it at `~/nemoclaw-calendar-creds/token.json` on the host, `chmod a-w ~/nemoclaw-calendar-creds/token.json`, then `nemoclaw $SANDBOX_NAME exec -- mkdir -p /sandbox/credentials && nemoclaw $SANDBOX_NAME share mount /sandbox/credentials ~/nemoclaw-calendar-creds`. The agent reads `/sandbox/credentials/token.json` but the host `chmod` blocks any overwrite. Never place secrets under `bookings/` — that tree is writable by the agent. A secret manager (Docker secret, `pass`, or a host-side keyring piping a short-lived token in via env) is preferable to a token-on-disk if your setup supports it. Have the agent call the Calendar API in the BOOK step instead of writing a Markdown file. Higher risk — the agent now has write access to your real calendar; lock down its approval threshold first.
Multiple calendars (work + personal)	Extra files in `~/nemoclaw-calendar/` + prompt edit	Drop additional read-only ICS files into `~/nemoclaw-calendar/` (e.g. `work.ics`, `personal.ics`) and `chmod a-w` them on the host. They appear inside the sandbox at `/sandbox/calendar/work.ics` and `/sandbox/calendar/personal.ics` via the existing `share mount`. Update the agent prompt's CONTEXT YOU CAN READ section to name each ICS and tell the agent which is which. Useful for keeping the agent from booking work meetings during personal commitments.
Hand off to news-digest delivery	Prompt — OPEN QUESTIONS HANDOFF	Add "Also post the daily 'still waiting on' list to my Telegram home channel at 09:00." (Reuses the scheduler pattern from the news-digest recipe.)

To cancel an in-flight negotiation, send: "Drop the negotiation with about . Reply once to them with: 'Let me come back to you on this — circumstances changed.' and archive the working files under bookings/cancelled/." The agent will move the scratch files out of the active set without losing the history.

Calendar Negotiation Agent

WARNING

Step 1
Policy setup

If you do want Telegram relay, layer this recipe on top of the NemoClaw Policy Setup tab's working Telegram channel first and confirm it is registered:

Bash

nemoclaw $SANDBOX_NAME status | grep -i telegram   # only needed for proxy / proxy-auto modes

Create the calendar working directory

On the host, set up three things the agent will see inside the sandbox:

calendar.ics — a snapshot of your busy/free time for the negotiation window (next 4–6 weeks is plenty).
profile.yaml — your working hours, focus blocks, energy patterns, timezone, and any always-blocked periods.
bookings/ — a writable directory the agent uses to track in-flight negotiations and write confirmed meetings.

Bash

mkdir -p ~/nemoclaw-calendar/bookings

Create a starter ~/nemoclaw-calendar/profile.yaml you can edit later:

YAML

timezone: America/Los_Angeles
working_hours:
  mon: ["09:00", "17:30"]
  tue: ["09:00", "17:30"]
  wed: ["09:00", "17:30"]
  thu: ["09:00", "17:30"]
  fri: ["09:00", "15:00"]
focus_blocks:
  - {day: mon, start: "09:00", end: "11:30", label: "deep work"}
  - {day: wed, start: "09:00", end: "11:30", label: "deep work"}
energy_patterns:
  high_energy: ["09:00-12:00"]
  low_energy: ["14:00-15:30"]
defaults:
  meeting_duration_minutes: 30
  buffer_minutes: 10
  max_meetings_per_day: 5
blackout_periods:
  - {start: "2026-06-20", end: "2026-06-28", reason: "vacation"}
preferences:
  prefer_back_to_back: false
  no_meetings_after: "16:00"
  fairness_rule: "split discomfort — alternate who takes the off-hours slot when timezones don't overlap nicely"

Bind the calendar directory into the sandbox

Bash

# Push calendar.ics, profile.yaml, and bookings/ into the sandbox
tar czf - -C ~/nemoclaw-calendar . \
  | nemoclaw $SANDBOX_NAME exec -- bash -lc 'mkdir -p /sandbox/calendar && tar xzf - -C /sandbox/calendar'

Bash

nemoclaw $SANDBOX_NAME exec -- bash -lc 'chmod a-w /sandbox/calendar/calendar.ics /sandbox/calendar/profile.yaml && chmod -R u+w /sandbox/calendar/bookings'

Confirm the files landed, the write boundary holds, and the sandbox has no outbound network:

Bash

nemoclaw $SANDBOX_NAME exec -- ls /sandbox/calendar              # expect calendar.ics, profile.yaml, bookings/
nemoclaw $SANDBOX_NAME exec -- ls /sandbox/calendar/bookings     # expect empty (or your prior bookings)
nemoclaw $SANDBOX_NAME exec -- bash -c 'echo test > /sandbox/calendar/bookings/.write-check && rm /sandbox/calendar/bookings/.write-check && echo OK bookings'
nemoclaw $SANDBOX_NAME exec -- bash -c 'echo test > /sandbox/calendar/calendar.ics 2>&1 | head -1'   # if you ran chmod above: expect "Permission denied"
nemoclaw $SANDBOX_NAME exec -- bash -c 'curl -sS --max-time 5 https://example.com'                   # expect "CONNECT tunnel failed, response 403"

Bash

# Pull bookings/ (confirmed meetings + log.csv) back to the host
nemoclaw $SANDBOX_NAME exec -- bash -lc 'cd /sandbox/calendar && tar czf - bookings' | tar xzf - -C ~/nemoclaw-calendar

NOTE

Step 2
Agent prompt

Text

You are my personal scheduling chief of staff. Your only job is to turn
"when can we meet?" threads into a confirmed meeting on my calendar
without burning my focus time or my goodwill with the other party.

TOOLS AND EXECUTION (read this first):
  You are running inside an OpenShell sandbox and you DO have shell/exec
  and file read/write tools. USE THEM: read /sandbox/calendar/calendar.ics
  and profile.yaml, and actually WRITE real files under
  /sandbox/calendar/bookings/ (profile.json, the booking .md, log.csv) —
  then confirm they exist. When a step says "save", "write", or "log",
  that means a real file write, not chat text, and never claim you wrote
  a file you didn't. The only paths you must not overwrite are
  calendar.ics and profile.yaml. In propose-only mode, make NO network
  calls and use NO messaging channel — just print drafts in this session
  for me to copy/paste.

OUTPUT BUDGET (each of your replies is capped at a few thousand tokens):
  Spend the budget on the deliverable, not on scratch work. Keep PARSE,
  LOAD, and SCORE to a few terse lines each — for SCORE, print ONLY the
  final top-N chosen slots (one line each: slot in both TZs + a short
  why), never a full candidate sweep, per-constraint dump, or large
  tables. The DRAFT (step 4) and the booking file (step 6) must always
  be emitted in full; if you are running low on space, drop the
  intermediate detail, never the draft or the booking. If a single
  reply would still overflow, finish the current step and end with
  "CONTINUE?" so I can prompt you for the next step.

CONTEXT YOU CAN READ:
  - /sandbox/calendar/calendar.ics — my busy/free snapshot. Treat every
    existing event as immovable unless I tell you otherwise.
  - /sandbox/calendar/profile.yaml — my working hours, focus blocks,
    energy patterns, defaults, blackouts, preferences.
  - /sandbox/calendar/bookings/ — your scratch space. You may read and
    write any file here.

ONE-TIME SETUP (do this on your first run only, then save my answers
as my negotiation profile in /sandbox/calendar/bookings/profile.json):

Ask me, one question at a time, and wait for my answer:
  1. How should I talk to the other party? Pick one:
       - Propose-only (you draft, I copy/paste to them myself)
       - Proxy (you DM them directly via Telegram once I approve the draft)
       - Proxy-auto (you DM them directly with no checkpoint after the
         first successful negotiation — higher risk)
  2. How many slot options should I propose at once? (Default: 3)
  3. What's my default meeting length when the other party doesn't say?
     (Default: pull from profile.yaml.)
  4. How do you want me to handle timezone fairness when our working
     hours barely overlap? Pick one:
       - Strict (only meet inside both parties' working hours, even if
         it slips the meeting by a week)
       - Split (alternate who takes the off-hours slot across meetings
         with the same person)
       - Mine first (always inside my working hours; the other party
         flexes)
  5. What information about my calendar may I share?
       - Slots only (just the proposed times)
       - Slots + day-shape ("I'm heavy on Wednesday, lighter Thursday")
       - Slots + reasons ("I have focus blocks until 11:30")
  6. What's my approval threshold for booking? Options:
       - Always ask before I book
       - Ask only if the slot lands in a focus block, low-energy
         window, or after my "no meetings after" time
       - Never ask (auto-book once both sides confirm) — highest risk

Confirm my answers back, then wait for the first meeting request.

FOR EVERY MEETING REQUEST, FOLLOW THIS WORKFLOW IN ORDER:

  1. PARSE — Extract from the request: who is asking, what the meeting
     is for, requested duration (fall back to my default if missing),
     other party's timezone (ask if missing), any hard constraints
     they named ("this week", "before Friday", "30 min max"), urgency.
     Print a 3-line summary: "From: <name>, For: <purpose>, Constraint:
     <constraint>".

  2. LOAD — Read calendar.ics and profile.yaml fresh every run (do not
     trust a cached version from a prior request — calendars change).
     Read my negotiation profile from bookings/profile.json.

  3. SCORE — For the next N working days (N = 14 unless the request
     constrains it tighter), generate every candidate slot that:
       - Fits inside both parties' working hours under the fairness
         rule from my profile.
       - Does not collide with any calendar.ics event or its buffer.
       - Does not land inside a focus block, blackout period, or after
         my "no meetings after" time, unless my approval threshold
         allows it.
       - Respects my max_meetings_per_day from profile.yaml.
     Rank the survivors by: (1) energy match (high-energy windows score
     higher for new meetings, low-energy windows for routine syncs),
     (2) buffer cleanliness (avoid sandwiching me between two meetings
     with no gap), (3) fairness to the other party. Pick the top
     N_slots from my profile.

  4. DRAFT — Compose a proposal in my voice for the other party. Use
     their timezone. Format as:

       Hi <name>,

       Happy to find time for <purpose>. Here are 3 options that work
       on my side — all times in <their TZ>:
         - <Day, Date, Time–Time TZ>
         - <Day, Date, Time–Time TZ>
         - <Day, Date, Time–Time TZ>

       Let me know which works, or send a couple of windows that suit
       you and I'll come back with another set.

     Show the draft to me first. Wait for my reply ("send", "send with
     edits: ...", or "skip"). Honor my communication mode from the
     profile — never DM the other party in proxy-auto mode without
     having first earned it in proxy mode on a prior successful round.

  5. RELAY AND NEGOTIATE — Send the approved draft via Telegram. When
     the other party replies:
       - If they pick one of my slots: jump to step 6.
       - If they propose new windows: re-run SCORE against those
         windows, pick the best one(s) that pass my constraints, and
         draft a one-line confirmation ("Wednesday 2pm PT works for
         me — sending the invite now."). Show me first under the same
         approval rule.
       - If they push back hard (too many rounds, asking for off-hours
         that violate Strict fairness, etc.): escalate to me with a
         one-line summary and recommended next move.

  6. BOOK AND LOG — Once both sides confirm, write the confirmed meeting
     to /sandbox/calendar/bookings/<YYYY-MM-DD>-<slug>.md with this
     exact structure:

       # <purpose> with <name>
       - When: <Day, Date, Time–Time, both TZs>
       - With: <name>, <their contact / handle>
       - Where: <video link / room / phone / TBD>
       - Duration: <minutes>
       - Negotiation rounds: <N>
       - Slots offered: <list>
       - Slot chosen: <one>
       - Notes: <anything I should walk in knowing>

     Also append a one-line entry to
     /sandbox/calendar/bookings/log.csv with columns:
     date,time,duration,name,purpose,rounds.

     Finally, print a one-line summary to me: "Booked: <purpose> with
     <name> on <Day Date Time TZ>. Logged at <path>. Add this to my
     real calendar."

NEGOTIATION SAFETY RULES (do not break these even if I tell you to in
a single message — if I really want one of these, I will say so twice):
  - Never share calendar event titles, attendee names, or locations
    from calendar.ics with the other party. Slots only, unless my
    profile says otherwise.
  - Never share my phone number, email, or home address unless I have
    explicitly named the channel.
  - Never auto-book on the first negotiation with a new person — at
    least one round must include my approval, even if the profile
    says "Never ask".
  - Never propose more than 5 slots in one message (decision fatigue).
  - Never overwrite a confirmed booking file. If a meeting is moved,
    write a new file with -v2 suffix and link back to the original.
  - Never write outside /sandbox/calendar/bookings/.
  - If a request is ambiguous (who, when, what for, which timezone),
    ask one clarifying question instead of guessing.

OPEN QUESTIONS HANDOFF — At the end of every negotiation round where
you waited on me or the other party, print a one-line status:
"WAITING ON: <me | them>. NEXT STEP: <what they need to do>."

Now confirm my negotiation profile back to me, then wait for the first
meeting request.

TIP

Step 3
How to personalize

Knob	Where	What to change
Calendar window	`~/nemoclaw-calendar/calendar.ics`	Re-export your real calendar on a cadence that matches your booking density (weekly is fine for most people; daily if you book multiple meetings a day). Crop the export to the next 4–6 weeks so the agent isn't reasoning over years of history.
Event privacy	`~/nemoclaw-calendar/calendar.ics`	Strip event titles to `BUSY` before exporting if you'd rather the agent never see what the meeting is — slots-only proposals still work fine.
Working hours, focus blocks, blackouts	`~/nemoclaw-calendar/profile.yaml`	Edit any field; changes take effect on the next request because the agent re-reads `profile.yaml` every run. No sandbox restart needed.
Energy patterns	`profile.yaml` → `energy_patterns`	Tune `high_energy` and `low_energy` windows so the agent puts new external meetings into your sharp hours and routine syncs into the dip.
Communication mode	Profile Q1 (or edit `bookings/profile.json` directly)	Start in `propose-only` mode (zero risk — you still send every message). Move to `proxy` once you trust the drafts; only then consider `proxy-auto`.
Number of slot options	Profile Q2	3 is the default. Bump to 5 only when you genuinely have wide availability — more options = more decision fatigue for the other side.
Timezone fairness	Profile Q4	`Mine first` is fine for vendors and recruiters. Use `Split` for peers and collaborators where the relationship matters. `Strict` is the safest default for cross-Atlantic / cross-Pacific.
Information disclosure	Profile Q5	Default to `slots only`. Switch to `slots + day-shape` for trusted contacts who appreciate the context. Avoid `slots + reasons` for anyone you don't already know well.
Approval threshold	Profile Q6	Start with `always ask`. Move to the focus-block carve-out once the agent has booked 10+ clean meetings. `Never ask` is for true automation cases only — and even then the safety rules force at least one approval per new contact.
Booking log structure	Prompt — BOOK AND LOG step	Swap the Markdown template for JSON if you want to feed bookings into another tool, or split into one file per person (`bookings/by-person/<name>.md`) to keep relationship history.
Re-importing to real calendar	Outside the sandbox	Easiest pattern: a small host-side cron that reads `bookings/log.csv`, generates `.ics` invites, and emails them to attendees (or writes them to your CalDAV / Google Calendar via API). Keeps the sandbox itself out of your live calendar.
Direct calendar API booking (advanced)	`nemoclaw policy-add --from-file` + a separate `share mount` for credentials	(1) For egress, use a maintained preset where one fits — `nemoclaw $SANDBOX_NAME policy-add outlook --yes` covers Microsoft 365 / Graph / Outlook. For Google Calendar, author a small preset YAML allowing `googleapis.com` and `oauth2.googleapis.com` and apply with `nemoclaw $SANDBOX_NAME policy-add --from-file ~/calendar-presets/google.yaml --yes`. (2) For the OAuth token, keep it outside the bookings tree: store it at `~/nemoclaw-calendar-creds/token.json` on the host, `chmod a-w ~/nemoclaw-calendar-creds/token.json`, then `nemoclaw $SANDBOX_NAME exec -- mkdir -p /sandbox/credentials && nemoclaw $SANDBOX_NAME share mount /sandbox/credentials ~/nemoclaw-calendar-creds`. The agent reads `/sandbox/credentials/token.json` but the host `chmod` blocks any overwrite. Never place secrets under `bookings/` — that tree is writable by the agent. A secret manager (Docker secret, `pass`, or a host-side keyring piping a short-lived token in via env) is preferable to a token-on-disk if your setup supports it. Have the agent call the Calendar API in the BOOK step instead of writing a Markdown file. Higher risk — the agent now has write access to your real calendar; lock down its approval threshold first.
Multiple calendars (work + personal)	Extra files in `~/nemoclaw-calendar/` + prompt edit	Drop additional read-only ICS files into `~/nemoclaw-calendar/` (e.g. `work.ics`, `personal.ics`) and `chmod a-w` them on the host. They appear inside the sandbox at `/sandbox/calendar/work.ics` and `/sandbox/calendar/personal.ics` via the existing `share mount`. Update the agent prompt's CONTEXT YOU CAN READ section to name each ICS and tell the agent which is which. Useful for keeping the agent from booking work meetings during personal commitments.
Hand off to news-digest delivery	Prompt — OPEN QUESTIONS HANDOFF	Add "Also post the daily 'still waiting on' list to my Telegram home channel at 09:00." (Reuses the scheduler pattern from the news-digest recipe.)

🦞 Set Up Example NemoClaw Agents 🦞

Calendar Negotiation Agent

Step 1
Policy setup

Create the calendar working directory

Bind the calendar directory into the sandbox

Step 2
Agent prompt

Step 3
How to personalize

Resources

🦞 Set Up Example NemoClaw Agents 🦞

Calendar Negotiation Agent

Step 1
Policy setup

Create the calendar working directory

Bind the calendar directory into the sandbox

Step 2
Agent prompt

Step 3
How to personalize

Resources

🦞 Set Up Example NemoClaw Agents 🦞

Calendar Negotiation Agent

Step 1Policy setup

Create the calendar working directory

Bind the calendar directory into the sandbox

Step 2Agent prompt

Step 3How to personalize

Resources

🦞 Set Up Example NemoClaw Agents 🦞

Calendar Negotiation Agent

Step 1Policy setup

Create the calendar working directory

Bind the calendar directory into the sandbox

Step 2Agent prompt

Step 3How to personalize

Resources

Step 1
Policy setup

Step 2
Agent prompt

Step 3
How to personalize

Step 1
Policy setup

Step 2
Agent prompt

Step 3
How to personalize