Latest release: use the releases page for the current 0.5.x patch, per-release upgrade guides, and Helm values diffs.

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 input, and resume — tracked in a live UI timeline.

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

The previous Task Builder is superseded by this engine. The legacy standalone supervisor and A2A agents are removed as of 0.5.22 — all routing flows through the dynamic agent layer.

Scheduled Agents​

Agents can now create, manage, and run scheduled jobs without any manual intervention. (0.5.36)

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

Enable with scheduler.enabled: true.

BYO Credentials and Impersonation for MCP Servers​

You can now attach credentials directly to MCP tool calls — 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: AES-GCM with KMS-style data-key wrapping in MongoDB. AWS KMS is recommended for production; local-cmk for non-production only. (0.5.0)
• Pin OAuth connections to MCP servers: Attach a GitHub, Jira, Confluence, or other OAuth provider connection directly to a custom MCP server. The platform forwards credentials automatically on every tool call. (0.5.18)
• PKCE public-client OAuth: For integrations where a fixed connection scope is not appropriate, the user's OAuth session scope is used directly. (0.5.29)
• Service account credential passthrough: Service accounts carry their own credentials into tool calls so integrations authenticate as the service account, not the invoking user. (0.5.13)
• Fail-closed enforcement: If a caller-scoped MCP tool requires OAuth credentials and none are present, the request fails with a clear error rather than silently proceeding. (0.5.18)
• Credentials panel: Single scrollable pane for all credential types, with secret hash tabs for reviewing stored hashes. (0.5.27/0.5.29)

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

Custom Agents​

The dynamic agents runtime is the sole routing layer. 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. Persisted in MongoDB and live immediately. (0.5.0+)
• MCP endpoint normalizer: Accepts bare hostnames, trailing-slash URLs, or missing /mcp suffixes — canonicalized automatically. (0.5.0)
• Editor blocker hints: The agent editor surfaces actionable hints when required configuration is missing, and blocks deletion of the platform default agent. (0.5.0)
• Agent owner team access: Agent owners and their team members get full manage access automatically — no explicit admin grant required. (0.5.34)
• MCP permissions panel: Each MCP server shows which teams and users have access, with grant management inline. (0.5.18)
• Deep links: Agent, MCP server, and LLM model editors are URL-backed and shareable. (0.5.52)

Fine-Grained Authorization​

Every access decision — agents, knowledge bases, MCP tools, workflows, credentials — flows through a single authorization service backed by OpenFGA and Keycloak. (0.5.0)

What's enforced​

Centralized Authorization Service (CAS) (0.5.12)​

A dedicated CAS component makes permission checks faster and more consistent across agents, workflows, and MCP tools — one decision, same result everywhere.

OpenFGA as source of truth (0.5.27)​

Team resource access is read exclusively from OpenFGA. The admin team UI shows only what FGA knows, removing local-state drift.

Access explorer and RBAC self-check (0.5.27)​

• Access explorer: Browse effective permissions by user, team, and resource — no need to read raw FGA tuples.
• RBAC self-check: Runs a suite of authorization checks and reports pass/fail — diagnose why a user can't reach a resource in seconds.

Identity and directory sync​

• Okta directory sync (0.5.10): Full SDK-based group sync with JIT user provisioning. Map Okta groups to CAIPE teams from Admin → Identity Group Sync → Okta. Large-org syncs are parallelized and resilient to invalid names, already-linked identities, and event-loop stalls. (0.5.48/0.5.49/0.5.51)
• Baseline access bootstrapped at sync: Directory-synced users get the baseline OpenFGA grants needed to pass the AgentGateway ext_authz gate before their first interactive login. (0.5.51)
• Stale grants cleaned up: Deleted users and teams have their OpenFGA grants removed automatically. (0.5.27)

Admin experience​

• Team-scoped admin views for non-admins (0.5.15): Non-admin team members can see users, teams, stats, and feedback scoped to their own teams. Team members can also manage their team's Slack/Webex integrations.
• Team-based user access view (0.5.22): Replaces raw FGA tuple management with a team-centric view of who can reach what.
• Policy manifest download (0.5.15): Download the full authorization policy as YAML for audits and version control.

The entire stack ships disabled by default. Enable with:

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

Webex Bot​

A full Webex bot ships as a first-class platform component alongside the Slack bot. (0.5.0)

