Agentic Studio 101 for Developers — Where Agents Stop and Your Code Still Matters

Agentic Studio is the part of SitecoreAI that demos well and integrates quietly. Sitecore introduced it on 4 November 2025 with the SitecoreAI announcement: a workspace where marketers and agents plan, create, and personalize, with 20 prebuilt agents and a visual builder for custom ones. A year later I am usually in the room as the person who has to explain why the agent's "successful" run did not change the website.

The explanation is almost always the same. The agent did what its tools allow, inside the caller's permissions, and wrote Sitecore items. The Next.js app renders only the renderings it was built with, through the fields those renderings read. Agentic Studio does not compile that app. This is the 101 I give developers who are about to be asked to "just add an agent" to an existing SitecoreAI implementation.

---

Two kinds of custom agent, and only one of them is a workflow

Sitecore's Agentic Studio docs split custom agents by shape.

A standard agent is the chat-style, task-driven one. You reach for it when the user is still deciding what they want, iterating on a brief, or asking for a draft they will edit by hand. It is the closer cousin of the Stream optimize-content panel I wrote about in 2025, except it sits in Agentic Studio and can call SitecoreAI tools rather than only rewriting the field in front of the author.

A workflow agent is for a sequence you can draw. Sitecore recommends it when the outcome should be consistent: a fixed order of steps, approvals, and structured outputs. The workflow editor opens on five tabs. Overview holds the name, the description, and the run-page copy ("what is it for", "how it works") plus the inputs the user must fill in. Parameters, schemas, and HTML templates shape what the agent accepts and how a result is presented. The Workflow tab is the sequence itself.

You need a Builder license to create either kind. I confirm that license before I sit down with a marketer to sketch steps. Duplicating a prebuilt agent is the documented shortcut when the change is small, and an exported JSON definition is a reasonable thing to keep in source control next to the rendering contract it depends on. I do not treat that JSON as a substitute for the Next.js component. It is configuration. The component is code.

A fixed sequence belongs in a workflow agent. A conversation that is still finding the brief belongs in a standard agent.

---

The tools are Sitecore operations, not React components

Workflow steps do their Sitecore work through the Invoke Tool action. The configuration is three fields: the tool, a Parameters JSON object, and an output variable that stores the response. A successful response carries success: true and a data object. A failure carries success: false and an error string. Some tools nest further, which is why the second step in a flow so often breaks.

Sitecore's own walkthrough chains Search Pages into Get Page Content. Search Pages takes siteName, searchText, language, and pageSize, and each hit includes an itemId. Get Page Content wants that id as pageId. The workflow expression that connects them is not "pass the previous output". You type @ in the Parameters editor, pick the upstream step, and then edit the path until it resolves to the id string alone. A path that resolves to the whole tool payload is a type error the tool will not forgive. The expression in Sitecore's walkthrough names the upstream step and ends at itemId. The step id is generated. The lesson I care about is that last segment: the id, not the envelope.

I redraw that flow for our sites with our site name and a rendering we actually ship:

{
  "siteName": "marketing",
  "searchText": "product overview",
  "language": "en",
  "pageSize": 1
}

The following step may only receive the id:

{
  "pageId": "{{@<generatedStepId>:Find product page.data...itemId}}"
}

I left the middle of the path as data... on purpose. Sitecore's docs say the exact path varies by tool and that you should inspect the previous step's output when a later step fails. Copying a path from a blog, including this one, is how you bind to data.data.data.1 on a tool that returned data.results[0]. Open the step log. Point the expression at the id. Then lock the flow.

The Invoke Tool catalog is wide. The docs group it into site discovery, page management, components, assets, personalization, brand kits, briefs, and experiments, and there is a web_search tool whose sample parameter is a query string. Web search is the one I flag in review. It can pull public pages into a prompt. It must not be the source of record for a claim we then publish on our own site. Our pages, our brand kit, and our indexed content are the sources I want in the flow. The public web is research, and a person should read it before it becomes a field value.

---

The same operations exist as an API and as an MCP server

Agentic Studio is the UI. The Agent API is the surface underneath it, and it is documented for developers who are not clicking the workflow editor. It is a REST API, called in the production environment, authorized with an automation-client JWT or with an OAuth app. An Organization Admin or Owner creates the automation client under SitecoreAI Deploy, and the client secret is shown once. I store that secret the way I store any other production credential. I do not paste it into a workflow screenshot.

The documented object areas match the tools: sites, pages, content items, components and datasources, assets, environments and languages, personalization variants, jobs, brand kits, brand context, briefs, experiments, and flow definitions for A/B/n tests. Every call still passes through Sitecore's security and approval rules. The detail I make sure our team hears is the job id. If an agent writes the wrong thing, the job id is the handle Sitecore documents for reverting that operation. "The AI did it" is not an audit trail. The job id is.

