Bound the Agent Mesh code-understanding workflow before trusting its migration plan

The Red Hat AI Americas agent-mesh-code-understanding field build demonstrates the first half of a larger software-modernization pattern: generate metadata from brownfield repositories, index it with GraphRAG, and query the result for refactoring artifacts and a migration plan. Version 0.1 is best evaluated as a reference workflow, not as an authoritative code-analysis system.

The pipeline’s assumptions

The documented environment starts at OpenShift 4.18 and OpenShift AI 2.22, with MLflow, Model Registry, Model Catalog and OpenShift AI Pipelines also required. Its tested hardware list calls for one NVIDIA H200, one H100 and one L40S GPU, plus at least eight vCPUs and 24 GiB of RAM.

The workflow expects three OpenAI-compatible model roles: a GraphRAG chat model, an embedding model and a coding-agent model. The README offers candidate models and sample vLLM commands, including long context windows and model-specific tool-call, reasoning and chat-template settings. Those examples are configuration starting points, not evidence that another model endpoint is interchangeable.

Repository access is supplied through GIT_REPO and GIT_BRANCH, or through a JSON list for multi-repository runs. External scanners and static analyzers can add JSON files under .code_metadata, but those files must conform to the project’s metadata schema.

What happens to the code

Data generation creates a text copy and metadata file for each relevant source file. Data indexing feeds that enriched fileset into GraphRAG to produce a graph representation. Data analysis then uses the GraphRAG SDK for canned and ad hoc queries, including questions about migration order, risky components and data stores.

That sequence creates three validation boundaries. First, file selection and text conversion must preserve the code and configuration that matter. Second, metadata from outside tools must merge without losing provenance or overriding contradictory findings. Third, answers from the graph must trace back to source files and commits rather than stand on fluent summaries alone.

A bounded evaluation

Start with one repository whose maintainers can score the output. Pin a commit and record exactly which paths were included, excluded or transformed. Seed a small set of known architecture facts, dependencies and risks, then measure whether generation captures them and whether retrieval cites the correct files.

Run the same query more than once and compare both answers and supporting evidence. Test stale branches, generated code, vendored dependencies, monorepo boundaries and intentionally conflicting scanner metadata. Reject migration recommendations that cannot be linked to versioned source evidence.

Finally, treat repository credentials and indexed code as sensitive inputs. Limit the service accounts that can clone source, inspect generated datasets and call model endpoints; define retention for text copies, metadata and graph indexes. The field build can accelerate discovery, but approval for a migration plan should remain with maintainers who can verify its evidence against the code.