The AI draft is approved. Should the website update immediately?

Letting an agent draft content and an editor review it can look like a complete production process. Once a website consumes that content, another set of questions appears: Which version does it read? Does approval make it public immediately? If the page stays unchanged, is the proposal still unmerged, or has the cache failed to refresh?

Content acceptance and website publication need separate rules. Acceptance determines what enters the trusted record. Publication determines what visitors can see. Connecting those rules gives editors a clear understanding of the consequences of their decisions.

Establish what the website actually reads

In Busabase, ChangeRequests preserve proposals and their modification history. Pending, approved, and merged changes represent different stages. Merging advances the record pointer so that the accepted version becomes the canonical record. Approval alone does not mean that transition has happened.

A website integration needs an explicit read contract. Public pages should generally consume accepted canonical records and filter them using the website's own publication conditions. Pending proposals can have a dedicated preview route, kept separate from the collection served to visitors.

Those public conditions belong to the particular CMS and website implementation. A team might require both a merged record and a defined publication status and time before a record becomes eligible for display. Busabase does not automatically establish that publishing policy for every connected website.

Permissions determine whether review is enforced

API key permissions change how proposals are handled. The changeRequest permission allows reading and proposing changes, but does not allow the caller to merge its own proposals. A writer with write permission may have a ChangeRequest merged immediately on creation. The caller can also explicitly set autoMerge: false to send that batch for review.

Using ChangeRequests therefore requires checking the actual credential, submission parameters, and returned status before concluding that a human approval gate exists.

When an editor must accept content first, give the drafting agent proposal-only credentials. Configure the site's reading credentials with the access required for their job. Keep credentials on the server, outside public pages and browser bundles.

Review the complete unit that will become public

A body can be accurate while its summary still promises an old capability. One language can be corrected while another retains an incorrect price. Link text can look right while its destination has stopped working. Reviewing the body alone leaves these failures untouched.

Treat the title, summary, body, cover, inline images, links, and language versions as one public unit. Preserve the relationships between localized versions and identify which can be accepted together and which must wait.

For revisions, inspect the before-and-after differences and their scope. Accepting a paragraph does not automatically authorize changes to publication dates, routes, or other articles. The proposal message and visible changes should make the affected pages clear to the reviewer.

Delivery continues after a record is merged

A useful website consumption contract specifies:

• Read scope: the Base, records, canonical version, and publication conditions the site consumes.
• Preview: where unpublished versions can be checked and whether preview uses the same rendering rules as production.
• Refresh: the controlled build, cache invalidation, or other mechanism that updates the site, including how failures are detected.
• Acceptance checks: the actual page body, language routes, images, links, and public metadata.
• Withdrawal: how pages, cached responses, and related entry points are removed after publication stops.

These are integration recommendations for the website maintainer to implement. An event covering newly created records should not be assumed to cover every content update. When choosing events or polling, verify coverage for updates, status changes, and withdrawals.

Locate the failed stage before retrying

When an editor asks why an approved change has not appeared, first check whether the ChangeRequest was merged, then inspect the record version the website reads. If the canonical record is correct, check publication filters, builds, and cache refreshes. Preserve the actual response and page version when production remains stale, rather than creating another copy of the article to trigger publication.

Retry the failed stage. If content is merged, retry downstream refresh. If it remains pending, resolve review. If versions conflict, inspect the proposal again. Treating every failure as a reason to rewrite the content creates duplicate records and obscures the original problem.

Withdrawal also needs verification. After changing a record's publication state, check that the page, listing, and other configured entry points follow the site's contract. Preserve historical changes in the audit trail so the team can explain what was previously public.

Organize the drafting-to-publication handoff in Busabase

Reuse the existing CMS Base rather than creating a parallel article library. For a new setup, a Folder can group the resources; a Base can hold each article’s title, summary, body, language, publication conditions, and preview link. A Doc holds editorial and publication rules, while a Skill preserves the method the agent reads before drafting. These are suggested fields, and their actual names and values must match the website’s reading logic. Relations can connect language versions, with traceable links to original sources.

The agent reads the rules and sources, then submits a ChangeRequest for the specified article, identifying affected fields and languages. The editor inspects the differences; merging makes the accepted content canonical. The website server reads canonical records from that Base, applies the agreed publication conditions, and refreshes the page. Write the production URL and verification result back to the article so the team can trace the draft, accepted version, and actual page from one record. Pending proposals stay in preview. Reading, refresh, and result writeback require a concrete website integration.

Complete one cycle with one content type

With Content Factory, teams can organize sources, drafts, and review records, then let an existing website consume accepted content. Start with one content type. Define the agent's proposal permissions, the editor's acceptance scope, and the website's read contract before extending automation.

A starting instruction for the content agent is:

Read the specified sources and editorial rules. Prepare the complete title, summary, body, and links, and check existing records for duplicates. Propose the changes through a ChangeRequest, explaining which pages and language versions are affected. Give the editor the returned status and preview link. Do not report pending content as published.

The website maintainer checks a different outcome: use a pending change, an accepted change, and a withdrawal to verify preview, canonical reads, and production behavior against the agreed rules. This is a suggested validation method; the particular website must run it and record the results.

The AI review bottleneck concerns how people review efficiently. Website delivery also needs a traceable connection between what an editor accepted and what a visitor sees. Making that connection explicit gives the content team a reliable foundation for increasing agent execution.