Calendar
Scheduling by validated deep link: for now.
What it does
When a conversation reaches "let us find a time", the agent produces a scheduling call-to-action pointing at your existing booking tool, with the destination checked against an allowlist so it cannot be steered somewhere else. That is the whole of it today.
Why it matters
We are listing this module precisely because it is the one that is not built. Most of the value of a public status ledger comes from the entries that are inconvenient. If we would tell you the truth about Calendar, the other ten entries are worth something.
How it works
The destination is allowlisted
The booking URL the agent emits is validated against a configured allowlist, so a conversation cannot talk the agent into linking somewhere arbitrary.
No availability, no event store, no sync
There is no calendar model behind this. If you need the agent to reason about free/busy time, it cannot do that today.
Questions
- Can the agent book a meeting for me?
- It can hand someone a validated link to your booking tool. It cannot read your availability or write an event.
- When will this be real?
- We have not committed to a date, and we would rather leave this on the bench than put a quarter next to it.
The rest of the bag
Your agent has its own inbox, not a share of yours.
Inbound arrives by webhook from an email provider. We do not run our own MX or SMTP servers.
Package
Export, share and install agents as portable archives.
Export, import, handoff links and showcase all work. There is no marketplace, no package versioning, and no signed packages.
Memory
Grounded retrieval over your own material, with receipts.
This is retrieval, not persistent agent memory. Vector grounding is code-complete; the vector deployment is still pending.
That was step 1 of 6: a request arrives. Next, the subdomain is the isolation boundary, so the request resolves to one workspace, one database, and one question of whether it is even in scope.