Skip to main content

0.4.18 → 0.5.52 Upgrade Guide — Workflow Engine, Webex Bot, BYO Credentials, Custom Agents, Fine-Grained Authorization, and Scheduled Agents

Sri Aradhyula
Sri Aradhyula
Erik Lutz
Erik Lutz
Shubham Bakshi
Shubham Bakshi
Sunny Whang
Sunny Whang
David Bouchare
David Bouchare

Released: 2026-07-15 Chart: oci://ghcr.io/cnoe-io/charts/ai-platform-engineering:0.5.52 Previous release: 0.4.18

Highlights​

0.5.52 marks a major milestone for the platform. The 0.5.x series ships six headline capabilities that fundamentally expand what you can build and how the platform governs access: a new agentic workflow engine, a configurable Webex bot, bring-your-own credentials and impersonation tokens for MCP servers, fully custom agent definitions, relationship-based fine-grained authorization, and agent-driven scheduled jobs. This post summarizes what changed from 0.4.18 to 0.5.52.

The entire authorization stack ships disabled by default — upgrading from 0.4.18 requires no values.yaml changes if you are not opting into RBAC, Webex, or credentials.

What's New​

Workflow Engine​

The platform now ships a first-class workflow engine backed by LangGraph. You can build multi-step agentic workflows that fan out to sub-agents, pause for human approval, and resume — all tracked in a live UI timeline.

  • Inline human-in-the-loop (HITL): When a workflow reaches a waiting_for_input state, the approval form renders directly inside the chat card. No navigation required.
  • Subagent timeline correlation: Each sub-agent's output is pinned to its triggering step so you can trace execution at a glance.
  • Workflow run sharing: Share a run with one or more teams for collaborative debugging. Team members can view and resume shared runs through the same OpenFGA access model used everywhere else.
  • Non-admin workflow creation: Team members can create, edit, and run workflows scoped to their team without platform-wide grants.
  • Live status in chat: When an agent kicks off a workflow, the chat response includes a direct link to the run and polls for live status updates.

The previous Task Builder tab is superseded by the new workflow engine. The legacy standalone supervisor and A2A agents are removed; all routing now flows through the dynamic agent layer.

Customizable Webex Bot​

A full Webex bot integration ships as a first-class platform component.

  • Space-to-agent routing: Webex spaces can be onboarded directly to an agent and team from the Integrations tab, with no admin involvement required for team members.
  • Bulk onboarding: Admins can assign multiple spaces to agents in a single step.
  • Markdown support: The bot renders rich markdown responses from agents natively.
  • Run As identity: Spaces can be configured to send messages as a named service account, giving you a consistent, auditable identity across bot-driven conversations.
  • Prometheus metrics: Bot activity is exposed for scraping out of the box.
  • Helm subchart: The bot is packaged as a first-class subchart and disabled by default (tags.webex-bot: false).

BYO Credentials and Impersonation for MCP Servers​

You can now bring your own credentials to MCP tool calls — either as personal OAuth tokens, service account credentials, or PKCE public-client flows for integrations that don't support a fixed scope.

  • Envelope-encrypted credential store: Credentials are stored with AES-GCM envelope encryption and KMS-style data-key wrapping in MongoDB. AWS KMS is the recommended key provider for production.
  • Pin OAuth connections to MCP servers: When adding a custom MCP server (GitHub, Jira, Confluence, etc.), attach an OAuth provider connection directly. The platform forwards those credentials automatically on every tool call.
  • PKCE public-client OAuth: For integrations where a fixed MCP connection scope is not appropriate, the user's OAuth session scope is used directly.
  • Service account credential passthrough: Service accounts carry their own credentials into tool calls so integrations authenticate with the service account's token, not the invoking user's.
  • Impersonation tokens: The platform uses Keycloak token exchange (requested_subject impersonation) so scheduled and automated runs execute as the owning user — access enforcement is identical to interactive runs.
  • Fail-closed enforcement: If a caller-scoped MCP tool requires OAuth credentials and none are present, the request fails with a clear message rather than silently proceeding.

Enable with CAIPE_CREDENTIALS_ENABLED: "true" and set CREDENTIAL_KEY_PROVIDER: "aws-kms" for production.

Custom Agents​

The dynamic agents runtime is now the sole routing layer for the platform. You can define, deploy, and manage agents entirely from the UI without writing code or modifying Helm values.

  • Full CRUD from the UI: Create agents with a system prompt, LLM config, and MCP tool selection. Agents are persisted in MongoDB and take effect immediately.
  • MCP endpoint normalizer: Agent configs accept bare hostnames, trailing-slash URLs, or missing /mcp suffixes — the platform canonicalizes them automatically.
  • Editor blocker hints: The agent editor surfaces actionable hints when required configuration is missing, and blocks deletion of the platform default agent.
  • Hello-World seed agent: Fresh installs auto-provision a working Hello-World agent and a default team so the platform is usable on first login.
  • Agent owner access: Agent owners and their team members get full manage access automatically — no explicit admin grant required.
  • MCP permissions panel: Each MCP server shows which teams and users have access, with grant management inline.

Fine-Grained Authorization​

