Red Hat quickstart puts five software agents behind one Llama Stack gateway

Red Hat has published a deployable OpenShift AI quickstart for an agentic software factory: five specialized agents that turn written requirements into GitHub issues, implement changes, review pull requests, investigate failed Tekton runs and triage application logs. The more useful part of the pattern is not the number of agents. It is the decision to put their model and tool access behind one Llama Stack gateway.

What the pattern deploys

A spec-collector interface writes requirement files to a shared persistent volume. A Scribe agent reads those files and creates GitHub issues; a Developer agent turns selected issues into pull requests; and a Review agent compares each pull request with its originating issue before approving and merging it. Two operations-focused agents extend the loop: Fixer examines failed Tekton PipelineRun objects and proposes repairs, while Rummager inspects application logs and files issues when it identifies likely defects.

The quickstart is workload-agnostic, with a separate sample application offered only as an optional demonstration. Red Hat says the pattern was tested with OpenShift 4.16 or later, OpenShift AI 3.4, the managed Llama Stack Operator, a reachable vLLM-compatible endpoint and Tekton Pipelines. Once those platform prerequisites exist, a namespace user can deploy the factory without cluster-admin access, provided that account can create the required workloads, routes, secrets, storage and Tekton resources.

One gateway, several boundaries

All five agents use the same Llama Stack deployment for inference and MCP tool invocation. GitHub and Kubernetes/OpenShift access are configured at that gateway, including the Tekton-status and pod-log queries used by Fixer and Rummager. Individual agents therefore do not each carry a GitHub client, Kubernetes client and separate set of connector credentials.

There is one explicit exception: Scribe directly reads the shared volume populated by the spec collector. That exception matters because it makes the trust boundary visible instead of pretending every component is isolated in the same way.

The quickstart also places a warning in the input interface telling users that submitted requirements feed downstream AI agents and that generated issues and code should be reviewed. That is a necessary control, not decoration: the documented Review agent can merge a pull request when it concludes that the implementation matches the issue.

What teams should test first

The supplied validation flow checks the chain one step at a time: submit a small requirement, confirm issue creation, watch the Developer agent open a pull request, verify Review’s decision, intentionally trigger a Tekton failure for Fixer, and insert error lines for Rummager to investigate. Teams evaluating the pattern should preserve that staged approach rather than granting broad repository and cluster authority at the start.

Red Hat labels the quickstart as expert-authored but not tested on every supported configuration. Its optional agent egress NetworkPolicy definitions also require manual application. That leaves production hardening—credential scope, merge protection, network isolation and approval policy—to the adopter. The quickstart is best read as a concrete architecture and test harness for agent-assisted delivery, not as a finished autonomous-development product.