On September 25, Sitecore released three new REST APIs for SitecoreAI (Components, Content Types and Content Items), and the obvious reading is that you can now create components and templates over REST, which is true, but what matters to me is that the definition layer now sits inside the automation surface that agents and workflows already use to write content.
Templates were already writable, the Authoring and Management GraphQL API has had createItemTemplate and updateItemTemplate for a while. What changes here is the contract, with dedicated REST resources, OpenAPI descriptions and environment automation client credentials, and that combination makes schema changes much easier to consume from agents, MCP servers and workflow tooling. In a typical governed Sitecore project, templates and renderings have been treated as code, represented in serialization, reviewed in source control and promoted through the pipeline, and with these APIs an automation client can write those definitions straight into an environment, so the governance question moves from whether an agent can change the schema to where you allow it to.
A new vocabulary on the same model
The three APIs share one authoring host (edge-platform.sitecorecloud.io/authoring), they are v1, and the Agent API lives on a different path (/stream/ai-agent-api). The Agent API and the Marketer MCP expose operations around pages, components, datasources and personalization, and while they can list components, read their details and create datasources for them, none of their documented component tools define a new component or content type.
Nothing underneath has changed. A "content type" is a template, with a parentId, baseContentTypes (base templates) and fieldGroups (sections), and its fields use the usual Sitecore field type names (the spec's example is Single-Line Text). Field sources are still Sitecore query strings, with examples like query:$site/*[@@name='Data'], creating a content item still needs a parentId and a templateId, and the Content Items API even names its request schemas CreateDatasourceInput and DatasourceItem.
I think Sitecore made the right call here. Experience Edge, the Content SDK and every existing SitecoreAI solution depend on the item and template model, and a parallel model would have given us two sources of truth. An OpenAPI document maps to an MCP tool catalog with very little translation, so I expect custom MCP servers and n8n workflows to wrap these endpoints long before anyone reaches for the GraphQL mutations.
Component drafts invert the modeling order
The Components API covers create, read and update over components (v1 has no delete endpoint for an activated component), plus read access to categories and site availability, and on top of that sits a draft lifecycle:
POST /components/drafts/suggestionstakes a natural-language prompt and returns a suggested name, display name, category and description.- A draft holds one or more variants, and each variant carries its own
code. POST /components/drafts/{id}/model-suggestionasks the AI service to infer a content type from the variant code, and you can pass "atoms" from the rendering host with it, which the spec describes as small reusable UI building blocks.POST /components/drafts/{id}/activationcreates the content type (when the draft has one), the component and the named variants in one operation, then permanently deletes the draft.
For most of Sitecore's history we modeled the template first and built the rendering against it, and drafts go the other way, with the implementation first and the schema derived from it. For marketing-led component work like a promo block or a campaign banner, that is a reasonable shortcut, and it is closer to how front-end teams already work.
The price is that a modeling decision becomes an inference step. The model suggestion can infer the structure the implementation in front of it needs, but it cannot know the modeling conventions of the wider estate, such as which concepts already have a canonical content type or which fields belong in shared base templates. On large estates, reuse gets decided at modeling time, and that decision drives most of what a content model costs over the years, so I would use model-suggestion as a starting point and have someone review it against the existing content type library before activation.
Activation needs some planning too. It is one-way and deletes the draft, so the draft can't serve as your record of what was requested, and if the prompt, the suggestion and the reviewed model matter (on regulated projects they will), store them on your side before activating. When the activation request omits availability, the endpoint falls back to what the draft stored, and without either the component is created with no site assignments. The DraftType enum also separates Code from Hosted components, but the spec doesn't explain how each is rendered, so I would confirm that before designing any pipeline around drafts.
Validation runs after the write
The Content Items API exposes GET /content-items/{id}/validate, which runs the validators assigned to the item's fields "against their persisted values" and returns results grouped by validation mode, with a severity per rule.
So you write first and validate second. On create, update and replace, the only documented 400 response is "Invalid input format", and none of those operations mention field validators, so my reading is that a request can succeed with content the validators will flag afterwards (worth confirming in a sandbox). Human authors in Page builder have the validator bar and the workflow between the edit and the publish, so this rarely mattered, but an automation client writing hundreds of items puts invalid content in the database and only learns about it on the next call.
I described this command-side problem in The Consumer Became an Author. The platform supplies the validators, but the decision about whether a write should happen at all still sits with the caller. My pattern would be to write into a state that cannot be published, where the surrounding workflow supports that separation, call /validate, and only allow promotion when no result has Error severity. The API gives you the check, and your workflow design has to supply the gate.
Two other operations in the same API are easy to miss. POST /content-items/live reads published items from the Edge Delivery API, so an automation can compare authoring state with what is live using the same client, and POST /content-items/{id}/translate starts a translation job with three strategies: skip if the target language exists, add a version, or add a version and reset workflow. I would use the last one whenever translations have to go back through approval.
PUT is the dangerous verb
All three APIs make the PATCH and PUT distinction explicit, and PUT is destructive by design:
PUT /content-types/{modelId}removes existing fields that are not in the request.PUT /content-items/{id}clears fields omitted from the request.PUT /components/drafts/{id}replaces the whole variants collection, dropping any variant missing from the body.
A migration script with the full object in hand can use PUT safely, but an agent assembling a payload from partial context is another matter. Picture an agent that reads a content type, decides to add one field and sends back its own idea of the model, and every field it left out is gone, including fields that still hold content on live items.
Content types have one more wrinkle, PATCH and PUT both return 202 Accepted instead of 200. The spec doesn't say what completes asynchronously, but I wouldn't write items against a new field until a GET on the content type shows it.
Concurrency deserves attention too. Each content item carries a revision, which the spec describes as an optimistic concurrency guard that changes whenever the item changes, "allowing clients to verify that they are updating the latest revision". The update and replace inputs don't take a revision though (no field, no header), so as documented the check happens on the client side, by reading the item again and comparing before writing. For agents working on content that people are also editing, I would make that comparison part of the write contract and keep the window between read and write short, because the API as documented won't reject a stale write for you.
If you expose these APIs as tools, give agents PATCH and keep PUT away from them, and I would also put DELETE on content types behind a human confirmation. Content item deletes go to the recycle bin unless permanently=true is passed, and I wouldn't let an agent set that flag, while the content types DELETE operation says nothing about a recycle bin, so I treat it as permanent.
Schema changes now have two entry points
Until now, the path for a definition change on a governed project was source control, then the pipeline, then the environment. The Content Types and Components APIs add a second path, from an automation client straight into the environment, and without a policy you have two authorities able to change the same definition. A team that uses both without a rule ends up with drift: definitions in the CM that source control doesn't know about, and a later deployment that overwrites them or fails in ways that take a while to trace.
The authentication model adds to this. The APIs use environment automation client credentials, which an Organization Admin or Owner creates in SitecoreAI Deploy and which are scoped to a single environment, while the Marketer MCP uses an authorization code flow with interactive sign-in through Sitecore Identity, so the two paths behave differently. The spec describes createdBy as "the user who created this resource", so check what that field records for an automation client, and whether it tells you which person or agent asked for the change, before relying on it for audit. The Agent API has a Jobs resource for viewing and reverting operations, but I found nothing equivalent in these three APIs, so rolling back a schema change is on you. I covered the wider question in The Agent Has Write Access, and for this release my short answer is to handle schema writes the way you handle migrations.
My working governance rule (my policy, not a Sitecore recommendation):
Environment | Content Types and Components write | Content Items write |
Local and dev | Allowed, results serialized back to source control | Allowed |
Staging / UAT | Pipeline only | Allowed with workflow and |
Production | Pipeline only | Allowed with workflow and |
Since clients are already scoped to one environment, I would also create a separate client for each materially different use case in that environment, rather than sharing one across unrelated workflows. That keeps revocation and blast radius narrow, and if the system fields record the client, you can read them when something breaks.
What I have not verified yet
These are v1 APIs whose documentation went live days ago. I have read the OpenAPI descriptions closely but haven't run them against a production-sized environment, and I found no documented rate limits. The Code and Hosted component types need checking in a sandbox, as does the real write-versus-validate behavior and how new components show up in Page builder, so treat the patterns above as architectural guidance to validate against your own environment.
Conclusion
The Components, Content Types and Content Items APIs expose the existing content model, definitions included, through a REST contract that agents and workflows can call directly, and that puts the definition layer inside the same automation boundary as pages and content. You get component and schema scaffolding without a deployment cycle, along with usable validation and translation primitives, but schema changes now need an owner and a promotion path like any other migration, and that has to be decided before any client gets write access to them.