• Space-to-agent routing: Webex spaces onboard to an agent and team from the Integrations tab — no admin involvement required for team members. (0.5.20)
• Bulk onboarding: Admins assign multiple spaces to agents in one step. (0.5.20)
• Markdown support: The bot renders rich markdown agent responses natively. (0.5.39)
• Run As identity: Spaces can be configured to send messages as a named service account for a consistent, auditable identity. (0.5.13)
• Webex MCP auth: The Webex MCP server forwards the provider token correctly so tool calls authenticate with the bot's Webex API token. (0.5.45)
• Prometheus metrics: Bot activity is exposed for scraping out of the box. (0.5.0)

Enable with tags.webex-bot: true.

Service Accounts (0.5.13)​

Teams can create non-personal bot identities for external systems and automation:

• Team-owned, scoped to selected agents and tools
• Carry their own credentials into tool calls
• One-time credential generation with rotation/revoke flows
• Caller-keyed tool authorization at the AgentGateway layer
• Slack channels can be set to "Run As" a service account for consistent bot-operated channel identity

Platform Health and Observability​

• Per-dependency health view (0.5.20): Platform Health probes each dependency — MongoDB, Keycloak, RAG, Webex, and others — independently. Failing items link directly to the recommended fix.
• Profile-aware capabilities (0.5.25): Health probes are now structured as named capabilities tied to the deployment profile. Integrations not in the active profile show as "not applicable" rather than failing.
• Audit log retention controls (0.5.27): Configure S3 lifecycle rules, view current storage usage, and tune log verbosity per event type from the platform admin panel.
• Prometheus metrics: Keycloak management metrics (0.5.34), OpenFGA metrics (0.5.35), and AgentGateway metrics (0.5.35) are all scrapeable with dedicated ServiceMonitors.

AgentGateway MCP Routing — No CRDs Required​

MCP traffic is proxied through AgentGateway in CRD-free static routing mode by default:

• One /mcp/<id> route per agent rendered automatically from Helm
• A built-in /mcp/knowledge-base route for the RAG server
• Dynamic route updates via config-bridge sidecar — no pod restarts
• Optional per-call JWT validation and OpenFGA ext_authz enforcement

global:
  agentgateway:
    enabled: true
    # routingMode: static  (default — no CRDs required)
    # routingMode: gateway-api  (opt-in — requires CRDs + controller)

Self-Service Channel Onboarding (0.5.20)​

Team members can grant their own Slack or Webex channel access directly from the Integrations tab — no platform admin required. Admins get a bulk onboarding flow to connect multiple channels in a single step.

New channel onboardings default to mention-only listen mode (0.5.49) — the bot responds only when @mentioned, not to every message.

Security Hardening​

• Keycloak client secrets for service-account clients rotate on every helm install/upgrade. keycloak.strictClientSecrets fails the install if dev placeholders are in use. (0.5.0)
• MongoDB strict-password gate: mongodb.auth.strictPasswords: true fails fast on placeholder rootPassword values. (0.5.0)
• SSRF protection in RAG web ingestors — non-public start and redirect URLs are blocked. (0.5.2)
• HMAC-SHA256 for catalog API keys (0.5.8) — keys stored at rest use HMAC-SHA256. Existing keys minted before 0.5.8 must be rotated.
• NoSQL injection fix in the GridFS store (0.5.48).
• Session silent-refresh tolerance — users are no longer forced out on transient refresh failures. (0.5.52)

Is This a Breaking Upgrade from 0.4.x?​

For most deployments: no. Stock 0.4.18 values.yaml is a drop-in upgrade. Keycloak, OpenFGA, and the Webex bot are all opt-in. The only behavioral notes:

Upgrade​

Pick the current patch from the releases page and use the Helm command in that release post. Each release post includes upgrade notes, Helm values diffs, and data migrations.

This post covers the full 0.5.x series. The 0.5 series is actively maintained — check the releases blog for the latest patch-specific changes.

Application for CNCF Sandbox. This post tracks the text merged in cnoe-io/ai-platform-engineering#904; copy each section into the corresponding field of the GitHub issue form when submitting.

Basic project information​

Project tagline​

CAIPE is an integrated, open source distributed multi-agent system and reference implementation for automating platform engineering and cloud native operations, with standardized protocols, built-in knowledge bases, curated platform skills, enterprise security, a rich UX, and multiple client integrations.

Project description​

