ChatGPT Space: How to Organize Shared Work Without Losing Context

The difficult part of shared AI work is knowing which context governs the next decision. A useful ChatGPT Space pilot should make four things easy to find: the current brief, the supporting sources, the unfinished work, and the person who owns the outcome.

OpenAI announced ChatGPT Space on September 29, 2026. Its DevDay recap lists Pro, Business, and Enterprise access on desktop and web. Mobile can find, read, and share Pages; mobile creation and editing are coming later. OpenAI’s DevDay recap

For an agency owner or operations leader, the value to evaluate is continuity. Can someone join the project, understand the current decision, find the evidence, and contribute without asking the owner to reconstruct the history?

Space might help provide that working home. The team still needs to decide which information is authoritative and who can change a commitment. A shared location becomes useful when it preserves those distinctions. This article develops a proposed project setup, rather than reporting results from a Rise Productive Space test.

Understand what Space brings together

View image detail

Portable project context helps a contributor understand the goal, find evidence, and identify the next decision.

Actual size

Choose Actual size to read the graphic closely.

OpenAI’s release notes say Space brings together Pages, files, and related work. It replaces Library for eligible accounts, while existing Projects remain separate. Enterprise sharing is an opt-in preview. A plan’s eligibility doesn’t mean every collaboration setting is enabled in every workspace. ChatGPT release notes

The distinction between a shared working home and the individual items inside it matters. A Page can hold the current brief or a research summary. A file can provide source material. A working conversation can help a contributor develop an idea. Those things perform different jobs, even if the team can find them near each other.

My recommendation is to organize around the project’s decisions rather than the tool’s menu. Start with what a colleague needs to understand, then choose the items that carry that information. That keeps the structure recognizable even as the product evolves.

Imagine a hypothetical agency preparing a service launch. The account lead needs the approved positioning. The designer needs the deliverables and constraints. Operations needs the agreed scope. The owner needs to see unresolved commitments. A useful project home makes those needs visible without requiring everyone to read every conversation.

The first design question is therefore simple: what should someone be able to find when they arrive? If the answer is “all the files,” the team hasn’t finished the design. A pile of material can be complete while still being difficult to use.

Give the project a front door

View image detail

A project entry point presents its current purpose, important links, and outstanding decisions.

Actual size

Choose Actual size to read the graphic closely.

A project home needs an obvious starting point. A short overview can explain the intended outcome, the current state, the important links, and the decisions that still need an owner.

For the hypothetical service launch, a short overview could look like this:

• Purpose: Prepare an internal launch plan for approval.
• Current state: The plan is a working draft. Client-facing language is not approved.
• Governing source: The approved positioning brief defines the audience and scope; the delivery record holds assignments.
• Next decision and owner: The account lead will confirm the proposed launch date after operations reviews delivery capacity.

The actual overview should link to those governing records and the working draft. A colleague can then enter the work without interpreting every file name or mistaking a proposed date for a commitment.

Keep that overview small enough to maintain. It shouldn’t become a second copy of every document. Its purpose is orientation: which material matters, what status it has, and where someone should contribute. The detailed work belongs in the linked items.

Describe status in terms that affect a decision. “Waiting for operations to confirm the delivery sequence” tells a contributor what remains open; “in progress” does not. Ordinary prose is enough when it tells readers what they may use and what still needs approval.

Name the owner of the project overview. If everyone can update it but nobody is responsible for it, the front door can become stale while the underlying work moves on. The owner’s job is to keep the orientation accurate enough that a new contributor doesn’t start from an outdated assumption.

A useful acceptance check is to ask a colleague who hasn’t been involved to explain what the project is trying to achieve and what decision comes next. If they need a separate explanation, repair the overview before adding more material.

Separate source material from working interpretation

View image detail

A rooted source separates governing information from working interpretations and unapproved proposals.

Actual size

Choose Actual size to read the graphic closely.

The team should be able to tell whether an item establishes a fact, records a request, or proposes an approach. Shared AI work becomes confusing when those roles disappear during summarization.

For example, a client-approved brief may establish the scope of a launch. Discovery notes may contain preferences that haven’t been confirmed. A research summary may interpret several sources. A draft plan may propose how the team will deliver the work. Calling all four items “project context” doesn’t make them equally authoritative.

Use descriptive introductions and links to preserve the relationship. A working summary can say which brief governs the scope and which question remains open. A proposed plan can explain which assumptions need approval. That lets a person or an agent use the material without treating every polished paragraph as a settled decision.

When a source changes, review the interpretations that depend on it. If the approved scope now excludes a deliverable, the launch plan and client-facing explanation may both need revision. Updating the source alone doesn’t establish that the other documents are current.

Keep the dependency explanation proportional. A small project may need a short note connecting the approved brief to the draft plan. A larger project may need an explicit list of related deliverables. The purpose is to identify the work affected by a decision, not to build a map nobody maintains.

This is also where AI can be useful as a proposed assistant task. Ask it to identify passages that appear to rely on the changed source and prepare a private list for review. Then inspect the list. Don’t assume it found every dependency or that finding a passage authorizes changing the approved work.

