Team Asks
Team Asks let you send a question to teammates — picked people or the whole org — and get answers back. Each recipient's Sage can draft an answer from their own memory before they respond. Per ask, you choose whether your identity is named and verified or hidden from peers; the service still authenticates the sender for abuse controls.
"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 peer-anonymous
Attach your verified identity, or hide it from teammates — 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#
Asks is a tab inside Team, alongside People, Broadcasts, Shared, Team memory, and Devices. It pulls knowledge: the "who knows X?" question that would otherwise be a Slack shot in the dark. Signals is a separate Studio for organizational outcomes. A teammate's Sage can prepare an answer from their own memory, but that teammate still sees the ask and chooses whether and what to return.
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.