The platform ships a complete relationship-based access control (ReBAC) stack backed by OpenFGA and Keycloak. Every access decision — agents, knowledge bases, MCP tools, workflows, credentials — flows through a single authorization service.

  • OpenFGA is the source of truth: Team resource access for agents, knowledge bases, tools, and skills is read exclusively from OpenFGA. The admin team UI reflects only what FGA knows.
  • Keycloak identity: Keycloak acts as the identity provider with realm-init, token-exchange, and auth-reconcile jobs bundled in the chart.
  • AgentGateway ext_authz bridge: The AgentGateway proxy enforces per-call MCP authorization decisions before requests reach backend tools.
  • Admin UI for access management: A team-centric view of user access lets admins see who can reach what through the lens of team membership — no need to understand the underlying authorization model. An access explorer and RBAC self-check tool help diagnose permission issues.
  • Okta / LDAP directory sync: Group sync runs on a configurable schedule, JIT-provisions users on login, and reconciles OpenFGA tuples transactionally so large-org syncs (hundreds of groups) complete without crashing.
  • Per-document RAG ACLs: Knowledge base access is governed by OpenFGA with per-document enforcement at retrieval time.
  • Stale grant cleanup: Stale RBAC principals and grants are removed automatically on sync.
  • Centralized Authorization Service (CAS): A dedicated component (0.5.12+) makes permission checks faster and more consistent across agents, workflows, and MCP tools.

The entire stack ships disabled by default. Enable with:

tags.keycloak: true
openfga.enabled: true
openfgaAuthzBridge.enabled: true
global.agentgateway.enabled: true

Scheduled Agents​

Agents can now create, manage, and run scheduled jobs without manual intervention.

  • Scheduler MCP server: A new mcp-scheduler tool exposes create, list, update, and delete operations for scheduled jobs. Each job is owned by the creating user — only they (or their team members) can manage it.
  • Kubernetes CronJob backend: Each schedule maps to a Kubernetes CronJob in the platform namespace. The caipe-cron-runner pod fires once per schedule interval and exits.
  • Owner impersonation on execution: The scheduler uses Keycloak token exchange to mint a real owner-user bearer on each firing. Access enforcement (agent#use) is identical to an interactive run — if the owner's access was revoked, the run fails closed.
  • Conversation history: Each scheduled run creates a Web UI conversation owned by the schedule's creator, so all runs are visible in chat history.
  • One-shot and recurring: Schedules support both standard cron expressions (recurring) and delayed one-off jobs with optional retry metadata.

Enable with:

scheduler:
  enabled: true

Security​

  • Keycloak client secrets for service-account clients rotate on every helm install/upgrade. Strict-mode gate (keycloak.strictClientSecrets) fails the install if dev placeholders are still in use.
  • BFF no longer falls back to admin/admin against Keycloak — production requires the client_credentials path and fails loudly otherwise.
  • Demo users with hardcoded passwords removed from the bundled realm config.
  • SSRF protections added to web ingestors (non-public URLs rejected).
  • Dependency pins: aiohttp, websockets, @aws-sdk/client-kms, protobuf, qs.
  • NoSQL injection fixes in the admin API surface.

Breaking Changes​

No breaking Helm values changes from 0.4.18 to 0.5.52 for operators who are not opting into RBAC, Webex, or credentials. All new configuration is additive with working defaults.

Two behavioral notes:

  1. active_team JWT claim removed — replaced by channel-derived team binding. Operators upgrading from 0.4.18 are unaffected (the claim was never issued by that release). Any external code that inspected active_team on a CAIPE-issued JWT should switch to reading the channel/space context.

  2. Legacy supervisor and standalone A2A agents removed — if your values.yaml references those components, the entries can be dropped. Dynamic agents are the supported routing layer from 0.5.22 onward.

Upgrade​

helm upgrade ai-platform-engineering \
  oci://ghcr.io/cnoe-io/charts/ai-platform-engineering \
  --version 0.5.52 \
  -f your-values.yaml

For the full incremental upgrade path with per-release values diffs, see the individual release notes for 0.5.0 through 0.5.45.

Upgrade Guide: 0.4.18 → 0.5.52​

Overview​

Drop-in for stock 0.4.18 deployments. Every new capability is additive and gated behind a feature flag that defaults to disabled. The only required review is whether your values.yaml references the legacy supervisor or standalone A2A agents (safe to remove).

StepWhat to enableKey values
1Dynamic agents (already default)No change
2RBAC + OpenFGAtags.keycloak, openfga.enabled, openfgaAuthzBridge.enabled, global.agentgateway.enabled
3Webex bottags.webex-bot: true
4Credentials storeCAIPE_CREDENTIALS_ENABLED: "true", CREDENTIAL_KEY_PROVIDER: "aws-kms"
5Schedulerscheduler.enabled: true

Helm Values: keys to drop​

If present in your values.yaml, these are now no-ops and can be removed:

  • Any supervisor (supervisor.*) config
  • a2a-agents.* standalone agent entries
  • AGENT_GATEWAY_MCP_SERVER_IDS: "jira" (no longer needed — AgentGateway handles routing based on profile)

Data Migrations​

No MongoDB schema migrations are required for the drop-in path. If enabling RBAC, the OpenFGA init job bootstraps the authorization model and backfills existing tuples automatically on first run.

Verify​

kubectl get pods -n <namespace>
# Send a test chat message and confirm a normal response