A practical ZGI workflow for teams that keep answering the same customer questions.
It is 9:15 a.m. A customer asks whether a particular product supports the setup their team uses.
The answer probably exists. Part of it is in a product guide. Another detail is in an implementation note. A colleague remembers a limitation discussed last month, but nobody can find the message.
Before anyone can write a useful reply, they have to reconstruct the context.
This is a practical place to start with ZGI: not an assistant that handles every customer conversation, but one that helps a team prepare a better answer from material it already owns.
The scenario below is an illustrative setup, not a customer case study or a measured deployment. Start with an internal assistant; keep the final customer reply with a person.
Start with one question the team actually receives
Choose a narrow job: help colleagues answer product-compatibility questions using approved documentation.
That scope gives the assistant a clear purpose. It should find relevant information, explain what the documents support, and identify what still needs confirmation. It should not invent a compatibility promise because the customer sounds impatient.
For the first version, leave out live customer records and outbound messaging. A colleague can paste in a question, inspect the draft, and send the final response through the team's existing process.
This makes the first build useful without requiring every system to be connected at once.
1. Give the assistant a dependable knowledge source
In ZGI's Knowledge Base area, create a focused collection for the product. Organize the approved guides, implementation notes, and frequently asked questions there.
Do not begin by uploading every document the company has. If an old guide contradicts a newer one, the assistant inherits that ambiguity. Choose the current material and make its ownership clear before asking a model to use it.
The product reference describes knowledge bases as file collections that agents and workflows can retrieve from. It also includes retrieval testing. Use that test with the customer's actual wording and inspect the material returned.
The question is simple: does the search find the passage a knowledgeable colleague would use?
If it does not, investigate the source material and its organization before rewriting the assistant's prompt. An eloquent answer cannot compensate for missing evidence.
2. Build an agent with a specific responsibility
Open the Agent Editor and configure the assistant's model, system instructions, and knowledge source. The editor brings those settings together with a preview conversation, so you can test the assistant while configuring it.
Call this example agent “Product Answer Assistant.” Give it a small, explicit job description:
Prepare an internal draft response to a product question. Use the connected approved documentation. Separate supported facts from missing information. Identify the source passages used. If the material does not establish an answer, ask for clarification or flag the question for a colleague. Do not make unsupported commitments.
This is a suggested instruction, not a built-in ZGI template. Asking for sources or restraint does not guarantee compliance; those behaviors need testing.
In the preview conversation, try a question the documents answer clearly. Then try one that omits a product version. Finally, ask about a capability the sources do not describe.
The third test is particularly useful. A trustworthy internal assistant should expose the gap, not hide it inside a confident paragraph.
Conceptual workflow. Human review is a team operating step here, not a claim that this example includes a configured approval integration.
3. Make the output easy for a colleague to check
A long answer is not necessarily a useful handoff. Ask for a short, repeatable structure:
| Output | What the reviewer needs |
|---|---|
| Draft reply | A concise response they can revise |
| Supporting material | The passages behind the answer |
| Missing information | Product version, configuration, or other facts still needed |
| Review note | Any statement that requires confirmation before sending |
For example, if the customer has not named their product version, the useful output may be a clarification question rather than a compatibility claim.
The feature being demonstrated is not just text generation. It is the combination of configured instructions, relevant knowledge, and a testable interaction in one agent.
4. Use a workflow when the sequence needs to be repeatable
An agent is a useful starting point for an interactive question. A workflow becomes relevant when the team wants the same processing stages each time.
ZGI's Workflow Editor provides a node canvas, node configuration, variables, a run panel, debugging, and version history. For this scenario, design a sequence that accepts the question, retrieves the relevant material, and prepares the structured draft. Use the node types available in your deployment rather than assuming a ready-made support template exists.
Run representative inputs through it and inspect each stage. Was the question passed through correctly? Did retrieval return useful material? Did the drafting step preserve uncertainty?
Keep delivery outside this first workflow. A person reviews the result and sends it manually. Connecting an external system later is a separate implementation step, not something a prompt alone enables.
Where models and Skills fit
The model supplies language understanding and drafting. ZGI's model-provider management is where available providers and models are configured; the agent uses a model made available to it.
Compare candidate models on the same questions. Look at factual support, handling of missing information, and usefulness of the draft—not only how polished the wording sounds. This article does not claim that one model is the best or cheapest choice.
Skills serve a different purpose. ZGI's product reference describes them as standard capabilities an AI can invoke, with system and custom Skills managed separately. Add a Skill when the job genuinely requires that capability and its configuration is ready. This first knowledge-and-drafting assistant does not need a collection of unrelated Skills to be useful.
The distinction matters: documents provide evidence, instructions define the task, models generate and interpret language, Skills supply callable capabilities, and workflows organize repeatable processing.
What should improve—and what still needs a person
The intended improvement is less time spent reconstructing the same product context. Instead of starting from scattered documents, a colleague starts with a draft, supporting material, and explicit gaps.
That is a goal to evaluate, not a promised time saving. Before expanding the pilot, check whether reviewers can find the cited evidence, whether unsupported questions are handled appropriately, and whether the draft actually reduces rework.
Keep source documents current. Test permissions in the environment you use. Remember that self-hosting alone does not determine where every model request is processed; deployment and provider choices still matter.
This example also does not assume an autonomous worker receiving and replying to messages across channels. ZGI's website labels its digital-worker and planned messaging connections as in development. The workflow here starts with a person submitting a question and ends with a person reviewing the answer. See ZGI's current product overview.
Build the smallest useful version
You do not need to demonstrate every ZGI feature in your first project.
Start with one product, one approved knowledge collection, one internal agent, and a handful of realistic questions. Introduce a workflow when the sequence needs to be consistent. Add further capabilities only when the task calls for them.
That is how ZGI's features become a working solution: each one has a clear role in helping someone finish a specific job.
Explore ZGI and inspect the project on GitHub. Bring one recurring product question and use it as your first test.
Top comments (0)