Skip to main content

​
Control UI Setup Model

Onboarding gets the machine ready. The Control UI makes the agent useful. The intended flow is: The first browser setup pass should start from the selected Agent:
1

/agents

Create or select the Agent that will own chat, chat app routes, tasks, and saved context.
2

Agent > Models

Connect provider auth if needed, then choose primary, fallback, and task models.
3

Agent > Skills

Create, review, install, configure, and allow skills for this Agent.
4

Agent > Channels

Install the official channel add-on when required, then connect and route accounts, topics, or guilds to this Agent.
5

Agent > Services

Connect external APIs such as web/search, Gmail, Calendar, GitHub, or browser/media.
6

Agent > Memory

Enable saved session context and review per-Agent archive state.
7

Agent > Tasks

Create saved tasks, triggers, workflows, graphs, programs, and templates.
8

/config

Use Advanced Config only for fields that do not have a friendly page yet.
For the focused model-to-agent flow, see Models to Agents to Chat.

​
What Onboarding Owns

Use onboarding for machine and security setup:
  • Local or Hosting profile
  • Gateway mode, port, auth, and token
  • workspace and service startup
  • local signer wallet setup when selected
  • optional singleton Mining wallet setup
  • Hosting profile Tailscale and host hardening
Onboarding is not the normal place to manage every model provider, skill, extension, hook, channel, service, or scheduled task.
Hosting is for VPS or always-on server machines. It can change SSH and firewall behavior. Local is for a laptop, desktop, or dev box and does not apply the hosting security baseline.

​
What The Control UI Owns

After onboarding, open:
Then use the browser pages for product setup:

/agents

Create or select an Agent and attach model, skills, services, chat apps, saved context, tasks, tools, sessions, and wallet controls.

/extensions

Review runtime plugins, source trust, dependencies, scanner warnings, and advanced extension setup.

/usage

Review local model usage by provider, model, Agent, session, task, chat app, and source.

/notifications

Configure notification routing and recent in-app/external delivery.

/wallet

Review wallet controls, approvals, balances, custody, and signer health.

/mining

Operate SAT mining readiness, capital, commit, recovery, and history.

/federation

Operate Fased Network status, routing, and marketplace-facing identity.

/marketplace

Review Fased Network offers, requests, purchases, and disputes.

/memory

Read memory diagnostics across Agents. Enable session-memory from Agent > Memory.

/config

Advanced Config only. Use this when a field is not exposed in a friendly page yet.
Dashboard is a launch/status widget board. It is not the setup wizard. Start with /agents when the Gateway is already online.

​
Agent Means

In the Control UI, an Agent is the workspace profile you actually operate. It can have:
  • model and fallbacks
  • skills
  • services
  • chat apps
  • saved context settings
  • scheduled tasks
  • files and workspace context
  • wallet controls
Examples:
  • Researcher
  • Support
  • Mining Operator
  • Operations Reviewer
Channels and scheduled tasks should route to a configured Agent. In the UI, Channels means chat app connections such as Telegram, Discord, and WhatsApp. Subagents are different: they are internal runtime workers used during a task, not normal chat routing targets. Agent > Tasks is the selected Agent’s saved-work control surface. Create a Task for scheduled work first. Add Triggers, Workflows, Graphs, Programs, or Templates only when the run needs that structure. Run history can include scheduled runs plus records mirrored from webhooks, chat apps, subagents/ACP, CLI/system runs, media generation, wallet approvals, Marketplace, mining, and workflows. It is audit data, not the primary task list. Use the owning page for the actual domain operation: Wallets for signing, Marketplace for orders/disputes, Mining for mining control, Channels for chat routes/delivery, and Services/Media for connector setup.

​
Skills, Extensions, Channels, Services

Use these words consistently: Skill A user-facing ability or instruction pack the agent can use. Create, review, configure, and allow it from Agent > Skills. Extension Plugin code that can add tools, channels, hooks, schemas, commands, or UI panels. Review it in /extensions. Channel A chat app where the agent receives or sends messages. Connect and route it from Agent > Channels. Channels do not own tasks. Service An external API the agent can use, such as Gmail, Calendar, GitHub, web/search, browser/media, or a plugin-reported API. Connect it from Agent > Services. Hook Background automation around Fased events. Review hook packs in /extensions; Agent memory archive control lives in Agent > Memory. Skill setup is intentionally split by responsibility but exposed in one Agent surface:
  • Agent > Skills: create workspace skills, review plugin-catalog installs, save skill config, fix dependencies, edit skill files, and allow/deny skills for that Agent.
  • Agent > Tools: allow or deny tools exposed by core code, services, channels, or extensions.
  • Agent > Services: connect API credentials a skill/tool depends on.
  • Wallet > Skill Grants tab: grant narrow Agent-wallet actions for reviewed wallet-capable skills. Mining and Vault wallets stay outside generic skill grants.
Agent > Channels exposes installed channels and official add-ons in the same order as onboarding. Telegram, WhatsApp, Discord, Slack, Feishu, and Google Chat show an Install action on a fresh core install; setup fields appear after the package is installed and the Gateway restarts. The normal setup path is per Agent; any global channel page is an implementation/deep-link fallback, not the first-run path. Fased includes provider clients for local model servers, but it does not install Ollama, LM Studio, vLLM, LiteLLM, or model weights. Install and run that service first, then connect it from Agent > Models. See Core And Optional Components. Agent > Services is the connector recovery center for task preflight. If a task needs web search, GitHub, Gmail/Google Workspace, Firecrawl, model auth, channel delivery, or a configured skill, it should pause in needs-access and point back to the matching setup surface instead of repeatedly running. Access is still constrained by that Agent’s Tools, Skills, wallet controls, and task policy.

​
Memory (Saved Context)

Memory has multiple pieces:
  • MEMORY.md: curated long-term workspace memory
  • memory/: markdown archive directory
  • session-memory: hook that archives recent session messages on /new and /reset
  • QMD/backend: optional indexing, search, and export
  • Memory Doctor: diagnostics and repair surfaces
Use Agent > Memory to enable or disable session-memory and review that Agent’s archive/QMD state. Use /memory for cross-Agent diagnostics and memory health. Repair and raw doctor actions stay in Debug or CLI.

​
Advanced Config

/config edits ~/.fased/fased.json directly. Use it when:
  • a plugin or channel exposes a schema field that does not have a friendly UI yet
  • you need raw JSON mode
  • you need validation, diff, reload, save, or apply controls
  • support or docs asks you to change a specific config field
Do not use Advanced Config as the normal first-run setup path. Prefer Agents, Extensions, Wallets, Mining, Fased Network, Marketplace, Usage, Notifications, Logs, and Debug first.

​
CLI

CLI remains useful for:
  • automation
  • repair
  • export/import
  • host-level operations
  • dangerous wallet or signer operations
  • scripted installs
Normal product setup after onboarding should happen in the Control UI whenever the relevant page exists.