stagent 0.3.1 → 0.3.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/cli.js +2 -0
- package/docs/.last-generated +1 -0
- package/docs/features/agent-intelligence.md +60 -0
- package/docs/features/chat.md +119 -0
- package/docs/features/cost-usage.md +61 -0
- package/docs/features/dashboard-kanban.md +73 -0
- package/docs/features/design-system.md +73 -0
- package/docs/features/documents.md +76 -0
- package/docs/features/home-workspace.md +66 -0
- package/docs/features/inbox-notifications.md +67 -0
- package/docs/features/keyboard-navigation.md +62 -0
- package/docs/features/monitoring.md +59 -0
- package/docs/features/playbook.md +57 -0
- package/docs/features/profiles.md +57 -0
- package/docs/features/projects.md +67 -0
- package/docs/features/provider-runtimes.md +49 -0
- package/docs/features/schedules.md +68 -0
- package/docs/features/settings.md +85 -0
- package/docs/features/shared-components.md +78 -0
- package/docs/features/tool-permissions.md +57 -0
- package/docs/features/workflows.md +81 -0
- package/docs/getting-started.md +141 -0
- package/docs/index.md +50 -0
- package/docs/journeys/developer.md +303 -0
- package/docs/journeys/personal-use.md +209 -0
- package/docs/journeys/power-user.md +248 -0
- package/docs/journeys/work-use.md +226 -0
- package/docs/manifest.json +240 -0
- package/package.json +2 -1
- package/src/app/api/environment/checkpoints/[id]/route.ts +3 -2
- package/src/app/api/environment/checkpoints/route.ts +2 -1
- package/src/app/api/environment/scan/route.ts +2 -1
- package/src/lib/agents/claude-agent.ts +3 -2
- package/src/lib/agents/runtime/claude.ts +4 -3
- package/src/lib/agents/runtime/openai-codex.ts +4 -3
- package/src/lib/chat/engine.ts +2 -1
- package/src/lib/chat/model-discovery.ts +2 -1
- package/src/lib/docs/reader.ts +11 -1
- package/src/lib/environment/scanner.ts +2 -1
- package/src/lib/environment/sync/mcp-sync.ts +2 -1
- package/src/lib/environment/sync-engine.ts +2 -1
- package/src/lib/environment/workspace-context.ts +6 -1
|
@@ -0,0 +1,81 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: "Workflows"
|
|
3
|
+
category: "feature-reference"
|
|
4
|
+
section: "workflows"
|
|
5
|
+
route: "/workflows"
|
|
6
|
+
tags: [workflows, patterns, sequence, parallel, swarm, autonomous, templates, multi-step]
|
|
7
|
+
features: ["workflow-engine", "workflow-blueprints", "ai-assist-workflow-creation", "workflow-context-batching"]
|
|
8
|
+
screengrabCount: 2
|
|
9
|
+
lastUpdated: "2026-03-21"
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
# Workflows
|
|
13
|
+
|
|
14
|
+
Workflows let you orchestrate multi-step agent operations using six built-in patterns. From simple sequences to parallel research fans and multi-agent swarms, workflows encode repeatable processes that agents execute with human checkpoints where you need them.
|
|
15
|
+
|
|
16
|
+
## Screenshots
|
|
17
|
+
|
|
18
|
+

|
|
19
|
+
*Workflow cards showing name, pattern type, step count, and status*
|
|
20
|
+
|
|
21
|
+

