crew
folk is multiplayer — let a friend's folk do things for you, and yours for them, privately and only with a tap to approve.
most of the time folk works just for you. crew is what lets folk work between you and the people you trust.
add a friend who's also on folk, and once they say yes, your folk can ask their folk to do something — and theirs can ask yours. the catch that keeps it safe: nothing happens without that person's ok, and by default you only ever find out whether it got done. you never see their stuff unless they explicitly approve sending a specific reply back to you.
a quick example
say your friend maya knows all the good sushi spots. you text your folk:
ask maya's folk to find a sushi spot for friday
maya gets a little prompt showing exactly what you asked. she taps approve. her folk does the work — on her account, with her tools — and you get back a simple "done." you never see maya's calendar, her contacts, or anything her folk looked at. just the result.
adding someone to your crew
head to your dashboard at getfolk.app/dashboard/crew:
invite them
enter their phone number and a nickname — the name you'll use when you talk to folk later ("ask maya to…").
they say yes
their folk pings them to confirm, and the request shows up on their crew page. when they accept, you'll both see the link.
start asking
now you can delegate — from the dashboard or right in chat.
the other person has to be on folk already. if they're not, invite them to folk first, then add them to your crew.
asking a crew member's folk
once you're linked, there are two ways to ask:
- in chat — just tell your folk: "ask maya's folk to find a sushi spot for friday."
- from the dashboard — on maya's card, tap "ask maya's folk" and type the request.
either way, maya's folk shows her the exact request and asks her to approve. she approves by telling her folk to go ahead (a 👍 works too), or from her dashboard. once she approves, it runs on her folk. you'll watch the status go from pending → in motion → done — and when it's finished you can send a one-tap thanks.
target-approved replies
some crew tasks need a small piece of information to come back to the requester: an email address for a calendar invite, a short answer, or another tiny artifact the requester needs to keep going. that now has its own consented path.
the target's folk must first show them the exact payload and get approval. only
then can it call crew_send_action_reply on the original incoming action. that
creates a requester-visible reply with a typed payload:
text— a short plain answeremail_address— one email addresscalendar_attendee— one email address meant to be used as a calendar attendee
the reply is delivered back into the requester's folk as a new crew reply turn, marked as untrusted data. their folk can use it as data for the original task, but it still has to ask before taking any external action that needs confirmation. the requester may also get a courtesy message saying the crew member sent a reply.
this is separate from the normal status/outcome model. the target's folk still
reports the action status as accepted, done, declined, blocked, or
failed, and any target-only failure detail stays on the target side. the
requester only sees artifacts or data when they were sent through
crew_send_action_reply.
who sees what
this is the important part. crew is built so the person asking only learns the server-authored outcome by default — never the other person's data. the only exception is a target-approved reply sent through the explicit reply flow above.
| you (asking) | them (doing) | |
|---|---|---|
| the request you wrote | yes | yes — to approve |
| whether it got done | yes — done / declined / couldn't | yes |
| approved reply payloads | yes, only if they explicitly send one | yes, they approve the exact payload |
| their data or their folk's work | never by default | yes, it's theirs |
| has to approve each time | — | always |
if a member's folk can't finish yet — say it needs them to connect an app first — the task is paused, not failed. only they see the reason, and they can retry. you're never shown a half-finished error.
shared memory
besides asking each other's folk to do things, crew members can share small durable facts — preferences, favorites, details worth remembering. tell your folk:
share with maya that i prefer aisle seats on long flights
next time maya plans a trip that involves you, her folk already knows.
categories, and who sees what
every shared memory lives in a category you name in chat — "travel preferences", "food", whatever fits. sharing in a category is per person and one-directional: enabling "travel preferences" for maya lets your folk share that category with her — it says nothing about what she shares with you.
two things to know about how categories work:
- the first time your folk shares in a new category with someone, you get a heads-up message — if you didn't ask for it, you can review and turn it off at getfolk.app/dashboard/crew.
- a memory belongs to its category, not to one person: if you enable the same category for another crew member later, they can see the memories already in it. keep categories scoped to what you'd share with anyone you'd enable them for.
changing your mind
everything is editable in chat:
- "what have i shared with my crew?" — your folk lists your shared memories.
- "forget what i shared about aisle seats" — deletes it for everyone, immediately. to correct something, forget it and share the updated version.
- "stop sharing travel stuff with maya" — disables the category for her; past memories in it are hidden from her too.
there's a generous cap on how much you can share. if your folk says shared memory is full, ask it to forget outdated entries and share again.
you can also toggle each member's categories from their card on the crew page. removing someone from your crew turns off all shared categories between you, both directions — re-adding them later starts from scratch.