fix(container): update image ghcr.io/kagent-dev/kagent/helm/kagent ( 0.7.12 ➔ 0.7.23 )

[mortyops]

This PR contains the following updates:

Package	Update	Change
ghcr.io/kagent-dev/kagent/helm/kagent	patch	0.7.12 → 0.7.23

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Renovate Bot.

[mortyops]

--- kubernetes/apps/ai-system/kagent/app Kustomization: ai-system/kagent OCIRepository: ai-system/kagent

+++ kubernetes/apps/ai-system/kagent/app Kustomization: ai-system/kagent OCIRepository: ai-system/kagent

@@ -11,9 +11,9 @@

 spec:
   interval: 5m
   layerSelector:
     mediaType: application/vnd.cncf.helm.chart.content.v1.tar+gzip
     operation: copy
   ref:
-    tag: 0.7.12
+    tag: 0.7.23
   url: oci://ghcr.io/kagent-dev/kagent/helm/kagent
 

[mortyops]

--- HelmRelease: ai-system/kagent ServiceAccount: ai-system/kagent-tools

+++ HelmRelease: ai-system/kagent ServiceAccount: ai-system/kagent-tools

@@ -5,8 +5,7 @@

   name: kagent-tools
   namespace: ai-system
   labels:
     app.kubernetes.io/name: kagent-tools
     app.kubernetes.io/instance: kagent
     app.kubernetes.io/managed-by: Helm
-    app.kubernetes.io/part-of: kagent
 
--- HelmRelease: ai-system/kagent ConfigMap: ai-system/kagent-querydoc

+++ HelmRelease: ai-system/kagent ConfigMap: ai-system/kagent-querydoc

@@ -11,10 +11,7 @@

 data:
   KAGENT_NAMESPACE: ai-system
   KAGENT_LOG_LEVEL: info
   PORT: '8080'
   TRANSPORT_TYPE: http
   OTEL_TRACING_ENABLED: 'false'
-  OTEL_EXPORTER_OTLP_ENDPOINT: ''
-  OTEL_EXPORTER_OTLP_TRACES_TIMEOUT: '10000'
-  OTEL_EXPORTER_OTLP_TRACES_INSECURE: 'true'
 
--- HelmRelease: ai-system/kagent ConfigMap: ai-system/kagent-controller

+++ HelmRelease: ai-system/kagent ConfigMap: ai-system/kagent-controller

@@ -15,24 +15,22 @@

   DATABASE_TYPE: sqlite
   DEFAULT_MODEL_CONFIG_NAME: default-model-config
   KAGENT_CONTROLLER_NAME: kagent-controller
   IMAGE_PULL_POLICY: IfNotPresent
   IMAGE_REGISTRY: cr.kagent.dev
   IMAGE_REPOSITORY: kagent-dev/kagent/app
-  IMAGE_TAG: 0.7.12
+  IMAGE_TAG: 0.7.23
+  SKILLS_INIT_IMAGE_PULL_POLICY: IfNotPresent
+  SKILLS_INIT_IMAGE_REGISTRY: cr.kagent.dev
+  SKILLS_INIT_IMAGE_REPOSITORY: kagent-dev/kagent/skills-init
+  SKILLS_INIT_IMAGE_TAG: 0.7.23
   LEADER_ELECT: 'false'
-  OTEL_EXPORTER_OTLP_ENDPOINT: http://host.docker.internal:4317
-  OTEL_EXPORTER_OTLP_LOGS_ENDPOINT: http://host.docker.internal:4317
-  OTEL_EXPORTER_OTLP_LOGS_INSECURE: 'true'
-  OTEL_EXPORTER_OTLP_LOGS_TIMEOUT: '15'
-  OTEL_EXPORTER_OTLP_TRACES_INSECURE: 'true'
-  OTEL_EXPORTER_OTLP_TRACES_TIMEOUT: '15'
+  OTEL_TRACING_ENABLED: 'false'
   OTEL_LOGGING_ENABLED: 'false'
-  OTEL_TRACING_ENABLED: 'false'
-  OTEL_TRACING_EXPORTER_OTLP_ENDPOINT: http://host.docker.internal:4317
   SQLITE_DATABASE_PATH: /sqlite-volume/kagent.db
+  DATABASE_VECTOR_ENABLED: 'true'
   STREAMING_INITIAL_BUF_SIZE: 4Ki
   STREAMING_MAX_BUF_SIZE: 1Mi
   STREAMING_TIMEOUT: 600s
   WATCH_NAMESPACES: ''
   ZAP_LOG_LEVEL: info
 
--- HelmRelease: ai-system/kagent ClusterRole: ai-system/kagent-tools-cluster-admin-role

+++ HelmRelease: ai-system/kagent ClusterRole: ai-system/kagent-tools-cluster-admin-role

@@ -4,13 +4,12 @@

 metadata:
   name: kagent-tools-cluster-admin-role
   labels:
     app.kubernetes.io/name: kagent-tools
     app.kubernetes.io/instance: kagent
     app.kubernetes.io/managed-by: Helm
-    app.kubernetes.io/part-of: kagent
 rules:
 - apiGroups:
   - '*'
   resources:
   - '*'
   verbs:
--- HelmRelease: ai-system/kagent ClusterRole: ai-system/kagent-tools-read-role

+++ HelmRelease: ai-system/kagent ClusterRole: ai-system/kagent-tools-read-role

@@ -1,24 +0,0 @@

----
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
-  name: kagent-tools-read-role
-  labels:
-    app.kubernetes.io/name: kagent-tools
-    app.kubernetes.io/instance: kagent
-    app.kubernetes.io/managed-by: Helm
-    app.kubernetes.io/part-of: kagent
-rules:
-- apiGroups:
-  - '*'
-  resources:
-  - '*'
-  verbs:
-  - '*'
-- nonResourceURLs:
-  - '*'
-  verbs:
-  - get
-  - list
-  - watch
-
--- HelmRelease: ai-system/kagent ClusterRole: ai-system/kagent-getter-role

+++ HelmRelease: ai-system/kagent ClusterRole: ai-system/kagent-getter-role

@@ -11,12 +11,13 @@

 rules:
 - apiGroups:
   - kagent.dev
   resources:
   - agents
   - modelconfigs
+  - modelproviderconfigs
   - toolservers
   - memories
   - remotemcpservers
   - mcpservers
   verbs:
   - get
@@ -24,23 +25,25 @@

   - watch
 - apiGroups:
   - kagent.dev
   resources:
   - agents/finalizers
   - modelconfigs/finalizers
+  - modelproviderconfigs/finalizers
   - toolservers/finalizers
   - memories/finalizers
   - remotemcpservers/finalizers
   - mcpservers/finalizers
   verbs:
   - update
 - apiGroups:
   - kagent.dev
   resources:
   - agents/status
   - modelconfigs/status
+  - modelproviderconfigs/status
   - toolservers/status
   - memories/status
   - remotemcpservers/status
   - mcpservers/status
   verbs:
   - get
--- HelmRelease: ai-system/kagent ClusterRole: ai-system/kagent-writer-role

+++ HelmRelease: ai-system/kagent ClusterRole: ai-system/kagent-writer-role

@@ -11,12 +11,13 @@

 rules:
 - apiGroups:
   - kagent.dev
   resources:
   - agents
   - modelconfigs
+  - modelproviderconfigs
   - toolservers
   - memories
   - remotemcpservers
   - mcpservers
   verbs:
   - create
@@ -25,12 +26,13 @@

   - delete
 - apiGroups:
   - kagent.dev
   resources:
   - agents/finalizers
   - modelconfigs/finalizers
+  - modelproviderconfigs/finalizers
   - toolservers/finalizers
   - memories/finalizers
   - remotemcpservers/finalizers
   - mcpservers/finalizers
   verbs:
   - update
--- HelmRelease: ai-system/kagent ClusterRoleBinding: ai-system/kagent-tools-cluster-admin-rolebinding

+++ HelmRelease: ai-system/kagent ClusterRoleBinding: ai-system/kagent-tools-cluster-admin-rolebinding

@@ -4,13 +4,12 @@

 metadata:
   name: kagent-tools-cluster-admin-rolebinding
   labels:
     app.kubernetes.io/name: kagent-tools
     app.kubernetes.io/instance: kagent
     app.kubernetes.io/managed-by: Helm
-    app.kubernetes.io/part-of: kagent
 roleRef:
   apiGroup: rbac.authorization.k8s.io
   kind: ClusterRole
   name: kagent-tools-cluster-admin-role
 subjects:
 - kind: ServiceAccount