|
|
22
|
+
*Workflow detail page with step-by-step breakdown and execution status*
|
|
23
|
+
|
|
24
|
+
## Key Features
|
|
25
|
+
|
|
26
|
+
### Six Pattern Types
|
|
27
|
+
Workflows support six orchestration patterns:
|
|
28
|
+
- **Sequence** — Steps execute one after another in order.
|
|
29
|
+
- **Planner-Executor** — A planning step generates a plan, then an executor step carries it out.
|
|
30
|
+
- **Checkpoint** — Inserts a human-in-the-loop approval gate between steps.
|
|
31
|
+
- **Autonomous Loop** — Repeats a step until a stop condition is met (max iterations, goal reached, error threshold, or timeout).
|
|
32
|
+
- **Parallel Research** — Fans out multiple steps to run concurrently, then merges results.
|
|
33
|
+
- **Multi-Agent Swarm** — Multiple agent profiles collaborate on a shared objective with dynamic handoffs.
|
|
34
|
+
|
|
35
|
+
### Tabs: All, Templates, Runs
|
|
36
|
+
The workflow page organizes content into three tabs. "All" shows every workflow. "Templates" shows reusable patterns you can instantiate. "Runs" shows active and historical executions with their current status.
|
|
37
|
+
|
|
38
|
+
### Workflow Cards
|
|
39
|
+
Each workflow card displays the name, pattern type, step count, and current status. Click a card to open the detail view.
|
|
40
|
+
|
|
41
|
+
### Workflow Detail Page
|
|
42
|
+
The detail view shows the full step-by-step breakdown of a workflow, including each step's name, instructions, assigned agent profile, runtime, and execution status. For running workflows, you can see which step is currently active.
|
|
43
|
+
|
|
44
|
+
### Step Builder
|
|
45
|
+
The creation form includes a step builder where you define each step with a name and instructions. Each step can be assigned a specific agent profile and runtime, enabling mixed-agent workflows.
|
|
46
|
+
|
|
47
|
+
### Templates
|
|
48
|
+
Save workflows as templates for reuse. Templates preserve the pattern type, steps, and configuration — instantiate them later with a single click, optionally overriding specific parameters.
|
|
49
|
+
|
|
50
|
+
## How To
|
|
51
|
+
|
|
52
|
+
### Create a New Workflow
|
|
53
|
+
1. Navigate to `/workflows` and click "New Workflow."
|
|
54
|
+
2. Enter a name and select a pattern type (e.g., Sequence, Checkpoint).
|
|
55
|
+
3. Optionally link the workflow to a project.
|
|
56
|
+
4. Use the step builder to add steps — each step needs a name and instructions.
|
|
57
|
+
5. Assign an agent profile and runtime to each step as needed.
|
|
58
|
+
6. Click "Create" to save the workflow.
|
|
59
|
+
|
|
60
|
+
### Run a Workflow
|
|
61
|
+
1. Open the workflow detail page by clicking its card.
|
|
62
|
+
2. Click "Run" to start execution.
|
|
63
|
+
3. For Checkpoint patterns, you will be prompted to approve at each gate.
|
|
64
|
+
4. Monitor progress in real time on the detail page or in the Runs tab.
|
|
65
|
+
|
|
66
|
+
### Use a Template
|
|
67
|
+
1. Go to the "Templates" tab on the workflows page.
|
|
68
|
+
2. Click a template card to preview its configuration.
|
|
69
|
+
3. Click "Use Template" to create a new workflow instance from it.
|
|
70
|
+
4. Modify any steps or parameters as needed, then save.
|
|
71
|
+
|
|
72
|
+
### Monitor Workflow Runs
|
|
73
|
+
1. Navigate to the "Runs" tab to see all active and completed executions.
|
|
74
|
+
2. Click a run to see step-by-step progress and any agent output.
|
|
75
|
+
3. Failed steps display error details to help with debugging.
|
|
76
|
+
|
|
77
|
+
## Related
|
|
78
|
+
- [Dashboard Kanban](./dashboard-kanban.md)
|
|
79
|
+
- [Projects](./projects.md)
|
|
80
|
+
- [Profiles](./profiles.md)
|
|
81
|
+
- [Schedules](./schedules.md)
|
|
@@ -0,0 +1,141 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: "Getting Started"
|
|
3
|
+
category: "getting-started"
|
|
4
|
+
lastUpdated: "2026-03-21"
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Getting Started
|
|
8
|
+
|
|
9
|
+
Get Stagent running in under a minute and create your first governed agent task.
|
|
10
|
+
|
|
11
|
+
## Installation
|
|
12
|
+
|
|
13
|
+
### Quick Start (npx)
|
|
14
|
+
|
|
15
|
+
Stagent runs as a single command with no clone or build step required:
|
|
16
|
+
|
|
17
|
+
```bash
|
|
18
|
+
npx stagent
|
|
19
|
+
```
|
|
20
|
+
|
|
21
|
+
This downloads and launches Stagent on [localhost:3000](http://localhost:3000). All data is stored locally:
|
|
22
|
+
|
|
23
|
+
- **Database**: `~/.stagent/stagent.db` (SQLite with WAL mode)
|
|
24
|
+
- **Uploads**: `~/.stagent/uploads/`
|
|
25
|
+
|
|
26
|
+
### From Source
|
|
27
|
+
|
|
28
|
+
For contributors or developers who want full control:
|
|
29
|
+
|
|
30
|
+
```bash
|
|
31
|
+
git clone https://github.com/navam-io/stagent.git
|
|
32
|
+
cd stagent && npm install
|
|
33
|
+
npm run dev
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
### Requirements
|
|
37
|
+
|
|
38
|
+
- **Node.js 20+** required for the runtime
|
|
39
|
+
- **One or both AI provider credentials**:
|
|
40
|
+
- Anthropic API key or OAuth token (for Claude Code runtime)
|
|
41
|
+
- OpenAI API key (for Codex App Server runtime)
|
|
42
|
+
|
|
43
|
+
## First Run
|
|
44
|
+
|
|
45
|
+
When you open Stagent for the first time at [localhost:3000](http://localhost:3000):
|
|
46
|
+
|
|
47
|
+
1. **Home Workspace** appears with empty stat cards, an activity feed placeholder, and sidebar navigation
|
|
48
|
+
2. **Configure a runtime** by navigating to **Settings** to enter your provider credentials
|
|
49
|
+
3. **Test connectivity** using the **Test Connection** button in Settings to verify your runtime is reachable
|
|
50
|
+
|
|
51
|
+
The Home Workspace serves as your daily briefing with active work counts, pending reviews, and a live activity stream that populates as you create and execute tasks.
|
|
52
|
+
|
|
53
|
+
## Configuration
|
|
54
|
+
|
|
55
|
+
### Claude Authentication
|
|
56
|
+
|
|
57
|
+
Navigate to **Settings** to configure Claude access:
|
|
58
|
+
|
|
59
|
+
- **OAuth** (recommended) -- Uses your Claude Max or Pro subscription. No API key needed. Best for users with an existing Anthropic subscription
|
|
60
|
+
- **API Key** -- Enter your `ANTHROPIC_API_KEY` for direct API access. Useful for programmatic or metered usage
|
|
61
|
+
|
|
62
|
+
OAuth is the default authentication method and is recommended for most users to avoid unexpected API charges.
|
|
63
|
+
|
|
64
|
+
### Codex Runtime Setup
|
|
65
|
+
|
|
66
|
+
To enable the OpenAI Codex runtime alongside Claude:
|
|
67
|
+
|
|
68
|
+
1. Navigate to **Settings**
|
|
69
|
+
2. Enter your `OPENAI_API_KEY` in the OpenAI section
|
|
70
|
+
3. Click **Test Connection** to verify the Codex App Server is reachable
|
|
71
|
+
4. Once connected, you can select Codex as the runtime when creating or executing tasks
|
|
72
|
+
|
|
73
|
+
### Budget Configuration
|
|
74
|
+
|
|
75
|
+
Control AI spending from **Settings**:
|
|
76
|
+
|
|
77
|
+
- Set monthly or per-task budget limits
|
|
78
|
+
- View token usage breakdowns by provider
|
|
79
|
+
- Enable budget guardrails that pause execution when thresholds are reached
|
|
80
|
+
- Monitor cumulative spend on the **Cost & Usage** page (`/costs`)
|
|
81
|
+
|
|
82
|
+
### Tool Permissions
|
|
83
|
+
|
|
84
|
+
Agents request permission before using tools. Streamline approvals from **Settings**:
|
|
85
|
+
|
|
86
|
+
- **Always Allow** -- Save patterns for tools you trust (e.g., `Read`, `Bash(command:git *)`)
|
|
87
|
+
- **Presets** -- Enable read-only, git-safe, or full-auto permission bundles
|
|
88
|
+
- **Per-request** -- Review and approve individual tool calls from the **Inbox**
|
|
89
|
+
|
|
90
|
+
### Seed Sample Data
|
|
91
|
+
|
|
92
|
+
To explore Stagent with example data before creating your own:
|
|
93
|
+
|
|
94
|
+
1. Navigate to **Settings** then **Data Management**
|
|
95
|
+
2. Click **Seed Sample Data**
|
|
96
|
+
3. This creates sample projects, tasks, and workflows you can browse and execute
|
|
97
|
+
|
|
98
|
+
## Creating Your First Task
|
|
99
|
+
|
|
100
|
+
1. Navigate to **Dashboard** (`/dashboard`) to see the kanban board
|
|
101
|
+
2. Click **Create Task** to open the task creation form
|
|
102
|
+
3. Enter a title and description for your task
|
|
103
|
+
4. (Optional) Click **AI Assist** to get an improved description, complexity estimate, and suggested agent profile
|
|
104
|
+
5. (Optional) Assign a project, select an agent profile, or attach documents
|
|
105
|
+
6. Click **Create** -- your task appears in the "Planned" column
|
|
106
|
+
7. Click the task card to open its detail view, then click **Execute** to dispatch it to an agent
|
|
107
|
+
8. Watch the **Monitor** page (`/monitor`) for live execution logs
|
|
108
|
+
9. Check **Inbox** (`/inbox`) for any tool approval requests the agent sends during execution
|
|
109
|
+
|
|
110
|
+
## CLI Usage
|
|
111
|
+
|
|
112
|
+
Stagent includes a CLI for headless and scripted workflows:
|
|
113
|
+
|
|
114
|
+
```bash
|
|
115
|
+
# Build the CLI from source
|
|
116
|
+
npm run build:cli
|
|
117
|
+
|
|
118
|
+
# Run the CLI
|
|
119
|
+
node dist/cli.js
|
|
120
|
+
|
|
121
|
+
# Or use the published package
|
|
122
|
+
stagent
|
|
123
|
+
```
|
|
124
|
+
|
|
125
|
+
### Useful Commands
|
|
126
|
+
|
|
127
|
+
| Command | Purpose |
|
|
128
|
+
|---------|---------|
|
|
129
|
+
| `npm run dev` | Start dev server with Turbopack |
|
|
130
|
+
| `npm run build:cli` | Build CLI to `dist/cli.js` |
|
|
131
|
+
| `npm test` | Run unit tests |
|
|
132
|
+
| `npm run test:coverage` | Generate coverage report |
|
|
133
|
+
| `npm run test:e2e` | Run end-to-end integration tests |
|
|
134
|
+
|
|
135
|
+
## What's Next
|
|
136
|
+
|
|
137
|
+
- [Personal Use Guide](./journeys/personal-use.md) -- Solo productivity walkthrough
|
|
138
|
+
- [Work Use Guide](./journeys/work-use.md) -- Team operations and document management
|
|
139
|
+
- [Power User Guide](./journeys/power-user.md) -- Advanced workflows and automation
|
|
140
|
+
- [Developer Guide](./journeys/developer.md) -- Platform configuration and extending Stagent
|
|
141
|
+
- [Feature Reference](./index.md) -- Browse all features by section
|
package/docs/index.md
ADDED
|
@@ -0,0 +1,50 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: "Stagent Documentation"
|
|
3
|
+
category: "index"
|
|
4
|
+
lastUpdated: "2026-03-21"
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Stagent Documentation
|
|
8
|
+
|
|
9
|
+
Stagent is a governed AI agent workspace that lets you create, execute, and monitor AI-powered tasks locally. It provides supervised execution with human-in-the-loop approvals, multi-step workflows, document management, and cost governance across multiple AI providers.
|
|
10
|
+
|
|
11
|
+
## Getting Started
|
|
12
|
+
- [Quick Start Guide](./getting-started.md)
|
|
13
|
+
|
|
14
|
+
## User Journeys
|
|
15
|
+
|
|
16
|
+
| Guide | Difficulty | Time | Description |
|
|
17
|
+
|-------|-----------|------|-------------|
|
|
18
|
+
| [Personal Use](./journeys/personal-use.md) | Beginner | ~20 min | Solo productivity with AI tasks |
|
|
19
|
+
| [Work Use](./journeys/work-use.md) | Intermediate | ~24 min | Team collaboration and document management |
|
|
20
|
+
| [Power User](./journeys/power-user.md) | Advanced | ~24 min | Advanced workflows and automation |
|
|
21
|
+
| [Developer](./journeys/developer.md) | Advanced | ~20 min | Platform configuration and CLI usage |
|
|
22
|
+
|
|
23
|
+
## Feature Reference
|
|
24
|
+
|
|
25
|
+
| Section | Route | Key Features |
|
|
26
|
+
|---------|-------|-------------|
|
|
27
|
+
| [Home & Workspace](./features/home-workspace.md) | `/` | Stat cards, activity feed, navigation |
|
|
28
|
+
| [Dashboard & Kanban](./features/dashboard-kanban.md) | `/dashboard` | Task board, AI Assist, drag-and-drop |
|
|
29
|
+
| [Inbox & Notifications](./features/inbox-notifications.md) | `/inbox` | Approvals, rich content, progressive disclosure |
|
|
30
|
+
| [Chat](./features/chat.md) | /chat | Conversations, model selection, suggested prompts, Quick Access |
|
|
31
|
+
| [Projects](./features/projects.md) | `/projects` | Workspaces, task grouping, file context |
|
|
32
|
+
| [Workflows](./features/workflows.md) | `/workflows` | 6 patterns, step builder, templates |
|
|
33
|
+
| [Documents](./features/documents.md) | `/documents` | Upload, preprocessing, agent context |
|
|
34
|
+
| [Monitor](./features/monitoring.md) | `/monitor` | Activity logs, execution tracking |
|
|
35
|
+
| [Profiles](./features/profiles.md) | `/profiles` | 21 agent profiles, auto-routing |
|
|
36
|
+
| [Schedules](./features/schedules.md) | `/schedules` | Recurring tasks, autonomous loops |
|
|
37
|
+
| [Cost & Usage](./features/cost-usage.md) | `/costs` | Spend tracking, budget guardrails |
|
|
38
|
+
| [Settings](./features/settings.md) | `/settings` | Auth, runtimes, permissions, budgets |
|
|
39
|
+
| [Playbook](./features/playbook.md) | `/playbook` | In-app documentation |
|
|
40
|
+
|
|
41
|
+
## Cross-Cutting Features
|
|
42
|
+
|
|
43
|
+
| Topic | Description |
|
|
44
|
+
|-------|-------------|
|
|
45
|
+
| [Provider Runtimes](./features/provider-runtimes.md) | Claude + Codex runtime architecture |
|
|
46
|
+
| [Agent Intelligence](./features/agent-intelligence.md) | AI Assist, routing, swarms, loops |
|
|
47
|
+
| [Tool Permissions](./features/tool-permissions.md) | Trust tiers, presets, approval flow |
|
|
48
|
+
| [Design System](./features/design-system.md) | Calm Ops visual language |
|
|
49
|
+
| [Keyboard & Navigation](./features/keyboard-navigation.md) | Command palette, accessibility |
|
|
50
|
+
| [Shared Components](./features/shared-components.md) | Reusable UI component library |
|
|
@@ -0,0 +1,303 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: "Developer Guide"
|
|
3
|
+
category: "user-journey"
|
|
4
|
+
persona: "developer"
|
|
5
|
+
difficulty: "advanced"
|
|
6
|
+
estimatedTime: "28 minutes"
|
|
7
|
+
sections: ["settings", "environment", "chat", "monitoring", "profiles", "workflows", "schedules"]
|
|
8
|
+
tags: ["advanced", "developer", "settings", "environment", "cli", "api", "monitoring", "profiles"]
|
|
9
|
+
lastUpdated: "2026-03-22"
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
# Developer Guide
|
|
13
|
+
|
|
14
|
+
Meet Riley, a platform engineer responsible for setting up, securing, and extending the Stagent installation for a development team. Riley needs to configure authentication, enforce budget guardrails, define permission presets, manage data lifecycle, explore the environment control plane, understand the chat streaming architecture, monitor agent execution, inspect workflows and schedules, and script batch operations via the CLI. This journey covers the infrastructure and configuration layer that keeps Stagent secure, observable, and performant.
|
|
15
|
+
|
|
16
|
+
## Prerequisites
|
|
17
|
+
|
|
18
|
+
- Stagent cloned from the repository and dependencies installed (`npm install`)
|
|
19
|
+
- Node.js 20+ and npm available on the system
|
|
20
|
+
- An Anthropic API key (for API key auth) or Claude Max subscription (for OAuth)
|
|
21
|
+
- Familiarity with terminal/CLI workflows and REST APIs
|
|
22
|
+
- Basic understanding of Stagent concepts (see [Personal Use Guide](./personal-use.md))
|
|
23
|
+
|
|
24
|
+
## Journey Steps
|
|
25
|
+
|
|
26
|
+
### Step 1: Configure Authentication
|
|
27
|
+
|
|
28
|
+
Riley starts at the Settings page -- the central hub for all system-level configuration. The first priority is getting authentication right, because every agent execution depends on a valid provider connection.
|
|
29
|
+
|
|
30
|
+

|
|
31
|
+
|
|
32
|
+
1. Click **Settings** in the sidebar under the **Configure** group
|
|
33
|
+
2. Locate the **Authentication** section at the top of the page
|
|
34
|
+
3. Choose between two authentication methods:
|
|
35
|
+
- **OAuth** (default, recommended for Claude Max subscribers): Uses your Max subscription tokens with no separate API billing
|
|
36
|
+
- **API Key**: Uses the `ANTHROPIC_API_KEY` from `.env.local`, billed per token
|
|
37
|
+
4. If using OAuth, click **Connect** to initiate the browser-based OAuth flow
|
|
38
|
+
5. If using API Key, verify the key is set in `.env.local` and click **Test Connection**
|
|
39
|
+
6. Confirm the connection status indicator shows **Connected**
|
|
40
|
+
|
|
41
|
+
> **Tip:** OAuth is the default for a reason -- it avoids per-token charges on your Anthropic account. If both OAuth and an API key are present, the SDK subprocess environment must be carefully managed to prevent the key from leaking into OAuth sessions. Stagent handles this automatically by stripping `ANTHROPIC_API_KEY` from the child process env when OAuth mode is active.
|
|
42
|
+
|
|
43
|
+
### Step 2: Set Up Budget Guardrails
|
|
44
|
+
|
|
45
|
+
With authentication in place, Riley configures spending limits. Budget controls are critical when multiple team members run agents concurrently -- a single runaway loop can burn through a monthly allocation in minutes.
|
|
46
|
+
|
|
47
|
+

|
|
48
|
+
|
|
49
|
+
1. Scroll to the **Budget** section in Settings (or click the section anchor)
|
|
50
|
+
2. Set a **Monthly Spend Cap** appropriate for the team (e.g., $50 for development, $500 for production)
|
|
51
|
+
3. Configure **Alert Thresholds** at 50%, 75%, and 90% of the budget
|
|
52
|
+
4. Choose the alert delivery method (inbox notification, browser notification, or both)
|
|
53
|
+
5. Enable **Hard Stop** to halt all agent execution when the cap is exceeded (recommended for non-production environments)
|
|
54
|
+
6. Review the current spend-to-date displayed alongside the cap
|
|
55
|
+
|
|
56
|
+
> **Tip:** Budget guardrails are enforced at the usage-metering-ledger level -- every token consumed by every provider (Anthropic and OpenAI) is metered into the ledger before the response streams back. The Cost & Usage dashboard (covered in the [Work Use Guide](./work-use.md)) visualizes spend against these limits in real time.
|
|
57
|
+
|
|
58
|
+
### Step 3: Configure Permission Presets
|
|
59
|
+
|
|
60
|
+
Riley defines the governance layer that controls what tools agents can invoke and under what conditions. Permission presets establish the baseline trust posture for the entire workspace.
|
|
61
|
+
|
|
62
|
+

|
|
63
|
+
|
|
64
|
+
1. Scroll to the **Permissions** section in Settings
|
|
65
|
+
2. Review the three built-in presets, each tagged with a risk badge:
|
|
66
|
+
- **Restrictive** (Low Risk): Agents ask before every tool use -- safest, highest friction
|
|
67
|
+
- **Balanced** (Medium Risk): Read operations are pre-approved, writes require human approval
|
|
68
|
+
- **Autonomous** (High Risk): Most operations pre-approved, only destructive actions require approval
|
|
69
|
+
3. Select a preset as the workspace default by clicking its radio button
|
|
70
|
+
4. Optionally toggle individual tool permissions to customize beyond the preset (e.g., always allow file reads, always ask for shell commands)
|
|
71
|
+
5. Observe how per-tool overrides are highlighted when they diverge from the active preset
|
|
72
|
+
|
|
73
|
+
> **Tip:** Permission presets interact with the "Always Allow" button in the Inbox. When a user approves a tool with "Always Allow," that approval is persisted in the settings table and survives across sessions. The preset sets the floor; individual approvals can only escalate, never reduce, the trust level.
|
|
74
|
+
|
|
75
|
+
### Step 4: Manage Data and Storage
|
|
76
|
+
|
|
77
|
+
Riley reviews data management to understand storage footprint, configure retention policies, and know how to reset the workspace cleanly when needed.
|
|
78
|
+
|
|
79
|
+

|
|
80
|
+
|
|
81
|
+
1. Scroll to the **Data Management** section in Settings
|
|
82
|
+
2. Review the **database location** (default: `~/.stagent/stagent.db`) and its current size
|
|
83
|
+
3. Check **storage usage** broken down by category: database, uploaded documents (`~/.stagent/uploads/`), and agent logs
|
|
84
|
+
4. Configure **log retention** policies (e.g., 30-day retention, auto-archive completed tasks after 90 days)
|
|
85
|
+
5. Use the **Clear Data** action cautiously -- it deletes all tasks, projects, workflows, documents, and logs while preserving settings
|
|
86
|
+
6. Note the FK-safe deletion order: child records (agent_logs, notifications) are removed before parent records (tasks, projects)
|
|
87
|
+
|
|
88
|
+
> **Tip:** The SQLite database runs in WAL (Write-Ahead Logging) mode for concurrent read performance. Agent logs and execution traces are typically the largest consumers of disk space. If the database grows beyond a few hundred megabytes, consider archiving old logs rather than clearing everything.
|
|
89
|
+
|
|
90
|
+
### Step 5: Explore the Environment Dashboard
|
|
91
|
+
|
|
92
|
+
Riley switches to the Environment page to understand the control plane -- what development tools are installed, how they are configured, and what project configurations Stagent has detected across the filesystem.
|
|
93
|
+
|
|
94
|
+

|
|
95
|
+
|
|
96
|
+
1. Click **Environment** in the sidebar under the **Configure** group
|
|
97
|
+
2. Review the **detected tools** section -- Stagent's environment scanner identifies installed CLIs (Claude Code, Codex CLI), their versions, and config file locations
|
|
98
|
+
3. Inspect the **project configurations** panel showing discovered projects with their working directories, detected languages, and framework versions
|
|
99
|
+
4. Check the **health scores** for each detected environment (green = fully configured, yellow = partial, red = missing required config)
|
|
100
|
+
5. Note the **sync status** indicators that show whether local project configs match the canonical templates
|
|
101
|
+
6. Use the **Refresh** action to re-run the environment scanner if you have just installed a new tool
|
|
102
|
+
|
|
103
|
+
> **Tip:** The environment scanner reads config files like `~/.codex/config.toml`, `.claude/settings.local.json`, and project-level `AGENTS.md` files. It caches results to avoid repeated filesystem scans. The cache is invalidated automatically when Stagent detects file modification timestamps have changed, or you can force a refresh from this dashboard.
|
|
104
|
+
|
|
105
|
+
### Step 6: Understand the Chat Architecture
|
|
106
|
+
|
|
107
|
+
Riley examines the Chat interface not as a user but as a developer, tracing the request lifecycle from input to streamed response. Understanding this architecture is essential for extending or debugging the conversational layer.
|
|
108
|
+
|
|
109
|
+

|
|
110
|
+
|
|
111
|
+
1. Open the **Chat** page and start or continue a conversation
|
|
112
|
+
2. Trace the request flow through these API endpoints:
|
|
113
|
+
- `POST /api/chat` -- Accepts a message, returns an SSE-streamed response
|
|
114
|
+
- `GET /api/chat/conversations` -- Lists conversations with pagination
|
|
115
|
+
- `POST /api/chat/conversations` -- Creates a new conversation
|
|
116
|
+
- `GET /api/chat/conversations/[id]` -- Retrieves a conversation with full message history
|
|
117
|
+
- `DELETE /api/chat/conversations/[id]` -- Deletes a conversation and its messages
|
|
118
|
+
- `GET /api/chat/suggested-prompts` -- Returns categorized prompt suggestions
|
|
119
|
+
- `GET /api/models` -- Dynamic model catalog with cost tier metadata
|
|
120
|
+
3. Observe the SSE stream in your browser's Network tab -- each chunk arrives as a `stream_event` wrapper containing a delta payload
|
|
121
|
+
4. Notice the **Quick Access pills** rendered below AI responses -- these are parsed from entity references (tasks, projects, documents) detected in the response text
|
|
122
|
+
5. Review the model selector to see how the dynamic model catalog populates available models with cost tier badges
|
|
123
|
+
|
|
124
|
+
> **Tip:** The chat engine uses the same provider-runtime-abstraction as task execution, meaning it respects the same authentication method, budget caps, and usage metering. Conversation data is stored in SQLite alongside the rest of the Stagent schema, so chat history is queryable via Drizzle ORM. The `stream_event` wrapper format was a hard-won lesson -- see the codebase commit history for the blank-response fix that added proper wrapper handling.
|
|
125
|
+
|
|
126
|
+
### Step 7: Monitor Agent Execution
|
|
127
|
+
|
|
128
|
+
With the platform configured, Riley turns to the Monitor to verify that agents are executing correctly and that permission checks, budget enforcement, and tool invocations are all behaving as expected.
|
|
129
|
+
|
|
130
|
+

|
|
131
|
+
|
|
132
|
+
1. Click **Monitor** in the sidebar under the **Manage** group
|
|
133
|
+
2. Scan the execution log for recent entries -- each row shows the agent profile, task, status, duration, and token count
|
|
134
|
+
3. Filter by **status** to surface any error-level entries that might indicate configuration problems
|
|
135
|
+
4. Click an execution entry to expand its full trace:
|
|
136
|
+
- **Tool calls**: What tools the agent invoked, with full argument payloads
|
|
137
|
+
- **Outputs**: What each tool returned (truncated for large payloads)
|
|
138
|
+
- **Timing**: Per-step duration to identify bottlenecks
|
|
139
|
+
- **Token usage**: Input and output token counts per step, rolled up into the usage ledger
|
|
140
|
+
5. Verify that permission checks appear in the trace -- approved actions proceed, denied actions show a "waiting for approval" state, and hard-denied actions show a rejection reason
|
|
141
|
+
|
|
142
|
+
> **Tip:** The Monitor is your primary diagnostic tool. When an agent behaves unexpectedly, check the tool call arguments first -- incorrect arguments are the most common root cause. For long-running autonomous loops, the Monitor shows iteration counts and stop-condition evaluations so you can see exactly why a loop terminated.
|
|
143
|
+
|
|
144
|
+
### Step 8: Inspect Workflow Runs
|
|
145
|
+
|
|
146
|
+
Riley drills into a workflow run to understand multi-step execution. Workflows chain tasks together with dependency ordering, and the detail page shows step-by-step progress including intermediate outputs.
|
|
147
|
+
|
|
148
|
+

|
|
149
|
+
|
|
150
|
+
1. Click **Workflows** in the sidebar under the **Work** group
|
|
151
|
+
2. Select a completed or in-progress workflow run from the list
|
|
152
|
+
3. Review the **step timeline** showing each task in execution order with status badges (completed, running, queued, failed)
|
|
153
|
+
4. Click individual steps to see their execution details -- the same trace data available in the Monitor, but scoped to this workflow
|
|
154
|
+
5. Check the **context propagation** between steps -- outputs from earlier steps are injected as context into later steps via the workflow-context-batching system
|
|
155
|
+
6. Review the **total duration** and **aggregate token usage** for the entire workflow run
|
|
156
|
+
7. If a step failed, inspect the error and note whether the workflow halted (fail-fast) or continued (skip-on-error)
|
|
157
|
+
|
|
158
|
+
> **Tip:** Workflows support parallel execution via fork-join patterns. When you see multiple steps at the same depth level in the timeline, those ran concurrently. The workflow engine respects the same permission presets as individual task execution, so a restrictive preset can create bottlenecks in multi-step workflows if each step requires approval.
|
|
159
|
+
|
|
160
|
+
### Step 9: Review Agent Profiles
|
|
161
|
+
|
|
162
|
+
Riley reviews the agent profile catalog to understand which behavioral configurations are available and how they map to different task types and provider capabilities.
|
|
163
|
+
|
|
164
|
+

|
|
165
|
+
|
|
166
|
+
1. Click **Profiles** in the sidebar under the **Manage** group
|
|
167
|
+
2. Review the profile grid, organized into **Work** and **Personal** tabs
|
|
168
|
+
3. Note the profile cards showing: name, description, provider compatibility icons (Anthropic, OpenAI), and capability badges
|
|
169
|
+
4. Observe that each profile declares its tool access scope -- some profiles (like Code Reviewer) have deliberately narrow access
|
|
170
|
+
5. Check provider compatibility: profiles that support both Anthropic and OpenAI runtimes show dual provider icons, while some are provider-specific
|
|
171
|
+
6. Note the profile count and verify all expected profiles are loaded (General, Code Reviewer, Researcher, Document Writer, plus any custom profiles)
|
|
172
|
+
|
|
173
|
+
> **Tip:** Agent profiles and permission presets form a two-layer governance model. The profile defines *what tools are available* to the agent, and the permission preset defines *the approval level* for each tool. A restrictive preset with a broad profile still requires approval -- the narrower of the two always wins.
|
|
174
|
+
|
|
175
|
+
### Step 10: Examine Profile Configuration
|
|
176
|
+
|
|
177
|
+
Riley opens a specific profile to understand its detailed configuration -- the system prompt, tool declarations, capability flags, and provider-specific settings that shape agent behavior.
|
|
178
|
+
|
|
179
|
+

|
|
180
|
+
|
|
181
|
+
1. Click any profile card to open its detail page
|
|
182
|
+
2. Review the **system prompt** that shapes the agent's persona and behavioral constraints
|
|
183
|
+
3. Examine the **tool declarations** -- the explicit list of tools this profile can invoke
|
|
184
|
+
4. Check the **capability flags**: can this profile access the filesystem, run shell commands, browse the web, or generate documents?
|
|
185
|
+
5. Review **provider-specific settings** -- some profiles have different temperature, max tokens, or model preferences per provider
|
|
186
|
+
6. Note the **task assignment count** showing how many tasks currently use this profile
|
|
187
|
+
7. Verify that the profile's tool list aligns with your permission preset expectations
|
|
188
|
+
|
|
189
|
+
> **Tip:** Profiles are defined in `src/lib/agents/profiles/` as TypeScript modules. To create a custom profile, add a new file following the pattern of existing profiles (types.ts defines the interface, registry.ts registers profiles). Custom profiles appear automatically in the UI after a server restart. The cross-provider-profile-compatibility feature ensures profiles work consistently across Anthropic and OpenAI runtimes.
|
|
190
|
+
|
|
191
|
+
### Step 11: Inspect Schedule Configuration
|
|
192
|
+
|
|
193
|
+
Riley examines a schedule to understand how automated prompt loops are configured, when they fire, and what their execution history looks like.
|
|
194
|
+
|
|
195
|
+

|
|
196
|
+
|
|
197
|
+
1. Click **Schedules** in the sidebar under the **Manage** group
|
|
198
|
+
2. Select a schedule to open its detail sheet
|
|
199
|
+
3. Review the **schedule configuration**: prompt text, interval (e.g., "every 4 hours," "daily at 9am"), associated project, and agent profile
|
|
200
|
+
4. Check the **firing history** showing past executions with timestamps, durations, and outcomes (success, failed, skipped)
|
|
201
|
+
5. Note the **next firing time** calculated from the interval parser
|
|
202
|
+
6. Review the **pause/resume** toggle -- paused schedules retain their configuration but skip firings until resumed
|
|
203
|
+
7. Verify that the schedule's agent profile and project assignment match your team's expectations
|
|
204
|
+
|
|
205
|
+
> **Tip:** The scheduler engine runs via the Next.js `instrumentation.ts` register hook, so it starts automatically with the dev server. The interval parser supports natural language patterns like "every 30 minutes," "daily at 9am," and "weekdays at 5pm." Schedules are stored in the `schedules` table and their execution history feeds into the same Monitor and usage ledger as manual task runs.
|
|
206
|
+
|
|
207
|
+
### Step 12: Build and Test the CLI
|
|
208
|
+
|
|
209
|
+
Riley builds the CLI for scripted operations, CI/CD integration, and terminal-first workflows. The CLI shares the same SQLite database as the web UI, so changes are instantly visible in both interfaces.
|
|
210
|
+
|
|
211
|
+

|
|
212
|
+
|
|
213
|
+
1. Build the CLI from the project root:
|
|
214
|
+
```bash
|
|
215
|
+
npm run build:cli
|
|
216
|
+
```
|
|
217
|
+
2. Verify the build succeeded:
|
|
218
|
+
```bash
|
|
219
|
+
node dist/cli.js --help
|
|
220
|
+
```
|
|
221
|
+
3. Test basic CRUD operations:
|
|
222
|
+
```bash
|
|
223
|
+
# List all projects
|
|
224
|
+
node dist/cli.js projects list
|
|
225
|
+
|
|
226
|
+
# Create a task
|
|
227
|
+
node dist/cli.js tasks create --title "CLI test task" --project <project-id>
|
|
228
|
+
|
|
229
|
+
# Execute a task with a specific agent profile
|
|
230
|
+
node dist/cli.js tasks execute <task-id> --profile general
|
|
231
|
+
|
|
232
|
+
# Check execution status
|
|
233
|
+
node dist/cli.js tasks get <task-id>
|
|
234
|
+
```
|
|
235
|
+
4. Verify that CLI-created entities appear in the web UI immediately (shared SQLite database, WAL mode)
|
|
236
|
+
|
|
237
|
+
> **Tip:** The CLI entry point is `bin/cli.ts`, compiled to `dist/cli.js`. It uses the same Drizzle ORM and data access layer as the web app, so there is zero drift between interfaces. The CLI is ideal for CI/CD pipelines -- create tasks, trigger workflows, or query execution results from shell scripts.
|
|
238
|
+
|
|
239
|
+
### Step 13: Script Batch Operations
|
|
240
|
+
|
|
241
|
+
Riley creates a shell script to bootstrap a new project with predefined tasks and a workflow -- a common pattern for onboarding new team members or standardizing project initialization.
|
|
242
|
+
|
|
243
|
+

|
|
244
|
+
|
|
245
|
+
1. Create a bootstrap script that chains CLI commands:
|
|
246
|
+
```bash
|
|
247
|
+
#!/bin/bash
|
|
248
|
+
set -euo pipefail
|
|
249
|
+
|
|
250
|
+
# Create the project
|
|
251
|
+
PROJECT_ID=$(node dist/cli.js projects create \
|
|
252
|
+
--name "New Initiative" \
|
|
253
|
+
--description "Bootstrapped project" \
|
|
254
|
+
--working-directory ~/Developer/new-initiative)
|
|
255
|
+
|
|
256
|
+
# Create standard tasks with appropriate profiles
|
|
257
|
+
node dist/cli.js tasks create \
|
|
258
|
+
--title "Set up repository structure" \
|
|
259
|
+
--project $PROJECT_ID \
|
|
260
|
+
--profile general
|
|
261
|
+
|
|
262
|
+
node dist/cli.js tasks create \
|
|
263
|
+
--title "Write initial documentation" \
|
|
264
|
+
--project $PROJECT_ID \
|
|
265
|
+
--profile document-writer
|
|
266
|
+
|
|
267
|
+
node dist/cli.js tasks create \
|
|
268
|
+
--title "Review security configuration" \
|
|
269
|
+
--project $PROJECT_ID \
|
|
270
|
+
--profile code-reviewer
|
|
271
|
+
|
|
272
|
+
echo "Project $PROJECT_ID bootstrapped with 3 tasks"
|
|
273
|
+
```
|
|
274
|
+
2. Run the script and verify the project and tasks appear in the web UI
|
|
275
|
+
3. Check the Monitor for execution traces from any tasks you triggered
|
|
276
|
+
4. Version-control the script so any team member can replicate the setup
|
|
277
|
+
|
|
278
|
+
> **Tip:** CLI scripts are infrastructure-as-code for your AI agent workspace. Store bootstrap scripts alongside your project code. Combine them with the schedule system for recurring maintenance tasks -- for example, a nightly script that creates a "review open PRs" task assigned to the Code Reviewer profile.
|
|
279
|
+
|
|
280
|
+
### Step 14: Verify Platform Health
|
|
281
|
+
|
|
282
|
+
Riley performs a final platform health check before handing the workspace over to the team. This checklist covers every layer touched in this journey.
|
|
283
|
+
|
|
284
|
+

|
|
285
|
+
|
|
286
|
+
1. **Authentication**: Verify connection status in Settings shows a green **Connected** indicator
|
|
287
|
+
2. **Budget**: Confirm the monthly cap is set and alert thresholds are configured at 50%, 75%, and 90%
|
|
288
|
+
3. **Permissions**: Execute a test task and verify the correct approval prompts appear in the Inbox based on your chosen preset
|
|
289
|
+
4. **Data**: Confirm the database is accessible at `~/.stagent/stagent.db` and WAL mode is enabled
|
|
290
|
+
5. **Environment**: Check the Environment dashboard for green health scores on all detected tools
|
|
291
|
+
6. **Chat**: Send a test message and verify the SSE stream completes with a coherent response
|
|
292
|
+
7. **Monitor**: Scan for any error-level entries from the last hour
|
|
293
|
+
8. **Profiles**: Confirm all expected profiles are loaded and show correct provider compatibility
|
|
294
|
+
9. **Schedules**: Verify any active schedules show correct next-firing times
|
|
295
|
+
10. **CLI**: Run `node dist/cli.js --help` to confirm the build is current
|
|
296
|
+
|
|
297
|
+
> **Tip:** Run this checklist after any significant configuration change, Stagent version update, or Node.js upgrade. A healthy platform has: authenticated provider connection, budget limits enforced, default permission preset active, environment scanner green, CLI built and current, and a clean Monitor with no recent errors.
|
|
298
|
+
|
|
299
|
+
## What's Next
|
|
300
|
+
|
|
301
|
+
- [Personal Use Guide](./personal-use.md) -- Review basic project and task creation workflows
|
|
302
|
+
- [Work Use Guide](./work-use.md) -- Learn team collaboration, documents, cost tracking, and scheduling
|
|
303
|
+
- [Power User Guide](./power-user.md) -- Build advanced workflows, autonomous loops, and multi-agent swarms
|