Changing what an agent knows while people are using it is the moment governance stops being a slide.
Someone edits an entity on a Tuesday afternoon. By Wednesday a manager says the pipeline number looks different. Was it the data, or the definition? Who changed it? Can we go back?
If the answers aren’t immediate, the tool loses trust faster than it earned it.
The model
ContextWorks versions definitions the way Salesforce versions Flows, because admins already know how that works.
Every save is a draft. Editing doesn’t change what agents receive until you activate.
Activation requires a comment. Not optional. “Removed deprecated stage values; added renewal-risk instruction.” The comment is what someone reads six weeks later.
Activation creates a version. The previous active version is kept. History shows every version, who activated it, when, and why.
Rollback is one action. Pick a prior version, activate it. No restore procedure, no developer.
Change logs, usage, quality
Beyond versions, three logs answer the questions that come up in a review:
- Change log — what changed in the configuration, by whom.
- Usage — which domains and entities agents are actually calling.
- Quality funnel — for each entity, how many fields were designed, how many are permitted for the calling user, how many came back populated. It separates a permissions problem from a data problem numerically, which saves a lot of guessing.
Version changes overlay the metrics, which gives immediate feedback and indication to the impact of the changes. Time-boxed payload logging (recording what an agent actually received) exists for full inspection.
Distributed, not centralized
Because domains are the unit of management, versioning is per domain. Sales can change pipeline definitions without touching Finance’s. Each business function owns its own context and its own history.
This is versioned configuration with rollback and change history. It is real, and it answers “who changed it and can we undo it” immediately.
