Give your tools the team picture

For owners and admins of a company workspace. On its own, each member's AUGMTD knows that member's work. With team memory on, every member's work and signals are available to colleagues and to the company's tools, from the moment an owner or admin turns it on: the state of the work, never its content.

Turn team memory on

An owner or admin opens Settings → Company → Team sharing, confirms the staff were told what colleagues and company tools will see (and your works council, where you have one), and clicks Turn on team memory. Two drafts you can hand to your adviser sit beside the box: a staff and works council notice and a DPIA template. They are drafts, not legal advice.
It is shared by default: all of each member's work is available to colleagues and company tools at once (no piece has to be shared by hand), unless that member hides it or switches sharing off for themselves. Only work is shared: personal life (personal emails, private errands, a solo appointment) is left out, and anything shared that later turns out not to be work is taken back. When two members work on the same client or project, their work shows as one. If you prefer, Let each person choose instead: nothing of a member is shared until that member switches sharing on for themselves; you cannot switch it on for anyone.
Your choice (who, when, which mode) is recorded in the activity. You can change the mode later: to "each person chooses" stops sharing at once for everyone who has not switched it on; back to "shared by default" asks for the staff confirmation again and shows every member the notice again.
It works at once. Members do not have to accept anything first: your confirmation that the staff were told is what turns it on for everyone, and their work appears within minutes (new work within the hour).

What members see and can do

Each member sees a short notice explaining what is shared, once. It is for their information; nothing waits on it.
Each member can hide any piece of work from the team, turn sharing off for themselves, or leave a shared piece of work, at any time. No admin setting overrides this.
Colleagues see the state of the work: open promises with who holds them and when they are due, next steps, the last touch ("Email with Acme, Tue" and who), meeting titles and times, and how many members have not shared (a count, never names).
Colleagues never see email subjects, email contents, transcripts, notes or files. Those stay with their owner.

What a connection sees, and never sees

A key or a connected app acts as one person, so it sees that person's view of the team, through the same reader as the app:

It can read	Operation
the team's shared work (every member's who shares, and the person's own), and the processes they hold a role in	`list_shared_work`
one shared piece of work: promises with holders, next steps, last touches, meeting titles, members	`get_shared_work`
a process's open runs, the stage each stands at and what it waits on; outcomes; patterns per stage	`get_shared_work` (kind `process`)
the team facts confirmed on one shared piece of work, or every team fact at once with the work each is about	`list_team_facts`, `list_all_team_facts`
the company facts (Settings → Company → Company knowledge): short facts an owner or admin confirmed	`list_company_facts`
how a process is run here: rules its owner confirmed	`list_process_facts`

It never sees email subjects or bodies, quotes, transcripts, files, a step's input or output, or work a member hid or keeps to themselves (an owner or admin by rank sees no more than any member). It never sees per-person activity: a pattern is per stage or per process, shown only over at least 5 finished runs and 3 people. Before team memory is on, the shared list is empty and an id answers 404.

History and changes

The current state of a shared piece of work includes what happened before team memory was turned on: the last touch, open promises and meetings come from each sharing member's own record.
Changes follow consent, never backwards. The changes feed (GET /api/v1/changes, list_changes) lists the person's own tracked work only. A webhook or feed destination carries a member's events only from the moment that member agreed to that destination, and the team's work_id only while they share the work.

Connect a company tool as the company

An owner or admin can connect a company tool, such as your CRM, as the company rather than as one person: in Settings → Connections → MCP → Company integrations, make a company integration. It gets its own token, which only reads and never proposes anything. It reads the team's shared state only: the shared work of members who share (all of it, never work a member hid), their signals (every kind, unless you keep a kind private to each person, whether or not the signal is about a shared piece of work), and only the processes you pick. It never reads anyone's own work. Every read is logged (per operation and hour, never per member). A company holds up to 5 live integrations; a token expires after 90 days unless you choose otherwise, and you can revoke one at any time. Team memory must be on.

A tool can also connect as one person, with that person's key or sign-in, and then reads exactly that person's view: their own work plus the shared work they belong to. Make the key in that person's Settings → Connections → API keys; any owner or admin sees it under Your team's keys and can revoke it. To let it only read, turn on Connected apps and keys may only read in the same place.

To send the team's changes to a tool instead, use a destination (Settings → Connections → Send to your tools): see Use it from your own app.