Community AI Platform Engineering (CAIPE, pronounced "cape") is an open source distributed Multi-Agent System (MAS) developed under the CNOE (Cloud Native Operational Excellence) Agentic AI SIG. As platform engineering, SRE, and DevOps environments grow in complexity, traditional approaches often lead to operational delays, fragmented tooling, and developer friction. CAIPE addresses this by providing a secure and scalable persona-driven reference implementation that orchestrates specialized AI agents. Each agent integrates securely with platform tools such as ArgoCD, Backstage, GitHub, PagerDuty, Jira, Slack, and Kubernetes using standardized interoperability protocols.

Built on open source agentic SDKs and the latest open standards in inter-agent and tool communication such as A2A, MCP, and A2UI, CAIPE's architecture enables agents to be developed, deployed, and scaled independently while securely interacting with Kubernetes platforms, cloud native infrastructure, and operational tooling.

The platform includes a curated prompt and skills library evaluated for reliability in agentic workflows, a modern AI-native user interface for interacting with agents, the Agent Forge plugin contributed upstream to backstage/community-plugins for Internal Developer Portal integration, and a command line interface for automation and developer workflows. The system also includes enterprise-grade security with OAuth2 and JWT-based agent authentication and production-ready deployment patterns using Docker Compose and Helm charts.

CAIPE also provides extensible knowledge bases that support retrieval-augmented generation (RAG) and GraphRAG. These knowledge systems enable agents to reason over both unstructured documentation and structured relationships between systems, services, and operational data. In addition, CAIPE supports persistent agent memory, fact extraction, and recall. Agents can extract operational knowledge from workflows, incident investigations, and platform telemetry, store these facts in shared knowledge systems, and reuse them in future tasks.

This capability allows agents to maintain contextual awareness across workflows in Kubernetes and cloud native environments. For example, agents can recall prior incidents, service dependencies, deployment history, and troubleshooting outcomes when assisting with new operational tasks. This reduces repeated investigation and improves operational efficiency.

The platform also includes built-in tracing via OpenTelemetry-compatible tooling (Langfuse), evaluation pipelines, and workflow observability to ensure predictable and auditable automation. Curated platform engineering skills encode operational best practices for common tasks such as incident investigation, GitOps deployment workflows, and platform diagnostics.

CAIPE fills a gap in the cloud native ecosystem by providing a vendor-neutral and community-driven reference architecture for applying agentic AI to platform engineering and operations. It enables teams to automate complex workflows across multiple tools, reduce mean time to resolution (MTTR), and accelerate developer self-service while maintaining transparency, governance, and operational reliability within modern Kubernetes and cloud native platforms.

Project details​

Org repo URL​

https://github.com/cnoe-io

Project repo URL in scope of application​

https://github.com/cnoe-io/ai-platform-engineering

Additional repos in scope of the application​

• https://github.com/cnoe-io/agent-chat-cli — CLI client for A2A agent interaction
• https://github.com/cnoe-io/openapi-mcp-codegen — OpenAPI-to-MCP server code generator
• https://github.com/cnoe-io/cnoe-agent-utils — Shared Python utilities for CAIPE agents
• https://github.com/cnoe-io/community-plugins/tree/agent-forge-upstream-docker/workspaces/agent-forge — Agent Forge Backstage plugin (upstream contribution to backstage/community-plugins, published as @caipe/plugin-agent-forge on npm)

Website URL​

https://caipe.io/

Roadmap​

CAIPE's roadmap is developed openly through GitHub issues and community working groups and is tracked in the project roadmap board.

Project roadmap: https://github.com/orgs/cnoe-io/projects/9

Issues and feature discussions: https://github.com/cnoe-io/ai-platform-engineering/issues

Key roadmap themes include:

1. Agent ecosystem expansion Adding new agents for cloud native and platform engineering tools such as Crossplane, Backstage catalog, Prometheus/Grafana, and cloud provider services, along with a plugin registry for community-contributed agents.

2. Enterprise hardening Improving multi-tenancy, agent-level RBAC, audit logging, and policy-based guardrails using technologies such as OPA/Rego.

3. Evaluation and observability Expanding automated evaluation pipelines and integrating with observability platforms such as Langfuse and OpenTelemetry to measure agent reliability and workflow execution.

4. Knowledge systems Enhancing RAG capabilities with GraphRAG, ontology-driven entity extraction, persistent memory, and multi-source ingestion of organizational knowledge.