The Marketer MCP server is the natural-language front door onto those same endpoints. Sitecore documents it as an MCP server that MCP clients such as Claude Desktop and Cursor can use to create pages, place components, and update content. The tool reference says the actions remain subject to the user's permissions and to whatever review, approval, versioning, and publishing workflow the site already has. I like that sentence. It means an MCP client is not a backdoor around the workflow we spent last year putting on the site. It also means a developer with publish rights, pointed at production, can do real damage in one prompt. The automation client should be scoped the way we scope a CI credential, and production prompts belong to people who already understand the site.

I do not wrap the Agent API in a second undocumented facade inside the Next.js app "so the frontend can call agents". The rendering app's job is to read published layout data and draw it. Agent calls belong in a server-side integration with a credential that never reaches the browser, or they belong in Agentic Studio itself. A NEXT_PUBLIC_ secret for the automation client would be a defect, not a shortcut.

---

The contract I write down before anyone opens the workflow editor

This is the page I want in the repo. It is short because the agent will not read our component source unless we hand it the constraints.

export const productHeroContract = {
  renderingName: 'ProductHero',
  templateId: 'B6C3E0A1-1111-2222-3333-444455556666',
  fields: {
    heading: { type: 'single-line', maxLength: 80 },
    summary: { type: 'multi-line', maxLength: 240 },
    image: { type: 'image', required: true },
    cta: { type: 'general-link' },
  },
} as const;

The GUID above is a placeholder. Yours comes from the template item. The rules I enforce around it:

• The rendering name matches the key in the Content SDK component map, character for character.
• The fields listed are the fields the React component reads. Extra fields are allowed only if a developer has agreed to ignore them on purpose.
• maxLength is a product decision we also enforce in the agent prompt and, where Sitecore validation exists, on the template. The agent will otherwise write a hero headline the length of a blog lede.
• Required image means the flow has to pick an asset from the library or stop. I would rather the step fail than publish a hero with a broken image field.
• Links use the site's link format. A bare https:// string stuffed into a general link field is a classic "the tool returned success and the component rendered nothing" bug.

Schemas and HTML templates in the workflow agent are how Sitecore lets you shape the agent's own output. They are useful for a brief, a tweet, or a summary the user will copy. They are not a second design system. When the output is supposed to land on a page, I prefer Invoke Tool against a known template over an HTML blob the page builder cannot edit properly later.

---

Where I still want application code

Rendering and design. Layout, responsive behavior, accessibility, and the design system live in the Next.js app. An agent that emits a one-off HTML fragment for a campaign landing page will not pick up the next brand refresh. Pages composed from existing renderings will.

Authoring mode. Content SDK exposes page.mode. Chrome, placeholders, and field metadata are the SDK's job. Our job is to keep custom components from hiding buttons, trapping focus, or rendering a different DOM tree in editing mode than they do on the live site. If the trees diverge, the page builder and the published page drift apart and authors stop trusting both.

Personalization variants that have logic. SitecoreAI can create variants and experiments through the Agent API. The variant is still content. If a variant depends on a claim code, a pricing rule, or a feature flag, that rule stays in code or in the personalization engine we already operate. I do not bury it in a system prompt.

Publishing and cache. A flow that creates a page has not published it unless a publish step ran, and a publish has not updated the CDN unless our revalidation ran. I keep that wiring in the application and in the existing publish hook. Agentic Studio does not know that Netlify, or any other host, keyed the HTML on a cache tag.

Secrets, retries, and idempotency. Workflow tools can fail halfway. I want a flow that searches for the page it might already have created before it creates another one. That is ordinary integration hygiene. The visual editor will not add it unless someone who has been paged for duplicate items insists.

---

A review I run the first time a flow touches a real site

I ask for a non-production site and a content tree we can delete. Then I walk the flow once and keep the notes.

1. Who can run it, and does that user have publish rights? If they do, say so in the run-page copy. "How it works" is not the place to be vague.
2. Does every Invoke Tool parameter resolve to the scalar the next tool documents, especially ids?
3. Does the created item use a template our component map renders? Open the page builder. If the rendering is unknown, the flow is ahead of the repository.
4. Is there a job id in the run log, and has someone actually reverted a test write with it? I want that rehearsal before the first marketing demo.
5. Did a publish happen, and did the head app show the new field values without a redeploy? If a new rendering was required, the answer is no, and the flow should not pretend otherwise.
6. Are brand-kit and language inputs explicit? Sitecore's November 2025 examples, Berkeley Homes and AFL among them, were about contextually aware content aimed at the right audience and channel. Those were Sitecore's customers in the press release, not a template you can copy. On our sites the brand kit and the language parameter have to be chosen, not assumed.

---

What I tell a developer who is new to the studio

Learn the five tabs and one chain: Search Pages, then Get Page Content, then a write or a Generate Content step you can read. Learn the @ path rule. Learn where the automation client is stored. Then stop, and go read the component that will render the result.

The prebuilt agents from November 2025 are allowed to be useful without a pull request. Campaign drafts, migration assistance, test ideas: that is the point of shipping twenty of them. The moment a flow creates a rendering, a template, or a field, it has crossed into the application, and the application changes in git. That line is the whole 101. Agents are very good at operating Sitecore. They are not the Sitecore implementation.