AgentOrchestrator
Connecting…
0 tok
0 st · 0 tl

Chat
Running Workflows

Simple questions get instant answers. Complex tasks use the full agent workflow.

How can I help?

Ask a question or give an instruction — the system decides the best approach.

No browser page open yet.

Files & Folder
Attach files
⏸️

### Step Approval Required

Step
🚀

### Welcome to Agent Orchestrator

#### Step 1 — Choose your model

Select the LLM that powers Agent. You can use a local Ollama model or a cloud provider.

Main model

Loading available models…

#### Step 2 — Connect integrations

Optional — you can always configure these later in Settings.

Outlook (email & calendar)
Google (Gmail, Calendar, Drive)
Brave Search (web search)

#### Step 3 — You're all set!

Your agent is configured and ready to go.

⚙️

### Settings

LLM Models

Main Model
Fast Model (optional — curator & validator)
Fallback Model (optional — auto-failover when primary fails)

Show model thinking (reasoning / chain-of-thought)

When enabled, the model's <think> reasoning is shown in a collapsible block during streaming. Default: hidden.

Recommended Model Profile

Main glm-5.1:cloud Fast gpt-oss:20b-cloud Fallback qwen3.5:9b

Cloud + local

Store your Ollama Cloud API key under API Keys if you use cloud variants. You can still sign in locally to pull cloud models through the Ollama runtime.

Download Ollama Models

Pull models from the Ollama library. Requires Ollama running locally. Cloud variants are available after signing in at ollama.com.

Installed Models

API Keys

Provider keys unlock additional model families. Keys are stored locally and never sent to third parties.

Ollama Cloud API Key (for cloud variants)

OpenAI API Key (for GPT / o-series models)

Google Gemini API Key (for Gemini models)

NVIDIA API Key (for NVIDIA models)