5. Standards alignment Continued alignment with emerging agent interoperability standards such as A2A and MCP, and integration patterns across the cloud native ecosystem.

6. Community growth Expanding contributors through working groups, improved onboarding, and community workshops such as CAIPE Labs.

Project documentation: https://caipe.io/

Contributing guide​

https://github.com/cnoe-io/ai-platform-engineering/blob/main/CONTRIBUTING.md

Code of Conduct (CoC)​

https://github.com/cnoe-io/governance/blob/main/CODE-OF-CONDUCT.md

Adopters​

https://github.com/cnoe-io/ai-platform-engineering/blob/main/ADOPTERS.md

Maintainers file​

https://github.com/cnoe-io/ai-platform-engineering/blob/main/MAINTAINERS.md

Security policy file​

https://github.com/cnoe-io/ai-platform-engineering/blob/main/SECURITY.md

Standard or specification?​

N/A. CAIPE is not a standard or specification. It is a reference implementation that builds on existing open protocols—specifically Google's Agent-to-Agent (A2A) protocol and Anthropic's Model Context Protocol (MCP)—to provide a practical, deployable multi-agent system for platform engineering.

Business product or service to project separation​

CAIPE originated as an open source initiative within the CNOE (Cloud Native Operational Excellence) community, a CNCF-affiliated forum. While maintainers and contributors from multiple organizations including AWS, Cisco, Splunk, and Demandbase participate, CAIPE is not the upstream version of any commercial product. It operates under its own open governance within the CNOE Agentic AI SIG, with community-elected maintainers from multiple organizations. All development happens in the open on GitHub, and the project's roadmap is driven by community consensus. Contributing organizations may use CAIPE internally or build internal tooling on top of it, but the project itself is community-owned and vendor-neutral.

Cloud native context​

Why CNCF?​

CAIPE is built for and by the cloud native community. Joining the CNCF would:

1. Accelerate adoption: CNCF's neutral governance and brand recognition would attract a broader contributor and adopter base across the platform engineering ecosystem.
2. Strengthen interoperability: Being part of the CNCF landscape alongside projects like Argo, Backstage, Kubernetes, and Prometheus would formalize integration patterns and encourage co-development with these projects' communities.
3. Solidify community-driven development: CNCF governance provides a stable, vendor-neutral home that formalizes multi-organization maintainership and encourages broader community ownership of the project's direction.
4. Advance the ecosystem: Agentic AI applied to platform operations is an emerging area, and the current landscape lacks dedicated, production-quality projects focused on full platform operations—most existing efforts are scoped to individual tools with specific operational functions. CNCF hosting would signal to the industry that unified, AI-assisted platform operations is a serious discipline, and provide a focal point for best practices that span the entire cloud native stack.

The CNOE forum, which champions CAIPE, already operates within the CNCF ecosystem and many CAIPE contributors are active participants in other CNCF projects and TAGs.

Benefit to the landscape​

CAIPE benefits the Cloud Native Landscape by:

1. Bridging AI and cloud native operations: There is currently no CNCF project that provides a reference architecture for applying multi-agent AI systems to platform engineering workflows. CAIPE fills this gap.
2. Unifying tool interaction: Platform teams use many CNCF and adjacent tools (Argo, Kubernetes, Prometheus, Backstage). CAIPE provides a unified conversational and agentic interface across all of its integrated CNCF and adjacent tools, reducing context-switching and operational friction.
3. Pioneering protocol-based agent interoperability: By building on A2A and MCP protocols, CAIPE demonstrates how AI agents can be composed in a loosely coupled, cloud native manner—similar to how microservices communicate via gRPC/REST.
4. Advance credibility of AI in production: CAIPE serves as a proof point for applying AI to real platform operations, with enterprise security, observability, and deployment patterns built in—demonstrating that agentic AI can be trusted in production cloud native environments.

Cloud native 'fit'​

CAIPE is cloud native by design:

• Containerized: Every component (supervisor, sub-agents, UI, RAG services) runs as an independent container, deployable via Docker Compose or Kubernetes.
• Orchestrated: Helm charts provide production-grade Kubernetes deployment with configurable resource limits, HPA, health checks, and rolling updates.
• Microservices architecture: Sub-agents communicate via the A2A protocol over HTTP, enabling independent scaling, deployment, and lifecycle management.
• Stateless compute with external state: Agent state is managed via Redis (persistence) and Milvus (vector store), following cloud native patterns for state externalization.
• Observable: Integrated with OpenTelemetry-compatible tracing (Langfuse), structured logging, and health endpoints.
• Declarative configuration: Agent behavior, personas, prompts, and tool configurations are defined declaratively via common cloud native, GitOps-friendly practices.
• Infrastructure-agnostic: Runs on any Kubernetes cluster (EKS, GKE, AKS, on-prem) or locally via Docker Compose.

