Agenda for Core Maintainers meeting 20260108

core-maintainers/2026-01-08.md

@@ -0,0 +1,60 @@
+# Core Maintainers Meeting - 2026-01-08
+
+## Attendees
+
+- @benbrandt
+- @agu-z
+- @rtfeldman
+- @ignatov
+- @anna239
+- @nikomatsakis
+
+## Agenda
+
+- **RFDs**
+  - [ACP Agent Registry](https://github.com/agentclientprotocol/agent-client-protocol/pull/289) (@ignatov)
+    - https://github.com/agentclientprotocol/registry
+    - Can we reuse this format for Zed extensions?
+      - Either translate to them, or use registry as another way to load them
+      - Ideally Zed would just use the registry
+    - Better update lifecycle
+      - Do we pin to a version?
+      - Either cron job to update to new versions
+      - Or submodule process
+    - Should we keep only the pointer to the latest?
+      - Should we keep track of history of all versions?
+    - Tied to auth updates so it is smoother to login to all of these agents
+    - Would be nice to have some basic way to track downloads
+      - Have some website/backend that people hit so we can add some custom logic
+    - For launch it should be somewhere on the main domain/seperate domain, but more official
+  - [Authentication flow for agents](https://github.com/agentclientprotocol/agent-client-protocol/pull/330/files) (@anna239)
+    - Agent managed: push button, agent manages it itself
+    - terminal auth: \_meta property, promote it
+      - restricted to the agent binary, don't allow the command somehow
+      - only allow additional args to the normal acp mode
+    - ability for the user to provide a key
+      - Does it require a restart or not?
+      - Not possible at the moment to know if the env is supposed to be there
+      - Allow the client to know if this is even supplied, if not, it can restart the process with that variable and automatically call the auth method for the user
+      - Agent still only uses this env variable when the auth method is called
+    - Will be better to keep this (as it currently is) within the protocol and not the registry to allow for more flexibility
+    - Would be nice to support alternate providers outside config files, maybe not related to auth flow
+    - Allow for types and client / agent can filter based on capabilities
+    - MCP Elicitation flows useful especially for remote agents
+  - [Symposium](https://github.com/agentclientprotocol/agent-client-protocol/pull/359) (@nikomatsakis)
+    - Provide extensions to agents that are more powerful than just an MCP server using the proxy mechanisms
+    - In the long run, parts of this would be better housed within a specific language org, but parts of it are the glue that allows for these sorts of extensions
+    - Provides capabilities for both adding deterministic and non-deterministic flows that don't always have to go through the agent like MCP, "superset of MCP", more portable and work in any editor
+    - Skills will likely replace many MCP servers. ACP Extensions could do this that works well across agents
+      - Ideally user just decides what they want the agent to do better, doesn't matter if they are skills, mcp servers, etc
+  - VSCode extension (@nikomatsakis)
+  - [Session Config Options](https://agentclientprotocol.com/rfds/session-config-options) - Prepping for Preview (@benbrandt)
+- Naming of ACP
+  - Lots of SEO competition, or confusion with the other ACPs
+  - Need to gather pros/cons and structure/framework before meeting so we can have a productive meeting
+  - Even using full-name and non acronym is a choice
+
+## Action items
+
+- [ ] Prep a productive naming discussion
+- [ ] [@benbrandt] Zed plan for registry