For agencies running many client brands
Each client gets its own brain, with its own storage, its own encryption key and its own agent in Slack. The agent writes in the client's voice and puts every draft in a queue for a person to approve. Nothing it writes reaches anyone on its own.
Design-partner stage · Storage in AWS Frankfurt · Runs on your client's own Claude account
The problem
"Every time an account manager leaves, the client's voice leaves with them."
The brand lives in people's heads, old briefs and a folder of PDFs nobody reads.
"I paste the same brand guidelines into ChatGPT for every brief."
And every account manager pastes a slightly different version.
"I can't let an AI tool loose on client accounts."
If it posts the wrong thing on a client's LinkedIn, that's someone else's brand you've damaged.
"I need to prove Client A's material never fed Client B's content."
Clients' security questionnaires ask where data lives and who can read it. For most AI tools, you can't answer.
How it works
Your account managers work in Slack and the web console. Nobody needs a terminal.
Type the company name. The brain's encryption key and private storage are created while you watch.
The brain reads up to 25 pages of the client's site and files them as knowledge, so the agent writes in their voice from day one. Add brand files and skills alongside.
Mention it in a channel and ask for a draft. A thread is one continuing conversation, and only the brain's owner can talk to it.
Each draft is listed with a fingerprint (SHA-256) of its exact bytes. The agent has no way to post it anywhere.
Enforcement after generation
No model is immune to prompt injection. So instead of trusting what the agent writes, we limit what it can reach. Here are four things the system refuses to do, and how finished each one is.
The agent's container can reach only the model API, through an allow-list proxy, and our tool proxy. Eight probes run on every deploy, and the deploy fails if one gets through.
Not yet: blocking and testing DNS exfiltration.
Tool and Slack tokens stay encrypted in the control plane. The agent holds only a 15-minute pass to the tool proxy, which adds the real token on the way out.
Not yet: catching a key someone pastes into a message.
Approving will mint a signed record bound to the draft's fingerprint. A missing approval, or a single changed byte, will be refused.
Today: the agent holds no channel credential, so the worst a prompt injection gets you is a draft nobody approved.
One bucket and one encryption key per brain, with access scoped to the client it belongs to. Credentials for one brain have no permission on another brain's bucket or key.
Also per brain: Slack app, agent container, tool connections and sessions.
Your tools, your model
Each brain connects to the tools your team already uses, with each person's own sign-in. Every connection starts read-only, enforced at the proxy rather than in the prompt. Write access is a separate switch the brain's owner flips per tool, and every change is logged.
Connect the client's Claude subscription or an Anthropic API key. The key is write-only: no screen or API ever shows it again.
Shown, not promised
All on a real agency client's brain, August 2026. Ask us and we'll walk you through it.
A request in Slack produced a LinkedIn draft from the crawled site and brand files, with MFlow, ClickUp and Sentry connected.
With the read-only tier on, the agent saw only read tools and reported that no create_task was available.
Refused at first. The owner switched ClickUp to full, a real task was created, then it was switched back. A deployment without the write licence returned 403.
Connecting ClickUp granted two workspaces. Pinning each connection to a single workspace is now on the build list.
Why not a chat tool?
| Question | Chat tool, one project per client | Brainstead |
|---|---|---|
| Where client material lives | One shared workspace, kept apart by folders and naming | Its own storage bucket and its own encryption key |
| Who can post on the client's channels | Whatever you've connected it to | Not the agent. It holds no channel credential and writes drafts only |
| Access to your tools | Whatever was granted when it was connected | Read-only by default; write is a per-tool switch, logged |
| The client's voice | Pasted into each brief | Kept in the brain: their site, brand files and skills |
| Unsupported claims | Up to the reviewer to spot | Marked [NEEDS-FACT] in the draft, with notes for the reviewer |
Security, honestly
We won't put a security property on this page that the product doesn't have. Use this list for your clients' questionnaires.
Internal security review: 17 August 2026, fixes merged.
Pricing
Every client you win adds a brain. Talk to us about what that looks like for your agency.
Request a demo
We're working with a small group of agencies as design partners while we finish the approval gate. Tell us about yours.
We'll reply to to set up a time.
agency: · client brands: · interest:
It has run a real client's brain end to end, in August 2026. It's at design-partner stage: the signed approval gate, single sign-on and short-lived cloud credentials are the next builds.
Storage, encryption keys and secrets are in AWS Frankfurt (eu-central-1). Model calls currently go to Anthropic's API; running inference in the EU is an open decision.
Each brain is its own bucket and its own key, and one brain's credentials have no permission on another's. Sessions, tool connections, Slack apps and agent containers are per brain too.
It has no credential to post with. What it writes is a draft in a queue. Once signed approvals ship, publishing will also require an approval bound to that exact draft.
Claude, on your client's own Claude subscription or Anthropic API key.
A brain is plain markdown files: knowledge, brand voice and skills. They're yours, in a format any tool can read.
It isn't immune to prompt injection: it limits what an agent can reach and puts a person before anything goes out. It isn't a publishing or scheduling tool. And it isn't certified yet: no SOC 2, no pentest.