Cloud native 'integration'​

CAIPE complements and integrates with the following CNCF projects:

Cloud native overlap​

CAIPE is an AI agent orchestration system that defines contextual intent and abstracted workflows, and orchestrates agents and resources to perform operations in service of those workflows. It operates at a layer above individual platform tools—using them through agents rather than replacing them. For example, while Backstage provides a developer portal UI and Argo provides GitOps capabilities, CAIPE complements both by providing an intelligent, conversational interface on top of them. CAIPE can also be integrated directly with Backstage via the Agent Forge plugin.

The closest CNCF project in the agentic AI space is kagent, a sandbox project focused on running AI agents in Kubernetes and providing MCP server tooling (kmcp). CAIPE and kagent are complementary rather than overlapping. kagent provides a Kubernetes-native framework for deploying and running individual agents, while CAIPE operates at a higher layer - defining platform engineering workflows, orchestrating multiple agents across tools, and maintaining contextual knowledge and memory across operations. CAIPE could leverage kagent's Kubernetes runtime and MCP infrastructure as part of its deployment and tool integration layer.

Similar projects​

• kagent (CNCF Sandbox): A Kubernetes-native framework for running AI agents and MCP servers. kagent focuses on the runtime and deployment layer for individual agents, while CAIPE is an integrated system that provides multi-agent orchestration, abstracted platform engineering workflows, knowledge systems, and a full application layer (UI, CLI, Backstage plugin)—ready to deploy and use in platform engineering environments.
• LangGraph (LangChain ecosystem): A framework for building agent workflows. CAIPE uses LangGraph as its agent runtime but provides the full platform engineering application layer (agents, tools, deployment, UI) on top of it.
• Coding agents (Claude Code, Cursor etc.): Many coding agents can be configured to perform tasks similar to CAIPE, but they are personal, individual solutions rather than integrated systems designed for team-wide platform engineering operations.

No existing CNCF project provides an integrated multi-agent system that combines workflow orchestration, contextual knowledge, persistent memory, and a full application layer purpose-built for platform engineering operations.

Landscape​

CAIPE is not yet listed on the Cloud Native Landscape. We would anticipate placement alongside kagent under the same primary categories (Provisioning and Automation & Configuration) and the additional category CNAI / Agentic AI, as shown on kagent's landscape entry.

CNCF policies​

Trademark and accounts​

• If the project is accepted, I agree to donate all project trademarks and accounts to the CNCF

IP policy​

• If the project is accepted, I agree the project will follow the CNCF IP Policy

Will the project require a license exception?​

N/A. CAIPE is licensed under Apache 2.0, which is the standard CNCF license. All dependencies are compatible with the CNCF Allowlist License Policy.

Project "Domain Technical Review"​

[To be completed — the project has not yet engaged with a TAG for a formal presentation. We plan to engage with TAG App Delivery and/or TAG Runtime for a Domain Technical Review prior to the sandbox application review.]

Contact information​

Application contact email(s)​

cnoe-steering@googlegroups.com

Contributing or sponsoring entity signatory information​

If an organization:

Or, if an individual or individual(s):

Signatories for this application (individuals): Hasith Kalpage approves on the business side (Director). Natali Vlatko and Tim Swanson provide additional sign-off from Cisco OSPO. Legal approval: TBD.

Additional information​

Maintainers (reference)​

CNCF contacts​

• The CAIPE project is championed by the CNOE (Cloud Native Operational Excellence) community, which has established relationships within the CNCF ecosystem.
• Several CAIPE contributors are active in CNCF TAGs and working groups.
• Natali Vlatko (Director of Open Source Software Engineering, Cisco OSPO)
• Tim Swanson (Cloud Native & Open Source Advocate, Cisco OSPO)
• Josh Halley (CNAI TOC)
• Ricardo Aravena (CNAI TOC)
• Lin Sun (CNCF TOC)

Additional information​

Community engagement and traction:

