When an Agent Can Prepare the Work but Shouldn’t Do It Yet

A practical approval workflow for support teams handling high-impact requests with ZGI.

A customer asks support to change the billing contact and issue a credit for a failed renewal. The agent can find the account, summarize the evidence, and prepare the change. It should not silently write to the account or send the credit.

That boundary is easy to describe in a prompt and easy to lose in a real workflow. If the agent is allowed to call every connected tool as soon as it has an answer, “helpful” can become an irreversible side effect.

The safer design is to let the agent prepare a proposed action, pause at an approval node, and continue only after a person has reviewed the exact inputs. ZGI’s workflow runtime is useful here because approval is represented as persisted execution state rather than as a sentence in the prompt.

Start with one request and three possible outcomes

Use a narrow support scenario first:

“The renewal failed after the customer updated their card. Please confirm the account owner, prepare a billing-contact update, and request a one-month service credit.”

The workflow should separate three outcomes:

Outcome	Agent may do	Human decision
Evidence only	Read the account record and renewal event	None, if the answer is informational
Proposed change	Prepare a structured update and credit request	Approve, edit, or reject
Executed change	Call the write-enabled action	Required before execution

This separation prevents a common mistake: treating a plausible recommendation as permission to perform the operation.

Configure the run as an explicit contract

In ZGI, keep the capabilities visible in the agent configuration instead of hiding them inside a long instruction. For this scenario, define:

1. A knowledge dataset for billing policy and credit limits.
2. A database binding that can read the account and renewal tables.
3. A workflow binding for the approval-and-update flow.
4. A write action that is reachable only after approval.
5. A memory policy that does not store a temporary credit decision as a permanent customer fact.

The important detail is the write boundary. A readable table and a writable table are not the same permission, and a workflow that contains a write action is not the same as an agent that may call it immediately. Treat the configuration as an execution contract: each binding should answer what the run can see, what it can prepare, and what it can change.

Build the five-step approval path

1. Normalize the request

The first node extracts account ID, requested change, evidence needed, and the requested amount. If the account cannot be identified, stop and ask a question. Do not let the model invent a customer record from a similar name.

2. Read and validate evidence

The next node reads the account and renewal event through the read-only binding. It checks whether the failed renewal is present, whether the requested credit is within policy, and whether the requester is authorized to ask for the change.

Return a structured failure when a condition is missing. “I found something close” is not enough to enter the approval step.

3. Create a proposed action

The agent now prepares a review object:

{
  "account_id": "acct_2048",
  "change": "update_billing_contact",
  "credit_months": 1,
  "evidence": ["renewal_event_8831", "policy_billing_04"],
  "risk_notes": ["credit requires human approval"]
}

This is still a draft. The object should show the source records, the exact write fields, and any policy exception. A reviewer should not have to reconstruct the agent’s reasoning from a paragraph of chat text.

4. Pause at approval

Place the approval node before the write action. The workflow persists its pause state and the proposed inputs. A reviewer can approve, reject, or request a correction. If the workflow is reopened later, it should resume from the stored state instead of recomputing a new credit amount from changing context.

5. Execute and record the result

Only the approved branch calls the write action. Record the approval identity, decision time, input version, and action result in the runtime log. If the action fails, keep the approval decision separate from the execution result. An approved request is not proof that the external system accepted the write.

What this exposes in the runtime

The product behavior is easiest to reason about when each stage has an observable state:

• the workflow run has a status and pause point;
• the approval node stores the pending decision;
• the write node receives the approved input contract;
• runtime logs retain node-level status and failure context.

That gives the support lead a practical debugging path. If a credit was never issued, ask whether the request failed validation, is waiting for approval, or reached the write action and failed there. A single chat transcript cannot answer that reliably.

ZGI provides the runtime pieces for this pattern: explicit workflow bindings, approval and question-answer nodes that can pause execution, and logs around workflow and node state. The design still depends on the connected system’s permissions and on how the team reviews approvals. The runtime does not make an unsafe write safe by itself.

Test the negative paths before connecting a real write

Use a small acceptance set:

1. Unknown account: the flow asks for clarification and performs no write.
2. Missing renewal evidence: the flow stops before proposal creation.
3. Credit over policy limit: the flow routes to rejection or a higher approval tier.
4. Duplicate approval click: only one execution is accepted.
5. Approval followed by an external failure: the run records the failure without claiming success.
6. Stale proposal: a changed account record forces revalidation before execution.

These cases test the boundary, not just the happy path. They also make the workflow easier to explain to support operators who need to know why a request is waiting.

The rule of thumb

Let the agent gather evidence and prepare a precise action. Put every high-impact write behind a persisted approval state. Log the difference between “approved” and “executed.”

That is a small workflow change, but it turns a vague instruction—“ask a human before changing anything”—into a path that can be inspected, paused, resumed, and tested.

ZGI: https://zgi.ai

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