Skip to content
alikhan.tech

Writing

From Pages to Spaces — How Collaboration Features Change Headless Delivery

Muhammad Ali Khan · 05 Nov 2026 · 06 Mins read

From Pages to Spaces — How Collaboration Features Change Headless Delivery

An editor pinged me a screenshot of a Space and asked when the homepage would update. The Space was doing what Sitecore documents. It held a chat, a couple of artifacts, two collaborators, and a status that said the work was still in progress. Nothing in that screenshot was a publish. Nothing in it was a layout payload Experience Edge could serve. The homepage did not update because the head was healthy, and I had to explain that without sounding like I was dismissing the workspace they had just been told was the new center of the product.

Pages, the page builder, is still where a page item becomes a tree of renderings and datasources. Spaces, in Agentic Studio, are where people and agents collaborate on the work that may later become those items. Headless delivery still reads the published result. The change for a delivery team is real, but it is a change in how many drafts exist and who is editing them at once, not a new rendering API. These are the delivery consequences I plan for.

What a Space is, according to the product

Sitecore's Agentic Studio docs describe a space as a team workspace for AI-driven work: artifacts, context, chats, runs, and the agents you execute while you are in it. You can create one manually, or turn a chat into one. Inside it, a team monitors what is in progress, refines artifacts, runs further agents, shares context, and manages collaborators. The Spaces page lists title, the agent or flow label, status, and time. Statuses distinguish work that is still going from work that is finalized or completed. My spaces and Shared are different lists. Collaborators are explicit.

The same docs carry a caveat I repeat, because it saves a week of "it works in the demo tenant" arguments. The newer Agentic Studio UI is rolling out in phases. An organization may not see the updated Spaces UI yet. I do not write a delivery design that assumes a specific card layout. I write it against the behaviors that are documented once the feature is in the tenant: artifacts exist, collaborators exist, and an artifact can be converted into a SitecoreAI item.

The 30 March 2026 changelog is the other public marker I use. Agents can run on items the user selected, including pages, briefs, artifacts, and CSV rows, across parameters such as language. That is a collaboration feature with a fan-out shape. A space that "localizes this section" can touch every language version of a page. The head's language resolution, which was already a source of stale routes, now has a practical reason to be wrong in more locales at once.

The handoff that delivery cares about

I draw the path as four nouns. An artifact is generated in the space. A person converts or copies it into a SitecoreAI item, on a template the component map already knows. Workflow and collaboration in the page builder decide when that item is allowed to publish. Experience Edge serves the published layout, and the head renders the renderings it was built with.

Skipping a noun is how the homepage incident happens. If a flow converts the artifact and publishes in one step, the space felt like a delivery tool because someone granted the flow the right to publish. That is an authorization choice, the one I wrote about yesterday, not a property of Spaces. If the flow stops at an item in draft, collaborators can still edit in the page builder, and the public site keeps the last published version. Preview is how those collaborators see the draft. Preview is a mode of the head, page.mode.isPreview or isEditing, and it must not write the public ISR entry. I covered the cache half of that earlier this week. Spaces make it more likely, because more people are now looking at unpublished work and refreshing the public URL to "see if it landed."

The component contract does not move into the space. A space can hold an artifact that looks like a hero, with a heading and a summary and a fourth field the hero does not read. Conversion into an item will store whatever the tool maps. The head will render the fields it knows. I would rather the conversion step fail validation against the contract than create a datasource that previews as a half-empty component. The page builder remains the place where a rendering is placed on a placeholder. A space does not have placeholders. Treating it like a second page builder produces items that exist and pages that do not reference them.

Concurrent editors, and the version the head will meet

Pages already had locking and versions. Spaces add collaborators who are not all in the page builder at the same time. One person refines the artifact. Another converts it. A third is in the page builder moving components. The version that publishes is the version that was approved, not the version that was open on a laptop during the space's "completed" status. I have started putting the item id and the version into the space notes when we convert, so the space and the item can be reconciled later. Sitecore's space status is about the AI work. It is not the workflow state of the item. A completed space can point at a draft item. A draft-looking chat can point at an item somebody already published. I do not build a status sync I have not seen documented. I teach the team the two statuses out loud.

Language versions are the sharp edge of the March changelog. A run that generates outputs per language creates several versions, and only some of them will be in a workflow the locale owner recognizes. Our head resolves language from the URL and falls back to the default when a version is missing. A half-finished localization that published the shell and not the body looks like a rendering bug. The check I add to the publish notes is a list of locales the run claimed to touch, compared with the locales Edge actually returns for that path. If a locale 404s or falls back, we do not announce the localization.

Design Library and component-level preview stay on page.mode as well. A collaborator reviewing a single component from a space-driven experiment is not a visitor. The HTML for that review must not be the HTML a CDN stores for the route.

type Mode = { isNormal?: boolean; isPreview?: boolean; isEditing?: boolean; isDesignLibrary?: boolean };

export function cachePublicHtml(mode: Mode | undefined): boolean {
  return Boolean(mode?.isNormal) && !mode?.isPreview && !mode?.isEditing && !mode?.isDesignLibrary;
}

I call this at the point where we decide the cache headers, not as a comment in the component. A space full of collaborators increases the number of preview sessions. It does not increase the number of public pages.

What I changed in the delivery checklist

Multisite and shared content were already easy to get wrong. Spaces make reuse more tempting, because a team will generate one artifact and then ask for it on three sites. The item still has to live in a site collection and a template those sites share, or it is a copy. I do not let a space become a backdoor around the site collection model. If the artifact is converted into site A, site B does not see it until someone places it there and publishes B.

Links inside generated copy are the other delivery bug. An artifact that contains a relative href is harmless. An artifact that contains a full authoring URL, or a localhost editing host, will publish that URL if nobody reads it. The governed-link idea from the Marketplace post is one control. A simpler control is a publish checklist that greps the datasource for localhost, pages.sitecorecloud.io, and the CM host. I would rather catch that in review than in a crawl.

Analytics and personalization do not read the space. They read the published page and the variant Edge returned. A collaborative decision to "ship variant B" still has to be an experiment or a publish, using the A/B/n path the middleware understands. A space status of completed is not a winning variant. I have now said "status is not publish" enough times in one post to make it the whole point.

How I introduce a team that just got Spaces

  1. Show a space and a page item side by side. Name the artifact, the item id, the workflow state, and the public URL as four different things.
  2. Convert one artifact through the documented action, onto a template the head already renders, and stop before publish. Open preview. Confirm the public URL did not change.
  3. Publish with a person who has that right. Confirm Edge, then the head, then the CDN, in that order.
  4. If the run fans out across languages, verify each locale on Edge before anyone shares the public links.
  5. Keep preview HTML out of the public cache, because Spaces increase the number of people refreshing drafts.

Collaboration got a real surface in SitecoreAI, and it is a better surface than a shared document full of headlines the CMS has never seen. Delivery did not move into that surface. The head still renders published layout data, the component map still decides what is visible, and a space is finished only when the item it created has a version we meant to publish. I trust Spaces with the draft. I trust Edge with the site.

Related notes