Hey team 👋 Nothing urgent here at all - hope you’re all having a great weekend and enjoying some downtime, I’ll just leave this thread here so you can share any thoughts whenever you have time.

Quick follow-up on the durable memory feature - I'll leave further detailed information inside the thread so as not to clutter the feed.

Hi @user, before I start the implementation https://github.com/archestra-ai/archestra/issues/3857 I'd like to confirm a few design choices that the issue doesn't make

explicit. The answers will significantly shape the PR.

1. Where should these settings live?

- Platform-level only - env vars / Helm values set by DevOps at deploy time (e.g. ARCHESTRAORCHESTRATORPERSONALK8SNAMESPACE,

ARCHESTRAORCHESTRATORPERSONAL_KUBECONFIG)

- Per-organization, configurable by admins via the UI (stored in DB)

- Per-team

- Per-user (each user configures their own)

The phrasing "through KUBECONFIG" suggests env/Helm, but I want to confirm.

2. One shared personal namespace, or one per user?

- A single shared namespace for all personal MCP servers across the org

- Namespace-per-user (e.g. personal-{userId}) for full isolation between users

3. Fallback behaviour when personal config is NOT set?

- Fall back to the current default namespace (no-op for existing installations, safe rollout)

- Hard-fail: installing a personal MCP server is rejected until the operator configures the personal target

4. What about existing personal MCP servers after the release?

- Leave them in the old namespace (no migration)

- Auto-redeploy them into the new namespace on next runtime startup

- Require manual reinstall

5. UI scope?

- No UI changes - env/Helm + docs only

- Read-only badge on personal MCP servers showing "deployed to namespace X / cluster Y"

- Full admin settings page to view/edit the personal target

6. PR scope you want to see?

- Backend runtime (manager, k8s-deployment, config) + tests + docs only

- Backend + UI badge

- Backend + full admin settings UI

Hey everyone! 👋

My name is Abdellah Bouarguan. I've been diving into Archestra recently and find the project and what you're building incredibly interesting!

I would love to work on the UI state desync and concurrency vulnerability (Issue #4030).

---

About me

---

Proposed approach

I’m looking to tackle this issue not just for the bounty, but as a practical architecture assignment for my engineering program.

My current plan to fix the double-execution race condition is:

- Using an "ON CONFLICT" write-lock

- Located in "chat-mcp-client.ts"

- Flip abandoned "approval-requested" states → "output-denied"

- Before DB persistence

---

Since the contributing docs highly recommend syncing with the core team first, I wanted to drop in and say hi!

Do you have any specific guides, architectural design choices, or feedback on this approach before I officially post my "/attempt" claim and spin up a PR?

Thanks!

Good Monday, everyone! 👋

Guys, do you have logo in .svg? I'd like to check a possibility of fix the size.

Hey everyone! Just joined and set up Archestra locally — really impressive project.

I've been going through the open issues and noticed the swap_agent bug in Slack/MS Teams (#4011). That caught my eye because I recently built a multi-channel AI bot with RAG and chatops integrations (Telegram + Discord), so I'm comfortable in that space.

Are there areas especially around agent triggers or chatops where the community could use more testing or bug reports? Happy to explore in and contribute properly.

Community call is tomorrow! See you!

Propose your agenda in 🧵

Hey! I noticed that when a tool result policy is blocked, the agent can confuse result blocking with call blocking. I could not find this mentioned in GH, looks like bug

New release! 🚀🚀🚀

Bug Fixes

---

This PR was generated with Release Please. See documentation.

New release! 🚀🚀🚀

Bug Fixes

---

This PR was generated with Release Please. See documentation.