If you've ever had to answer "why does this user have access to X?"
in an AD environment, you know the pain: the answer usually lives
three or four nested groups deep, and the native tools don't show
you the path.
Whohas syncs your directory into Postgres and precomputes every
effective membership with the full path. Click a user, see every
group they're in and how they got there — direct, or via which
nested chain. Same the other way: click a group, see everyone with
access through it.
One design decision worth calling out: it stores one row per
distinct path, not per (user, group) pair. If someone reaches a
group through two different chains, you see both. That matters for
audits — "revoke access" is a different task if there are multiple
paths.
I’ve been experimenting with a simple idea: what happens if AI agents work more like a design team instead of a single assistant?
After reading “Patterns for Building AI Agents”, I got curious how multiple agents would handle creative work together. So I built a small canvas where different agents take on roles like design, copy, and layout.
Instead of one prompt, tasks are distributed. You can guide them, override them, or let them collaborate on the same canvas.
One thing I found interesting is that the process itself becomes useful. Not just the final design, but how the agents are set up. So you can share agent configurations and reuse different “design teams”.
It’s still an experiment. Sometimes this approach feels better than a single prompt, sometimes it doesn’t.
Would be curious to hear where you think something like this is useful, or where it feels unnecessary.
If you've ever had to answer "why does this user have access to X?" in an AD environment, you know the pain: the answer usually lives three or four nested groups deep, and the native tools don't show you the path.
Whohas syncs your directory into Postgres and precomputes every effective membership with the full path. Click a user, see every group they're in and how they got there — direct, or via which nested chain. Same the other way: click a group, see everyone with access through it.
One design decision worth calling out: it stores one row per distinct path, not per (user, group) pair. If someone reaches a group through two different chains, you see both. That matters for audits — "revoke access" is a different task if there are multiple paths.