Working with your agent

OrbitMap is where a conversation with an AI coding agent becomes shared work. You describe what you want in natural language; the agent checks the repository and context, then proposes the next decision. You keep ownership of the outcome and choices that affect people. The agent carries out the work and leaves a trail you can inspect in the app.

Start with a conversation

You do not need to learn a command or fill in a task form before you begin. Ask your connected agent what you want to achieve, for example:

I want new customers to invite a teammate without contacting support.
Help me work out the outcome and what is out of scope.

The agent may inspect code and documents before asking a question. It should ask only about decisions that change the result, one at a time, with a recommendation when options are clear. Say what to change, challenge a proposal, or ask to see more detail. The intent flow explains the moments where you approve an outcome, design and plan; it does not require you to narrate every step.

Your agent has an identity in OrbitMap. That identity tells the app which connected agent is writing the record; it is not your identity and it is not permission for the agent to decide the product direction. Your agreement, corrections and scope decisions are recorded as yours. The agent's implementation choices are recorded as the agent's. This distinction makes a later review understandable even when several people or agents have contributed.

What the app shows

As the conversation becomes work, OrbitMap creates an intent in the workspace. In the app, open the intent from the mission board or dashboard to see its outcome, design, plan, current status and the tasks underneath it. The board is the shared view: it does not depend on one chat window being open.

Tasks are units of agent work created from an agreed plan. You normally steer at the intent level rather than maintaining a hand-written task list. A task is useful when an agent can build and check that part independently; its instructions and tests give it a focused starting point. The app shows task status and which work is waiting for review. Inspect a task when you need to understand a particular change, without taking over routine decisions.

The work log is the memory of the work

The agent writes short entries as it works: decisions and their reasons, code changes, blockers, and notes that help resume a session. The app shows the task log and the intent log, so a decision that matters to the whole outcome does not disappear inside a terminal transcript. A blocked task can explain what it needs; a finished task can wait for your review.

When a session ends, the next connected agent can read the intent, its tasks and the recent log before continuing. You can also ask the agent to inspect the same work in a new conversation. This is why a short, reasoned log is more useful than copying a complete chat history.

Shared documents keep context useful

Documents are workspace memory: a decision, guide, specification or architecture note that the agent should not rediscover. An agent reads relevant documents and can update them when a completed change makes them stale. Documents can belong to one area or the whole workspace, so a cross-repository decision stays visible to every agent that needs it.

You can ask naturally:

Read the deployment guide before designing this change, and tell me
if the proposed flow contradicts it.

The app is the place to review the document and its history; the agent is the practical way to find the relevant section while working. See how work is organized for how repositories map to that shared context.

When context looks wrong

The agent's current folder determines which workspace and area the CLI resolves. If the app shows no intent you expected, or a task appears under the wrong repository, first check that the agent was started in the right folder. From that folder, the small diagnostic command below reports the resolved agent, workspace and area:

orbitmap context

This is a recovery check, not a command catalogue. If the folder has never been connected, return to getting started and run the guided init flow. init links the folder to a workspace, maps repositories as areas, and connects the agent identity chosen during onboarding. The app reflects that connection and its areas; it does not recreate the conversation or invent missing work. If a teammate clones the repositories, their agent key stays on their machine while the committed mapping lets them see the shared workspace.

If the context is correct but the work is not, open the intent's outcome and log in the app before asking the agent to continue. Correct the outcome or point to the relevant document in chat; the next session can then use the same shared record.

Keep steering, not bookkeeping

Use plain language for goals, constraints and questions. Let the agent turn an approved direction into tasks and updates, then use the app to review the same outcome, documents, statuses and decisions. The important record is the shared work in OrbitMap—not the particular terminal session that produced it.