• 316+ GitHub stars, 46+ forks, 3,055+ commits as of March 2026
• 32 releases with active development cadence (multiple releases per week)
• 77+ Architecture Decision Records documenting project evolution
• Weekly community meetings (CNOE Agentic AI SIG) with participants from multiple organizations
• Active Slack channel (#cnoe-sig-agentic-ai) on CNCF Slack
• Adopters include Outshift by Cisco, Splunk, and Demandbase
• Comprehensive documentation site with getting-started guides, architecture docs, and workshops (CAIPE Labs)

Technical maturity indicators:

• Extensive CI/CD pipeline with 30+ GitHub Actions workflows covering build, test, lint, security scanning, and release automation
• Conventional commits enforcement, automated dependency updates (Dependabot), and code ownership (CODEOWNERS)
• Helm chart with production-ready configuration for multi-node and single-node deployment modes
• Integration test suites for supervisor, multi-agent, and individual agent components
• Security policy with responsible disclosure process and GitHub Security Advisories

Governance:

• Governed by the CNOE Agentic AI SIG: https://github.com/cnoe-io/governance/tree/main/sigs/agentic-ai
• Open governance with community-driven roadmap and decision-making
• DCO (Developer Certificate of Origin) required for all contributions

Agentic Systems landscape is evolving rapidly, understanding the distinction between AI Agents and MCP Servers is crucial for building scalable agentic systems. While MCP Servers provide a standardized interface for tools and data sources, AI Agents leverage these capabilities to perform complex reasoning, planning, and execution tasks.

MCP​

MCP (Model Context Protocol) provides a standardized interface for LLMs to access tools and data sources.

Agent​

• Agents are systems that use LLM-based reasoning to plan and take actions—including invoking MCP tools when needed.
• Agents can handle complex tasks that could require multiple MCP tools and are capable of maintaining both short-term and long-term memory.
• Agents encapsulate more than simple tool calls to MCP servers, providing an additional abstraction layer.

Agent Composition & Capabilities​

• Tool Pruning: Optimizes the toolset for efficiency and relevance, including filtering tools from large MCP servers (with optional RAG for selection).
• Long-term and short-term memory management: Agents utilize short-term memory for session-specific context and long-term memory for cross-session data recall.
• Agent Registry: Manages agent versions and configurations.
• Prompty Library: Provides a versioned repository for managing and evaluating prompts.
• MCP Registry: Handles MCP server versions and configurations.
• Maintain Conversation Context: Preserves conversation history within a thread for more effective LLM reasoning and action.
• Prompt Engineering: Shapes agent behavior with well-designed system prompts.
• Evaluation: Validates agent actions using standardized rubrics and tool trajectory audits.
• Flexible LLM Bindings: Supports various LLM providers (e.g., GPT, Claude, Mistral).

This architecture makes agents composable, validated black-box units that can be reused across multi-agent systems and different personas.

Note: Agents built in CAIPE (Community AI Platform Engineering) project are exposed via the A2A protocol, standardizing external I/O and providing authentication and authorization support.

System Diagram​

Sequence Diagram​

export AGENT_NAME=foo

1. Clone the Target Monorepo (ai-platform-engineering)

cd /tmp
git clone git@github.com:cnoe-io/ai-platform-engineering.git

2. Clone agent-$AGENT_NAME to a temp location:

cd /tmp
git clone git@github.com:cnoe-io/agent-$AGENT_NAME.git agent-$AGENT_NAME-temp
cd agent-$AGENT_NAME-temp

3. Rewrite history to move everything into ai_platform_engineering/agents/$AGENT_NAME:

git filter-repo --to-subdirectory-filter ai_platform_engineering/agents/$AGENT_NAME

4. Now add this rewritten repo as a remote to your monorepo:

cd ../ai-platform-engineering    # Go back to your main repo
git remote add $AGENT_NAME-temp ../agent-$AGENT_NAME-temp
git fetch $AGENT_NAME-temp

5. Create a branch

git checkout -b migrate_agent_$AGENT_NAME

6. Merge the imported history (use --allow-unrelated-histories the first time):

git merge $AGENT_NAME-temp/main --allow-unrelated-histories

7. Clean Up (Optional)

git remote remove $AGENT_NAME-temp
read -p "Delete ../agent-$AGENT_NAME-temp and all contents? [y/N] " ans && [[ $ans =~ ^[Yy]$ ]] && rm -rf ../agent-$AGENT_NAME-temp

8. Upload branch and PR

git push origin migrate_agent_$AGENT_NAME