Overview · Roko Platform Docs

Roko Platform is a collaboration platform for AI-native product teams. The team plans, discovers, blueprints, builds and measures its software in one place. Coding agents, your own or the platform's, work from the same written decisions as the people.

Why Roko Platform

AI makes each engineer faster, but on a team that runs a ticket-based lifecycle the gain rarely reaches the team's output. In that lifecycle, somebody writes a PRD, splits it into tickets, and hands each ticket from design to engineering to QA to ops. Nobody builds until the requirements are signed off, and every handoff adds queue time that a faster individual does not remove. When stakeholders react to a demo, the cycle starts again with new requirements and new handoffs.

Small, cross-functional feature and product teams work differently. They run discovery and implementation at the same time, every member has the full context, and they plan for rework and cleanup. Agentic development needs the same conditions: small units of work, a cleanup pass after each one lands, and enough context to prompt well. These teams turn the per-engineer gain into a team-level gain.

Roko Platform builds the lifecycle around that way of working:

	Ticket-based lifecycle	Roko Platform
Unit of planning	Atomic tickets that move from queue to queue.	Goals on a story map and a roadmap. A goal is an area of ownership with a named owner, who breaks it into tasks.
Requirements	Gathered and signed off before work starts.	Discovery runs next to delivery. A discovery goal answers an open question before the delivery goals that depend on it.
Discovery evidence	Spread across drives, chats and slide decks.	Prototypes, interview transcripts, research notes and diagrams sit in the project and link to the goal they answered. They record what the team learned at one point in time, and the platform does not keep them current. What lasts moves into the working model.
Decisions	A PRD and ADRs that drift away from the code.	The working model: six documents that act as a living PRD and ADR. Agents read it before they plan or write code.
Specification	The ticket description.	A change request records the intent, the schema and data model, and the decisions before anybody writes code. Another member reviews it.
Quality and security	QA and ops at the end of the funnel.	QA and security engineers are members of the team from the start. They write and review change requests, and they set the bar in the Quality Plan. Cron agents, such as the Security Auditor, add a scheduled check and propose change requests that the team reviews like any other.
Traceability	Tickets linked to commits by hand.	A change request links to its roadmap goal, and its implementation links to the pull requests, with who built it, with which model, and at what cost.

How the pieces fit

A project's sidebar groups its pages into five stages. Work moves through them in order, and what the team learns at the end feeds the next round.

1Plan
Decide what to build and when.
- Ideas
- Story maps
- Roadmap
- Board
2Discover
Find out what is true.
- Artifacts
- Prototypes
3Blueprint
Agree on the change.
- Working model
- Change requests
4Implement
Build and merge it.
- Implementations
- Agents
5Observe
See how delivery goes.
- Analytics
- Reporting
- Issues

Findings start the next round. People turn metrics and issues into ideas and change requests. Cron agents open change requests themselves.

The five stages are the groups in a project's sidebar, in the same order. Each card lists that group's pages.

Stage	What happens there
Plan	The team records ideas, lays out user journeys as story maps, and places goals on the roadmap, each with an owner. The Board shows the Roadmap's goals in columns by status.
Discover	The team answers open questions with interviews, prototypes and spikes, and links the evidence to the goal.
Blueprint	The team keeps its decisions in the working model and proposes each change in a change request before it builds.
Implement	Your own agent or a Platform agent builds an accepted change request and opens pull requests.
Observe	The team measures delivery, reports on goals, and tracks bugs and incidents. Cron agents propose change requests from what they find.

Above the stages, Setup lists what a new project still needs, Inbox collects what waits for you, and Playbooks holds the reference architectures.

The core objects

Object	What it is
Idea	A suggestion that nobody has decided on yet, numbered `IDEA-007`. It commits nobody to anything.
Goal	The decision to act on one area of the product. It has a kind, an owner or a pair of owners, a due date from its roadmap band, and tasks.
Story map	One user journey as stages. Each stage ranks the product goals that improve it.
Roadmap	One sheet of time bands. A goal's band sets its due date, and arrows show which goal must land first.
Artifact	A document or diagram, such as an interview transcript or research notes.
Prototype	An interface built to learn something about the product, in one or more flavors that the team comments on.
Working model	Six documents: Goals & Metrics, Users & Needs, Domain Model, Flows, Architecture and Quality Plan.
Change request	A written proposal, numbered `CR-12`. It carries spec sections, model changes to the working model, or both.
Implementation	The build of one change request, numbered `IMPL-4` and linked to its pull requests. `IMPL-4` and `CR-4` are usually unrelated.
Agent run	One run of a Platform agent, with its transcript, tokens and cost.
Issue	A bug or an incident.

A goal has one of four kinds. A product delivery goal builds something the user sees, and it always sits under a stage of a story map. An enabling delivery goal builds something the product or the system needs, such as a CI pipeline. A product discovery goal finds out what is true about an outcome the user sees, and an enabling discovery goal, such as a spike, does the same for what the system needs. The answer to a discovery goal changes the plan.

The big picture workflows

Set up a project

A new project opens in setup mode, with an amber banner on every page. The Setup page lists what the project needs before an agent can do useful work: a code host and repositories, a model provider, the team, and a first draft of each working model document. Your agent writes the first draft of all six documents on one change request, and the team reviews and merges it. See Seeding the working model.

From an idea to a goal

Anybody records an idea in a few seconds. Members upvote it, label it, and group it with related ideas. When the team decides to act, a person promotes the group to a goal. When the goal completes, the platform archives the group's ideas. See Idea capture.

Plan the product

The product manager lays out each user journey as a story map and ranks the goals under each stage. The top goal of each stage forms the walking skeleton. The product manager and the tech lead then place the goals on the roadmap, add enabling and discovery goals, assign owners, and draw dependencies. They replan at least once a week. See Story maps and Roadmaps.

Find out what is true

An open question becomes a discovery goal, placed in front of the goals it shapes. An agent runs the method: it prepares interviews, maps assumptions, or builds prototype flavors and publishes them to the platform. The team links the transcript or the prototype that answered the question to the goal. See Discovery.

Propose and review a change

When somebody knows what should change and why, their agent opens a change request. The change request carries spec sections that say how to build the change, and model changes when the team's reasons change too. Members comment, then Accept or Block. See Change requests.

Build it

An accepted change request gets an implementation. You choose who builds it:

Local. Your own agent builds it on your computer, opens the pull request, links it, and reports its token usage.
Single agent or Writer + Reviewer. A Platform agent builds it on the platform. With Writer + Reviewer, a second agent checks the diff before people see it.

The implementation completes when every linked pull request has merged. A person then marks the change request complete, and the platform merges its model changes into the working model. See Implementations.

Watch and improve

Analytics shows change request throughput, cycle time and part of the DORA set. Cron agents read the project on a schedule and open change requests for what they find, such as a missing test or a security weakness. People triage those like any other. See Background agents.

People and agents

Actor	Role
People	Own goals, review pull requests, and make every decision: promote, accept or block, and mark complete.
Your own agent	Works in the platform over MCP as you, with your permissions. It drafts change requests, seeds documents, builds prototypes, and builds Local implementations.
Platform agents	Build implementations on the platform, review diffs, and run on a schedule as cron agents. They propose changes through change requests and never edit the working model directly.

The platform serves its methods to agents over MCP. See Skills & Prompts.

Where to start

Foundational tooling

Install git and a coding agent, and learn to drive it.

Connect over MCP

Connect your agent to Roko Platform, so it can read and write your projects.

Seed the working model

Set up a new project and write the first body of each working model document.

Story maps

Plan the product as user journeys, then place the goals on the roadmap.