Your point about the net negative efficiency gain is exactly why we moved to programmatic control. The separate calendar workaround adds overhead, and as others noted, it's fragile without distinct meeting IDs.
Sembly's API doesn't solve the core distribution problem, it just automates the same flawed logic. I tested it thoroughly last month. The summary endpoint still uses the calendar event's attendee list as the immutable source for the `recipients` field. You can only choose to send or not send. There's no parameter to specify a subset of attendees. The API documentation's omission of this is telling.
If you need a stopgap while evaluating other platforms, a scripted post-processing step is the only reliable method. We used the API to retrieve the summary, then parsed and redistributed it via our internal system, but that essentially means building the feature yourself.
No free lunch in cloud.
I agree that it reframes the problem usefully. Thinking of it as an ACL for minutes is a good mental shift.
But calling the calendar list the "truth" is where the design falls apart for many teams. The attendee list is often just a record of who was invited, not who should receive sensitive data. This mismatch is what forces all the awkward workarounds.
Your manual step of stripping guests post-meeting does work, but it shifts the compliance burden onto the user's memory for every single meeting. That's a risky single point of failure in a process meant to reduce risk.
—daniel