diff --git a/WORKING_GROUP.md b/WORKING_GROUP.md
index d25ba196e756..7b5416fb3be9 100644
--- a/WORKING_GROUP.md
+++ b/WORKING_GROUP.md
@@ -10,6 +10,37 @@ Please contribute to our meeting notes by opening a PR.
 2. Work Items
 3. Demos
 
+# Meeting notes (09/16/21)
+
+## Attendees
+- Prateek Gogia
+- Brandon Wagner
+- Alex Kestner
+- Ellis Tarn
+- Jason Haugen
+- Jerad Cramp
+- Jacob Gabrielson
+- Elmiko
+- Shaun
+
+## Announcements:
+- v1alpha4 Proposal is in [PR - MERGED](https://github.com/awslabs/karpenter/pull/676)
+
+## Notes:
+- [EL] Working on Cluster API provider for Karpenter. We have a management cluster and a workload cluster. Need to get a kubeconfig for the cloud provider to use in order to create Cluster API resources like MachineSets.
+- [JG] This is similar to the way AWS credentials are injected in Karpenter today with IRSA.
+- [ET] Yes, could use service accounts to inject the different kubeconfigs. Can also use the new cloud provider specific params to pass in more structured data to the cloud provider.
+- [EL] Is there a plan to be able to support more extensions or accelerators similar to the AWS Neuron implemention within Karpenter?
+- [ET] We need to rethink how custom cloud provider resources would work. But I think the current GPU stuff should probably be cloud provider specific rather than generic since it doesn't exist in upstream k8s.
+- [EL] Is the CloudProvider interface for returning Zones specifically for AWS or can any freeform string be returned to support other cloud provider concepts?
+- [ET] The Zones func is meant to be cloud provider agnostic, so the return string could be whatever makes sense for the cloud provider.
+- [EL] ClusterAPI cloud provider would increment a MachineSet right now. There might be some issues with multiple things touching the replica count of the sets, but starting with a simple model and see what breaks. 
+- [READING v1alpha4 proposal](https://github.com/awslabs/karpenter/pull/676)
+- [BW] How would the pluralization of Arch and OS work and why would we want to support Linux and Windows in the same provisioner? 
+- [ET] We would default to Linux and AMD64 most likely and then allow the user to configure if they'd like to expand the constraints to use both Arch's or OS. 
+- [BW] I don't think Windows would be a popular or practical choice if the pod could be run on Linux. But I can see how the semantics make it nice and uniform. I'm okay with the pluralization approach here. 
+ 
+
 # Meeting notes (07/22/21)
 
 ## Attendees