# 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](https://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 answer
- `email_address` — one email address
- `calendar_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](https://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.

## staying in control

**does folk ever act without approval?**

no. every crew request is gated on the other person tapping approve. nothing
runs automatically, in either direction. shared memories work the same way —
your folk only shares one after you say yes.

**can the other person read my data?**

only what's in the request you wrote, plus any memories you explicitly chose to
share. crew is one-way by design — the work runs on their side, and you just
get the result.

**how do i remove someone?**

open your crew page and remove them. that cancels any in-flight requests between
the two of you, both directions, right away — and turns off all shared memory
categories between you. memories you authored stay yours and remain shareable
with the rest of your crew.

**what's my crew profile?**

your crew sees you as a small profile — a photo, a handle, and a short bio you
can edit at the top of the crew page. that's also where you rename or remove
members.

---

Canonical page: https://www.getfolk.app/docs/crew
More about folk (for AI agents): https://www.getfolk.app/llms.txt · full context: https://www.getfolk.app/llms-full.txt
folk is a personal AI that lives in your texts (iMessage, Telegram, WhatsApp). Pro $20/mo, Max $100/mo. Made by Nozomio Labs. Sign up: https://www.getfolk.app/