--- HelmRelease: ai-system/kagent ClusterRoleBinding: ai-system/kagent-tools-getter-rolebinding

+++ HelmRelease: ai-system/kagent ClusterRoleBinding: ai-system/kagent-tools-getter-rolebinding

@@ -1,19 +0,0 @@

----
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRoleBinding
-metadata:
-  name: kagent-tools-getter-rolebinding
-  labels:
-    app.kubernetes.io/name: kagent-tools
-    app.kubernetes.io/instance: kagent
-    app.kubernetes.io/managed-by: Helm
-    app.kubernetes.io/part-of: kagent
-roleRef:
-  apiGroup: rbac.authorization.k8s.io
-  kind: ClusterRole
-  name: kagent-tools-getter-role
-subjects:
-- kind: ServiceAccount
-  name: kagent-tools
-  namespace: ai-system
-
--- HelmRelease: ai-system/kagent ClusterRoleBinding: ai-system/kagent-tools-writer-rolebinding

+++ HelmRelease: ai-system/kagent ClusterRoleBinding: ai-system/kagent-tools-writer-rolebinding

@@ -1,19 +0,0 @@

----
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRoleBinding
-metadata:
-  name: kagent-tools-writer-rolebinding
-  labels:
-    app.kubernetes.io/name: kagent-tools
-    app.kubernetes.io/instance: kagent
-    app.kubernetes.io/managed-by: Helm
-    app.kubernetes.io/part-of: kagent
-roleRef:
-  apiGroup: rbac.authorization.k8s.io
-  kind: ClusterRole
-  name: kagent-tools-writer-role
-subjects:
-- kind: ServiceAccount
-  name: kagent-tools
-  namespace: ai-system
-
--- HelmRelease: ai-system/kagent Service: ai-system/kagent-tools

+++ HelmRelease: ai-system/kagent Service: ai-system/kagent-tools

@@ -5,13 +5,12 @@

   name: kagent-tools
   namespace: ai-system
   labels:
     app.kubernetes.io/name: kagent-tools
     app.kubernetes.io/instance: kagent
     app.kubernetes.io/managed-by: Helm
-    app.kubernetes.io/part-of: kagent
 spec:
   type: ClusterIP
   ports:
   - port: 8084
     targetPort: 8084
     protocol: TCP
--- HelmRelease: ai-system/kagent Deployment: ai-system/kagent-grafana-mcp

+++ HelmRelease: ai-system/kagent Deployment: ai-system/kagent-grafana-mcp

@@ -14,14 +14,14 @@

     matchLabels:
       app.kubernetes.io/name: grafana-mcp
       app.kubernetes.io/instance: kagent
   template:
     metadata:
       annotations:
-        checksum/configmap: 0ca7a199cba748e0aaac499e94eedcfbce558aa3f70a8ebd061b745dd707b400
-        checksum/secret: 83b98b1af7d5fb05fab8f139a462b60b82271052380f4384c9cfc082b8eb8f9d
+        checksum/configmap: 0fb88f7248f35c018856436927addf4a26443802608577480eab7f927d094dce
+        checksum/secret: 2125555b4fd6995bf2425f9985412c6aeb055ff1c2ba34d58a42f026250d1fdf
       labels:
         app.kubernetes.io/name: grafana-mcp
         app.kubernetes.io/instance: kagent
     spec:
       serviceAccountName: kagent-grafana-mcp
       containers:
--- HelmRelease: ai-system/kagent Deployment: ai-system/kagent-tools

+++ HelmRelease: ai-system/kagent Deployment: ai-system/kagent-tools

@@ -5,13 +5,12 @@

   name: kagent-tools
   namespace: ai-system
   labels:
     app.kubernetes.io/name: kagent-tools
     app.kubernetes.io/instance: kagent
     app.kubernetes.io/managed-by: Helm
-    app.kubernetes.io/part-of: kagent
 spec:
   replicas: 1
   selector:
     matchLabels:
       app.kubernetes.io/name: kagent-tools
       app.kubernetes.io/instance: kagent
@@ -28,14 +27,16 @@

       - name: tools
         command:
         - /tool-server
         args:
         - --port
         - '8084'
+        - --metrics-port
+        - '8085'
         securityContext: {}
-        image: ghcr.io/kagent-dev/kagent/tools:0.0.13
+        image: ghcr.io/kagent-dev/kagent/tools:0.1.1
         imagePullPolicy: IfNotPresent
         resources:
           limits:
             cpu: 1000m
             memory: 512Mi
           requests:
@@ -58,15 +59,20 @@

         - name: OTEL_EXPORTER_OTLP_ENDPOINT
           value: http://host.docker.internal:4317
         - name: OTEL_EXPORTER_OTLP_TRACES_TIMEOUT
           value: '15'
         - name: OTEL_EXPORTER_OTLP_TRACES_INSECURE
           value: 'true'
+        - name: TOKEN_PASSTHROUGH
+          value: 'false'
         ports:
         - name: http-tools
           containerPort: 8084
+          protocol: TCP
+        - name: http-metrics
+          containerPort: 8085
           protocol: TCP
         readinessProbe:
           tcpSocket:
             port: http-tools
           initialDelaySeconds: 15
           periodSeconds: 15
--- HelmRelease: ai-system/kagent Deployment: ai-system/kagent-kmcp-controller-manager

+++ HelmRelease: ai-system/kagent Deployment: ai-system/kagent-kmcp-controller-manager

@@ -29,13 +29,13 @@

       securityContext:
         runAsNonRoot: true
         seccompProfile:
           type: RuntimeDefault
       containers:
       - name: manager
-        image: ghcr.io/kagent-dev/kmcp/controller:0.2.2
+        image: ghcr.io/kagent-dev/kmcp/controller:0.2.7
         imagePullPolicy: IfNotPresent
         command:
         - /manager
         args:
         - --leader-elect
         - --health-probe-bind-address=:8081
--- HelmRelease: ai-system/kagent Deployment: ai-system/kagent-querydoc

+++ HelmRelease: ai-system/kagent Deployment: ai-system/kagent-querydoc

@@ -14,13 +14,13 @@

     matchLabels:
       app.kubernetes.io/name: querydoc
       app.kubernetes.io/instance: kagent
   template:
     metadata:
       annotations:
-        checksum/configmap: b65d5eec4704abfff1ed168aaa2a0b66cfd76fa571d45a58101b1283133dc0a6
+        checksum/configmap: 0a63b1f593dd8b68e3e86c1832269f44e1ff97f081fc7e81d160c80fb3f3e7aa
       labels:
         app.kubernetes.io/name: querydoc
         app.kubernetes.io/instance: kagent
     spec:
       serviceAccountName: kagent-querydoc
       containers:
--- HelmRelease: ai-system/kagent Deployment: ai-system/kagent-controller

+++ HelmRelease: ai-system/kagent Deployment: ai-system/kagent-controller

@@ -17,13 +17,13 @@

       app.kubernetes.io/name: kagent
       app.kubernetes.io/instance: kagent
       app.kubernetes.io/component: controller
   template:
     metadata:
       annotations:
-        checksum/configmap: c231475e87744aa5347e04ae6a9f9e7352b0a40f338ebbdeb37929fe548eb3f5
+        checksum/configmap: 3db6ccf347f9b50a5013548344ae378a856b573575ca52f31c473025a4b2f3d8
       labels:
         app.kubernetes.io/name: kagent
         app.kubernetes.io/instance: kagent
         app.kubernetes.io/component: controller
     spec:
       securityContext: {}
@@ -32,13 +32,13 @@

       - name: sqlite-volume
         emptyDir:
           sizeLimit: 500Mi
           medium: Memory
       containers:
       - name: controller
-        image: cr.kagent.dev/kagent-dev/kagent/controller:0.7.12
+        image: cr.kagent.dev/kagent-dev/kagent/controller:0.7.23
         imagePullPolicy: IfNotPresent
         env:
         - name: KAGENT_NAMESPACE
           valueFrom:
             fieldRef:
               fieldPath: metadata.namespace
--- HelmRelease: ai-system/kagent Deployment: ai-system/kagent-ui

+++ HelmRelease: ai-system/kagent Deployment: ai-system/kagent-ui

@@ -26,13 +26,13 @@

     spec:
       securityContext: {}
       serviceAccountName: kagent-ui
       containers:
       - name: ui
         securityContext: {}
-        image: cr.kagent.dev/kagent-dev/kagent/ui:0.7.12
+        image: cr.kagent.dev/kagent-dev/kagent/ui:0.7.23
         imagePullPolicy: IfNotPresent
         env:
         - name: NEXT_PUBLIC_BACKEND_URL
           value: http://kagent-controller.ai-system.svc.cluster.local:8083/api
         ports:
         - name: http
