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.
Files changed (42) hide show
  1. package/dist/cli.js +2 -0
  2. package/docs/.last-generated +1 -0
  3. package/docs/features/agent-intelligence.md +60 -0
  4. package/docs/features/chat.md +119 -0
  5. package/docs/features/cost-usage.md +61 -0
  6. package/docs/features/dashboard-kanban.md +73 -0
  7. package/docs/features/design-system.md +73 -0
  8. package/docs/features/documents.md +76 -0
  9. package/docs/features/home-workspace.md +66 -0
  10. package/docs/features/inbox-notifications.md +67 -0
  11. package/docs/features/keyboard-navigation.md +62 -0
  12. package/docs/features/monitoring.md +59 -0
  13. package/docs/features/playbook.md +57 -0
  14. package/docs/features/profiles.md +57 -0
  15. package/docs/features/projects.md +67 -0
  16. package/docs/features/provider-runtimes.md +49 -0
  17. package/docs/features/schedules.md +68 -0
  18. package/docs/features/settings.md +85 -0
  19. package/docs/features/shared-components.md +78 -0
  20. package/docs/features/tool-permissions.md +57 -0
  21. package/docs/features/workflows.md +81 -0
  22. package/docs/getting-started.md +141 -0
  23. package/docs/index.md +50 -0
  24. package/docs/journeys/developer.md +303 -0
  25. package/docs/journeys/personal-use.md +209 -0
  26. package/docs/journeys/power-user.md +248 -0
  27. package/docs/journeys/work-use.md +226 -0
  28. package/docs/manifest.json +240 -0
  29. package/package.json +2 -1
  30. package/src/app/api/environment/checkpoints/[id]/route.ts +3 -2
  31. package/src/app/api/environment/checkpoints/route.ts +2 -1
  32. package/src/app/api/environment/scan/route.ts +2 -1
  33. package/src/lib/agents/claude-agent.ts +3 -2
  34. package/src/lib/agents/runtime/claude.ts +4 -3
  35. package/src/lib/agents/runtime/openai-codex.ts +4 -3
  36. package/src/lib/chat/engine.ts +2 -1
  37. package/src/lib/chat/model-discovery.ts +2 -1
  38. package/src/lib/docs/reader.ts +11 -1
  39. package/src/lib/environment/scanner.ts +2 -1
  40. package/src/lib/environment/sync/mcp-sync.ts +2 -1
  41. package/src/lib/environment/sync-engine.ts +2 -1
  42. 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
+ ![Workflows list view](../screengrabs/workflows-list.png)
19
+ *Workflow cards showing name, pattern type, step count, and status*
20
+
21
+ ![Workflow detail view](../screengrabs/workflows-detail.png)
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
+ ![Settings page showing auth, runtime, and configuration sections](../screengrabs/settings-list.png)
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
+ ![Budget guardrails section with spend cap configuration](../screengrabs/settings-budget.png)
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
+ ![Permission presets with risk badges and toggle controls](../screengrabs/settings-presets.png)
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
+ ![Data management section in Settings](../screengrabs/settings-data.png)
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
+ ![Environment dashboard showing Claude Code and Codex CLI configurations](../screengrabs/environment-list.png)
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
+ ![Active chat conversation with streamed response and Quick Access pills](../screengrabs/chat-conversation.png)
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
+ ![Agent monitoring dashboard with execution logs](../screengrabs/monitor-list.png)
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
+ ![Workflow detail page showing steps and execution status](../screengrabs/workflows-detail.png)
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
+ ![Agent profiles grid with work and personal tabs](../screengrabs/profiles-list.png)
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
+ ![Profile detail page showing capabilities, tools, and configuration](../screengrabs/profiles-detail.png)
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
+ ![Schedule detail sheet showing configuration and firing history](../screengrabs/schedules-detail.png)
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
+ ![Settings page for CLI configuration reference](../screengrabs/settings-list.png)
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
+ ![Agent monitoring dashboard showing batch execution results](../screengrabs/monitor-list.png)
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
+ ![Environment dashboard for final health verification](../screengrabs/environment-list.png)
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