Most of what a team knows about its own product doesn't live in a spec. It lives in a PR from three months ago, a Linear ticket linked to a Slack thread, a Figma file shared by URL, a customer call where the real reason for a feature got mentioned in passing.
Every time someone picks up a new Brief — a teammate, a new joiner, an agent — the same questions come up: what do we already have, why does it work that way, what did we decide last quarter and why? When the answers are in reach, the work moves. When they're not, someone has to go find the person who remembers.
Knowledge is how Hamster keeps those answers in the room. Blueprints describe what's true about your product; Methods describe how your team works; the Context Graph links them to your real systems. Hamster drafts Blueprints from what you share and proposes updates as Briefs ship. Your team reviews them and steers the work.
Here, shared understanding becomes infrastructure: the next person on the work, teammate or agent, starts from what the team already knows instead of reconstructing it. That's what keeps the last 30% grounded in the team instead of improvised from a prompt.
Hamster Studio reads in both directions between English — Goals, Initiatives, Briefs, Blueprints, Methods — and the concrete artefacts in your real systems: code, Linear tickets, GitHub PRs, Figma frames, Notion pages, call transcripts.
Take a Brief from chat to a Plan to a pull request or merge request, and Hamster carries the work end to end. Update a Blueprint, and the next Brief that draws on it starts from the new picture. Mark a Brief done, and Hamster proposes Blueprint updates that reflect what shipped. Record Goal Results to track progress, and edit Methods as your team's conventions change.
That's why Briefs, Blueprints, Goals, and Initiatives aren't write-once documents. They give your team a shared description of the product and the work to do.
A Blueprint is an English representation of something stable in your business: a product, a system, a team, a process. It captures what is true today — not what you're changing, not how you do the work, just the current state.
When an AI agent (or a new engineer, or a new PM) picks up work, the same questions surface every time: what is this product, what does it do, what's the architecture, who uses it, what already exists. A Blueprint is the answer to those questions, written once and read by everyone — agent and human — every time a Brief gets refined.
Blueprints come in a few common shapes: product Blueprints describe what something does and who uses it; system Blueprints describe internal services and how they fit together; team Blueprints describe how a team operates. The hard rule: a Blueprint describes state, not change. Change lives in Briefs.
You don't usually write a Blueprint from scratch. Hamster drafts your first Blueprints from your company website and the documents you share during setup, or from a short conversation. When a Brief is marked done, Hamster checks your Blueprints against what shipped and proposes updates for your team to accept.
A Method is an instruction for how AI should help humans do a particular kind of work. It captures the way your team operates — how a Brief for a billing change should be written, how a database migration should be tested, how a design-system change should be reviewed.
An assistant becomes useful when it knows how your team operates. Methods bring your conventions into Briefs and Plans. Start from Hamster's library, save your own copy, or ask Hamster to write a new one for your team's convention.
Hamster ships with defaults — library Methods such as Hamster Direction, Hamster Discovery, and Hamster Delivery — that cover the most common patterns: how to write a Brief, how to Plan, how to deliver, how to handle PRs. New teams ship effectively with the defaults. When a convention emerges that the defaults don't cover (specific testing patterns, deploy procedures, design-system rules), you save a copy of a library Method into your workspace and add what's needed. Copy once at the workspace level; drift across per-team copies compounds.
The Context Graph is the connected, summarised view of everything your team has already accumulated — your code, your tickets, your design files, your docs, your conversations — linked together so AI can read across all of it at once.
Most context in a software team doesn't live in a spec. It lives in a PR from three months ago, a Linear ticket linked to a Slack thread linked to a Loom, a Figma file shared by URL, a Notion page that was right two months ago, a customer call where the real reason for a feature got mentioned in passing. The Graph is how the AI sees all of it without anyone moving it.
The Context Graph connects three layers: Hamster's own artefacts (Goals, Initiatives, Briefs, Blueprints, Methods); external context summarised from GitHub, GitLab, Cursor Origin, Linear, Slack, Figma, Notion, Google Drive; and the relationships between everything. The relationships are what makes the Context Graph useful rather than just exhaustive.
The Context Graph isn't tied to any specific tool. If your team uses Jira instead of Linear, swap the Connection. If you move off a tool entirely, your Blueprints, Methods, and Briefs stay in Hamster — what migrates is the Connection, not what you've built.
Knowledge stays available across every loop:
When Blueprints and Methods are in place, Briefs and PRs line up with how your team actually builds, and answers in Hamster Chat stay grounded in your real systems through the Context Graph.
The Context Graph is what populates Knowledge. Connect the systems where work already happens. Start with your code host (GitHub, GitLab, or Cursor Origin) and Slack, then add Linear or Jira, Figma, Notion, and Google Drive as your team needs them. Hamster drafts from that context, and your team steers what should become durable.