llama.cpp Server URL (local llama-server, default http://localhost:8080)
llama.cpp Model Path (.gguf file)
Extra Arguments (optional, e.g. --n-gpu-layers 99 --ctx-size 8192)

llama-server starts automatically when you use a llama.cpp model. Stop to free memory.

Co-Pilot

Enable Co-Pilot

You can configure each Co-Pilot before turning Co-Pilot on. Initiative stays shared; schedule and instructions are now set per Co-Pilot.

Morning Brief

Checks today's agenda, recent email, and drafts, then proposes priorities and next actions.

Enable Daily Brief

Creates a recurring Co-Pilot Morning Brief schedule.

Daily Time
Initiative
Morning Brief Instructions
Follow-up

Checks open loops across recent email and upcoming meetings, then shows what still likely needs a reply, decision, or preparation.

Enable Daily Follow-up

Creates a recurring midday or end-of-day follow-up sweep.

Daily Time
Focus

Open loops, pending replies, upcoming prep, and stalled decisions.

Follow-up Instructions

Context Sources

Checking Outlook availability…

Checking Google authorization…

Durable wiki memory for important threads and ongoing context.

No relevant memory stored yet.

Outlook

Enable Outlook skills for agents

Persistent folder context is managed centrally in Settings → Context.

Google Workspace

Enable Google skills for agents
Client ID
Client Secret

Provide OAuth 2.0 credentials from Google Cloud Console to enable Gmail, Calendar and Drive skills.

Redirect URI (add this in Google Cloud Console)

Persistent label context is managed centrally in Settings → Context.

Brave Search

Brave Search API Key (internet search)

Microsoft OneDrive

Enable OneDrive skills for agents
Access mode
Local sync folder Microsoft Graph (OAuth)
OneDrive folder path

No OAuth or Azure setup required — reads directly from your synced OneDrive folder.

Application (client) ID
Client Secret

Register an app in Azure Portal → App Registrations. Add `Files.ReadWrite.All` and `User.Read` delegated permissions. Set the redirect URI below as a Web platform redirect.

Redirect URI (add this in Azure Portal)

Browser Control

In-app preview only

Browser navigation stays inside the app preview. External Chromium windows are disabled.

MCP Servers

Connect external tool servers via Model Context Protocol. Add from presets or manually.

Advanced: Raw JSON

Webhooks

Define data endpoints the agent can call to fetch information. Each webhook becomes available as a named data source the agent can query during runs.

WhatsApp

Enable WhatsApp channel
Not connected
Preparing…

Open WhatsApp → Linked Devices → Link a Device → Scan this QR

📱 Linked: —

Send Test Message

Available only after WhatsApp is connected. The app sends a test message to your linked WhatsApp.

Uses WhatsApp Web (linked device). No Meta Business API needed. Setup and connection are handled automatically — no external dependencies required.

Slack

Enable Slack channel
Bot Token (xoxb-…)
App Token (xapp-… for Socket Mode)
Webhook URL (optional)

Create a Slack app at api.slack.com. Add scopes: `chat:write`, `channels:read`, `app_mentions:read`, `im:history`. Enable Socket Mode for the App Token (xapp-…).

Telegram

Enable Telegram channel
Bot Token

Create a bot via @BotFather on Telegram. Send `/newbot` and paste the token here. Messages sent to your bot will be executed as agent goals.

Run Options

Internet Access
Email Access
Human in the Loop
Speed Mode

Server Control

Use Start Server if the backend has dropped completely. Reset Server is for restarting a backend that is still partly reachable.

Stop server when browser closes

When enabled, closing the last browser tab will stop the server and free system resources. A confirmation dialog is shown first. Default: on.

System Check

Test all configured integrations at once.

Run Policy & Budgets

Policy Mode

Max Steps per Run
Max Skill Calls per Run
Max Validation Retries per Step
Max Tokens per Run
Max Runtime (seconds)
Blocked Skills (comma separated)
Require Approval Skills (comma separated)

Updates

Automatic version check and one-click update install. Existing user settings are preserved.

Current Version
Latest Version

Built-in Skills

Custom Skills (created by agent · persisted in tools/ folder)

No custom skills yet. The agent can create skills with `create_skill`.

MCP Skills (discovered from configured MCP servers)

No MCP skills discovered yet. Add or refresh MCP servers in Settings.

System Log

Self-improvement events from the last 30 days — corrections, reflections, memory maintenance, and server starts.

Automatic Learnings

A stronger model reviews proposed learnings automatically and either promotes them into durable rules or discards them.

0 reviewed

No reviewed learnings yet.

No system events recorded yet.

❓

### Help & Documentation

Overview

AgentOrchestrator is a local-first work assistant that combines chat, email, calendar, browser automation, file handling, cloud context, scheduled jobs, and multi-step execution in one interface.

You use the composer like a normal chat app, but the runtime behaves more like an operations layer than a plain chatbot. For every message it decides whether it should answer immediately, use a deterministic functional path, or launch a full multi-stage workflow.

In practice this means the same input box can handle very different kinds of work: answering a question, opening the right email, updating a calendar event, summarizing an attachment, searching connected context sources, or running a multi-step agent plan with visible progress.

- Direct chat handles quick questions, clarifications, simple follow-ups, and lightweight reasoning where no structured action pipeline is needed.
- Fast integration paths cover high-frequency product actions such as email reads, email updates, message drafting, calendar lookups, calendar mutations, and attachment-oriented follow-ups without paying the cost of a full agent run.
- Workflow mode is used when the goal needs planning, research, tool coordination, browser work, code or file changes, or validation across multiple steps.
- Multi-goal requests are expanded into an explicit to-do list so the run does not stop after the first successful subtask.

What the product is optimized for

- Operational assistance for real work such as inbox triage, finding meetings, preparing summaries, or coordinating information across tools.
- Stateful follow-up so a second message like `open the first one` or `move it to Friday` can reuse the right records from the prior step.
- Mixed-mode execution where the app can combine deterministic business logic with LLM reasoning instead of forcing everything through the model.
- Inspectable runs with visible progress, run state, history, schedules, and optional thinking traces for supported models.

Current Setup Flow

1. Welcome explains what the product configures and what can still be changed later.
2. Install Location picks the working directory for settings, memory, skills, output, downloads, and attachments.
3. AI Models checks Ollama, applies the recommended model profile, and lets you add optional cloud-provider keys.
4. Internet Search keeps built-in search available and optionally adds Brave Search.
5. Channels turns on Slack, WhatsApp, and Telegram.
6. Integrations turns on Outlook, Google Workspace, OneDrive, Google Drive, browser automation, and MCP servers as needed.
7. Summary reviews your choices before the app marks setup as complete.

The recommended model profile is glm-5.1:cloud for main work, gpt-oss:20b-cloud for fast work, and qwen3.5:9b as fallback. If you use Ollama Cloud models, the local Ollama runtime must already be signed in with `ollama signin`.

Interface Layout

- Header shows connection state, selected runtime model, live run state, policy budgets, theme controls, help, and settings.
- History sidebar gives you session history, scheduled jobs, and the user identity panel without leaving the active run.
- Chat area shows the welcome state, direct answers, workflow progress events, thought summaries, clarifications, and final reports.
- Browser panel shows live browser previews when a web or Playwright-driven task is active, so the interface can expose what the automation is looking at.

Conversations

Every fresh chat starts from the How can I help? welcome state. A newly opened browser tab or window also starts clean, so the product does not silently attach you to an older conversation unless you explicitly continue one from History.

- New Chat clears the active conversation binding, resets the thread, drops transient run state, and brings back the welcome screen.
- View in History opens an old session read-only so you can inspect what happened without changing follow-up state.
- Continue in History rebinds the composer to that session so the next message is treated as a real follow-up rather than a brand-new task.
- Parallel runs can still exist in the background; use the Active pill to jump between them when more than one workflow is live.

Composer

- Press `Enter` to send and `Shift + Enter` for a new line.
- Use the + menu for files, folders, Drive, OneDrive, Co-Pilot quick starts, and context actions.
- Attached files are injected as live request context. Attached folders are indexed so the agent can selectively open specific files when needed instead of loading everything at once.
- The clock picker schedules the message instead of running it immediately, turning the same request into a future job.

Live Workflows

- Workflow plans are shown as a to-do list with To do, Doing, Done, and Issue states.
- If the agent asks a clarifying question, reply in the same chat and the run resumes with the new information.
- Final reports stay in the transcript so the chat itself becomes the audit trail of what was attempted, completed, skipped, or left unresolved.

Agent Pipeline

Complex work uses a staged pipeline so planning, information gathering, execution, and quality checks do not collapse into a single opaque model response.

1. Planner turns the goal into a concrete task sequence, tool plan, or explicit todo structure.
2. Researcher gathers facts, files, emails, pages, prior session evidence, and live search results that may matter.
3. Curator compresses and filters the raw evidence so execution sees only the context that is actually useful.
4. Executor performs the work, including tool calls, deterministic actions, browser interaction, and content generation.
5. Validator checks whether the result is complete, coherent, and grounded enough to finish safely.
6. Report Out turns the run state into the final user-facing answer, summary, or completion report.

The product does not always use every stage. A simple request can bypass most of this. A harder task can loop through planning, execution, and validation more than once before it returns a final answer.

Fast Paths

- Simple email and calendar lookups often bypass the full workflow and go through specialized logic paths that are faster and more stable.
- Common actions like reply, send, create meeting, update meeting, folder moves, labels, attachments, and free-slot finding use dedicated logic instead of asking the model to improvise everything.
- Multi-goal requests are expanded into explicit todo steps so the system does not stop after only the first successful subtask.

Safety

- Approval mode pauses before sensitive skills when enabled in Settings.
- Run Policy controls step limits, tool-call limits, retries, runtime budget, blocked skills, and approval-required skills.
- Validation can trigger re-planning, fallback routing, clarification, or issue reporting when something is incomplete or risky.

Co-Pilot

Co-Pilot is the proactive briefing layer. It reads your connected inboxes and calendars and turns them into structured summaries.

- Morning Brief focuses on today: priorities, meetings, and messages needing action.
- Follow-up Brief focuses on open loops, pending replies, and stalled work.
- Each brief has its own toggle, daily time, instructions, and Run Now action.
- Folder and label descriptions from Outlook and Google can be added so Co-Pilot understands why a mailbox section matters.
- Supported channel command: `copilot: morning brief` or another configured brief name.

Skills

Skills are the tools the agent can call. The app separates them into Built-in Skills and Custom Skills.

- Built-in Skills cover search, files, shell, browser, email, calendar, cloud storage, messaging, and scheduling.
- Custom Skills live in the `tools/` folder and can be turned on or off in Settings.
- MCP server skills are discovered automatically after you configure an MCP server.
- Disabled skills are never selected. Approval-required skills pause before execution.

Custom Skill Basics

- Each custom skill is one Python file.
- Define a unique name, a clear description, an argument schema, and a `run(args)` entry point.
- Use shared helpers from `tools/_std.py` for consistent success and error output.
- Restart the server after editing custom skill files.

Settings

Use the gear icon to open Settings. The most important sections are Models, Integrations, Channels, Server, and Updates.

Models

- Main Model is the default for planning, execution, and reporting.
- Fast Model is used for lighter or helper stages.
- Fallback Model is used when the preferred model is unavailable.
- Recommended defaults: glm-5.1:cloud, gpt-oss:20b-cloud, qwen3.5:9b.

Integrations

- Outlook uses Outlook Desktop on Windows and does not need API keys.
- Google Workspace needs OAuth credentials and a browser authorization step after setup.
- OneDrive can work from a local sync folder or through Microsoft Graph OAuth.
- Browser relies on Playwright plus Chromium.
- MCP Servers add external tool catalogs through Model Context Protocol.

Channels

- WhatsApp is now a QR-based setup. Enable it, then go to Settings > Channels > WhatsApp and scan the code.
- Slack uses Bot Token plus App Token with Socket Mode.
- Telegram uses a BotFather token.

Channel commands include `status`, `pause`, `resume`, `stop`, `schedule: <interval> <goal>`, `schedules`, `unschedule: <id>`, `copilot: <name>`, and `help`. In practice, normal natural-language requests still work best, and commands are mostly useful for messaging channels where you want quick operational control.

Server and Updates

- Run options control internet access, email access, approval mode, and fast mode.
- Show Thinking reveals reasoning blocks for supported models.
- Use Start, Reset, or Stop to manage the backend.
- Updates preserve settings, memory, and custom skills.

Shortcuts and UI Tips

`Enter` | Send message
`Shift + Enter` | Insert a new line
`Escape` | Close the current overlay

- Use New Chat whenever you want a clean thread with the welcome screen.
- Use the Active pill to switch between running workflows.
- The left sidebar keeps History, Schedules, and Identity available without leaving the current page.
- The browser pane can be refreshed, expanded, or collapsed from its own controls.
- The schedule picker next to the composer turns the next message into a scheduled run.

Technical: Memory and Context

The system uses several context, memory, routing, execution, and persistence layers at once. They are not interchangeable. Some exist to answer the current request, some exist to preserve continuity, and some exist only so the runtime can inspect itself and improve future runs.

Reading guide

- Start with the lifecycle if you want the shortest end-to-end explanation of what happens from message send to final answer.
- Jump to routing and orchestrator sections if you want to understand how the app decides between direct replies, fast paths, and full workflows.
- Use the memory, tooling, and frontend sections if you want to understand where continuity, side effects, and UI updates actually come from.

Architecture at a glance

    Composer/UI
       -> request packaging + attachments + session binding
       -> backend routing + task understanding + context assembly
       -> direct reply OR deterministic fast path OR full orchestrator
       -> validation + fallback/replan/clarification when needed
       -> final report + session history + memory/log side effects

    Cross-cutting layers:
       settings/keyring | managed integrations | tool registry | memory/wiki/user profile | websocket events

End-to-end request lifecycle

1. User input enters the composer. A request may contain plain text, follow-up wording, attached files, attached folders, selected cloud items, scheduled timing, and whatever session is currently bound in the UI.
2. The frontend packages the request. The browser sends the message to the backend together with the active session id, attachment references, scheduling data, and the relevant UI toggles such as model selection or internet access.
3. The backend restores live state. The server resolves settings, active model choices, auth state, connected providers, current session context, and any prior workflow state needed for continuation.
4. Request classification begins. The runtime decides whether the goal is direct chat, a fast deterministic action, a live follow-up on prior tool output, or a full orchestrated run.
5. Context is assembled. The system merges the current message, active session history, stored lookup records, attached context, managed context sources, relevant durable memory, and user identity where appropriate.
6. Routing chooses the cheapest safe path. If the task can be solved deterministically, the app stays out of the heavy workflow. If not, it escalates into the orchestrator.
7. Execution runs with live progress events. The runtime emits status, step, reasoning, todo, thought-summary, and completion events back to the UI over WebSocket.
8. Validation decides whether to stop or continue. The run can finish, ask a clarification, retry with a fallback, re-plan, or report an issue.
9. Results are persisted. The session transcript, tool trace, selected records, final report, and learning or memory side effects are stored in the appropriate layers.
10. The interface becomes the audit trail. The final answer stays in chat, the session lands in History, and any scheduled or long-lived state remains available for follow-up.

What happens before the model is even called

- Settings load first. The backend reads `settings.json`, resolves secret placeholders from keyring where needed, and determines which providers, channels, policies, and models are currently active.
- Session state is restored. If the message belongs to an existing session, the backend reloads prior messages, selected email or calendar records, stored lookup results, last tool traces, and run metadata used for follow-up continuity.
- Task understanding runs early. The system tries to infer the real task type, such as email lookup, email update, calendar create, calendar move, browser search, filesystem request, or general chat, before it spends tokens on a generic LLM pass.
- Fast-path guards run early. If the product already has a reliable path for a request class, it avoids unnecessary planning and goes directly into the relevant functional runtime.

Context Layers

Current request | Your latest message, live toggles, selected models, browser state, and anything attached to the current send action.
Current session | The active conversation history, recent tool results, run state, and short-range continuity used for follow-up questions.
Attached context | Files, folders, Google Drive items, and OneDrive items attached to the active request.
Managed context sources | Mailbox folders, labels, local folders, and cloud folders configured in Settings > Context so the agent can search them when relevant.
Relevant Memory | Durable user-facing wiki memory such as ongoing topics, important reference threads, and stable preferences that matter in future dialogue.
User Identity | The structured profile in `user.md`. This stores durable personal facts and communication preferences.
Semantic history recall | Search across earlier sessions when older work is relevant but not already present in the active session.
System Log | Operational traces for learning, reflection, corrections, memory maintenance, and server events. This is diagnostic, not conversational memory.

How routing chooses the execution path

- Direct respond path is used for normal conversational answers, lightweight interpretation, and cases where no external action is required.
- Deterministic action path is used when the product can reliably map a request to a purpose-built function such as reading emails, drafting replies, searching a mailbox, or mutating calendar items.
- Context follow-up path is used when the current message depends on earlier results, for example `open the second one`, `summarize the PDF`, or `move that meeting`.
- Full orchestrator path is used when the task needs planning, multi-tool coordination, browser interaction, file work, research, or iterative validation.

The practical goal of this routing layer is to keep simple work fast and stable while still allowing complex tasks to expand into a real agent run when necessary.

What the memory layers are for

- Session memory keeps the current conversation coherent while a topic is still active.
- Wiki memory stores durable user-relevant context rather than low-level engineering incidents or temporary runtime noise.
- User identity stores stable preferences such as tone, language, recurring personal facts, and long-lived user profile details.
- Managed context sources are not memory by themselves; they are curated places the agent may search live when a request needs external data.
- Private sessions are excluded from durable memory and learning.

Functional section map

- Lifecycle explains the chronological flow of one request.
- Routing explains how the app chooses the cheapest correct execution path.
- Orchestrator explains the staged agent runtime for harder tasks.
- Tooling and provider runtimes explain where side effects and structured business actions come from.
- Memory, learning, and frontend updates explain what persists after the answer and how the UI reflects a live run.

How the orchestrator actually runs

1. Planner stage. The planner receives the goal, the current task state, run policy, available tools, prior relevant memory, and any user-supplied context. Its job is not just to brainstorm, but to produce an actionable structure the rest of the runtime can execute.
2. Research stage. If a task needs live information, the researcher gathers it from the appropriate systems: email, calendar, browser, filesystem, managed context sources, search results, or prior workflow artifacts.
3. Curator stage. The curator trims the evidence down to the minimum context that still supports the next decision. This is important because raw research output is often too noisy or too large to pass directly into later stages.
4. Executor stage. The executor calls tools, performs browser steps, updates files, drafts messages, or produces structured outputs. This stage is where most side effects happen.
5. Validator stage. The validator checks whether the objective is actually complete, whether the evidence is strong enough, and whether a retry or re-plan is needed.
6. Report stage. The system converts the internal run state into a user-facing answer, preserving enough detail to be useful without dumping raw internal traces into the final response.

The orchestrator is policy-bound. It tracks maximum steps, maximum tool calls, validation retries, token budgets, runtime budgets, approval rules, disabled tools, and dynamic policy adjustments based on earlier outcomes. This means the runtime is not only trying to solve the task, but also trying to do so within operational constraints.

Tooling model under the hood

- Built-in tools cover browser work, shell commands, workspace search, file access, managed integrations, messaging channels, and other first-party capabilities.
- Custom tools live in the `tools/` folder and are loaded dynamically so you can add project-specific functionality without rewriting the core app.
- MCP tools come from configured Model Context Protocol servers and extend the system with external tool catalogs.
- Approval-gated tools can be marked as sensitive so the runtime pauses before executing them when the approval policy requires it.
- Disabled tools are kept out of planning and execution entirely, which is different from approval gating.

How email and calendar stay reliable

- The product does not treat email and calendar as generic text tasks. It uses dedicated intent extraction, record matching, follow-up resolution, and provider-specific action runtimes.
- Earlier lookup results are stored in structured form so follow-ups can reference `the first one`, `that draft`, or `the meeting tomorrow` without re-inventing selection logic each time.
- Provider scope matters. The runtime can distinguish Outlook versus Google requests, preserve that scope across follow-ups, and still fall back intelligently when both ecosystems are enabled.
- This is why the product can behave more like a task system than a chatbot when you work with inbox and calendar actions.

How attachments and external context are processed

- Attached files are treated as immediate request context. They can be summarized, searched, or passed into the right downstream runtime.
- Attached folders are not blindly inlined. They are indexed so the agent can inspect the folder and open the right file when needed.
- Cloud attachments from Google Drive and OneDrive are normalized into the same execution model so the rest of the runtime can work with them consistently.
- Managed context sources are long-lived, curated search surfaces. They are available across future requests and are different from one-off attachments added to a single message.

How memory, learning, and reflection differ

- Conversation memory exists to answer the next user request better.
- User identity exists to preserve stable profile and preference information.
- Wiki memory exists to keep durable, user-relevant knowledge available across future sessions.
- System log exists to explain what the runtime did internally. It is operational evidence, not user memory.
- Learning rules exist to modify future prompting, routing, or planner behavior when repeated patterns show that the system should adapt.
- Reflection is the app evaluating how a run went so future runs can be more reliable, not simply summarizing the user conversation.

Learning and System Log

- The System Log records corrections, reflections, hypothesis decisions, KPI snapshots, learning updates, memory events, and server starts.
- Repeated correction patterns can be promoted into learning rules that influence future prompt or planner behavior.
- The log is for inspection and debugging; it is separate from the user-facing Relevant Memory shown in Context.
- Older operational log entries are pruned automatically so the log does not grow without bounds.

What the frontend is really doing during a run

- The frontend is not only rendering chat bubbles. It also tracks the active session binding, active run id, visible todo state, thinking visibility, browser preview state, attachment state, schedules, and settings overlays.
- Most long-running work is streamed back over WebSocket as typed events. The UI listens for these events and updates the transcript, progress list, thought bubbles, browser preview, and final report in near real time.
- The result is a split architecture: HTTP handles settings, uploads, and ordinary API calls, while WebSocket carries the live conversational run.

A concrete mental model

Think of the app as five cooperating systems running behind one chat box: a UI session manager, a routing layer, a set of deterministic business runtimes, an agent orchestrator, and a memory and learning layer. The product feels simple from the front, but under the hood it keeps deciding which of those systems should take the lead for the current message.

That is the core design principle of AgentOrchestrator: do not send everything to one giant model prompt. Instead, preserve structured state, choose the narrowest correct path, expose progress, and only expand into a full autonomous workflow when the task truly requires it.

⚠️

### Security & Safety Notice

AgentOrchestrator can perform autonomous actions on your system, including reading and writing files, executing code, sending emails, and fetching external data via the internet.

By using this application you acknowledge the following:

- Autonomous agents can make irreversible changes to your files and system.
- Internet access may expose data to third-party services.
- Email access (Outlook) is used entirely at your own risk and responsibility.
- Generated files and output may contain sensitive information.
- Use in production environments or with sensitive data is entirely at your own risk.

Ensure you have the appropriate permissions for all actions performed by the agent.

## Welcome to AgentOrchestrator

Your AI-powered autonomous assistant. Let's set up the essentials — it only takes a minute.

✓ Choose your install location
✓ Choose your AI models
✓ Connect channels & integrations

The recommended setup uses Ollama plus optional cloud providers. You can change everything later in Settings.

## Install Location

Choose where AgentOrchestrator stores its data — output files, memory, skills, and settings.

📁

### Working Directory

All agent data will be stored in this folder.

Current location
Change location (optional)

📦

### Auto-created folders

These folders will be created automatically:

memory/ output/ tools/ (skills) attachments/ downloads/

## AI Models

Ollama runs locally on your machine. The recommended profile uses GLM as the main cloud model, GPT-OSS as the fast cloud model, and local Qwen as fallback.

🏠

### Ollama Required

Local runtime with optional Ollama Cloud access for GPT-OSS cloud models.

Checking…

Recommended profile: glm-5.1:cloud main · gpt-oss:20b-cloud fast · qwen3.5:9b fallback.

For Ollama Cloud models: sign in locally first with `ollama signin`. The Qwen fallback stays local.

Open Ollama account → Command: `ollama signin`
🤖

### OpenAI Optional

GPT-4.1, o3, o4-mini and more cloud models.

API Key Get your OpenAI API key →
💎

### Google Gemini Optional

Gemini 2.5 Pro, Flash and more from Google.

API Key Get your Gemini API key →
🟢

### NVIDIA Cloud Optional

NVIDIA-hosted models via build.nvidia.com.

API Key Get your NVIDIA API key →

## Internet Search

Agents can search the web. A built-in fallback works without a key, but Brave gives better results.

🔍

### Built-in Search Included

DuckDuckGo-based search. Works out of the box, no key needed.

✓
🦁

### Brave Search API Optional

Premium search results with Brave. Free tier available.

API Key Get your Brave API key (free) →

## Channels

Connect messaging channels so you can control your agent from anywhere.

💬

### Slack Optional

Control the agent from Slack via Socket Mode.

Bot Token App Token

Create a Slack app at api.slack.com. Enable Socket Mode.

📱

### WhatsApp Optional

Send commands via WhatsApp. Turn it on here, then scan the QR code later in Settings.

No credentials required. After setup, go to Settings → Channels → WhatsApp to scan the QR code with your phone.

✈️

### Telegram Optional

Control the agent from a Telegram bot chat.

Bot Token

Create a bot via @BotFather on Telegram and paste the token here.

## Integrations

Connect external services so agents can read email, manage calendar, and access files.

📧

### Google Workspace Optional

Gmail, Google Calendar & Drive access for agents.

Client ID Client Secret

Get credentials from Google Cloud Console. You can authorize after setup in Settings → Integrations.

📬

### Outlook Windows Only

Read & send email via Outlook Desktop. No key needed.

## You're All Set!

Here's a summary of your configuration:

You can change any of these later in Settings (gear icon).

/ Root
Loading…

### Server Offline

The backend server is not running.

Checking launcher...