When should KentiCopilot use CI/CD files instead of the Management MCP server?

As KentiCopilot gains broader write access through the Management MCP server, teams can often reach the same desired state in two ways: modify CI/CD-tracked configuration and deploy it, or let an agent apply a direct change through Management MCP. Repository data may be authoritative but difficult for an agent to interpret, while MCP provides a structured, validated interface.

How are teams deciding which path to use? My instinct is that repeatable structural changes should normally begin in source control, pass review and testing, and flow through CI/CD. Direct MCP changes may fit exploratory setup, content operations, or tightly scoped maintenance—but only when the action is logged, attributable, validated, and reproducible.

What decision rules have worked in practice? In particular, how do you prevent configuration drift when an MCP action changes an environment directly, and should every successful direct action produce an export, change record, or pull request so CI/CD remains the source of truth?

Tags:
CI/CD KentiCopilot Deployments MCP

Answers

I only use the CI repository when the Management API/MCP server hasn't yet added supported for that object or operation.

That list of scenarios is shrinking every month - in fact we added support for several new object types in the September 2026 Refresh.

Forms/Form Builder support is being worked on and is planned for the October Refresh.

There are a large number of objects in Xperience and we're working to get them exposed through the Management API as quickly as possible.

Everyone's feedback will help us prioritize future updates. For example would you like to see custom activities added? Maybe headless content items?

Thanks Sean, that's really helpful context on the coverage gaps - good to know the list is shrinking fast with the September Refresh (and forms coming in October).

Building on Mike's original question a bit further: for the cases where an object is already supported by both paths, we've generally leaned toward CI/CD for anything structural/repeatable (module classes, forms, consents, etc.) since it naturally gets review and testing, and kept direct MCP writes for exploratory or one-off content ops.


One thing that might help teams avoid drift in the meantime: would it make sense for MCP to optionally trigger an export (or a suggested PR) after a write, so the CI repo doesn't quietly fall out of sync with what MCP changed? Curious if that's already on the roadmap alongside the API coverage work.

would it make sense for MCP to optionally trigger an export (or a suggested PR) after a write, so the CI repo doesn't quietly fall out of sync with what MCP changed?

We intentionally disable CI for Management API operations because agents can perform many of them very quickly and it would lead to a lot of file updates and a performance impact. I think we also noticed some issues with concurrent edits from multiple agents and CI updates.

We are aware that agents don't always run CI store after a set of operations and that's something we want to improve.

The CI really only needs to be updated before a commit because the agent shouldn't need the CI data to validate its work. So, including some instructions/guidance in the MCP server or in skills could help here.

Thanks for the detailed explanation, Sean, that makes sense, especially the concurrent edits from multiple agents point, that's not something I'd considered.

Good to hear it's on your radar to improve. If it's helpful feedback: even lightweight guidance/skill instructions telling an agent to run CI store before committing (as you mentioned) would go a long way for teams who aren't aware of that gap today. Appreciate you digging into this one!


Thanks!

To response this discussion, you have to login first.