Knowledge — shared understanding across your tools

Knowledge is the foundation Direction, Discovery, and Delivery all build on — Blueprints, Methods, and your Context Graph — so AI and humans reason from the same facts and conventions, in the product instead of pasted into every chat.

Here, shared understanding becomes infrastructure: what's true about the product, how your team works, and what's connected in your stack.

Blueprints — what's true today

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, you edit what's wrong, and from then on the Blueprint stays current as the Graph notices code, tickets, and docs moving underneath it.

Methods — how your team works

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.

Generic AI loses; AI that knows how your team operates wins. Methods are how your team's way of working becomes part of every Brief, every Plan, every delivery, without anyone re-explaining it on each piece of work.

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.

Context Graph — the connective tissue

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 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 Graph useful rather than just exhaustive.

The 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.

How Knowledge gets used

Knowledge is referenced, not consumed:

  • When you start a Brief, the relevant Blueprints come along automatically.
  • When AI ships a PR, it's already read your Methods.
  • When you ask a question in chat, your Context Graph is doing the lookup behind the answer.

When Blueprints and Methods are in place, Briefs and PRs line up with how your team actually builds, and answers in chat stay grounded in your real systems through the Context Graph.

Two-way translation lives here

Hamster Studio translates in both directions between English (Goals, Initiatives, Briefs, Blueprints, Methods) and concrete artefacts in your real systems (code, Figma frames, Linear tickets, GitHub PRs, Notion pages, call transcripts).

  • Write English in a Goal, an Initiative, or a Brief, and Hamster translates it into the concrete artefacts that ship — a Plan, a PR, a spec, a delivery.
  • Sync a codebase, a Notion dump, a Linear board, or a Figma file, and Hamster translates it back into English — the Blueprint updates to reflect what's true, Goal results roll forward, Methods learn from how work has actually been done.

This is why Briefs, Blueprints, Goals, and Initiatives aren't write-once documents. They're a living English representation of the business that you can edit; the software follows.

Where to start

The Context Graph is what populates Knowledge. Connect tools and Hamster does the work — start with GitHub and Slack, then add Linear or Jira, Figma, Notion, Google Drive, and the Meeting Agent as your team needs them.

Where to go next