From Prototype to App: Deploying the Agent as a Service

Persona: Platform Engineer (primary). Also relevant: AI Engineer.
In this lab

You will turn the agent you prototyped in the previous module into a running service on OpenShift. We will deploy the ai-agent tenant, build and expose the FastAPI app, and wire the Tekton pipeline trigger so failures send context to the agent which then creates a GitHub issue.

Estimated time: 60–90 minutes

Objectives

  • Deploy the ai-agent tenant resources

  • Point build configs to your GitHub fork

  • Build and roll out the agent service (FastAPI)

  • Verify connectivity to Llama Stack from the app

  • Wire the pipeline trigger so failures call the agent

  • Validate end-to-end by creating a GitHub issue from a failure

Prerequisites

  • Completed Module 05 with a working agent flow in the notebook

  • Your repo fork is up to date and the cluster GitOps points to it

  • Llama Stack server reachable inside the cluster (module 04 deployment)

Deploy the ai-agent Tenant

  • Confirm the project exists and resources are present:

    oc get ns ai-agent
oc -n ai-agent get deploy,svc,route,cm,sa,rolebinding,secret

  • If resources are missing, ensure your GitOps/App-of-Apps includes the tenant. Then sync in Argo CD.

Point to Your GitHub Fork and Correct the Webhook Path

By default the tenant and Helm chart reference redhat-ai-services/etx-agentic-ai and post to /webhook, while the FastAPI app exposes /report-failure.

  • Set your GitHub username:

    export YOUR_GITHUB_USER=your-gh-user
export YOUR_FORK=https://github.com/${YOUR_GITHUB_USER}/etx-agentic-ai.git

  • Update the tenant Tekton Pipeline to use your fork and the correct endpoint:

    sed -i "s#https://github.com/redhat-ai-services/etx-agentic-ai.git#${YOUR_FORK}#g" \
  infra/tenants/ai-agent/base/sno/templates/pipeline.yaml

# Use the app's actual endpoint
sed -i "s#/webhook#/report-failure#g" \
  infra/tenants/ai-agent/base/sno/templates/pipeline.yaml

  • Update the Job that triggers a PipelineRun so it also uses your fork:

    sed -i "s#https://github.com/redhat-ai-services/etx-agentic-ai.git#${YOUR_FORK}#g" \
  infra/tenants/ai-agent/base/sno/templates/job.yaml

  • (Optional, if using the Helm chart locally) Update the chart defaults:

    sed -i "s#https://github.com/redhat-ai-services/etx-agentic-ai.git#${YOUR_FORK}#g" code/chart/values.yaml
sed -i "s#/webhook#/report-failure#g" code/chart/values.yaml

  • Commit and push changes so GitOps applies them:

    git add .
git commit -m "tenant(ai-agent): use my fork and correct webhook endpoint"
git push

Ensure Secrets and Config

  • Verify agent-config points to your Llama Stack service. Defaults to the in-cluster service:

    infra/tenants/ai-agent/base/sno/templates/configmap.yaml

    data:
  LLAMA_STACK_URL: "http://llamastack-with-config-service.llama-stack.svc.cluster.local:8321"
  MODEL_ID: "llama-4-scout-17b-16e-w4a16"
  TEMPERATURE: "0.0"
  MAX_TOKENS: "5000"

  • If needed for your Llama Stack config, hydrate any missing secrets (GitHub, Tavily) as per module 04/05.

Build and Roll Out the App

  • Trigger the build PipelineRun via the provided Job (creates a new run):

    oc -n ai-agent create -f infra/tenants/ai-agent/base/sno/templates/job.yaml

  • Watch the PipelineRun in the OpenShift Console (Pipelines) until tasks complete.

  • Verify the Deployment rolls out:

    oc -n ai-agent rollout status deploy/ai-agent
oc -n ai-agent get pods

  • Get the route and test health:

    ROUTE=$(oc -n ai-agent get route ai-agent -o jsonpath='{.spec.host}')
curl -s http://${ROUTE}/health | cat

Reset/retry tips:

  • If pip install upgraded dependencies earlier, restart the Jupyter kernel before re-running notebook cells (module 05)

  • Stop previous port-forward (Ctrl+C) before starting a new one

  • If a PipelineRun is stuck, cancel and start a fresh run; ensure Workspace PVC is recreated when using generateName

Pipeline overview

This demo application pipeline models a common CI/CD flow and adds an automated recovery aid:

  • Fetch source: git-clone pulls your repo and revision

  • Build image: buildah builds and pushes the container image

  • Deploy: oc rollout status verifies the deployment

  • Finally: On failure, a finally step triggers the agent service with pod context

