The Agent Worked Yesterday. Which Version Is Running Today?

A practical release workflow for teams that edit an agent while customers are still using it.

Your support agent worked correctly yesterday. Today, someone improves the system prompt, replaces a knowledge source, and changes the model. The test chat looks better, but the public agent still gives the old answer.

The first question should be simple: which configuration is actually running?

When draft settings and the live version are treated as the same thing, every edit becomes risky. A team may assume that a saved change is already public, or believe it is testing the draft while the customer-facing app is still using an earlier release.

This article uses one support-agent scenario to show a safer workflow: edit in draft, test a release candidate, publish a configuration snapshot, verify the live surface, and restore an earlier version when necessary.

The scenario: a return-policy answer changed

Imagine an agent that answers order and return questions. Its current public answer says customers have 30 days to request a return. The policy team updates the approved document to 14 days for one product category.

The change touches more than one field:

• the knowledge dataset must point to the revised policy;
• the prompt must tell the agent when to escalate exceptions;
• the model and generation settings must remain approved;
• the public agent must use the intended configuration.

If a teammate only edits the draft and closes the page, the live answer may remain unchanged. If the team publishes immediately, an incomplete binding or prompt edit can reach users.

Step 1: write down the current live behavior

Before editing, run two or three sanitized questions against the customer-facing agent and save the responses.

Use questions with known answers:

1. “Can I return Product A after 20 days?”
2. “The item arrived damaged. What should I do?”
3. “My order is outside the standard window. Can you make an exception?”

For each result, record the expected policy, the cited source if available, whether escalation was required, and the version currently serving users. This small baseline makes later comparison possible.

Do not use a fluent response as proof. The acceptance condition is whether the answer matches the approved policy and follows the correct handoff rule.

Step 2: make the change in draft

Update the draft configuration without assuming that the public version has changed. In ZGI, an agent configuration can combine instructions, model settings, enabled Skills, knowledge, database bindings, workflow bindings, and memory settings. A policy update may therefore require more than replacing one sentence.

For this example, check the draft in this order:

Draft check	What to confirm
Knowledge	The revised return-policy dataset is attached and processed
Prompt	The 14-day rule and exception path are unambiguous
Workflow	Escalation still receives the required order context
Model	The intended provider and model remain selected
Memory	Old customer context cannot override the current policy

Keep the change set small. If the policy, model, workflow, and response format all change together, a failed test will be harder to explain.

Step 3: test the draft as a release candidate

Run the same baseline questions against the draft. Add one boundary case on each side of the new rule: day 14 and day 15. Also test a damaged item, because that exception should not be silently absorbed by the standard window.

The release candidate should produce:

• the revised answer for Product A;
• the approved source or a clear indication that a source was unavailable;
• an escalation for exceptions that require human review;
• no change to unrelated product categories.

If one result fails, keep working in the draft. Avoid editing the public version through ad hoc changes that cannot be reconstructed later.

Step 4: publish a known configuration snapshot

Once the release candidate passes review, publish it as a versioned configuration. ZGI’s public source includes a published-version model and runtime paths that distinguish the mutable draft from published configuration. The web application path also checks whether a published version exists before serving the agent.

That separation gives the team a useful operating model:

• Draft is where changes are assembled and tested.
• Published version is the configuration intended for the live runtime.
• Version history is the record used to inspect or restore an earlier configuration.

Publishing a snapshot does not prove that every external action can be rolled back. If an agent already sent a message or changed a record, restoring configuration will not undo that side effect. The snapshot controls future runtime configuration, not the history of outside systems.

Step 5: verify the live surface after publishing

Do not stop at a successful publish message. Open the customer-facing surface and rerun the baseline questions. Confirm that the live answer now uses the 14-day rule and still escalates the damaged-item case.

Record four things:

1. the published version identifier;
2. the time of the release;
3. the exact test inputs and observed outputs;
4. the reviewer who accepted the result.

This turns “we published something” into a traceable release decision.

Step 6: restore first, investigate second when impact is active

Suppose the live agent starts applying the 14-day rule to every product category. The immediate goal is to reduce customer impact.

Select the last known-good published version and restore its configuration into the draft. Review it, publish the restored candidate, and rerun the same live checks. Then investigate the failed release separately.

Restoring into draft is an important safety step: it gives a human a chance to inspect the candidate before it becomes live again. Teams should still follow their own approval rules, especially when the agent can write data, send messages, or trigger workflows.

A compact release checklist

Before every agent release, ask:

• What changed in the draft?
• Which knowledge, tools, workflows, and memory settings are included?
• Which fixed test cases passed?
• Which version is currently live?
• What evidence will confirm the new version is serving users?
• Which version will we restore if the release fails?
• Which external side effects cannot be undone by a configuration restore?

The checklist is short enough to use in everyday work. Its purpose is to keep editing, testing, publishing, and recovery as distinct actions.

The practical lesson

When an agent behaves differently from yesterday, resist the urge to rewrite the prompt immediately. First identify the live version, compare it with the current draft, and reproduce the difference with a fixed request.

ZGI can support this workflow by keeping draft configuration separate from published versions and retaining a path to restore a selected version into draft. The exact controls available still depend on the deployment and release you are using, so verify the behavior in your environment.

Website: https://zgi.ai

GitHub: https://github.com/zgiai/zgi