A guide for admins setting up Hamster at a 50+ person product org. Multiple teams, multiple repos, often multiple business units. Existing engineering platform in place. Engineers already deeply embedded with Cursor, Claude Code, or other coding agents. Covers workspace topology decisions, integrating with your existing platform, setting Direction across the org, governing Methods at scale, and the audit and attribution model.
Under 50 people? How to use Hamster: Startups and mid-size companies is the right starting point. Want to try Hamster on a single brief first without the setup? See Just ship.
Running Hamster at scale
~4 minutes
Video coming soon
At scale, the first decision is workspace boundary. Hamster doesn't currently support cross-workspace nesting, so pick the boundary that matches how your delivery org actually runs.
The three common patterns:
You can move briefs between workspaces if you pick wrong, but it's not zero-cost. We recommend talking to us before locking topology — see Get in touch at the bottom of this page.
At this scale, configure connections at the organisation level rather than per-team where possible. Your Context Graph is what makes Blueprints, Briefs, and Methods work — and at scale, you want the graph reading consistently across your whole org, not stitched together per team.
See Connections overview for the full list.
At your scale, your engineers are deeply embedded with Claude Code, Cursor, Codex, or other coding agents. The MCP server plus the Hamster CLI give them your Context Graph, Briefs, Blueprints, and Methods inside their existing tool. Engineers ship from their IDE, with your team's accumulated context already loaded.
Two pieces every engineer installs:
We strongly recommend making MCP setup a step in your engineering onboarding. The IDE flow is what most of your engineers will use day-to-day, and it scales without forcing engineers into a new surface they didn't ask for.
A Cloud Agent is the configured environment Hamster runs deliveries in when nobody's hands are on a keyboard. At scale, configure one Cloud Agent per active repo per environment.
Cloud Agents complement the IDE flow rather than replacing it. They're how PMs kick off deliveries from briefs without an engineer in the loop, how Routines run automated deliveries, and how parallel deliveries run across the team without queuing on engineer time.
Common patterns:
mobile-ios, mobile-android each get their own).Cloud Agents respect Hamster's permission model. Only Creators can configure Cloud Agents; Reviewers can read configurations but not trigger deliveries. For sensitive environments, use the Admin role to gate configuration changes. See Roles & permissions for the full model.
At this scale, you typically have many product surfaces. Each one deserves its own Blueprint — generated from your Context Graph, edited by the team that owns the surface, and used as the source of truth every Brief on that surface gets refined against.
Treat Blueprints as part of your platform documentation. Owners, review cadence, change control, the works. The benefit at scale is that Blueprints are connected to your real systems through your Context Graph, not lying in a wiki — they update in both directions as code changes and as new docs are authored.
For organisations with central architecture, security, or platform teams: have those teams own the cross-cutting Blueprints (security posture, infrastructure topology, compliance policies). Each product team's Blueprint inherits from the cross-cutting ones rather than restating them.
At enterprise scale, Direction usually runs at multiple altitudes — a company-level framework that boards and execs read against, plus team-level frameworks that product groups operate against quarter to quarter.
Common patterns:
Each Goal takes a metric and results per period. Initiatives link many-to-many to Goals (with optional weights), so a "Mobile launch" Initiative can roll up to both "Q3 launches" and "Mobile platform investment" Goals without forking work. Frameworks are versioned and switching them doesn't disturb the Initiatives, Briefs, Plans, or Tasks below.
The Methods Library is your team's AI playbook — the methods the AI reads from when it builds. At scale this is load-bearing: drift in your library means drift in every delivery, multiplied by your team count.
We recommend:
A platform team typically owns the workspace-level Methods Library fork at this scale, in the same way an internal-tooling team would own a CI configuration or a build system. Product teams contribute Methods up to the central fork rather than maintaining their own.
Top tip: Add an "Internal compliance and review gates" Method to your Library fork early. This is where security review requirements, audit logging, and PII-handling rules live; AI agents need them in the brief context, not pasted in by an engineer at delivery time.
Hamster doesn't replace your engineering platform. It sits on the spec layer above it.
| Surface | Hamster | Your platform |
|---|---|---|
| Brief / spec | Hamster | — |
| Plan | Hamster | (synced) |
| Tasks | (synced) | Linear / Jira |
| Code review | — | GitHub |
| CI/CD | — | GitHub Actions / Buildkite / Jenkins |
| Delivery agent observability | Hamster | — |
| Production observability | — | Datadog / Sentry / your stack |
| Customer signal | Hamster + Slack | Gong / Zendesk / your stack |
The pattern: keep your existing platform; let Hamster own the goals, initiatives, briefs, blueprints, and methods, plus AI delivery. The connections do the gluing. Most rollouts at this scale don't change anything in the existing platform — they add Hamster to it.
The loop — Discovery, refine, align, deliver — doesn't change at scale. What changes is the surface area each loop touches. Discovery at this scale still doesn't have to start in a Brief: spike code in a feature branch, ideate in Figma, run a Research Agent pass, hold an architecture review. Converge into a Brief when the shape is clear and alignment voters are ready.
Initiatives become the primary planning surface. Brief-level visibility doesn't scale past ~5 teams; Initiative-level does. Each Initiative links to one or more Goals, so company- and team-level Direction stays connected to the work in flight.
The pattern at scale:
At small scale, alignment happens in the room. At scale, it happens in the activity timeline and Slack alignment unfurls. Make sure every Brief has a clear set of required alignment voters before it moves to delivery; the brief-status flow gates this.
Routines automate "every time X happens, do Y" patterns. At scale, common Routines include:
At scale, who triggered what and when matters. Hamster provides:
If your security or compliance team needs more (audit log exports, retention policies, SOC 2 attestation), see below.
Hamster supports SSO via the major IdPs (Okta, Google Workspace, Microsoft Entra) on the Business plan and above. SOC 2 Type II attestation is available; reach out for the report.
For procurement processes, custom DPAs, security questionnaires, or VPC-isolated deployments: email [email protected] before procurement starts. We'll work it through case-by-case.