Coming from Module 05: You codified the agent and validated the flow in a Workbench. Here we connect that flow to your pipeline so failures automatically notify the agent.

Wire the Pipeline Trigger

The Tekton agent-service-build Pipeline includes a finally step that posts a failure payload to the agent service.

  • Confirm the finally step now points to /report-failure and namespace: ai-agent in:

    infra/tenants/ai-agent/base/sno/templates/pipeline.yaml

  • Ensure the ai-agent service account/rolebinding exist in the ai-agent namespace:

    oc -n ai-agent get sa pipeline
oc -n ai-agent get rolebinding openshift-pipelines-edit

End-to-End Test

To simulate a build failure and test the agent integration, use the pre-configured bad revision.

Option 1: Web Console

  1. In the OpenShift Web Console, navigate to Pipelines in the ai-agent namespace.

  2. Click on the agent-service-build pipeline.

  3. Click Start to create a new PipelineRun.

  4. In the parameters, set the GIT_REVISION value to bad to use the intentionally broken revision.

  5. Start the PipelineRun.

Option 2: Run a pre-created Job

From the console, create a job from YAML using the infra/tenants/demo-pipeline/base/sno/templates/job-bad.yaml as a reference, or run via CLI:

oc -n demo-pipeline create -f infra/tenants/demo-pipeline/base/sno/templates/job-bad.yaml

Feel free to use the web console or CLI to trigger the job.

Option 3: One-off PipelineRun via CLI

Start a one-off PipelineRun with the bad ref:

oc -n demo-pipeline create -f - <<'EOF'
apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
  generateName: agent-service-build-run-bad-
  namespace: demo-pipieline
spec:
  taskRunTemplate:
    serviceAccountName: pipeline
  pipelineRef:
    name: agent-service-build
  params:
    - name: APP_NAME
      value: "ai-agent"
    - name: IMAGE_NAME
      value: "image-registry.openshift-image-registry.svc:5000/ai-agent/ai-agent"
    - name: GIT_REPO
      value: "https://github.com/${YOUR_GITHUB_USER}/etx-agentic-ai.git"
    - name: GIT_REVISION
      value: "bad"
    - name: PATH_CONTEXT
      value: "code"
  workspaces:
    - name: workspace
      volumeClaimTemplate:
        spec:
          accessModes: [ "ReadWriteOnce" ]
          resources:
            requests:
              storage: 3Gi
EOF

  • Intentionally break the build (e.g., temporarily change code/Containerfile to an invalid base) and trigger a build:

    oc -n ai-agent create -f infra/tenants/ai-agent/base/sno/templates/job.yaml

  • When the PipelineRun fails, the finally step calls the agent. The agent reads logs via MCP OpenShift, searches the web, and creates a GitHub issue.

  • Verify:

    • Console → ai-agent → Workloads → Pods show agent logs with tool calls

    • Your GitHub repo shows a new issue with the summary

Artifacts to carry forward

  • Route URL for ai-agent (health verified)

  • Updated tenant pipeline/job YAML pointing to your fork

  • A sample failed PipelineRun name and failing pod name

  • URL of the created GitHub issue

Troubleshooting

  • If the PipelineRun cannot reach the agent route, verify the Route/Service are ready and DNS resolves in-cluster.

  • If the agent times out on Llama Stack, confirm the server is healthy and reachable from the ai-agent namespace.

  • If MCP tools are not registered, revisit module 04 to re-register mcp::openshift and mcp::github in Llama Stack.

  • If no GitHub issue is created, check the agent logs for the tool call to create_issue and ensure the GitHub MCP server is configured.

See Troubleshooting Guide for more.

What’s Next

With the agent running as a service and integrated with the pipeline trigger, you have the foundation for a production rollout. You are now setup for a scenario where you have a new ticket coming in and you need to update your agent and your MTTR is fast due to the automation. Perhaps you are event adventurous enough to add the agent tooling itself as a finally call in your agent build pipeline to catch and resolve errors quickly. We will not be doing that today, so that will be left to the reader, but in the next module, we will discuss hardening, observability, and promotion flows. == Next Steps

With your agent now running as a service and integrated with the pipeline trigger, you have established the foundation for a production-ready workflow. This setup enables rapid response to failures, as new issues are automatically created in your GitHub repository, reducing mean time to resolution (MTTR).

In the next module, you will learn how to further harden your deployment, add observability, and implement promotion flows to ensure your agent remains robust and reliable as you move toward production.

Onward to Module 07!