Why Knowledge, Databases, and Workflows Should Be Explicit Bindings in ZGI

A practical customer-support scenario for turning a prompt prototype into a reviewable agent configuration.

Your team has a recurring problem: agents can answer simple questions from a product guide, but complex requests require checking account data and starting a follow-up process. A single prompt can describe all three activities. It cannot make their boundaries visible.

That is where prototypes become difficult to operate. A prompt may say “use the knowledge base, look up the customer, and create a case,” while nobody can tell which data is readable, which action is allowed, or which workflow version was used.

ZGI’s agent runtime can be understood as a composed execution contract. The system prompt, model parameters, enabled Skills, knowledge datasets, database bindings, workflow bindings, and memory are configured as separate parts of a run. The practical lesson is simple: bind each capability explicitly, then review the contract before trusting the answer.

Start with one support request

Imagine a support specialist receives this request:

“The customer says the latest desktop build still crashes after login. Check the troubleshooting guide, confirm whether their plan includes priority support, and prepare the next-step case for review. Do not send anything yet.”

The request combines three different jobs:

1. Find an answer in approved product knowledge.
2. Read one account attribute from a database.
3. Prepare a repeatable case workflow without sending an external message.

Treating those jobs as one invisible capability creates avoidable ambiguity. A retrieved paragraph is not proof that the account was checked. A database row is not authorization to change it. A prepared workflow is not a sent message.

Define the bindings before writing the long prompt

Create an agent called Support Triage Reviewer. Begin with a narrow, read-first setup:

Binding	Example configuration	Boundary to review
Knowledge	Approved troubleshooting and plan-policy datasets	Which documents are current and in scope?
Database	Read-only customer account table	Which fields may be read?
Workflow	“Prepare support case” workflow, version 3	Does it create a draft only, or trigger an external side effect?
Skill	Case-formatting Skill	Does it format evidence without inventing facts?
Memory	Optional per-user preference slot	Is durable context necessary for this task?

The exact names are examples, not a prebuilt ZGI template. The useful move is separating the capabilities so a reviewer can inspect them independently.

Configure the agent in ZGI

In Agent Studio, select a model available in your deployment, add the system instruction, and bind only the knowledge datasets, database table, workflow, and Skill needed for this scenario. ZGI’s public product overview describes Agent Studio as combining models, knowledge, tools, and Skills, with workflows for multi-step work: https://zgi.ai

Use an instruction that keeps the boundaries visible:

For each support request, use only the bound knowledge datasets for product facts. Read the bound customer table only for fields required by the request. Produce a reviewable case draft with source references and an explicit “not checked” section. If a workflow is bound, prepare its input but do not execute an external side effect unless the request explicitly authorizes it and a human reviewer confirms it. Never treat a missing field as a negative fact. Mark uncertainty instead of guessing.

Now run the example request. The expected shape is not a confident paragraph; it is an auditable handoff:

Knowledge finding: The troubleshooting guide lists a clean profile reset as the next diagnostic step. Source: Desktop Login Troubleshooting, section 4.

Account check: Priority-support eligibility: yes, based on the bound account field support_tier. Other account fields were not checked.

Prepared workflow input: Customer ID, issue summary, diagnostic step, and source references. Status: draft for review. No case was sent and no customer record was changed.

The response is useful because each statement has a different origin and authority. Knowledge supports the product instruction. The database supports one account fact. The workflow produces a structured draft. Human review remains the decision point.

Why a single prompt is not enough

A prompt can request all three actions, but it does not replace explicit runtime wiring. Without a visible database binding, a reviewer cannot tell whether “priority support” came from an account record, a remembered conversation, or a model guess. Without a workflow binding, “prepare the case” may be interpreted as free-form text rather than a defined input contract.

Explicit bindings also make failure easier to diagnose. If the answer cites outdated troubleshooting guidance, inspect the knowledge dataset and its version. If the account field is missing, inspect the readable-table binding. If the case draft has the wrong shape, inspect the workflow input contract or Skill. Debugging becomes a configuration question instead of prompt archaeology.

Keep read, prepare, and execute separate

For a first production-shaped test, use three stages:

Read. Retrieve product evidence and the minimum account fields.

Prepare. Assemble a case draft, citations, and unresolved questions.

Review. Let a person confirm scope, data, and any external action before execution.

This separation is an operating practice, not a claim that every ZGI deployment provides a built-in approval gate. Build the workflow from the steps available in your deployment, and verify what each step actually does.

Test the boundaries deliberately

Before using real support data, run sanitized cases with known outcomes:

• Remove the troubleshooting document from the bound knowledge set. The agent should say the evidence is unavailable, not invent a fix.
• Remove support_tier from the readable table. The agent should mark eligibility as unchecked.
• Change the workflow version from 3 to 2. The draft should expose which contract was used.
• Add “send the case now” to a request that still says “for review.” The agent should flag the conflict rather than silently sending.

These tests do not prove universal reliability. They show whether your chosen bindings and instructions preserve the distinctions your team cares about.

The runtime contract is the product decision

ZGI’s runtime composition is useful when it turns hidden assumptions into inspectable configuration: which model runs, which knowledge is available, which database fields are readable, which workflow is bound, and which memory is enabled. The public code and documentation describe these as parts of the agent execution context; they do not establish that every capability is available in every edition or deployment.

Start with one support request and one read-only path. Review the resulting case draft against the source documents and account record. Only then decide whether a workflow should be allowed to perform a real side effect.

Website: https://zgi.ai

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