Orbitmap Logo | Docs

The intent flow

An intent is a conversation with a useful memory. You bring the problem and the judgement about what matters. Your agent investigates, proposes and builds. At each gate, Orbitmap records the part that should survive the chat. The flow is the same whether you start in the app or ask your agent through the CLI.

This example follows a team that wants a new customer to create a workspace without asking support.

1. Brainstorm: agree on the promise

You start with a rough idea, not a specification:

I want trial customers to get from signup to a usable workspace on their own.
Help me work out what success should mean.

The agent checks the current workspace, mission and existing documentation before asking a focused question. It may point out that invitations and paid plans are different problems, then propose a short list of outcomes. You decide what the intent promises, what is out of scope and how you will recognise success.

Orbitmap records the accepted outcome on the intent. In the app, you can see the intent in the planning view and review the outcome as a shared contract. The agent does not quietly turn a vague request into a build plan while you are still deciding what “done” means.

2. Design: choose an approach

Once the outcome is clear, the agent reads the relevant areas and proposes a solution. It explains the choices that affect the outcome—for example, whether an unfinished signup is recovered by an email link or only saved in the browser.

Design this intent. Show me the meaningful options and recommend one for a
small team that wants the simplest reliable signup.

You approve, change or reject the approach. The agent writes the agreed design and the decisions behind it to the intent. The app gives those decisions a stable home; a later agent can read why an option was rejected instead of reopening the same discussion without context.

3. Plan: turn the design into buildable work

The agent now breaks the approved design into tasks, placing each task in the area where its work belongs. It checks that the tasks cover the outcomes and that the order makes sense. You are deciding whether the plan is a sensible way to deliver the promise, not naming every implementation step.

Plan the signup design. Show me the tasks, what each one proves, and anything
that depends on another task.

After you approve, the tasks become the agent's working queue. In the app you can move from the intent to its tasks and see how the plan maps back to the outcome. Through the CLI, the agent can inspect the same intent and continue from the task that is ready.

4. Execute: build and keep the record current

During execution, the agent works through the tasks, asks only when a choice would change the agreed intent, and records decisions or blockers that matter to the next person. You can ask for a progress summary without reconstructing it from a chat:

Continue the signup intent. Read its context first, work on the next ready
task, and tell me only if the design or outcome needs a decision.

Orbitmap keeps the tasks, work log and intent together. The app shows what is being worked on and what is ready for review; the CLI lets the agent read and update that record from the repository it is changing. Implementation details stay with the code. The work log is for decisions, discoveries and hand-offs that another session would otherwise have to guess.

5. Review: compare the result with the promise

When the planned work is complete, the agent checks the result against each outcome and asks you to review it. It reports what shipped, any decision made along the way and anything still blocked. The intent's app view gives you the same trail: outcome, design, tasks and record of work.

You decide whether the result is acceptable. If it is, merge or release it through your normal repository process, then ask the agent to close the intent. If an outcome was not delivered, keep the intent open or explicitly drop that outcome rather than letting the record imply success.

The signup work is ready. Summarise each outcome, point me to the evidence,
and leave the intent ready for my review.

Where the two interfaces fit

Use the app when you want to scan the mission, compare intents, inspect a plan or review the whole story. Use the CLI when your agent is working in a repository and needs the workspace context, the next task or a place to log a decision. They are two views of the same records, not two separate workflows.

You do not need to memorise every onboarding prompt. Follow onboarding to the connection step, run init in the workspace or repository, and let it connect the folder to the workspace and agent profile. The resulting mapping is what the CLI uses to resolve context; the connected workspace, areas and first mission then appear in the app. For the setup path, see Setup and troubleshooting.

Next

Download as Markdown