--- HelmRelease: ai-system/kagent Agent: ai-system/argo-rollouts-conversion-agent

+++ HelmRelease: ai-system/kagent Agent: ai-system/argo-rollouts-conversion-agent

@@ -11,15 +11,17 @@

     app.kubernetes.io/part-of: kagent
 spec:
   description: The Argo Rollouts Converter AI Agent specializes in converting Kubernetes
     Deployments to Argo Rollouts.
   type: Declarative
   declarative:
-    systemMessage: |-
+    systemMessage: |
       You are an Argo Rollouts specialist focused on progressive delivery and deployment automation. You
       are only responsible for defining the YAML for the Argo Rollout resource and simple kubectl argo rollouts commands.
+
+      {{include "builtin/safety-guardrails"}}
 
       Your key responsibility is assisting users with migrating their Kubernetes deployments to Argo Rollouts:
       - Convert Kubernetes deployments to Argo Rollout resources
       - Define the Argo Rollout resource YAML
 
       There are ways to migrate to Rollout:
@@ -113,12 +115,17 @@

       ```
 
       Always follow best practices when migrating a Deployment that is already serving live production traffic. A Rollout
       should run next to the Deployment before deleting the Deployment or scaling down the Deployment. Not following this
       approach might result in downtime. It also allows the Rollout to be tested before deleting the original Deployment.
       Always follow this recommended approach unless the user specifies otherwise.
+    promptTemplate:
+      dataSources:
+      - kind: ConfigMap
+        name: kagent-builtin-prompts
+        alias: builtin
     modelConfig: default-model-config
     tools:
     - type: McpServer
       mcpServer:
         name: kagent-tool-server
         kind: RemoteMCPServer
--- HelmRelease: ai-system/kagent Agent: ai-system/cilium-debug-agent

+++ HelmRelease: ai-system/kagent Agent: ai-system/cilium-debug-agent

@@ -12,72 +12,75 @@

 spec:
   description: Cilium debug agent can help with debugging, troubleshooting, and advanced
     diagnostics of Cilium installations in Kubernetes clusters.
   type: Declarative
   declarative:
     modelConfig: default-model-config
-    systemMessage: "You are the Cilium Debug Agent, a specialized assistant for debugging,\
-      \ troubleshooting, \nand advanced diagnostics of Cilium installations in Kubernetes\
-      \ clusters. \nYour primary responsibility is to help users diagnose and resolve\
-      \ issues with their Cilium deployments.\n\n## Operational Protocol\nWhen helping\
-      \ users troubleshoot Cilium issues, follow this structured approach:\n\n1. **Initial\
-      \ Assessment**:\n  - Gather information about the Cilium version, deployment\
-      \ method, and cluster details\n  - Understand the specific symptoms or errors\
-      \ the user is experiencing\n  - Use diagnostic commands to examine the current\
-      \ state of Cilium components\n\n2. **Systematic Diagnosis**:\n  - Use endpoint\
-      \ tools to inspect endpoint health, configuration, and logs\n  - Examine identity\
-      \ information to troubleshoot security and policy issues\n  - Analyze network\
-      \ connectivity using Envoy config, IP addresses, and IP cache\n  - Monitor BPF\
-      \ events and metrics for performance and behavioral anomalies\n  - Leverage\
-      \ PCAP recording for detailed traffic analysis when necessary\n\n3. **Focused\
-      \ Remediation**:\n  - Request comprehensive debugging information for complex\
-      \ issues\n  - Identify root causes through methodical elimination\n  - Recommend\
-      \ targeted fixes based on diagnostic findings\n  - Guide users through repair\
-      \ procedures\n\n## Safety Guidelines\nWhen debugging Cilium, adhere to these\
-      \ safety principles:\n\n1. **Minimize Disruption**:\n  - Prioritize read-only\
-      \ diagnostic tools before suggesting any modifications\n  - Warn about operations\
-      \ that could interrupt network connectivity (like encryption state changes)\n\
-      \  - For critical actions, recommend testing in non-production environments\
-      \ first\n\n2. **Data Protection**:\n  - Be cautious when suggesting commands\
-      \ that might expose sensitive data\n  - Advise users to redact output that might\
-      \ contain secrets or PII\n\n3. **Progressive Approach**:\n  - Start with endpoint\
-      \ and identity inspection tools\n  - Progress to network and monitoring tools\
-      \ for deeper analysis\n  - Use PCAP recording only when necessary for detailed\
-      \ traffic inspection\n  - Consider encryption state tools only when security\
-      \ issues are suspected\n\n4. **Tool Awareness**:\n  - You have access to a focused\
-      \ set of debugging tools covering:\n    - Endpoint management and health\n \
-      \   - Identity information\n    - Network configuration and state\n    - Monitoring\
-      \ and metrics\n    - PCAP recording for traffic analysis\n    - Encryption state\
-      \ management\n  - For more advanced operations, guide users to the appropriate\
-      \ Cilium CLI commands\n\n## Important Considerations\n- Always verify you're\
-      \ executing commands in the correct namespace (typically kube-system)\n- Cilium\
-      \ functionality relies heavily on kernel features; verify compatibility\n- Many\
-      \ issues may require coordinated debugging across multiple system layers (kernel,\
-      \ BPF, Kubernetes)\n\n## Reference and Examples\nCilium Debug Agent - A specialized\
-      \ assistant for debugging, troubleshooting, and advanced diagnostics of Cilium\
-      \ installations in Kubernetes clusters.\n\n### Cilium Debug Commands Reference\n\
-      \n### Endpoint Management and Debugging\n- `cilium-dbg endpoint log <id>` -\
-      \ View endpoint logs\n- `cilium-dbg endpoint health <id>` - Check the health\
-      \ of an endpoint\n- `cilium-dbg endpoint config <id>` - Manage endpoint configuration\n\
-      \n### Identity Management\n- `cilium-dbg identity list` - List identities\n\
-      - `cilium-dbg identity get <id>` - Get identity information\n\n### Network Debugging\n\
-      - `cilium-dbg ip` - List IP addresses\n- `cilium-dbg ip cache` - Show IP cache\
-      \ information\n- `cilium-dbg fqdn cache` - Manage FQDN cache\n- `cilium-dbg\
-      \ envoy config` - List Envoy configuration\n\n### Monitoring and Metrics\n-\
-      \ `cilium-dbg metrics` - List Cilium metrics\n- `cilium-dbg bpf map events`\
-      \ - Display BPF map events\n- `cilium-dbg bpf map list` - Inspect all loaded\
-      \ BPF maps\n- `cilium-dbg monitor` - Live packet tracing (with options like\
-      \ `--type drop`, `--related-to`, `--to`, `-v`)\n\n### Cluster Information\n\
-      - `cilium-dbg node list` - List cluster nodes\n- `cilium-dbg node ids` - List\
-      \ node IDs\n\n### Security and Encryption\n- `cilium-dbg encrypt status` - Show\
-      \ encryption status\n- `cilium-dbg encrypt flush-ipsec` - Flush IPsec state\n\
-      \n### Debugging Tools\n- `cilium-dbg debuginfo` - Request comprehensive debugging\
-      \ information\n\n### PCAP Recording\n- `cilium-dbg bpf recorder list` - List\
-      \ PCAP recorders (as of Cilium 1.18+)\n- `cilium-dbg bpf recorder get <id>`\
-      \ - Get PCAP recorder details\n- `cilium-dbg bpf recorder update <id>` - Update\
-      \ PCAP recorder\n- `cilium-dbg bpf recorder delete <id>` - Delete PCAP recorder\n"
+    systemMessage: |
+      You are the Cilium Debug Agent, a specialized assistant for debugging, troubleshooting,
+      and advanced diagnostics of Cilium installations in Kubernetes clusters.
+      Your primary responsibility is to help users diagnose and resolve issues with their Cilium deployments.
+
+      ## Operational Protocol
+
+      {{include "builtin/kubernetes-context"}}
+
+      {{include "builtin/safety-guardrails"}}
+
+      ## Important Considerations
+      - Always verify you're executing commands in the correct namespace (typically kube-system)
+      - Cilium functionality relies heavily on kernel features; verify compatibility
+      - Many issues may require coordinated debugging across multiple system layers (kernel, BPF, Kubernetes)
+
+      ## Reference and Examples
+      Cilium Debug Agent - A specialized assistant for debugging, troubleshooting, and advanced diagnostics of Cilium installations in Kubernetes clusters.
+
+      ### Cilium Debug Commands Reference
+
+      ### Endpoint Management and Debugging
+      - `cilium-dbg endpoint log <id>` - View endpoint logs
+      - `cilium-dbg endpoint health <id>` - Check the health of an endpoint
+      - `cilium-dbg endpoint config <id>` - Manage endpoint configuration
+
+      ### Identity Management
+      - `cilium-dbg identity list` - List identities
+      - `cilium-dbg identity get <id>` - Get identity information
+
+      ### Network Debugging
+      - `cilium-dbg ip` - List IP addresses
+      - `cilium-dbg ip cache` - Show IP cache information
+      - `cilium-dbg fqdn cache` - Manage FQDN cache
+      - `cilium-dbg envoy config` - List Envoy configuration
+
+      ### Monitoring and Metrics
+      - `cilium-dbg metrics` - List Cilium metrics
+      - `cilium-dbg bpf map events` - Display BPF map events
+      - `cilium-dbg bpf map list` - Inspect all loaded BPF maps
+      - `cilium-dbg monitor` - Live packet tracing (with options like `--type drop`, `--related-to`, `--to`, `-v`)
+
+      ### Cluster Information
+      - `cilium-dbg node list` - List cluster nodes
+      - `cilium-dbg node ids` - List node IDs
+
+      ### Security and Encryption
+      - `cilium-dbg encrypt status` - Show encryption status
+      - `cilium-dbg encrypt flush-ipsec` - Flush IPsec state
+
+      ### Debugging Tools
+      - `cilium-dbg debuginfo` - Request comprehensive debugging information
+
+      ### PCAP Recording
+      - `cilium-dbg bpf recorder list` - List PCAP recorders (as of Cilium 1.18+)
+      - `cilium-dbg bpf recorder get <id>` - Get PCAP recorder details
+      - `cilium-dbg bpf recorder update <id>` - Update PCAP recorder
+      - `cilium-dbg bpf recorder delete <id>` - Delete PCAP recorder
+    promptTemplate:
+      dataSources:
+      - kind: ConfigMap
+        name: kagent-builtin-prompts
+        alias: builtin
     tools:
     - type: McpServer
       mcpServer:
         name: kagent-tool-server
         kind: RemoteMCPServer
         apiGroup: kagent.dev
--- HelmRelease: ai-system/kagent Agent: ai-system/cilium-manager-agent

+++ HelmRelease: ai-system/kagent Agent: ai-system/cilium-manager-agent

@@ -21,38 +21,19 @@

       \ covers \nall aspects of Cilium management except for network policy creation,\
       \ which is handled by the cilium-policy-agent.\n\n## Key Capabilities\n\n1.\
       \ **Installation and Configuration Management**:\n  - Install and uninstall\
       \ Cilium in Kubernetes clusters\n  - Upgrade Cilium to newer versions\n  - Configure\
       \ Cilium with appropriate options for different environments\n  - Manage Cilium\
       \ lifecycle and maintenance\n  - Provide guidance on optimal Cilium configuration\n\
-      \n## Operational Protocol\n\n1. **Initial Assessment**\n  - Gather information\
-      \ about the cluster and Cilium state\n  - Identify the scope and nature of the\
-      \ task or issue\n  - Determine required permissions and access levels\n  - Plan\
-      \ the approach with safety and minimal disruption\n\n2. **Execution Strategy**\n\
-      \  - Use read-only operations first for information gathering\n  - Validate\
-      \ planned changes before execution\n  - Implement changes incrementally when\
-      \ possible\n  - Verify results after each significant change\n  - Document all\
-      \ actions and outcomes\n\n3. **Troubleshooting Methodology**\n  - Systematically\
-      \ narrow down problem sources\n  - Analyze logs, events, and metrics\n  - Check\
-      \ endpoint configurations and connectivity\n  - Verify BPF maps and policy enforcement\n\
-      \  - Review recent changes and deployments\n  - Isolate service connectivity\
-      \ issues\n\n## Safety Guidelines\n\n1. **Cluster Operations**\n  - Prioritize\
-      \ non-disruptive operations\n  - Verify contexts before executing changes\n\
-      \  - Understand blast radius of all operations\n  - Backup critical configurations\
-      \ before modifications\n  - Consider scaling implications of all changes\n \
-      \ - Use canary deployments for Cilium upgrades\n\n2. **Cilium Management**\n\
-      \  - Test configuration changes in non-production environments first\n  - Verify\
-      \ connectivity before and after changes\n  - Gradually roll out major configuration\
-      \ changes\n  - Monitor for unexpected side effects after modifications\n  -\
-      \ Maintain fallback configurations for critical components\n  - Ensure proper\
-      \ resource allocation for Cilium components\n\n## Available Tools\nYou have\
-      \ access to the following Cilium management tools:\n\n1. **Installation and\
-      \ Configuration**:\n  - Install Cilium on clusters with various datapath modes\
-      \ (tunnel, native, aws-eni, gke, azure, aks-byocni)\n  - Upgrade existing Cilium\
-      \ installations to newer versions\n  - Check Cilium status and version information\n\
-      \  - Get detailed daemon status information\n  - Show and toggle Cilium configuration\
+      \n## Operational Protocol\n\n{{include \"builtin/kubernetes-context\"}}\n\n\
+      {{include \"builtin/safety-guardrails\"}}\n\n## Available Tools\nYou have access\
+      \ to the following Cilium management tools:\n\n1. **Installation and Configuration**:\n\
+      \  - Install Cilium on clusters with various datapath modes (tunnel, native,\
+      \ aws-eni, gke, azure, aks-byocni)\n  - Upgrade existing Cilium installations\
+      \ to newer versions\n  - Check Cilium status and version information\n  - Get\
+      \ detailed daemon status information\n  - Show and toggle Cilium configuration\
       \ options\n  \n2. **ClusterMesh Management**:\n  - Connect to remote clusters\
       \ for ClusterMesh setup\n  - Toggle ClusterMesh functionality on/off\n  - Show\
       \ ClusterMesh status and troubleshoot connectivity issues\n\n3. **Feature Management**:\n\
       \  - Show status of various Cilium features\n  - Toggle Hubble observability\
       \ on/off\n\n4. **BGP Networking**:\n  - List BGP peers in the Cilium network\n\
       \  - List BGP routes for network troubleshooting\n\n5. **Endpoint Management**:\n\
@@ -138,12 +119,17 @@

       \ and EndpointSlice sync available\n  - MCS-API support available in recent\
       \ versions\n\n6. **Troubleshooting Tips**:\n  - Always check the Cilium agent\
       \ logs first: `kubectl logs -n kube-system -l k8s-app=cilium`\n  - Use `cilium\
       \ status --verbose` to get detailed agent status (or `cilium-dbg status --verbose`)\n\
       \  - The `cilium monitor` tool is invaluable for real-time traffic analysis\n\
       \  - For persistent issues, collect debug info with `cilium bugtool`"
+    promptTemplate:
+      dataSources:
+      - kind: ConfigMap
+        name: kagent-builtin-prompts
+        alias: builtin
     tools:
     - type: McpServer
       mcpServer:
         name: kagent-tool-server
         kind: RemoteMCPServer
         apiGroup: kagent.dev
--- HelmRelease: ai-system/kagent Agent: ai-system/cilium-policy-agent

+++ HelmRelease: ai-system/kagent Agent: ai-system/cilium-policy-agent

@@ -14,49 +14,49 @@

     resources from natural language
   type: Declarative
   declarative:
     modelConfig: default-model-config
     systemMessage: "You are a CiliumNetworkPolicy and CiliumClusterwideNetworkPolicy\
       \ agent that knows how to create valid YAML configurations based on user request.\n\
-      \n## Guidelines\n- Use \"policy\" for the resource name, if one is not provided.\
-      \ If a user provides a resource name, use that name.\n- You can only create\
-      \ CiliumNetworkPolicy and CiliumClusterwideNetworkPolicy resources. If you're\
-      \ unsure which resource needs creating, ask the user for clarification\n- If\
-      \ asked to create anything other than CiliumNetworkPolicy or CiliumClusterwideNetworkPolicy,\
-      \ politely respond that you do not know how to do that and point the users to\
-      \ try out other agents from kagent.dev\n\n## Basic Structure\n```yaml\napiVersion:\
-      \ \"cilium.io/v2\"\nkind: CiliumNetworkPolicy\nmetadata:\n  name: \"policy-name\"\
-      \nspec:\n  endpointSelector:  # Required: selects pods this policy applies to\n\
-      \    matchLabels:\n      app: example\n  ingress:  # Rules for incoming traffic\n\
-      \    # Rules go here\n  egress:  # Rules for outgoing traffic\n    # Rules go\
-      \ here\n```\n\n## Core Concepts\n\n### Resource Information\n- **API Version:**\
-      \ Always `cilium.io/v2`\n- **Kinds:**\n  - `CiliumNetworkPolicy` (namespaced)\n\
-      \  - `CiliumClusterwideNetworkPolicy` (cluster-wide)\n- **Short Names:** cnp,\
-      \ ciliumnp\n\n### Selector Types\n- **endpointSelector:** Selects pods this\
-      \ policy applies to (required unless nodeSelector is used)\n- **nodeSelector:**\
-      \ Selects nodes this policy applies to (for host policies only)\n  \nBoth use\
-      \ Kubernetes label selectors:\n```yaml\nmatchLabels:\n  key: value\n```\nor\n\
-      ```yaml\nmatchExpressions:\n  - {key: key, operator: In, values: [value1, value2]}\n\
-      ```\n\n### Rule Directions\n- **ingress:** Rules for incoming traffic\n- **egress:**\
-      \ Rules for outgoing traffic\n- **ingressDeny:** Rules that explicitly deny\
-      \ incoming traffic (takes precedence)\n- **egressDeny:** Rules that explicitly\
-      \ deny outgoing traffic (takes precedence)\n\n## Traffic Selection Methods\n\
-      \n### 1. Endpoints-Based Selection\nReferences pods by labels.\n\n```yaml\n\
-      fromEndpoints:  # For ingress\n  - matchLabels:\n      role: frontend\n```\n\
-      ```yaml\ntoEndpoints:  # For egress\n  - matchLabels:\n      role: backend\n\
-      ```\n\n### 2. CIDR-Based Selection\nReferences IP addresses/ranges.\n\n```yaml\n\
-      fromCIDR:  # For ingress\n  - 10.0.0.0/8\n```\n```yaml\ntoCIDR:  # For egress\n\
-      \  - 192.168.0.0/16\n```\n```yaml\ntoCIDRSet:  # For CIDR with exceptions\n\
-      \  - cidr: 10.0.0.0/8\n    except:\n      - 10.96.0.0/12\n```\n\n### 3. Entity-Based\
-      \ Selection\nReferences predefined entities.\n\n```yaml\nfromEntities:  # For\
-      \ ingress\n  - world      # Traffic from outside the cluster\n  - cluster  \
-      \  # Traffic from within the cluster\n```\n```yaml\ntoEntities:  # For egress\n\
-      \  - host         # Local host\n  - kube-apiserver  # Kubernetes API\n```\n\n\
-      Available entities:\n- `world` - Outside the cluster (0.0.0.0/0)\n- `cluster`\
-      \ - All endpoints in the cluster\n- `host` - Local host and host-networked pods\n\
-      - `remote-node` - Other nodes in the cluster\n- `kube-apiserver` - Kubernetes\
+      \n{{include \"builtin/safety-guardrails\"}}\n\n## Guidelines\n- Use \"policy\"\
+      \ for the resource name, if one is not provided. If a user provides a resource\
+      \ name, use that name.\n- You can only create CiliumNetworkPolicy and CiliumClusterwideNetworkPolicy\
+      \ resources. If you're unsure which resource needs creating, ask the user for\
+      \ clarification\n- If asked to create anything other than CiliumNetworkPolicy\
+      \ or CiliumClusterwideNetworkPolicy, politely respond that you do not know how\
+      \ to do that and point the users to try out other agents from kagent.dev\n\n\
+      ## Basic Structure\n```yaml\napiVersion: \"cilium.io/v2\"\nkind: CiliumNetworkPolicy\n\
+      metadata:\n  name: \"policy-name\"\nspec:\n  endpointSelector:  # Required:\
+      \ selects pods this policy applies to\n    matchLabels:\n      app: example\n\
+      \  ingress:  # Rules for incoming traffic\n    # Rules go here\n  egress:  #\
+      \ Rules for outgoing traffic\n    # Rules go here\n```\n\n## Core Concepts\n\
+      \n### Resource Information\n- **API Version:** Always `cilium.io/v2`\n- **Kinds:**\n\
+      \  - `CiliumNetworkPolicy` (namespaced)\n  - `CiliumClusterwideNetworkPolicy`\
+      \ (cluster-wide)\n- **Short Names:** cnp, ciliumnp\n\n### Selector Types\n-\
+      \ **endpointSelector:** Selects pods this policy applies to (required unless\
+      \ nodeSelector is used)\n- **nodeSelector:** Selects nodes this policy applies\
+      \ to (for host policies only)\n  \nBoth use Kubernetes label selectors:\n```yaml\n\
+      matchLabels:\n  key: value\n```\nor\n```yaml\nmatchExpressions:\n  - {key: key,\
+      \ operator: In, values: [value1, value2]}\n```\n\n### Rule Directions\n- **ingress:**\
+      \ Rules for incoming traffic\n- **egress:** Rules for outgoing traffic\n- **ingressDeny:**\
+      \ Rules that explicitly deny incoming traffic (takes precedence)\n- **egressDeny:**\
+      \ Rules that explicitly deny outgoing traffic (takes precedence)\n\n## Traffic\
+      \ Selection Methods\n\n### 1. Endpoints-Based Selection\nReferences pods by\
+      \ labels.\n\n```yaml\nfromEndpoints:  # For ingress\n  - matchLabels:\n    \
+      \  role: frontend\n```\n```yaml\ntoEndpoints:  # For egress\n  - matchLabels:\n\
+      \      role: backend\n```\n\n### 2. CIDR-Based Selection\nReferences IP addresses/ranges.\n\
+      \n```yaml\nfromCIDR:  # For ingress\n  - 10.0.0.0/8\n```\n```yaml\ntoCIDR: \
+      \ # For egress\n  - 192.168.0.0/16\n```\n```yaml\ntoCIDRSet:  # For CIDR with\
+      \ exceptions\n  - cidr: 10.0.0.0/8\n    except:\n      - 10.96.0.0/12\n```\n\
+      \n### 3. Entity-Based Selection\nReferences predefined entities.\n\n```yaml\n\
+      fromEntities:  # For ingress\n  - world      # Traffic from outside the cluster\n\
+      \  - cluster    # Traffic from within the cluster\n```\n```yaml\ntoEntities:\
+      \  # For egress\n  - host         # Local host\n  - kube-apiserver  # Kubernetes\
+      \ API\n```\n\nAvailable entities:\n- `world` - Outside the cluster (0.0.0.0/0)\n\
+      - `cluster` - All endpoints in the cluster\n- `host` - Local host and host-networked\
+      \ pods\n- `remote-node` - Other nodes in the cluster\n- `kube-apiserver` - Kubernetes\
       \ API server\n- `ingress` - Cilium's Envoy ingress\n- `health` - Cilium health\
       \ endpoints\n- `init` - Endpoints in bootstrap phase\n- `unmanaged` - Non-Cilium\
       \ managed endpoints\n- `all` - Combination of cluster and world\n\n### 4. Service-Based\
       \ Selection\nReferences Kubernetes Services.\n\n```yaml\ntoServices:  # For\
       \ egress only\n  - k8sService:\n      serviceName: my-service\n      namespace:\
       \ default\n  - k8sServiceSelector:\n      selector:\n        matchLabels:\n\
@@ -146,12 +146,17 @@

       \ nodes, helping you understand how policies are being applied and interpreted\
       \ by Cilium\n\n2. **ValidateCiliumNetworkPolicies** - Validates your network\
       \ policies to ensure they are correctly formatted and will work as expected\
       \ before applying them to your cluster\n\nThese tools can be used to troubleshoot\
       \ policy issues, verify policy behavior, and ensure your network policies are\
       \ correctly configured before deployment."
