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. The assistant your team uses is general-purpose; the English layer inside Hamster is yours. Blueprints describe what's true about your product; Methods describe how your team works; the Context Graph links it to your real systems. Hamster drafts most of it from what your team is already doing — chats, PRs, tickets, calls — and your team steers it.
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 PR, and Hamster carries the work end to end. Update a Blueprint, and the next Brief that draws on it starts from the new picture. Sync a codebase or a Notion dump, and Hamster updates the Blueprint to reflect what's true; Goal Results roll forward; Methods catch up with how work has actually been done.
That's why Briefs, Blueprints, Goals, and Initiatives aren't write-once documents. They're a living English representation of your product — drafted by Hamster from what your team is already doing, kept current as work ships, read by humans and agents through the same surface.
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 generates a first draft from your Context Graph, your team shapes it to taste, and from then on the Blueprint stays current as the Context Graph notices code, tickets, and docs moving underneath it.
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 are how your conventions become part of every Brief, every Plan, every Delivery — drafted from how your team has actually been working, edited when you want a different default.
Hamster ships with a default — the Hamster Method — that covers 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 default. When a convention emerges that the default doesn't cover (specific testing patterns, deploy procedures, design-system rules), you fork the Hamster Method into your workspace and add what's needed. Fork once at the workspace level; drift across per-team forks 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, Linear, Slack, Figma, Notion, Google Drive, and the Meeting Agent; 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 GitHub and Slack, then add Linear or Jira, Figma, Notion, Google Drive, and the Meeting Agent as your team needs them. Hamster drafts from that context, and your team steers what should become durable.