Preserve one authoritative home for each commitment

View image detail

A decision record identifies the official source, any conflicting information, and the decision owner.

Actual size

Choose Actual size to read the graphic closely.

Before the pilot grows, identify where each consequential commitment becomes official. The project home can explain the work, but its summary should point to the record that governs a date, scope item, or assignment.

Suppose the team keeps contractual scope in an approved client brief and delivery assignments in a project system. Link both from the overview. If a working Page proposes a different launch date or an added deliverable, label the proposal and name who can decide it. The proposed change becomes a commitment only after the appropriate governing record is updated.

Once that decision is recorded, review the working drafts that relied on the old version. This sequence gives the team a way to use Space for interpretation without asking a polished summary to serve as approval.

When records conflict, make the conflict visible. A project overview that says “the delivery date needs confirmation because the plan and approved brief differ” is more useful than an AI-generated compromise date. The disagreement contains a real business decision.

Also decide how the team recognizes a superseded draft. Use a clear note or an agreed naming convention that identifies the current version. Don’t rely on the most polished file or the most recent conversation being the authoritative one. Recency can help locate activity, but it doesn’t establish approval.

Design sharing around the people doing the work

View image detail

Purposeful access helps a reviewer find the work, open necessary sources, and complete their review.

Actual size

Choose Actual size to read the graphic closely.

OpenAI documents Page view and edit access, revocation, and workspace restrictions. Uploaded files follow Page permissions. Linking to a separately stored file doesn’t grant access to it, while content copied onto the Page is visible to its readers. The feature is rolling out gradually. Space sharing, data, and controls

That means the project design needs two questions: who should read the working material, and who needs the source behind it? Those groups may overlap without being identical.

For a proposed internal launch pilot, the team might work from a permitted summary of the client’s approved brief. Some reviewers may also need the original to verify details. If they can’t open it, the owner should resolve the review path rather than assume the link provides enough evidence.

Read the assembled project material before sharing it. A summary can contain information that was appropriate in the original source but inappropriate for the new audience. The team should inspect what is actually present, not simply where it came from.

Keep external collaboration separate from an internal pilot until the organization has defined how the material should be used. An internal project home may contain unresolved risks, draft alternatives, or private planning notes. The client may need the approved outcome and a clear explanation of the remaining decisions, rather than access to every working item.

If a reviewer’s access differs from the owner’s access, test the actual reading experience. Ask whether they can find the item, open the necessary source, and understand its status. A link that works for the owner can still leave the reviewer unable to perform their assigned job.

Treat agents as contributors with a defined assignment

View image detail

A delegated contribution has defined inputs, a private review output, and a clear stop condition.

Actual size

Choose Actual size to read the graphic closely.

Shared project context can make an agent’s assignment easier to explain. It doesn’t eliminate the need to define the output or the authority attached to the task.

An agency could propose an assignment to inspect the launch materials and prepare a list of inconsistencies. The inputs would be the permitted project items. The output would be a private review note linking each issue to the relevant passage. The stop condition would be that the agent doesn’t change approved commitments or communicate with the client.

That is a complete useful contribution. It gives the project owner something concrete to inspect. The owner can then decide whether to revise the plan, ask a colleague for confirmation, or leave a proposed alternative unchanged.

The review note can use a repeatable shape without becoming another project system: identify the governing source, name the draft passage that differs, explain the consequence if it stays, and ask for one owner decision. In the hypothetical launch, "The draft FAQ names two customer segments, while the approved positioning names one" is a finding. "Remove the second segment from every client-facing item" is a proposed action that the owner still needs to accept. Keeping those two sentences separate makes the agent's work easier to check.

By contrast, “keep this project up to date” can mean several different things. It might mean refresh a summary, collect new files, reconcile conflicting dates, update a source record, or tell the client what changed. Those actions need different instructions. Define the smallest responsibility that produces value before expanding it.

Keep the contributor’s perspective visible when necessary. A subject expert may have information another teammate doesn’t have. An agent may be missing a source or working from an outdated assumption. A shared location doesn’t guarantee that every contributor has identical context.

Use a brief that names the governing sources, the intended reader, and the review destination. When the agent reports a limitation, inspect whether it reflects missing access, missing information, or a decision the owner hasn’t made. Each problem has a different remedy.

Make change updates explain their consequences

View image detail

A hypothetical narrower first release affects positioning, the sales FAQ, and the launch plan; the owner reviews the affected drafts.

Actual size

Choose Actual size to read the graphic closely.

A project can accumulate activity faster than a person can understand what it means. A useful update should explain which decision or deliverable changed and what happens next.

Consider a hypothetical change to the service launch: the team narrows the first release to one customer segment. The change may affect positioning, examples, the sales FAQ, and the launch plan. A useful update describes that connection rather than simply announcing that the brief has been edited.

It might say that the positioning source now defines a narrower audience, the draft FAQ still includes an example for the old audience, and the owner needs to decide whether that example remains useful. This gives the reviewer a specific job with a clear reason.

