When will Composio app connections be enabled on Multica Cloud?

[gsayer]

Hi! I've been digging into the Composio integration and I'd love some clarity on its availability on the managed cloud.

What I can see from the repo:

• The full integration shipped around v0.3.36 (feat(composio): add standalone Go SDK client (MVP) #4603, feat(composio): server-side connect flow + connections REST (Notion MVP) (MUL-3720) #4608, feat(composio): inject MCP overlay into agent runtime at task dispatch (MUL-3721) #4704, feat(composio): per-agent allowlist + originator-scoped MCP overlay (MUL-3869) #4736, feat(agents): agent invocation permission system (MUL-3963) #4844…): hosted OAuth connect flow (Notion first), per-agent toolkit allowlist, and the per-task MCP overlay injected into agent runtimes.
• It's gated behind the composio_mcp_apps release flag (feat(composio): gate MCP apps behind feature flag #4876), and https://api.multica.ai/api/config currently reports "composio_mcp_apps": false — so it appears to be off on Multica Cloud.
• The v0.3.31 changelog teased it as a "foundation that prepares the upcoming third-party integrations", but no public announcement since, and the docs only cover the self-host env vars (COMPOSIO_API_KEY, …).

My questions:

1. Is there a rough timeline for enabling Composio app connections on the managed cloud?
2. When it lands, will it be GA for everyone or a gradual rollout?
3. Is anything specific blocking it (security review, pricing/quotas, toolkit coverage)?

For context: self-hosting with the flag on works, I'm mostly asking for cloud workspaces. Thanks for the great work — the per-agent allowlist + owner-scoped session design is really clean. 🙏

[ADanMan]

Re-checked this against current main and the live cloud config just now — nothing here has changed since you posted; the flag is still off and no PR has touched it since it shipped.

What's verifiable from the repo:

• composio_mcp_apps is a plain feature-flag gate, server/internal/featureflags/keys.go:20-25,74, default false. It gates two things together: the server-side Composio integration (server/cmd/server/router.go:993-1007 — only wired up when both COMPOSIO_API_KEY is set and the flag is on) and the frontend UI/access-picker (create-agent-dialog.tsx, PR fix(agents): gate create-agent access picker on composio_mcp_apps flag (MUL-4010) #4888).
• Toolkit coverage (which apps are connectable) isn't a code-level gate at all — the toolkit→auth-config mapping is resolved dynamically per project from Composio's /auth_configs at request time (router.go:1000-1003), so enabling a new toolkit on an already-enabled deployment is a dashboard action, not a redeploy.
• The flag itself is backed by server/pkg/featureflag (doc.go), which supports plain on/off and deterministic percent rollouts via env override (FF_COMPOSIO_MCP_APPS=42% etc., see env_provider.go). So the mechanism to do a gradual rollout exists in code — but there's no evidence in the repo of it being used that way for this flag specifically, and there's no committed config (no flag YAML in-repo) showing the current cloud value; that's set purely by cloud ops outside version control.
• I just hit https://api.multica.ai/api/config directly: "composio_mcp_apps": false, same as what you found on Aug 6. No drift.
• Your read on the docs is right too — environment-variables.mdx only documents the self-host COMPOSIO_API_KEY / COMPOSIO_CALLBACK_BASE_URL / COMPOSIO_STATE_SECRET vars; there's no public doc on the flag itself or a cloud-enablement date anywhere in apps/docs/.

What isn't answerable from the repo: the actual rollout decision (timeline, GA-vs-gradual, and whatever's blocking it — security review, pricing, toolkit scope) is a Multica Cloud ops/business call made outside this codebase; nothing in source, migrations, or docs encodes it. I'm an external contributor here too, not on the team running Cloud, so I don't have visibility into that decision either — this needs someone from the Multica team to answer directly.

One concrete thing worth clarifying in the meantime: since self-hosting with the flag already works for you, is Cloud specifically required for your case (e.g. no infra to self-host), or would a documented way to flip the flag on your own instance close the gap for now? That's useful context for whoever from the team picks this up.

[gsayer]

?