The OrbitMap work model

OrbitMap gives a person and an AI agent a shared map of the work. You can talk to the agent in plain language, while the app keeps the outcome, decisions and open work in a place that survives the chat. The names below are useful when you need to find something or decide where a new piece of work belongs; they are not a form you have to fill in all at once.

Start with the level you need

Workspace is the team's shared home. It brings together the repositories, current focus, agreed outcomes and project memory. Use it when work crosses repositories or when you want to see the whole team rather than one codebase.

Area is the part of the workspace where implementation happens, usually one repository. An intent can span several areas, but each task belongs to the area whose code or files it changes. You normally do not choose an area in every conversation: after init, OrbitMap resolves it from the folder where your agent is working. In the app, areas make it clear which product or repository a piece of work touches.

Mission is the team's current direction for a limited period. It answers “what are we trying to move forward now?” Use one to keep several related intents together, for example “make the first week successful for new teams.” The mission is a lens over the workspace, not a second task list.

Intent is one outcome you are willing to stand behind. It might be “a new team can connect its repositories and reach its first useful view.” An intent holds the promise, the design agreed with you, the plan and the record of what happened. It is the right level when the work needs discussion or a decision that should not be rediscovered in another chat.

Task is a bounded piece of an approved intent that an agent can build and check. Tasks are created from the plan and placed in areas. You steer the intent; the agent uses tasks to carry it through. You do not need to turn every small thought into a task—use an intent when there is an outcome to agree on, and let the plan provide the smaller pieces.

What this looks like in the app

The workspace view gives you the broad picture: the active mission, intents and the areas connected to the work. The mission view groups the outcomes currently important to the team. An intent's planning view is where you can follow its outcomes, design, plan and work log; after the build, it becomes the place to review what was delivered.

The same records are available to your agent through the OrbitMap CLI. Run the agent from the workspace or an area folder after setting up the connection. Commands such as orbitmap context show what that folder resolves to. You can ask naturally:

Show me the active mission and the intents connected to it.

Find the intent about onboarding and tell me what is waiting for review.

The agent reads the shared records before proposing work, and writes accepted outcomes, decisions, tasks and useful hand-off notes back to the relevant record. That is why another person—or another agent session—can continue without relying on one conversation's memory.

A small example

Imagine a team improving its trial signup. The workspace contains the web app and billing service as two areas. The mission is “make the first week easy.” “Let a new customer create a workspace without support” is an intent. Its plan may produce tasks for the signup screen, the account endpoint and the welcome email, each in the area where that work lives.

If the agent asks whether an invite should expire after 24 or 72 hours, that is an intent-level decision: you answer once, and the choice remains visible with the design. If it asks which helper function to edit while executing a task, that is ordinary implementation detail. The distinction keeps OrbitMap useful for the decisions people need to see, without making you manage every line of the build.

Next

• The intent flow: how a conversation becomes reviewed work.
• Working with your agent: tasks, memory and hand-offs.