100xprompt scales from one developer to an entire engineering organization. The same agent that reads your codebase, edits code, and runs commands is shared across a team with common configuration, centrally managed permission policies, standardized models and tool connections, and deployment that fits how your organization works. This page maps how to adopt 100xprompt at scale. It covers collaboration, governance, model and provider management, and the choice between a managed and a self-managed setup.

​
Understand the mental model

Suppose your team already uses 100xprompt individually and you now want everyone working from the same guardrails. Each developer runs 100xprompt against a project. At team scale you layer shared configuration and policies on top: everyone inherits the same defaults, guardrails, and approved tools, and each developer keeps the local control that makes the agent safe to use.
Team settings layer rather than replace. Organization defaults apply everywhere; a project can tighten or extend them; and each session still asks before doing anything sensitive. Control flows down, and safety is preserved at every level.

​
See what you get at team scale

Shared sessions

Turn any working session into a shareable link so teammates can follow the agent’s reasoning, review a change, or pick up where a colleague left off.

Managed configuration

Ship a common 100xprompt.json with your defaults - models, rules, tool connections - so every developer starts from the same baseline instead of configuring by hand.

Permission policies

Define allow / ask / deny rules for what the agent may read, edit, and run, and roll them out consistently across the team.

Model & provider control

Standardize on the frontier models your organization approves, and constrain which providers are available.

Standard tool connections

Distribute a shared set of MCP connections, skills, and commands so everyone has the same trusted integrations on day one.

Flexible deployment

Choose a fully managed setup or run 100xprompt in your own environment for maximum control over data flow.

​
Collaborate with shared sessions and workspaces

Suppose a teammate solved a tricky task and you want to see how. A session is a complete record of that task: the request, the agent’s plan, the files it touched, the commands it ran, and the outcome. Sharing the session turns solo work into team work.

Review and hand off

Share a session link so a reviewer can see exactly what changed and why - no need to reconstruct the agent’s reasoning after the fact.

Onboard by example

New teammates learn your patterns by reading real sessions that solved real tasks in your codebase.

Standardize the setup

Check a project’s 100xprompt.json, AGENTS.md, and shared skills/commands into your repo so every clone of the workspace behaves identically.

Control the default

Set sharing to manual, automatic, or fully disabled to match your team’s norms - and unshare any session at any time.
Sharing is opt-in and reversible. You decide whether sessions are shared manually, automatically, or not at all, and a shared session can always be made private again. See Sharing for the full walkthrough.

​
Centralize configuration and policies

100xprompt reads configuration from layered sources. An organization sets sensible defaults; teams and projects refine them. Distribute a shared 100xprompt.json with a repository - or apply it at the machine level - and everyone starts from the same baseline.
Layers merge, and the more specific layer wins. A project can raise the bar the organization set. A session can never quietly weaken a policy - permission denials always hold.
Ship one configuration file with your models, rules, permission policy, and approved tool connections. Every teammate inherits it automatically when they work in the repository.

Permission policies in depth

See how allow / ask / deny rules and permission patterns give admins fine-grained control over what the agent may do.

​
Standardize models and providers

Pick the intelligence your team relies on and keep everyone on it. 100xprompt supports the leading frontier models across multiple providers, with the controls to hold the team to your approved set.
ControlWhat it does
Default modelSet the model the whole team uses for its primary work.
Small / auxiliary modelChoose a lighter model for routine tasks like titling and summarization.
Per-agent modelsAssign specific models to specialized agents and subagents.
Provider allow-listRestrict availability to only the providers your organization approves.
Provider deny-listDisable providers that would otherwise load automatically.
Managed credentialsPoint the team at organization-provided access instead of personal keys.
Standardizing on a default model and an approved provider list means a new engineer is productive on day one - no guesswork about which model to pick or which provider to sign up for.

​
Choose a deployment option

100xprompt fits how your organization prefers to operate - from a turnkey managed experience to a fully self-managed setup you run yourself.

Managed

The fastest path to value. Your team installs 100xprompt, signs in, and starts working with organization defaults applied. Ideal when you want minimal setup and maintenance.

Self-managed

Run 100xprompt within your own environment for maximum control over where work happens and how data flows. Ideal for organizations with strict data-handling requirements.
Choose managed when you want the least operational overhead and are comfortable with a standard setup. Choose self-managed when you need to keep tighter control over your environment and data flow, or must meet specific internal data-handling requirements. Both options share the same configuration and permission model, so policies you author apply either way.
Yes. Shared configuration, permission rules, model and provider controls, and rules files behave identically regardless of deployment option. You author policy once and it applies wherever your team runs 100xprompt.
Your configuration is portable. Because policies live in configuration your team already controls, you can adopt 100xprompt quickly and adjust your deployment approach as your requirements evolve.

​
Roll out to your team

Suppose you’re bringing 100xprompt to a pilot team and want a clean baseline before you widen access. Work through these steps in order.
1

Define your baseline

Draft a shared 100xprompt.json with your default model, approved providers, and a starting permission policy that reflects your risk tolerance.
2

Encode your conventions

Add an AGENTS.md rules file capturing your standards, review expectations, and any areas the agent should avoid.
3

Package trusted tools

Bundle the MCP connections, skills, and commands your team relies on so everyone gets the same integrations without manual setup.
4

Choose a deployment option

Decide between managed and self-managed based on your data-handling needs, then roll out to a pilot team.
5

Expand with confidence

Use shared sessions to review outcomes, refine policy from what you learn, and widen access across the organization.
Tips:
  • Start the permission policy strict and loosen specific rules as the pilot builds trust.
  • Keep the shared 100xprompt.json and AGENTS.md in your repo so every clone behaves the same.
  • You author policy once - it applies whether the team runs managed or self-managed.
Keep secrets out of configuration and rules files that you distribute. Provide credentials through approved access rather than committing keys. See Security & privacy for how credentials are handled and protected.

Sharing

Share sessions for review, handoff, and onboarding.

Security & privacy

The safety model, credential handling, and admin controls.

Permissions

Author allow / ask / deny rules for what the agent may do.