Help Articles – Page 6
By the four-phase exit criteria, not by the model's benchmark scores. The readiness signal is operational: scoped identity in place, audit captures intent, discovery-mode plans match human-operator plans, governed execution has run a representative volume of writes with zero unrecoverable actions, and a governance cadence is established and attended. If any of those is missing, the agent is not ready to scale, regardless of how the model performs in isolation.
With a standing governance group, a monthly cadence, and the audit log as the agenda. Governance covers tool-permission drift, new-tool onboarding, model changes, incident review, and retiring tools the agent no longer needs. The governance group needs representation from digital, platform, security, and risk - not just the team that built the agent.
When it has demonstrated, in discovery mode, that its plans are the plans a human operator would approve, on a representative task set, over a window long enough to surface your edge cases. Write access is earned, not defaulted. And the first writes should be reversible, low-blast-radius actions inside a tight tool box - not high-stakes operations on customer-facing data.
The narrowest set of permissions that lets it do the specific job you hired it for. Agents should never inherit a human's permission set, and they should never share credentials with another agent or service. Permissions are granted at the tool level, scoped to the record types and actions the agent's job actually requires, and reviewed on the same cadence as the rest of your privileged-access program.
In phases, with read-only first. The pattern that works is: prepare the environment with scoped identity and audit, validate the agent in discovery mode where it can plan but not write, promote it to governed execution with tight tool boundaries and rollback, then run it under continuous governance with a standing review cadence. The single most common failure mode is granting write access before discovery-mode validation is honestly complete.
MCP, the Model Context Protocol, is a standard for exposing tools to AI agents as a declarative surface. Instead of every agent integrating against every system through bespoke code, the system publishes its tools through MCP and the agent discovers and calls them through a single protocol. For enterprise rollouts, MCP matters because tool boundaries become enforceable. You grant an agent access to specific tools rather than to whole systems, and you can revoke access without rewriting the agent. Core dna's MCP server exposes 80+ tools across 400+ APIs, in production today.
A chatbot answers. An agent acts. The chatbot lives in the conversation layer and hands off to a human or a workflow when something needs to happen. The agent owns the doing. That difference is why the governance model for agents looks more like the model for a privileged service account than like the model for a content surface.
An enterprise AI agent is a software actor that takes goals, plans actions, and calls tools against your production systems on its own initiative. The distinguishing trait is autonomy with consequence. Unlike a chatbot, an agent is doing work that changes state - updating records, dispatching workflows, calling APIs that move money or content or customers. Enterprise-grade means it operates inside the same identity, audit, and governance perimeter as the rest of your platform.
Only if the business case for headless exists independently of the migration. Headless solves real problems - multi-channel delivery, frontend framework freedom, separation of editing and rendering - but it adds complexity. Migrating to headless because the migration was happening anyway is how teams end up with a stack they can't staff.
In practice, none. "Migration" tends to describe the content and URL move. "Replatform" tends to describe the broader project, including the new CMS, integrations, and team workflow. The checklist applies to both.
No, and you shouldn't. A migration is the cleanest moment you'll ever get to retire content that isn't earning. Categorise everything into keep, merge, rewrite, and retire before the build starts. Pages that get fewer than ten organic visits a month and carry no backlinks are usually retirement candidates.
A minimum of 12 months. Google has stated it processes 301s relatively quickly, but external sites and email signatures take longer to update. Twelve months covers the long tail. For high-value URLs with sustained backlink growth, keep them permanently.
Separately, in that order. Migrate the CMS first with the existing design intact, prove the platform works, then redesign on the new stack. Combining the two doubles the variables when something breaks. If the business case forces them together, freeze URL structure and content so the redirect map stays valid.
An incomplete redirect map. Specifically, URLs that earned backlinks years ago, aren't in the current sitemap, but still drive referral traffic and link equity. A crawl of the live site catches the obvious ones. A backlink export from Ahrefs, Semrush, or Search Console catches the rest.
It can, and most migrations do see a short-term dip. A clean migration recovers in four to eight weeks. A migration without a complete redirect map, or one that changes URL structure without 301s, can lose rankings permanently. The difference is phase one planning, not platform choice.