Team Asks
Team Asks let you send a question to teammates — picked people or the whole org — and get answers back. What makes it more than a group chat: each recipient's Sage drafts them an answer from their own memory before they even look, so a good reply is one tap away. And you choose per ask whether it goes out named and verified or fully anonymous.
"Does anyone remember the staging DB password policy?" — to the whole org or a few people, with your identity attached or with none at all. The answer isn't a blank box: the recipient's assistant has already drafted a reply from what they know, so they send it, edit it, write their own, or dismiss silently. Answers stream back to your Asks tab.
❔ Ask anyone
A question to specific teammates or your whole organization.
❔ Answers pre-drafted
Each recipient's Sage drafts a reply from their memory before they look.
❔ Named or anonymous
Attach your verified identity, or ask with none at all — chosen per ask.
❔ Streams back
Replies collect in your Team hub's Asks tab as people respond.
/askteam, or click the Open chip. Whether Sage can send an ask for you is governed by your standing policy: normally she stages a card you send yourself; you can set it to auto-send, or off.What it is#
Team Asks is one of the three surfaces of the Team hub — the encrypted layer connecting your org (with Signals and Broadcasts). Where Signals shares status and Broadcasts pushes action, Asks pulls knowledge: the "who knows X?" question that would otherwise be a Slack shot in the dark. Because each teammate's Sage answers from their memory first, an ask taps what the org actually knows, not just who happens to be watching a channel.
Asking the team#
Pose a question in the Team hub or with /askteam. Target specific people (by their directory emails) or leave it open to the whole organization. Sage stages the ask as a card you review before it goes; whether she can send it herself follows your standing ask policy — confirm (you send, the default), auto (she sends immediately), or off (asks are refused). She respects that setting and won't retry around it.
Named or anonymous#
You pick an identity mode per ask, matching two real situations:
✓ Named & verified
For confidential requests where people need proof of who's asking. Recipients see your directory-attested identity — the ✓ principal chip, rooted in your org sign-in, is the proof. Display names are just labels.
◯ Anonymous
For the "I feel silly asking, I just need a reminder" case. The ask travels on a fresh throwaway keypair to a hidden mailbox; answers seal back to it. Teammates can't link the ask to a person.
Set anonymous when you'd rather not be named; leave it named when the recipient needs to trust the source.
The anonymity boundary#
It's worth being precise about what "anonymous" means here, because Zimac is honest about it: anonymity is peer-facing, not operator-facing. Teammates — even one running a modified client — cannot link an anonymous ask to you. But the discovery service authenticates every call, so the server can still attribute an anonymous ask to a token. That's deliberate: it keeps abuse attributable and rate-limited. So anonymity here protects social comfort — the awkwardness of asking — not deniability against the infrastructure.
Answering an ask#
When an ask reaches you, your Sage has already drafted an answer from your own memory — so responding is a glance, not a research task. You can send the draft as-is, edit it, write your own, or dismiss it silently (no one is told you ignored it). Answers stream back to the asker's Asks tab as they come in, named or sealed to the anonymous mailbox as appropriate.