VSearch

What Problem Does It Solve?

At a large organization, taking over a piece of work often takes longer than doing it. The analysis document sits in a file attached to the work item, the decision history is in the wiki, the actual behavior is in the code, the existing tests are somewhere else, and the trail of the bug is in the logs. When a new request, a support ticket or a bug comes in, the first day goes to collecting all of this.

VSearch is a chatflow I built to take that load off the teams in the Accounting, Human Resources, Performance and Enterprise Resource Planning Department. The user describes the work; VSearch scans the sources and explains it as either a summary or a detailed report.

What Does It Do?

1. Work analysis

It lets users get up to speed in minutes on work they've never seen before. A request, a support ticket, a bug or a data update that needs to be made: they all go through the same flow. Behind it are enterprise LLMs and MCP tools I built myself:

The result is a report specific to the work: what's being asked, which screens and services are affected, what the code does today and what shows up in the logs.

2. Test generation

For completed work, it generates a test guide and scenarios from scratch and creates them as a test plan, test suites, test cases and test steps under UI, Functionality, API and Regression. It draws on the same sources as above: code, analysis, the wiki, existing tests if any, and logs.

The scenarios come out clear and concrete enough to be automated. The QA side spends its time turning ready-made scenarios into automation instead of designing them.

3. Workflow simulation

It can simulate workflows that have started, are in progress or have finished: why the workflow is with this person, why it's at this unit or branch; what happens if it's approved or rejected, what the next step is and who it will be assigned to. Figuring out where a workflow is stuck no longer means tracing the process by hand.

How Does It Work?

MCP is the backbone of the flow. Tools provided out of the box by the enterprise infrastructure work alongside the ones I wrote; the LLM decides for itself which tool to call and when. The tools bring back only the data that's needed, with a narrowed context.

The tools I wrote cover the documentation side: finding the analysis document linked to a work item, reading the attachment, trimming it to the useful part and stripping unnecessary characters, searching the wiki and fetching the relevant page. The document enters the context as pure data, RAG-style. On the code, test and log side, the infrastructure's built-in tools do the work; for example, finding the work item with a query, reading its analysis with my own tool, and pulling the code and logs with the built-in tools.

User question
  └─ Chatflow (enterprise LLM)
       ├─ Work item + analysis document   (my tools)
       ├─ Wiki search and reading         (my tools)
       ├─ Repo and code                   (backward analysis from code)
       ├─ Test plan / suite / case / step (existing tests)
       └─ Application logs                (masked)
            └─ Summary or detailed report · Test scenarios · Workflow simulation

Results

VSearch's real payoff isn't speed. Institutional knowledge stops depending on the people who happen to hold it; someone seeing a piece of work for the first time can get the same report from the same sources. And the test generation side takes the step QA spends the most time on, scenario design, off the team's plate.