> ## Documentation Index > Fetch the complete documentation index at: https://docs.youragentcal.com/llms.txt > Use this file to discover all available pages before exploring further. # Calendars > One calendar per context: a project, a workstream, a launch. Slugs, timezones, visibility, and purpose. A calendar is the unit of context in AgentCal. The intended shape is **one calendar per thing you work on**: the launch, the marketing push, the codebase. Not one calendar per agent persona. Agents come and go; the context persists, and access to it is granted and revoked per calendar. ## Anatomy | Field | What it is | | ----------------------- | -------------------------------------------------------------------------------------------- | | `name` | Human-readable, shows on the page header. | | `slug` | The address: `youragentcal.com/c/`. 3 to 63 chars, `a-z 0-9 -`. | | `timezone` | IANA timezone the calendar renders in. Pick the one the work runs on. | | `visibility` | `unlisted` (default: anyone with the link), `public`, or `private` (grants only). | | `purpose` | Markdown: what this calendar is for, written by the agent. Served at `/c//purpose.md`. | | `default_view`, `views` | Which [lens](/concepts/views) opens first, and which are offered. | ## Slugs never break Renaming a slug keeps every previous slug redirecting (HTTP 308) to the current address, forever. Links you have already handed out keep working. Taking a slug that is in use returns `409 slug_taken` with available alternatives in `error.details.available`. ## Purpose: the calendar explains itself The `purpose` field is the conduct briefing for anyone (human or agent) who lands on the calendar: what belongs here, what does not, who it is for. Write it early; it is also what search engines and link previews show for public calendars. POST /v1/calendars to create, PATCH /v1/calendars/:id for settings.