Skip to main content
This walkthrough takes you from your first sign-in to a delivered outcome. Expect the setup to take a few minutes. How long delivery takes depends on what you ask for.
Kanaeru is in an invite-only closed beta, with no published pricing yet. To get an invite, join the waitlist on the Kanaeru Software Factory page. Your invite email has the link to sign in.
1

Sign in

Open the link in your invite and choose Sign in with Google or Sign in with Microsoft. Use the address your invite was sent to.No invite yet? Join the waitlist on the Software Factory page.On first sign-in you’ll:
  1. Read the closed beta terms and choose Accept and continue.
  2. Pick Your Primary Role. Kana uses it to decide which terms to explain to you.
You don’t need to set up an organization. It was created with your invite, so its name is already filled in.
2

Sign in your agent runtimes

Agents need a machine to run on. In the closed beta, Kanaeru gives you a cloud machine, created when you finish signing in. You don’t install anything, but the coding agents on it (the runtimes, such as Claude Code or Codex) need your sign-in for their model provider before they can work.
  1. Select your cloud machine. If it shows Asleep, choose Wake and give it about a minute.
  2. In Provider credentials, add access for each runtime you want to use: an API key, or a sign-in such as Sign in with ChatGPT for Codex.
  3. Watch Runtime checks. Each runtime you’ve given access turns from Needs setup to Ready.
As soon as at least one runtime is Ready, choose Continue to Kana to open the chat. You can add more runtimes later. See Runtimes for which providers each runtime accepts.
3

Connect GitHub

Open Profile from the user menu: select your name at the bottom of the left sidebar, then Profile. In the connectors section, choose GitHub and install the Kana GitHub App on the account or organization that owns your repositories. Kanaeru opens its pull requests through this app. See GitHub.
4

Create a workspace and describe your vision

Choose New Workspace and tell Kana what you want to build. Give it a Vision Title and a Description. For example:
  • Vision Title: Online Mafia for friends
  • Description: Six to ten friends play Mafia in a browser, with no installs and no accounts. One person creates a room and shares a link, everyone joins, and the game runs the night and day rounds, tracks who’s still in, and lets someone rejoin after their connection drops.
In the Context Sources step, attach what Kana should read: repositories, issues from GitHub or Linear, Slack threads, Notion pages, Figma files, and more from your connected services. A source can be a one-time snapshot or, for GitHub and Slack, live, so Kana sees new events as they arrive.Kana starts a Vision & Roadmap session. She asks questions where your description leaves gaps, then proposes a roadmap of items grouped into outcomes, such as “Join and play a round” and “Rejoin after a disconnect”. Items not yet in an outcome wait in the backlog. Open a refinement session at any time to reshape the roadmap with her.
See a real one: Nadia’s vision session, from idea to plan.
5

Kana plans the outcome

When an outcome starts, Kana runs a planning session for it. She splits the outcome into tasks. Each task covers one or more user journeys, and each journey carries its acceptance criteria (Given / When / Then scenarios) and its blueprints.Blueprints show what Kana understood before any code is written. They include live, clickable UX mockups of the real screens, user journeys, sequence diagrams, API contracts, data and domain models, architecture, state machines, and the tech stack with the reason for each choice. See Blueprints.Anything Kana isn’t sure about becomes an understanding gap, raised at the narrowest level it affects: one journey, one task, the task list, or the whole outcome. Routine gaps cover missing information, ambiguities, assumptions, and recorded decisions. Blocking gaps (risks, escalations, spec gaps, intent drift, comprehension checks, and context only you hold) must be resolved before execution. See Understanding gaps.
See a real one: Nadia’s planning session, from outcome to reviewable work.
6

Review the plan

Open the outcome on the Roadmap and expand Plan & Review. You review in three steps:
  1. Task Breakdown: are these the right tasks? Choose Approve Task Breakdown.
  2. User Journey List: does each task cover the right journeys? Choose Approve Journey List.
  3. Each journey: check its acceptance criteria and blueprints, then approve it and move to the next.
Answer understanding gaps in the Understanding Gaps panel at the level where they were raised.Start Outcome unlocks only when every check passes: tasks approved and requirements reviewed, every blueprint approved with no open blocking annotations, and no blocking gaps left. The last check is a quiz. In the review chat, Kana walks you through the plan, then asks three to five questions, and you need every one right. When you choose Start Outcome, confirm that you passed, then choose Confirm and start.
See a real one: Nadia’s review session, where the bug was caught before any code.
7

Let the agents build

As each task becomes ready, a task planning session designs its pipeline, and an independent reviewer checks it. The pipeline always has five phases: Biz Logic, API, UI, QA, and Deploy. Each phase has layers, such as domain and use cases in Biz Logic, and each layer runs two cycles:
  • Build: most layers write the code first, then the tests. Use cases are test-first. Every piece of generated code is lint-fixed right away.
  • Review and fix: a review step checks what was written, sends rejected work back to be fixed, and reviews it again. If it keeps failing, an escalation judge decides.
QA proves the task end to end. Deploy commits the work, runs a final review of the whole change, and opens a pull request. The agent then answers review comments and fixes CI until the pull request merges. Up to three tasks run at once. See Pipelines for the details.Watch it all in the Execution tab. If you’ve handed the outcome to Koa, he runs it for you and only escalates to your human inbox, Waiting on you, when a call is yours.
8

Ship the delivery

Each task pull request merges into the outcome’s own branch (outcome/<id>), so the outcome builds up in one place. When the last task merges, Kanaeru opens one delivery pull request per repository, from the outcome branch into your default branch. Review and merge it to ship the whole outcome. If you’d rather review another way, ask Kana. For example, she can stack task pull requests or merge each one straight into your base branch.Once it’s merged, the Execution tab shows Delivery is ready for sign-off. Choose Start retrospective.
9

Close the cycle with a retrospective

The retrospective covers what went well, what didn’t, and what it cost. Add at least one piece of feedback, check the evidence (tests, approvals, and whether what was built matches the blueprints you approved), then choose Accept delivery and complete outcome. What the retrospective learned goes into the next outcome.

​
Next steps

How Kanaeru works

The model behind visions, outcomes, and tasks.

Working with Kana

Chat, steer running agents, and answer questions.