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
AccessControl
Per-document permissions that filter answers, not just pages.
Policy resolution is cached per session for speed; a permission change propagates on cache invalidation rather than instantly on every in-flight request.
Docs
A folder tree the agent reads, and a config file it obeys.
Extraction covers PDFs, spreadsheets and transcripts. Exotic binary formats are not parsed.
Events
A durable ledger of what agents did, and why.
The in-process event bus is a single-node emitter, not a distributed broker. The durable cross-agent record is a separate Postgres task ledger.
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.