Move from an AI assistant that suggests work to project agents that receive bounded missions, use approved tools, ask when blocked, and return results to the source of truth.
Product agent
Framing · execution · review
Mission
Prepare release mission
Project context
Implement MCP access
Review agent output
The project defines the goal and context. The agent performs a bounded mission. The team reviews the result and the workspace keeps the trace.
01
Give the agent a role, rules, tools, and project scope.
02
Turn a card into a mission with clear success criteria.
03
Run in the cloud, on a connected desktop, or through MCP.
04
Answer questions, inspect failures, and review proposals.
05
Keep useful outcomes, decisions, and memories in the workspace.
Mission STL-128
Give the agent a role, rules, tools, and project scope.
Checklist
Linked context
The agent receives the card, linked documents, project rules, and relevant workspace knowledge.
Every agent combines an identity, a role, an execution target, allowed tools, project context, and an autonomy policy. Capability is explicit rather than assumed.
The agent receives the card, linked documents, project rules, and relevant workspace knowledge.
Use cloud models, connected local CLIs, local servers, or an external MCP loop according to the mission.
Questions, refusals, timeouts, cancellations, tool failures, and final results remain visible to the team.
| Action | Human | Supervised | Approval |
|---|---|---|---|
| Read project context | Direct | Direct | Direct |
| Routine safe action | Direct | Direct | Proposal |
| Protected write | Direct | Proposal | Proposal |
| Unavailable capability | Visible error | Visible refusal | Visible refusal |
A useful project agent needs a bounded mission: expected result, available context, constraints, allowed tools, and a definition of done. The card provides that operational contract.
When information is missing, the agent can ask from the mission Activity instead of silently inventing a requirement.
A proposal is not an error or a side channel. It is a first-class state for work that needs human judgment before it changes the project.
The reviewer sees the requested action in context, decides, and preserves the result beside the original mission.
Detached AI assistant
Stellary project agent
Goal
Detached AI assistant
Answers the current prompt.
Stellary project agent
Works toward a defined card outcome.
Context
Detached AI assistant
Depends on what the user pastes.
Stellary project agent
Uses authorized project and document context.
Actions
Detached AI assistant
Suggests steps outside the system.
Stellary project agent
Uses allowed tools or creates proposals.
Trace
Detached AI assistant
History remains in a separate chat.
Stellary project agent
Questions, progress, and results return to Activity.
Depending on its tools and policy, an agent can read project context, prepare cards, execute missions, update allowed objects, ask questions, create proposals, and report completion or failure.
Yes. Stellary Desktop can connect supported CLIs such as Codex, Claude Code, and Cursor Agent, link a local repository to a project, and run eligible agent missions on that machine.
Limit its tool allowlist and project scope, then use approval mode for non-read actions. Supervised mode can reserve approval for protected tools while allowing routine safe work.
No. Documents and project state remain the shared source of truth. Memory can preserve useful agent-specific experience, but it should not hide important decisions from the team.
Start with a real card, explicit context, and the autonomy level you trust.
Create your first agent