Product Brain01 / Workspace
Choose the place your team’s context belongs.
Sign in to Product Brain, then create a workspace or join the one your team has invited you to. If you need an account, choose “Open Product Brain” on thesetup and access page.
Keep this first exercise small. Use a short note you are allowed to share: what your team is trying to do, one agreement it already works from, and who answers for it. Keep customer information and secrets out of this first test.
You can name the workspace you opened and the person responsible for this first task.
Account screens can differ during beta. The workspace setup instructions explain the current path.
02 / Connection
Connect the tool you will actually work in.
This path starts in Codex, with the Product Brain command-line tool available in your project. Follow the current installation and authentication instructions, then return here for the first task.
Use the connection details for the workspace you chose. Keep an API key in the authentication mechanism described by the setup instructions; never put it in a prompt, source note, public screenshot or committed project file. Your workspace administrator may need to provide access.
Ask Codex to run pb whoami. Read the returned workspace and profile. If either is unexpected, stop and correct the connection before continuing.
pb whoami identifies the active connection. It does not prove that a task has a correctly bound role session. Other supported tools have their own connection guides.
03 / Authority
Give the work a role, with a real boundary.
Choose a role your workspace has authorised this agent to hold. Read its purpose, responsibilities and applicable rules. Name the human who answers for the work. If no appropriate role or permission exists, ask your workspace’s owner to resolve that first.
Ask Codex
Before doing the task, show me the connected workspace and the role you are authorised to use. Start a Product Brain session explicitly in that role, with a unique conversation identity. Orient for this task. Show the returned session, role and applicable rules, and tell me what context is missing. Do not change any Chain entries yet.
What should the agent verify?
With the current CLI, session start accepts --role and--conversation. Where the same role is held in multiple teams, it also accepts --team. The agent must use your workspace’s actual identifiers and permitted role.
Keep PB_CONVERSATION_ID set to that conversation identity on subsequent calls. Use pb session show with the session or conversation identity to inspect the server record and served governance. Use pb orient --task with the actual job, then read the relevant entries and rules.
A role label in a chat response is insufficient. Check the returned record. If the result is incomplete, truncated or refused, resolve that gap before asking the agent to act on it.
The workspace, session, role and relevant rules are visible. You can explain what the agent may do and what it must leave to someone else.
04 / First task
Make the first result easy to inspect.
Try a Marketing task: prepare a short draft explaining one agreement your team already works from. Use your own source and your own authorised role. This is a draft for review, with no publication or accepted Chain changes.
Illustrative source · Replace with your own
“Our team reviews every customer-facing release note before publication. The Marketing Lead owns that review. We made this agreement because an earlier draft described work that had not shipped.”
Your task brief
Prepare a short draft explaining the agreement in my assigned source. First search the Chain for relevant context and read what you use. Keep the reason and owner visible. Return the draft, its sources and any unanswered questions. Do not invent missing facts, publish the draft or change the Chain.
Read it beside the source.
- Does the draft preserve the agreement, its reason and its owner?
- Can you open the cited entries and see what the agent relied on?
- Did it expose gaps instead of filling them with invented answers?
- Did it stay inside the role and the draft-only boundary?
If the source is new and the Chain has nothing relevant yet, that is a useful finding. The draft alone is not shared memory. Before a later task can rely on the agreement, it needs an appropriate, reviewed entry in your workspace.
05 / Continuity
Check the record another session can find.
Review existing entries before adding one. If an agreement already exists, work with its owner to correct that entry rather than create a near-copy. If a new entry is needed, ask the authorised role to prepare it from your source, with its reason and owner, and inspect it before any acceptance. Draft and accepted are different states.
Have the agent close only its own session under the applicable rules. In a fresh, properly authorised session, ask it to find the agreement and return its wording, reason, owner and actual status. Compare that answer with the entry itself.
A later session can locate and cite the right entry. You can see what was recorded, what is still a draft and what still needs a person’s decision.
One inspected task does not establish reliable autonomous operation. Shared context needs maintenance, and each task still needs the right access, role and sources. Read the current limits.
Build on the setup
Practise the way of working.
The three supporting lessons include examples and workbooks. They help you design the work; they do not configure the connection.
A role is a seatWork from a shared recordThe rules that bindStuck on access or connection? Ask for setup help, with the step and error message. Leave credentials and private source material out.