8.2 · Give your agent write access

Write access lets your agent act on what it finds, not just report it. Everything in the playbook treats your agent as an analyst: it reads your workspace, the container holding everything GrowthOS knows and does for your brand, and argues a recommendation. With write access, the same agent can apply it: update your context, build and edit briefs, triage opportunities, start agent runs, and publish through your connected CMS. The point is where this happens: inside the Claude project, Claude Code session, or agent workflow you already run your content operation from, so acting on a decision no longer means leaving it. And you stay in charge throughout: every change is previewed before it's applied, and your agent can never do anything your own account couldn't do in the app.

When you'd want this

Write access is built for teams whose content operation already runs somewhere of their own: a Claude project with its own instructions, a Claude Code session, an agent workflow they've assembled. From there, your agent can take any action in GrowthOS on your behalf, so the whole loop, from context to published page, stays in the conversation you were already having. A few moments where that shines:

• After a strategy call. Hand your agent the transcript and have it update personas, competitors, and your foundation documents to match what was actually said.
• When you build briefs in your own workflow. Your agent creates the brief in GrowthOS, writes the outline your way, and kicks off article generation, all from the chat where the thinking happened.
• Weekly triage. Talk through the open opportunities once, then have the agent apply the verdicts instead of clicking through them.
• Shipping. Publish a finished brief into your connected CMS from the same conversation.

Turn it on

Write access is granted when you connect, not from a settings page. Sign in to the GrowthOS connector again (the same steps as 2.3 · Connect your agent) and the approval screen offers Include write access, off by default. Tick it to grant everything, or expand it and pick areas one by one: each area is its own permission, so an agent can be allowed to manage briefs but not touch your team or your taxonomy.

Two practical notes: adding write access takes a fresh sign-in, so if the new abilities don't show up, disconnect the connector and connect again rather than debugging. And if the approval screen doesn't offer Include write access at all, write access isn't enabled for your workspace yet: ask your GrowthX team.

What it looks like in practice

The same prompt style as the playbook, now ending in applied changes instead of a to-do list for you:

Here's the transcript of today's positioning call. Using GrowthOS, update our personas and competitors to match what we decided, and draft an edit to the Company Overview. Show me each change before you apply it.

Using GrowthOS, create a brief for a comparison page on us versus Acme aimed at our buyer persona, generate the outline, and stop there so I can review before the article is written.

Using GrowthOS, walk me through my open page opportunities one by one with your recommendation. When I say accept or dismiss, apply it.

Using GrowthOS, publish the brief titled "Example article" to our CMS.

That last one goes through the same CMS connection as the button in the app, with the same rules: drafts by default, and pages only go live if your connection's live-publishing switch is deliberately on.

Why it's safe to turn on

• Every change previews first. A write happens in two steps: the first call returns a preview of exactly what would change and changes nothing; only a confirmed second call applies it. That's what makes "show me each change before you apply it" work.
• Your agent is you, with your permissions. The connection is personal, and each write is checked against what your own account may do in that workspace. An agent can't invite a teammate or delete a brief on behalf of someone whose role doesn't allow it.
• Deletes show what they take with them. A delete's preview lists everything that would be removed before anything is. Deletes are permanent, so that preview is the moment to read carefully.
• Documents are snapshotted. Before an agent rewrites a foundation document or an article, GrowthOS keeps a snapshot of the previous version.
• Everything is on the record. Changes made over MCP land in your workspace activity attributed to the person whose connection made them, just like edits in the app.
• Agent runs have a daily allowance. Starting generation and research runs draws on a per-workspace daily budget, so a runaway loop can't burn unlimited work. If you hit the limit, it resets daily; talk to your GrowthX team if it's genuinely too low.

Revoking is as simple as granting: disconnect the connector, or connect again without the write toggle, and the agent is back to read-only.

Common questions

Do I have to grant everything? No. The per-area permissions exist so you can start narrow, say Page briefs and Opportunities only, and widen later once the workflow has earned it.

Does this change my teammates' connections? No. Grants are per person, per connection. One teammate's agent having write access says nothing about anyone else's.

Can the agent put something live on my site? Only through your CMS connection, under its rules: drafts by default, live only where you've turned on that connection's live-publishing switch. Stage 7 covers the per-platform details.

What if it makes a change I didn't want? The preview step is the main guard: ask the agent to show changes before applying, and it can. After the fact, workspace activity shows what changed, and document snapshots preserve the previous version. And you can always pull the grant entirely.

Where to go next