Avoid making every small edit an announcement. Fixing a typo and changing the promised delivery sequence have different consequences. Decide which updates need a review request, which belong in the regular project summary, and which don’t require anyone’s attention.

For important changes, identify what is already checked and what remains open. “The operations lead has confirmed the new sequence; the account lead still needs to review the client explanation” prevents someone from assuming all related work is complete.

This is a proposed operating pattern, not a claim that Space automatically maintains every dependency. Test any proposed AI-assisted update against a known source change before relying on it. The reviewer should be able to see what the assistant found, what it missed, and which decisions remain human-owned.

The result you want is understandable continuity. Someone returning to the project should be able to see why the current draft differs from the one they remember and which decisions still need them.

Test a small project before migrating the archive

View image detail

A project pilot tracks existing friction, return-to-work clarity, and the effort needed to maintain context.

Actual size

Choose Actual size to read the graphic closely.

A Space pilot should answer a practical question about the team’s work. Pick a project whose source material is manageable and whose owner can recognize the correct outcome.

Start by writing down the current friction. Perhaps a colleague repeatedly asks for the latest brief. Perhaps a reviewer can’t find the source behind a claim. Perhaps the owner has to explain which of several draft plans is current. Those observations create a baseline for the pilot.

Set up the project overview, the governing sources, and the current working items. Assign one or two colleagues a real contribution. Ask them to use the project home to find the information they need and return their work through the agreed review path.

Then observe what still required a separate conversation. Did the overview omit a decision? Was a source inaccessible? Did the contributor misread a proposal as an approved commitment? Record each friction point with the affected item and the person who can resolve it. A vague conclusion that the pilot was "confusing" leaves the owner without a repair.

For the hypothetical service launch, a pilot note could read: "The designer found the approved positioning but could not open the linked scope brief. The account lead will provide a permitted source or identify a reviewer who can verify the constraint before the concept is approved." That note separates a missing permission from a design problem. It also gives the next contributor a specific stop condition. No result is being claimed here; the example shows the kind of observation the team should collect.

Judge the pilot against the friction named at the start. If the problem was repeated requests for the latest brief, ask whether contributors found the governing version without the owner reconstructing it. If the problem was unsupported claims, ask whether reviewers could reach the sources. If the problem was unclear approval, ask whether someone could distinguish a proposal from a commitment. A successful search for a file does not prove the team understood its status.

Keep the pilot at one project when a reviewer cannot open the governing source, cannot identify the next decision owner, or still needs a separate call to learn which version is current. Repair that specific gap and repeat the same check. Try another project when contributors can find the governing material, explain its status and next decision, complete their assigned review, and maintain the overview without duplicating another reporting process. This is a proposed decision rule, not a claim about a tested Space outcome.

Include a return-to-work check. After a gap, ask a contributor to explain the current state and the next action. Continuity matters most when someone wasn’t present for every edit. A project home that only makes sense to the people who built it hasn’t solved the context problem.

Compare the administrative effort as well. If maintaining the overview duplicates work already done elsewhere, simplify the design. The pilot should reduce reconstruction and confusion without creating a second reporting obligation for the project lead.

Keep migration separate from evaluation. Moving an old archive can involve obsolete material, conflicting ownership, and access questions. Those are worthwhile issues to address if the tool fits, but they can obscure the result of an initial collaboration test.

Know when to keep the existing working system

Space may be a useful home for AI-assisted project work without becoming the home for every process. Choose its role based on the task, the people, and the systems the organization already relies on.

A team with an established approval workflow may want to keep that workflow while using Space to develop working material. A project with outside contributors may need a destination those contributors already use. A process governed by an existing system of record may need to preserve that system’s authority.

These are operating decisions rather than a feature-by-feature verdict against other products. This article doesn’t establish that Space is better or worse than a complete document suite. It proposes a way to evaluate whether a shared AI workspace helps a particular team maintain context.

Likewise, test the platform your contributors actually use. If their role depends on creating or editing from mobile, the launch limitation may change the pilot’s fit. A desktop workflow can succeed while leaving a mobile contributor unable to perform the same job.

The right outcome may be a limited role: one project home for research and working drafts, with approved commitments maintained elsewhere. That can be enough to justify the pilot if it makes the team’s decisions clearer and the handoffs easier to follow.

Organize for the next person entering the work

The useful test for ChatGPT Space is whether the next contributor can find the right context and understand what it means. A shared location helps only when the material inside it has a purpose, a status, and an owner.

Start with one project. Create a clear overview, identify the governing sources, separate proposals from commitments, and assign a reviewable contribution to a person or agent. Test access from the reviewer’s perspective and record the points where they still need clarification.

Expand when the pilot shows that the project home preserves context without adding a reporting burden. Keep the existing systems where they remain useful. The aim is a team that can pick up the work with less reconstruction and spend its attention on the decisions that move the project forward.

Product documentation checked September 30, 2026. Availability and sharing controls may change during rollout.