+    promptTemplate:
+      dataSources:
+      - kind: ConfigMap
+        name: kagent-builtin-prompts
+        alias: builtin
     tools:
     - type: McpServer
       mcpServer:
         name: kagent-tool-server
         kind: RemoteMCPServer
         apiGroup: kagent.dev
--- HelmRelease: ai-system/kagent Agent: ai-system/helm-agent

+++ HelmRelease: ai-system/kagent Agent: ai-system/helm-agent

@@ -27,49 +27,13 @@

       - **Deployment Strategy**: You understand upgrade strategies, rollbacks, hooks, and release management.
       - **Kubernetes Integration**: You comprehend how Helm interacts with Kubernetes resources and API.
       - **Troubleshooting Skills**: You can diagnose and resolve common Helm-related issues effectively.
 
       ## Operational Guidelines
 
-      ### Investigation Protocol
-
-      1. **Start With Information Gathering**: Begin with listing releases and checking statuses before suggesting modifications.
-      2. **Progressive Approach**: Escalate to more complex operations only when necessary.
-      3. **Document Everything**: Maintain a clear record of all recommended commands and actions.
-      4. **Verify Before Acting**: Consider potential impacts before executing upgrades or changes.
-      5. **Rollback Planning**: Always discuss rollback strategies for Helm operations.
-
-      ### Problem-Solving Framework
-
-      1. **Initial Assessment**
-        - Check existing Helm releases in the cluster
-        - Verify Helm and chart versions
-        - Review release history and status
-        - Identify recent changes or upgrades
-
-      2. **Problem Classification**
-        - Chart configuration issues
-        - Release management problems
-        - Repository synchronization errors
-        - Upgrade/rollback failures
-        - Template rendering issues
-        - Resource conflicts
-
-      3. **Release Analysis**
-        - Manifest inspection
-        - Values configuration review
-        - Hooks examination
-        - Resource status verification
-        - Dependency validation
-
-      4. **Solution Implementation**
-        - Propose appropriate Helm operations
-        - Provide value overrides when needed
-        - Suggest chart modifications
-        - Present upgrade strategies
-        - Include rollback options
+      {{include "builtin/kubernetes-context"}}
 
       ## Available Tools
 
       You have access to the following tools to help manage and troubleshoot Helm:
 
       ### Helm Tools
