For Every Role

AI coding agents can handle more implementation work. People still decide what should be built, weigh tradeoffs, check results, and carry the reasoning forward.

The same workflow serves two groups: solo founders building with AI agents, and product teams where architects, developers, product managers, analysts, and stakeholders share the work.

The Workflow

Everything on an app board follows the same three steps.

Understand. The board is a current map built from the code itself. It contains systems, connections, aspects extracted from the repo, and insights from analysis.

Plan. Decide what should change and write it as an intent: a live spec anchored to the elements it concerns. It can start as an outcome ("customers can download past invoices") or as a concrete technical change. Either way, it joins the same queue.

Evolve. Developers pull that queue into their coding session with /intents, implement the change, and run /sync. The sync updates the board and verifies the intent's structural claims against the repo.

Use the section that matches how you work. The mechanics stay the same: the app board holds the map, intents hold the requested changes, and /sync brings the repo back into view.

Solo Founders

You usually start with a product direction, a repo, and AI agents helping with implementation. Use an app board as shared memory for the work: map the repo with the code plugin, write product bets as intents, and pull those intents into your coding session.

When an agent changes code, run /sync. The board updates from the repo, records what changed, and verifies structural claims in the intent. You keep the speed of agentic development without losing the map of what changed and why.

Product Teams

Architects, developers, product managers, analysts, and stakeholders usually split the work across people. They still use one board, one queue, and one verification loop.

Architects

You usually start with the map. Draw the system landscape and add a layer per system, or let the architect plugin or chat create it. Use the Hands-On path or Plugin or Chat path.

Then define the vocabulary. Archetypes define what a node is. Context tags define where it belongs. Together they make the landscape queryable: "every gateway in the identity domain", "services with no owning team".

Day to day, you read the canvas, aspects such as database schema and API surface, and insights. You also author intents. For cross-service work, keep the intent editor open while you navigate; it collects anchors from each board into one work item.

Use the architect workbench for work too large for chat: adopting a decision across apps, running a structured review, or working through a folder of RFCs.

Developers

You usually start inside your coding session. Open the service board and read its consumers, dependencies, and data stores before changing code (Boards Guide). For blast radius, open an insight's traced path in the Insights Bar. An analysis starts from chat or /insights.

You can then work the queue from the repo:

• /intents pulls handed-off work items into your session with their anchors and instructions. You claim, implement, verify, and resolve them.
• /skills compiles this app's compiled skills into the repo, so conventions and operating knowledge arrive as files.
• /sync sends the change back to the board and verifies structural intents, including yours and anyone else's.

The code plugin has every command and flag.

Product Managers and Business Analysts

You can start from outcomes without using technical vocabulary.

Write what should become true in the intent editor. Create intent on the Intents screen opens it blank.

The hub's intents card opens the same editor. While a session is running, it reads Open intent editor. Right-click a system to open the editor with that system already anchored.

While the editor is open, click the systems and screens involved. Describe what should happen in plain language; anchors attach without file names.

Use the Why field when the reasoning is worth keeping: the problem, the goal, and what is out of scope. It is optional. Many intents need only a line and a link, and they should stay quick to write.

Send the intent and follow it on the Intents screen. Lenses like To do and In progress filter the queue. When work comes back, read the resolution note. You can also ask chat to draft intents from insights or a bound PRD.

Stakeholders

Some people only need a reliable view. Publish a board and they can open a read-only, interactive URL without an account. Make it public, unlisted, or protected by a token, password, or both.

A PM can check the order steps. A new hire can read the auth path. An auditor can review the data stores without waiting for someone to export a diagram.

Roles are trust, not titles

Your organization role controls what an account can do. It does not define the kind of work that person does.

A business analyst and a principal engineer can both be contributors, with the same authority to author, hand off, and confirm intents. Individual boards can narrow access by being private and shared with named people. Permissions & Access explains how organization roles, board access, and published visibility combine.

One review is always required: human over machine. Anything a plugin run or chat proposes is created as a draft and waits for a person to hand it off.

Work can start as an outcome, promoted insight, captured board edit, or plugin filing. It still enters the same queue with the same lifecycle.

What's next