Quick distinction first. A Studio is like a folder. It’s just an organizational boundary where things live. Inside that folder, you can create multiple Pickaxes. Each Pickaxe is like an individual file. Studios are isolated by design, so they don’t talk to each other. The work and logic happen inside the Pickaxes.
Within the same Studio, Pickaxes can be chained or linked together and can share the same Knowledge Base. A single, well-designed Pickaxe is usually faster and simpler. Chaining multiple Pickaxes can give you clearer structure and guardrails, but it may add a small amount of extra processing time.
One Studio can have multiple Pickaxes under it, all working off the same Knowledge Base. I might be wrong, but it sounds like what you may need is either multiple Pickaxes inside the same Studio, or even one clean Pickaxe that handles different roles or levels of questioning.
If you’re open to it, I’d love to hear more about what you’re hoping to achieve by splitting this into multiple Pickaxes instead of keeping it as one. There may be a nuance I’m missing, and a bit more detail would help point you in the cleanest direction.
Thanks — that makes sense, and I appreciate the clarification around Studios vs Pickaxes.
One of the reasons I was keen on separating this into multiple Studios was user experience and cognitive load, rather than technical complexity.
At the operational level, I’m deliberately designing for:
• Very low overwhelm
• Minimal choice
• Clear, guided inputs
Whereas manager- and leader-level users naturally tolerate (and expect) more depth, interrogation, and optionality.
My concern with housing everything in a single Studio is that:
• Front-line users could still see a large number of Pickaxes or folders
• Even if they don’t use them, that visibility alone can feel cluttered or intimidating and hurt adoption
That said, I understand the current architectural constraint and I’m open to designing within it if there are ways to:
• Restrict visibility of Pickaxes by role or user type
• Present a clean, minimal entry point for operational users
• Ensure higher-level users can access richer tooling without exposing that complexity downstream
If there are recommended patterns for achieving progressive disclosure (simple front-end, powerful back-end) within a single Studio — whether through role-aware Pickaxes, entry-point Pickaxes that route users, or visibility controls — I’d really value your advice.
Ultimately, my goal is to preserve simplicity for front-line users while still enabling structured, hierarchical insight upstream.
