Roman's ZCode research agent: from community noise to product evidence
Roman, a community moderator at Z.ai, describes the ZCode plugin he planned, engineered and developed, with traceable evidence and a human-written final answer.
Editorial introduction
This article is about Roman, a community moderator at Z.ai, and his ZCode Discord Research Agent project. The first-person essay below is Roman's account of his planning, engineering and development work. It is a personal project account, not an official Z.ai announcement or a claim of company commission, adoption or endorsement.
Roman's first-person essay
The problem I chose to solve
Communities like Z.ai's Discord are where users say what they critically need, long before it becomes a trend everyone else sees. Spotting the tendencies of certain events while they are still forming, in the middle of that volume, is hard. I decided to build a technological solution around that problem.
The raw material was already there, and that was exactly the problem. A support community can be full of information and still be difficult to learn from. One person describes a broken workflow in a bug thread. Another reports the same failure under a different title. Someone posts the only useful diagnostic detail inside a screenshot. A long conversation mixes direct complaints, short agreements and questions about whether a fix has arrived. Reading more messages does not automatically produce a better product decision.
I planned, engineered and developed the ZCode Discord Research Agent to close that gap: the distance between what a community is saying and what a product team can responsibly act on. I wanted a repeatable way to investigate feedback, preserve the evidence behind it and produce a report that a support manager could inspect. The product's purpose is to make community research defensible, rather than merely faster.
A research workflow, not another chatbot
I built the project as a native plugin for the ZCode harness, with a local Python toolchain at its core. Its workflow moves from scope and collection to analysis, reporting and, where appropriate, a reviewed response. The collector gathers thread messages and attachment metadata; the agent then applies the research method. The report builder turns the resulting structured analysis into working documents.
That separation matters. Collection should preserve what was said. Analysis should explain what it means. Reporting should make both the conclusion and its limits visible. I did not treat a plausible paragraph as a substitute for this chain of evidence.
The design also keeps judgment explicit. Semantic grouping, screenshot inspection and the distinction between a real complaint and a passing remark belong to the agent-guided workflow. They are not hidden behind a claim that a small Python script can understand every conversation automatically.
Engineering for the way Discord actually works
A useful research tool has to respect the structure of its source. Discord forums contain threads, and those threads contain the conversations that matter. The project includes category and channel discovery, recent and archived thread discovery, message pagination, attachment downloads and a local collection manifest. The API layer includes retry handling for rate limits and network errors.
The collector is deliberately bounded. It uses configured forum and thread limits, and its message walker has a default cap of 800 messages per thread. Existing cached thread files are skipped rather than continuously refreshed. These choices reduce repeated work, but they also define what a report can claim. A collected sample is not proof that every conversation has been read, and a cached thread is not automatically current.
The toolchain runs locally, inside the operator's own environment, rather than through a separate hosted credential service. Local operation is an architectural choice, not a blanket guarantee of privacy, security or platform approval.
Spotting tendencies without manufacturing certainty
This is where the system earns the word 'tendencies'. Ten messages do not necessarily mean ten affected users. One author may cross-post the same complaint, several replies may only ask for an update, and a short 'same' may carry less information than a clear description of a failure.
The workflow therefore separates strict complaints from borderline responses, excludes status questions from complaint counts and counts repeated copies of the same text by one author only once. It groups related reports into issue families while retaining the underlying thread references. It also asks the researcher to inspect downloaded screenshots when useful diagnostic identifiers are absent from message text.
This makes the numbers easier to challenge, which is exactly the point. A tendency you can defend is worth acting on; a tendency you cannot explain is just a rumor with a chart. A manager should be able to ask why an author was counted, which thread supports a conclusion or what evidence remains incomplete. I wanted the report to survive those questions rather than discourage them.
Reports a manager can interrogate
The reporting layer creates a multi-sheet Excel workbook and print-ready HTML, with native PDF generation when the optional ReportLab library is available. The workbook separates the summary, threads by issue family, detailed evidence, reply audit and attachment checks.
This gives different readers a way into the same investigation: a manager can start with priorities, while someone investigating a specific failure can go back to the evidence. The report is the product's memory. If a conclusion is challenged next month, the chain back to the original threads is still there.
A brain that assists support, with a human writing the final answer
Here is the part I find most interesting. The brain of the plugin, the same research workflow that investigates what users are experiencing, can also assist with the support work itself.
Given a question, it can run a deep research pass: gather the thread evidence, retrieve the relevant documentation through a local knowledge base, and offer possible solutions with their sources attached. A support specialist facing an unfamiliar bug gets a researched starting point instead of a blank page.
The handoff is intentional. A person still writes the final answer. The agent proposes; a human decides what the community actually hears. The reply workflow requires official documentation or approved moderator precedent, exact source URLs and an honest escalation when those sources do not answer the question, and it rules out invented promises about fixes, dates or compensation. Sending remains a separate step that a person approves first. I did not want a system that quietly takes over someone's judgment or voice, so I built one that hands over the evidence and steps back.
Making the tool usable beyond its developer
I also treated installation as part of the product. The repository includes its own plugin marketplace definition, so a downloaded ZIP can serve as the installation source. The documented path lets a support manager ask ZCode to install the local plugin rather than assemble a Python environment by hand.
The core scripts use Python's standard library; direct PDF generation is the optional dependency. The code includes paths for macOS, Windows and Linux; live validation is currently recorded only for macOS, including real thread collection, attachment downloads, report generation and a knowledge-base round trip. Windows and Linux support is implemented, but the verification notes still call for live checks on those systems.
What I built, and what comes next
This is an early implementation with concrete working parts and clear unfinished work. The repository's validation record is evidence of specific checks, not proof of production scale, adoption or measured time savings. Collection coverage, cache freshness, cross-platform behavior and the platform rules that govern automated community research all deserve further work before broader deployment. I would rather state those boundaries than hide them behind the word 'agent'.
The product reflects the kind of engineering I want to do: start with a real operational problem, choose a workflow that fits it, build the tools it needs and keep the claims no larger than the evidence. What began as a wish to understand users better became a system for turning community feedback into product priorities that people can inspect and use.
The goal is simple: when a team decides what needs attention, it should be able to show why.
Publication note
Project capabilities and recorded checks are described by Roman; they are not independently rerun product tests. The public ZCode documentation confirms the plugin and local-marketplace mechanism, not this project's results or platform-policy compliance.