The assistant reads the agreed value
This is the reason to connect one at all. Ask an assistant about your rocket's dry mass today and it answers from whatever number appeared in the document you pasted, which may be four revisions out of date. Ask it once it is connected and it calls the specifications directly, so it answers with the value your team actually agreed on, along with the version and when that version was published. The same goes for components: it can see which ones have gone stale because a parent spec moved underneath them, which is the failure this whole product exists to catch. An assistant that can check is a different tool from one that has to be told.
It writes documentation, tasks and minutes back
Reading is half of it. An assistant can create and edit documentation pages, file and update tasks, add links to the document and research library, and write meeting minutes and meeting notes. So you can hand it a transcript and have the minutes written into the meeting, or ask it to draft a test procedure and have the page waiting in the project when you go looking. Pages are written as markdown and converted to the app's rich text, and every edit lands in the page history like any other edit, so you can see what changed and roll it back.
Everything it writes has a person's name on it
A connected assistant is not an anonymous robot account. It acts as whoever connected it, and that person appears as the author of every page, task and set of minutes it produces. That is deliberate, and it is enforced rather than assumed: a connection with no person behind it can read but is refused every write. It also means the assistant sees what that person sees and no more. A private project stays invisible unless they are a member of it, and a restricted meeting stays invisible unless they were entitled to it.
One decision for the team, one for each person
An owner turns assistants on for the workspace and sets how far one may go, once, under Admin then Integrations. That is the decision about your team's data reaching a model provider, and it belongs to whoever can make it. After that, anyone connects their own assistant from Settings, then Your assistant, with no admin involved. The two questions are genuinely different: whether this workspace allows assistants at all, and whether this particular assistant acts as you. Folding them into one approval, which is where this started, meant only owners could use the feature and every connection carried an owner's reach instead of the reach of the person at the keyboard.
You choose what it can touch, and it can be read-only
Access is granted one area at a time, and read and write are listed separately so turning on the ability to change things is a decision made on purpose rather than one more box in a row. New workspaces start read-only, because the two failure modes are not symmetric: an assistant that reads too much is a disclosure you can still reason about, while one that writes too much has already changed the record everybody else is working from. The assistant is only ever shown the tools it has been granted, so a read-only connection has no way to even attempt a write. Narrowing what is allowed later disconnects the assistants that no longer fit, rather than quietly applying only to the next person who connects.
Publishing a specification still needs a person
There is no way for an assistant to publish a specification or a component version, and that is a line we do not intend to move. Publishing marks every dependent component stale and can route an approval to somebody, and that has to happen once, through the app, where the team can see it. An assistant can read a spec, argue about whether it is right, and write its reasoning into a document for review. Deciding that the number changes stays with the person whose name goes on it. It cannot delete anything either: there is no delete tool.