Velocity is the lifeblood of any company: it is a function of work delivered, in the right Direction. Discovery sharpens the bet; Delivery is where that bet becomes shipped reality — Initiatives that commit, Briefs that define scope, Plans and Tasks and PRs that land.
Delivery is where alignment becomes execution — owned workstreams, concrete scopes, and changes in repo that move the metrics you're tracking.
An Initiative is how a Goal becomes committed work. Each one says which Goal you're serving, who owns it, and how it's tracking — a clear line of sight from outcome to workstream.
Initiatives are where outcome talk becomes ownership talk. A Goal says "Activation should move from 30% to 60%". An Initiative says "Onboarding redesign, owned by Priya, targeting +20pp by end of Q2, tracking on time." When briefs roll up under an Initiative, you stop talking to your CEO about tickets and start talking about the bet you've committed to and whether it's working.
An Initiative can serve more than one Goal (with optional weights), and a Goal can be served by more than one Initiative — the link is many-to-many. State and health are tracked on the Initiative itself, and the bidirectional Linear and Jira sync keeps the existing rituals (stand-ups, sprint reviews) intact.
A Brief is the unit of "we're building this" inside an Initiative. It captures what's being built — the goal, the user need, the scope, the constraints, the design, the acceptance criteria — refined against the relevant Blueprints until humans and AI both agree on what done means.
Most teams don't have one place where the next thing being built lives. They have a Linear ticket, a Notion spec, a Figma file, a Slack thread, and an engineer's interpretation — five sources, none complete, all hand-translated when an AI agent or a new engineer picks the work up. A Brief consolidates that into one English document that the team and the AI both read from. Stakeholders comment on the Brief, the Plan derives from the Brief, the PR ships from the Brief.
The Brief is also the through-line from Discovery to Delivery. It doesn't start in Delivery — it starts as a hunch in chat, gets refined against the relevant Blueprints, and crosses into Delivery when the team votes the Brief ready and a Plan generates. The same artefact carries the work end-to-end, which is why every PR can trace back to the conversation that started it.
A Plan is a structured breakdown derived from the Brief: Tasks, subtasks, dependencies, and acceptance criteria. The Plan is mostly internal scaffolding — it gives the AI agent (and any human shipping the work) a deterministic path from Brief to PR.
You don't manage a Plan the way a PM would in a project tool. You glance at it once before delivery to make sure the agent understood the scope. If the Plan misses something, you ask in chat and Hamster regenerates it; no hand-editing required.
Tasks are what actually runs. The agent walks the Task list in priority and dependency order, marks each Task as it goes, and the run streams into the Brief's activity timeline so you can see where the work is at any moment.
Stacked together, the layers go from outcome at the top to shipped change at the bottom:
Goal ← Direction
Initiative ← what we're going to ship
Brief ← a deliverable chunk
Plan → Tasks → PR
Two paths run from the same Brief:
Both paths read from the same Briefs, Plans, and Blueprints, so you can switch on a per-Brief basis depending on what suits the work. Most teams use both — CLI/MCP for individual engineers who want to be in the loop on the agent's choices, Cloud Agents for everything else.