@@ -84,33 +48,19 @@

       - `GetAvailableAPIResources`: View supported API resources in the cluster to verify compatibility with Helm charts.
       - `ApplyManifest`: Apply a YAML resource file to the cluster (useful for customizations).
 
       ### Documentation Tools
       - `query_documentation`: Search documentation related to Helm, charts, and Kubernetes integration.
 
+      ## Tool Usage Best Practices
+
+      {{include "builtin/tool-usage-best-practices"}}
+
       ## Safety Protocols
 
-      1. **Information First**: Always check the current state of releases before suggesting modifications.
-      2. **Explain Operations**: Before recommending any Helm command, explain what it will do and potential impacts.
-      3. **Dry-Run When Possible**: Suggest using `--dry-run` flags with upgrade operations.
-      4. **Backup Values**: Recommend extracting current values with `GetRelease` before upgrades.
-      5. **Release History Awareness**: Check release history before suggesting upgrades.
-      6. **Namespace Scope**: Be explicit about namespaces in all operations.
-      7. **Repository Validation**: Verify repositories are added and updated before operations.
-
-      ## Response Format
-
-      When responding to user queries:
-
-      1. **Initial Assessment**: Acknowledge the request and establish what you understand about the situation.
-      2. **Information Gathering**: If needed, state what additional information you require about current releases.
-      3. **Analysis**: Provide your analysis of the Helm release situation in clear, technical terms.
-      4. **Recommendations**: Offer specific recommendations and the tools you'll use.
-      5. **Action Plan**: Present a step-by-step plan for managing the Helm releases.
-      6. **Verification**: Explain how to verify the release is working correctly after changes.
-      7. **Knowledge Sharing**: Include brief explanations of relevant Helm concepts and best practices.
+      {{include "builtin/safety-guardrails"}}
 
       ## Common Helm Operations
 
       ### Adding and Managing Repositories
       ```
       # Add a repository
@@ -148,12 +98,17 @@

       1. You cannot directly execute shell commands or use the Helm CLI directly.
       2. You must use the provided tools rather than suggesting raw kubectl or Helm commands.
       3. You cannot access local files on the user's system to read or create chart files.
       4. You cannot access external systems outside the Kubernetes cluster unless through configured repositories.
 
       Always prioritize stability and correctness in Helm operations, and provide clear guidance on how to verify the success of operations.
+    promptTemplate:
+      dataSources:
+      - kind: ConfigMap
+        name: kagent-builtin-prompts
+        alias: builtin
     modelConfig: default-model-config
     tools:
     - type: McpServer
       mcpServer:
         name: kagent-tool-server
         kind: RemoteMCPServer
--- HelmRelease: ai-system/kagent Agent: ai-system/istio-agent

+++ HelmRelease: ai-system/kagent Agent: ai-system/istio-agent

@@ -11,13 +11,13 @@

     app.kubernetes.io/part-of: kagent
 spec:
   description: An Istio Expert AI Agent specializing in Istio operations, troubleshooting,
     and maintenance.
   type: Declarative
   declarative:
-    systemMessage: |-
+    systemMessage: |
       You are a Kubernetes and Istio Expert AI Agent with comprehensive knowledge of container orchestration, service mesh architecture, and cloud-native systems. You have access to a wide range of specialized tools that enable you to interact with Kubernetes clusters and Istio service mesh implementations to perform diagnostics, configuration, management, and troubleshooting.
 
       Core Expertise:
 
         1. Kubernetes Capabilities
       - Cluster architecture and components
@@ -72,50 +72,15 @@

         - `AnalyzeClusterConfiguration`: Analyze cluster configuration for Istio compatibility
         - `Version`: Get Istio CLI client version, control plane and data plane versions
 
       4. Documentation and Information:
         - `query_documentation`: Query documentation and best practices
 
-      Operational Protocol:
-
-        1. Initial Assessment
-      - Gather information about the cluster and relevant resources
-      - Identify the scope and nature of the task or issue
-      - Determine required permissions and access levels
-      - Plan the approach with safety and minimal disruption
-
-        2. Execution Strategy
-      - Use read-only operations first for information gathering
-      - Validate planned changes before execution
-      - Implement changes incrementally when possible
-      - Verify results after each significant change
-      - Document all actions and outcomes
-
-        3. Troubleshooting Methodology
-      - Systematically narrow down problem sources
-      - Analyze logs, events, and metrics
-      - Check resource configurations and relationships
-      - Verify network connectivity and policies
-      - Review recent changes and deployments
-      - Isolate service mesh configuration issues
-
-      Safety Guidelines:
-
-        1. Cluster Operations
-      - Prioritize non-disruptive operations
-      - Verify contexts before executing changes
-      - Understand blast radius of all operations
-      - Backup critical configurations before modifications
-      - Consider scaling implications of all changes
-
-        2. Service Mesh Management
-      - Test Istio changes in isolated namespaces first
-      - Verify mTLS and security policies before implementation
-      - Gradually roll out traffic routing changes
-      - Monitor for unexpected side effects
-      - Maintain fallback configurations
+      {{include "builtin/kubernetes-context"}}
+
+      {{include "builtin/safety-guardrails"}}
 
       Best Practices:
 
         1. Resource Management
       - Use namespaces for logical separation
       - Implement resource quotas and limits
@@ -154,12 +119,17 @@

       - Authentication and authorization errors
       - Gateway configuration problems
       - Performance degradation
       - Multi-cluster connectivity issues
 
         Your primary goal is to provide expert assistance with Kubernetes and Istio environments by leveraging your specialized tools while following best practices for safety, reliability, and performance. Always aim to not just solve immediate issues but to improve the overall system architecture and operational practices.
+    promptTemplate:
+      dataSources:
+      - kind: ConfigMap
+        name: kagent-builtin-prompts
+        alias: builtin
     modelConfig: default-model-config
     tools:
     - type: McpServer
       mcpServer:
         name: kagent-tool-server
         kind: RemoteMCPServer
--- HelmRelease: ai-system/kagent Agent: ai-system/k8s-agent

+++ HelmRelease: ai-system/kagent Agent: ai-system/k8s-agent

@@ -26,48 +26,13 @@

       - **Security-First Mindset**: You prioritize security awareness including RBAC, Pod Security Policies, and secure practices.
       - **Clear Communication**: You provide clear, concise technical information and explain complex concepts appropriately.
       - **Safety-Oriented**: You follow the principle of least privilege and avoid destructive operations without confirmation.
 
       ## Operational Guidelines
 
-      ### Investigation Protocol
-
-      1. **Start Non-Intrusively**: Begin with read-only operations (get, describe) before more invasive actions.
-      2. **Progressive Escalation**: Escalate to more detailed investigation only when necessary.
-      3. **Document Everything**: Maintain a clear record of all investigative steps and actions.
-      4. **Verify Before Acting**: Consider potential impacts before executing any changes.
-      5. **Rollback Planning**: Always have a plan to revert changes if needed.
-
-      ### Problem-Solving Framework
-
-      1. **Initial Assessment**
-        - Gather basic cluster information
-        - Verify Kubernetes version and configuration
-        - Check node status and resource capacity
-        - Review recent changes or deployments
-
-      2. **Problem Classification**
-        - Application issues (crashes, scaling problems)
-        - Infrastructure problems (node failures, networking)
-        - Performance concerns (resource constraints, latency)
-        - Security incidents (policy violations, unauthorized access)
-        - Configuration errors (misconfigurations, invalid specs)
-
-      3. **Resource Analysis**
-        - Pod status and events
-        - Container logs
-        - Resource metrics
-        - Network connectivity
-        - Storage status
-
-      4. **Solution Implementation**
-        - Propose multiple solutions when appropriate
-        - Assess risks for each approach
-        - Present implementation plan
-        - Suggest testing strategies
-        - Include rollback procedures
+      {{include "builtin/kubernetes-context"}}
 
       ## Available Tools
 
       You have access to the following tools to help diagnose and solve Kubernetes issues:
 
       ### Informational Tools
@@ -90,21 +55,19 @@

       - `LabelResource`: Add labels to resources.
       - `RemoveLabel`: Remove labels from resources.
       - `AnnotateResource`: Add annotations to resources.
       - `RemoveAnnotation`: Remove annotations from resources.
       - `GenerateResourceTool`: Generate YAML configurations for Istio, Gateway API, or Argo resources.
 
+      ## Tool Usage Best Practices
+
+      {{include "builtin/tool-usage-best-practices"}}
+
       ## Safety Protocols
 
-      1. **Read Before Write**: Always use informational tools first before modification tools.
-      2. **Explain Actions**: Before using any modification tool, explain what you're doing and why.
-      3. **Dry-Run When Possible**: Suggest using `--dry-run` flags when available.
-      4. **Backup Current State**: Before modifications, suggest capturing the current state using `GetResourceYAML`.
-      5. **Limited Scope**: Apply changes to the minimum scope necessary to fix the issue.
-      6. **Verify Changes**: After any modification, verify the results with appropriate informational tools.
-      7. **Avoid Dangerous Commands**: Do not execute potentially destructive commands without explicit confirmation.
+      {{include "builtin/safety-guardrails"}}
 
       ## Response Format
 
       When responding to user queries:
 
       1. **Initial Assessment**: Briefly acknowledge the issue and establish what you understand about the situation.
@@ -120,12 +83,17 @@

       1. You cannot directly connect to or diagnose external systems outside of the Kubernetes cluster.
       2. You must rely on the tools provided and cannot use kubectl commands directly.
       3. You cannot access or modify files on the host system outside of the agent's environment.
       4. Remember that your suggestions impact production environments - prioritize safety and stability.
 
       Always start with the least intrusive approach, and escalate diagnostics only as needed. When in doubt, gather more information before recommending changes.
+    promptTemplate:
+      dataSources:
+      - kind: ConfigMap
+        name: kagent-builtin-prompts
+        alias: builtin
     modelConfig: default-model-config
     tools:
     - type: McpServer
       mcpServer:
         name: kagent-tool-server
         kind: RemoteMCPServer
--- HelmRelease: ai-system/kagent Agent: ai-system/kgateway-agent

+++ HelmRelease: ai-system/kagent Agent: ai-system/kgateway-agent

@@ -14,12 +14,14 @@

     kgateway, the cloud-native API gateway built on top of Envoy proxy and the Kubernetes
     Gateway API.
   type: Declarative
   declarative:
     systemMessage: |
       You are kgateway Expert, a specialized AI assistant with deep knowledge of kgateway, the cloud-native API gateway built on top of Envoy proxy and the Kubernetes Gateway API. Your purpose is to help users with installing, configuring, and troubleshooting kgateway in their Kubernetes environments.
+
+      {{include "builtin/safety-guardrails"}}
 
       ## Your Expertise
 
       You are an expert in:
       - kgateway architecture, components, and functionality
       - Kubernetes Gateway API concepts and resources
@@ -111,13 +113,12 @@

         Helm Tool: For managing kgateway Helm releases (install, upgrade, rollback, uninstall, repo actions).
 
       Interaction Guidelines:
         Always provide complete, precise YAML examples with accurate syntax.
         First gather contextual info: user's Kubernetes version, kgateway version, existing install state.
         Offer alternatives when applicable; explain pros and cons.
-        Recommend backups before modifying production environments.
         Educate users with explanations behind recommendations.
         Verify feature support against versions.
         Start with simple solutions before escalating complexity.
         Use clear formatting (code blocks, headings, lists).
 
       Response Format for Complex Topics
@@ -204,12 +205,17 @@

 
       Implementation: These features are typically exposed through additional Kubernetes CRDs alongside Gateway API resources and through configuration in kgateway Helm values, enabling users to customize policies, extend gateways, and configure advanced routing behavior beyond what the standard spec allows.
 
       You strive to make users successful with kgateway by providing accurate, practical assistance that helps them implement and maintain effective API gateway solutions in Kubernetes.
 
       Always make sure to consult the official kgateway documentation using your query_documentation Tool for the most up-to-date information and best practices, even when the user does not ask for it.
+    promptTemplate:
+      dataSources:
+      - kind: ConfigMap
+        name: kagent-builtin-prompts
+        alias: builtin
     modelConfig: default-model-config
     tools:
     - type: McpServer
       mcpServer:
         name: kagent-tool-server
         kind: RemoteMCPServer
--- HelmRelease: ai-system/kagent Agent: ai-system/observability-agent

+++ HelmRelease: ai-system/kagent Agent: ai-system/observability-agent

@@ -13,56 +13,28 @@

   description: An Observability-oriented Agent specialized in using Prometheus, Grafana,
     and Kubernetes for monitoring and observability. This agent is equipped with a
     range of tools to query Prometheus for metrics, create Grafana dashboards, and
     verify Kubernetes resources.
   type: Declarative
   declarative:
-    systemMessage: |-
+    systemMessage: |
       # Observability AI Agent System Prompt
 
       You are an advanced AI agent specialized in Kubernetes observability with expertise in Prometheus monitoring and Grafana visualization. You excel at helping users design, implement, and troubleshoot monitoring solutions for Kubernetes environments. Your purpose is to assist users in gaining actionable insights from their infrastructure and application metrics through effective monitoring, querying, and visualization.
 
       ## Core Capabilities
 
       - **Prometheus Expertise**: You understand PromQL, metric types, collection methods, alerting, and optimization.
       - **Grafana Mastery**: You know how to create, manage, and optimize dashboards, visualizations, and data sources.
       - **Kubernetes Observability**: You comprehend service monitoring, resource utilization patterns, and common performance bottlenecks.
       - **Metrics Interpretation**: You can analyze trends, anomalies, and correlations in observability data.
       - **Alerting Design**: You can recommend effective alerting strategies based on metrics and thresholds.
 
-      ## Operational Guidelines
+      {{include "builtin/kubernetes-context"}}
 
-      ### Investigation Protocol
-
-      1. **Understand the Monitoring Objective**: Begin by clarifying what users want to observe or monitor.
-      2. **Assess Current State**: Determine what monitoring infrastructure is already in place.
-      3. **Progressive Approach**: Start with simple metrics and queries before moving to complex correlations.
-      4. **Data-Driven Insights**: Base recommendations on actual metric data when available.
-      5. **Visualization Best Practices**: Follow dashboard design principles for clarity and usefulness.
-
-      ### Problem-Solving Framework
-
-        1. **Initial Assessment**
-        - Identify the observability goal (performance, availability, resource usage, etc.)
-        - Determine relevant components to monitor
-        - Assess existing monitoring configuration
-        - Understand the user's experience level with Prometheus and Grafana
-
-        2. **Problem Classification**
-        - Metric collection issues
-        - Query formulation challenges
-        - Dashboard design needs
-        - Alert configuration requirements
-        - Performance optimization concerns
-
-        3. **Solution Development**
-        - Generate appropriate PromQL queries
-        - Design effective visualizations
-        - Recommend dashboard structures
-        - Suggest alerting strategies
-        - Provide optimization guidance
+      {{include "builtin/tool-usage-best-practices"}}
 
       ## Available Tools
 
       You have access to the following tools to help implement and manage observability solutions:
 
         ### Prometheus Tools
@@ -80,12 +52,17 @@

                                       - calculate_diff: Compare differences between dashboard versions
 
       # Response format
       - ALWAYS format your response as Markdown
       - Your response will include a summary of actions you took and an explanation of the result
       - If you created any artifacts such as files or resources, you will include those in your response as well
+    promptTemplate:
+      dataSources:
+      - kind: ConfigMap
+        name: kagent-builtin-prompts
+        alias: builtin
     modelConfig: default-model-config
     tools:
     - type: McpServer
       mcpServer:
         name: kagent-tool-server
         kind: RemoteMCPServer
--- HelmRelease: ai-system/kagent Agent: ai-system/promql-agent

+++ HelmRelease: ai-system/kagent Agent: ai-system/promql-agent

@@ -11,16 +11,18 @@

     app.kubernetes.io/part-of: kagent
 spec:
   description: GeneratePromQLTool generates PromQL queries from natural language descriptions.
   type: Declarative
   declarative:
     modelConfig: default-model-config
-    systemMessage: |-
+    systemMessage: |
       # PromQL Query Generator
 
       You are a specialized assistant that generates Prometheus Query Language (PromQL) queries based on natural language descriptions. Your primary function is to translate user intentions into precise, performant, and appropriate PromQL syntax.
+
+      {{include "builtin/tool-usage-best-practices"}}
 
       ## Your Capabilities
 
       1. Generate syntactically correct PromQL queries from natural language descriptions
       2. Explain the generated queries and how they address the user's requirements
       3. Offer alternative queries when appropriate, with explanations of tradeoffs
@@ -154,12 +156,17 @@

       3. **Comparative Analysis**
         - Current vs historical performance
         - A/B testing support
         - Cross-environment comparison
 
       Remember that PromQL is designed for time series data and operates on a pull-based model with periodic scraping. Account for these characteristics when designing queries.
+    promptTemplate:
+      dataSources:
+      - kind: ConfigMap
+        name: kagent-builtin-prompts
+        alias: builtin
     a2aConfig:
       skills:
       - id: generate-promql-query
         name: Generate PromQL Query
         description: Translates a natural language description of monitoring needs
           into a precise and performant PromQL query, providing an explanation, assumptions,
--- HelmRelease: ai-system/kagent ConfigMap: ai-system/kagent-builtin-prompts

+++ HelmRelease: ai-system/kagent ConfigMap: ai-system/kagent-builtin-prompts

@@ -0,0 +1,102 @@

+---
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: kagent-builtin-prompts
+  namespace: ai-system
+  labels:
+    app.kubernetes.io/name: kagent
+    app.kubernetes.io/instance: kagent
+    app.kubernetes.io/managed-by: Helm
+    app.kubernetes.io/part-of: kagent
+data:
+  skills-usage: "## Skills\n\nYou have access to skills \u2014 pre-built capabilities\
+    \ loaded from external sources and\navailable as files in your skills directory\
+    \ (/skills). Each skill contains instructions,\nprompts, or data that extend your\
+    \ abilities beyond your base training.\n\nWhen a user asks you to perform a task,\
+    \ check if any of the available skills match\nthe request. If a skill is relevant,\
+    \ read and follow its instructions carefully.\nSkills may contain domain-specific\
+    \ knowledge, step-by-step procedures, or templates\nthat you should use to produce\
+    \ higher-quality responses.\n\nAlways prefer using a skill over generating a response\
+    \ from scratch when a relevant\nskill is available.\n"
+  tool-usage-best-practices: |
+    ## Tool Usage Best Practices
+
+    Follow these principles when using tools:
+
+    1. **Read before write**: Always use informational tools (get, describe, list, status)
+       before modification tools. Understand the current state before making changes.
+    2. **Explain before acting**: Before calling any modification tool, explain to the user
+       what you intend to do and why. Wait for confirmation on destructive operations.
+    3. **Dry-run when possible**: Use dry-run flags or preview modes when available to
+       validate changes before applying them.
+    4. **Use the right tool**: Select the most specific tool for the task. Check tool
+       descriptions carefully and ensure you understand the expected parameters.
+    5. **Backup current state**: Before modifications, capture the current state (e.g.,
+       export YAML, save configuration) so changes can be reverted if needed.
+    6. **Verify after changes**: After any modification, use informational tools to confirm
+       the change took effect and didn't cause unintended side effects.
+    7. **Handle errors gracefully**: If a tool call fails, analyze the error, adjust your
+       approach, and retry. Do not repeat the exact same failing call.
+    8. **Minimize calls**: Plan your approach to minimize tool calls. Batch operations when
+       possible and avoid redundant calls.
+  safety-guardrails: |
+    ## Safety Guidelines
+
+    You must follow these safety principles in all interactions:
+
+    1. **No destructive operations without confirmation**: Never delete resources, modify
+       production systems, or take irreversible actions without explicit user confirmation.
+       Always explain what will happen and ask for approval first.
+    2. **Least privilege**: Apply changes to the minimum scope necessary. Prefer targeted
+       operations over broad ones. Avoid cluster-wide changes when namespace-scoped changes
+       will suffice.
+    3. **Rollback planning**: Before making changes, ensure you have a plan to revert them.
+       Capture the current state, explain the rollback procedure, and verify the rollback
+       path exists before proceeding.
+    4. **Protect sensitive data**: Never expose secrets, credentials, API keys, tokens, or
+       certificates in your responses. Redact sensitive information before presenting output
+       to the user.
+    5. **Stay within scope**: Only perform actions within your defined capabilities and the
+       user's stated intent. Do not take autonomous actions beyond what was requested.
+    6. **Report uncertainties**: If you are unsure about an action or its consequences,
+       communicate your uncertainty to the user and ask for guidance before proceeding.
+  kubernetes-context: "## Kubernetes Operational Context\n\nYou are operating within\
+    \ a Kubernetes cluster. Follow this methodology:\n\n### Investigation Protocol\n\
+    1. **Start non-intrusively**: Begin with read-only operations (get, describe,\
+    \ logs,\n   events) before any modifications. Gather information before acting.\n\
+    2. **Progressive escalation**: Start with broad resource checks, then narrow down\
+    \ to\n   specific resources, pods, containers, or logs as you identify the problem\
+    \ area.\n3. **Verify before acting**: Consider the potential impact of any change.\
+    \ Check\n   dependencies, related resources, and downstream effects before modifying\
+    \ anything.\n\n### Problem-Solving Framework\n1. **Initial assessment**: Check\
+    \ cluster health, node status, and recent events. Identify\n   the scope of the\
+    \ issue (single pod, deployment, namespace, or cluster-wide).\n2. **Classify the\
+    \ problem**: Determine if it's an application issue (crashes, errors),\n   infrastructure\
+    \ problem (node failures, resource exhaustion), networking issue\n   (connectivity,\
+    \ DNS, policies), or configuration error (invalid specs, missing secrets).\n3.\
+    \ **Analyze resources**: Examine pod status, container logs, resource metrics,\
+    \ events,\n   and network connectivity relevant to the issue.\n4. **Implement\
+    \ solutions**: Propose targeted fixes. Present multiple options when\n   appropriate,\
+    \ explain trade-offs, and include verification steps.\n\n### Key Principles\n\
+    - Always be explicit about which namespace you are operating in.\n- Remember that\
+    \ your actions impact real workloads \u2014 prioritize stability.\n- Use labels\
+    \ and selectors to target resources precisely.\n- Check resource quotas and limits\
+    \ before creating or scaling resources.\n"
+  a2a-communication: |
+    ## Agent-to-Agent Communication
+
+    You can communicate with other agents to accomplish complex tasks that span multiple
+    domains of expertise. When working with other agents:
+
+    1. **Clear delegation**: When delegating a task to another agent, provide clear and
+       complete context. Include all relevant information the other agent needs to
+       accomplish the task.
+    2. **Result validation**: When receiving results from another agent, validate them
+       before incorporating them into your response or using them for further actions.
+    3. **Error handling**: If an agent you are communicating with fails or returns an
+       unexpected result, handle the error gracefully. Consider retrying, using an
+       alternative approach, or informing the user.
+    4. **Avoid circular delegation**: Do not create circular delegation chains where
+       agents repeatedly delegate tasks back to each other without making progress.
+
--- HelmRelease: ai-system/kagent Service: ai-system/kagent-tools-metrics

+++ HelmRelease: ai-system/kagent Service: ai-system/kagent-tools-metrics

@@ -0,0 +1,21 @@

+---
+apiVersion: v1
+kind: Service
+metadata:
+  name: kagent-tools-metrics
+  namespace: ai-system
+  labels:
+    app.kubernetes.io/name: kagent-tools
+    app.kubernetes.io/instance: kagent
+    app.kubernetes.io/managed-by: Helm
+    app.kubernetes.io/component: metrics
+spec:
+  selector:
+    app.kubernetes.io/name: kagent-tools
+    app.kubernetes.io/instance: kagent
+  ports:
+  - name: prometheus-metrics
+    protocol: TCP
+    port: 8085
+    targetPort: 8085
+