Relaunch payment flow
PSP + fallback, e2e on the critical path.
Stellary is a delivery workspace where projects, cards, documents, cockpit steering, automations, and specialized AI agents all operate on the same system of record.
Most teams are not looking for another AI surface. They want delivery, context, and execution to stop living in separate tools.
Projects, scopes, boards, cards, comments, attachments, labels, and field-level structure stay in the same operating model instead of being split across planning and documentation tools.
Specs, ADRs, briefs, notes, references, and templates can live at organization, workspace, project, or scope level, then link directly back to cards and missions.
Stellary is built around multiple agents with missions, proposals, approvals, and MCP access, not a single generic assistant tab bolted onto a board.
Cockpit brings priorities, missions, decisions, proposed actions, and portfolio-style signals into one place so leads can steer without rebuilding context in meetings.
Checkout relaunch
A project where humans and AI work inside the same system.
Recent activity
0 handoffsThe history fills up as soon as the AI starts changing the project.
AI mission
Product AIObjective
Relaunch checkout
Execution log
01/06Global view
72%
Delivered
2
Blocked
3
Green light
Decisions
Todos
A real board, not a mockup
The product makes more sense as one loop than as a flat feature list. A team usually moves through these layers in roughly this order.
Create or join an organization and workspace, invite the right people, and open the first project as the main delivery container.
Use scopes, cards, labels, fields, comments, and attachments to map work in a format both people and agents can execute against.
Link specs, ADRs, notes, and references directly to the relevant project or scope so context travels with the work.
Launch specialized agents on objectives or card-linked missions, review proposals, and keep sensitive actions under the right level of control.
Use cockpit, automations, MCP, and the REST API to steer work at workspace level and connect external systems without bypassing the model.
Before anything smart happens, Stellary needs a clean operating model: who is in the workspace, what they can access, and how a team gets a first project live.
Create a workspace, launch a first project, add context, and prepare the ground for agents or integrations. This is the fastest way to understand the product in motion.
See how organization, workspace, project, and pilotage roles fit together so people, agents, and reviewers do not all have the same reach by default.
This is the spine of the product: projects structure the work, cards carry execution, and documents keep the shared context close enough for both humans and agents to act on it.
Projects are the primary delivery container. Inside them, scopes group work, the board exposes views and workflows, and cards hold status, ownership, discussion, and custom structure.
Documents can live at organization, workspace, project, or scope level. They are linked into execution so context travels with cards, missions, and decisions instead of living in a detached wiki.
The wizard helps turn rough intent into a structured project draft with clearer scope, context, and next steps before the backlog hardens.
Project board
The card travels Todo → In progress → Done with a full execution trail.
Latest activity
Execution log
LiveLinked documentation
PSP primary route, card vault rules, fallback ladder when authorization is deferred.
Agent channel
…
…
Workspace patch
Watch agents execute on the board
This is where Stellary stops feeling like a standard project tracker. Agents, missions, cockpit, and approvals are built as operational flows on top of the same delivery model, not as side-panel chat.
Workspace agents can run direct objectives or card-linked missions, submit proposals where needed, and work inside explicit tooling and approval boundaries.
Cockpit aggregates the signals that matter for steering: priorities, missions, decisions, proposed actions, and portfolio-style views across the workspace.
Automations trigger repeatable actions inside the same delivery and context model, for example when a project reaches a state or when a recurring workflow should run.
Review
In review7 cards need a decision
The cockpit surfaces only what matters
External AI clients and service integrations should plug into the same workspace model as the UI, not tunnel around it. This is where MCP and the REST API matter most.
Connect Cursor, Claude Code, or another MCP client to the same workspace data and tools used by the product, with the same identity and mission model.
The API reference lists the real routes behind auth, workspaces, delivery, documents, agents, pilotage, billing, and MCP-related flows. It is the contract for custom integrations.
Different people should start in different places. These paths are usually more useful than reading every page in order.
Read this first if you want an honest view of what Stellary is optimizing for, what it is not trying to be, and whether the product is even a fit.
Open the docs hub if you already know you need Stellary detail, but you are not yet sure which guide matches your job to be done.
Start here if your first question is how projects, scopes, cards, fields, comments, and views work day to day in the product.
Read this if your main problem is fragmented context and you want to see how specs, notes, ADRs, and references stay attached to work.
Read this before turning Stellary into a serious multi-agent system. It covers agent setup, missions, proposals, memory, and approval behavior.
Use this if you want Cursor, Claude Code, or another MCP client to operate on the same workspace model as the product.
Go here when you need the route-level contract behind auth, workspaces, delivery, documents, agents, cockpit, billing, and MCP-related behavior.
Everything on this page works together in a single workspace. Start a project and see how agents, docs, and delivery connect.
Free during early access — no credit card required.