Pioneer has a few terms that are worth understanding before you go deep. This page explains them from the user’s point of view. It does not try to describe the internal architecture.
Gateway
The gateway is the center of Pioneer. When something important happens, it usually happens in the gateway.
It talks to model providers, stores Pioneer data, stores gateway secrets in keystore.db, keeps editable identity files in runtime home, runs tools, manages skills and MCP servers, owns tasks, and streams results back to connected clients. You can run a gateway on the same computer as the desktop app, or on another machine.
A good rule: the gateway is where work happens. The desktop app is how you control it.
That rule matters because tools run on the gateway host. If the gateway is on your laptop, tools touch your laptop environment. If the gateway is on a server, tools touch the server environment.
Desktop App And Other Clients
The desktop app is the main Pioneer client today. It gives you the UI for gateway connections, workspaces, threads, providers, skills, MCP servers, tasks, and settings. It can also start and manage a local gateway when you use Pioneer on one computer.
Pioneer is not limited to the desktop app. The gateway exposes a protocol that other clients can use too. That means custom clients can be built on top of Pioneer, and mobile clients can connect to gateways in the same product model.
Gateways And Workspaces
A gateway is the larger environment. A workspace is the container where your threads, skills, MCP servers, tasks, and settings come together.
The desktop app creates a default workspace on first launch. You can also create additional workspaces, switch between them, and rename them from the workspace selector in the main thread sidebar.
Use separate workspaces when the work should be organized separately inside the same gateway: different projects, clients, experiments, provider keys, MCP servers, skills, task schedules, or artifacts.
Use separate gateways when the execution environment should be different: different machine, different filesystem, different network, different accounts, or different security boundary.
Threads
A thread is a conversation inside a workspace.
Use a new thread when you want fresh context. Keep one thread for a coding task, another for research, another for planning, and another for testing tools. Long threads can be useful, but they also accumulate assumptions. Starting a new one is often cleaner.
Each thread has a timeline. The timeline shows messages, model output, tool calls, tool results, errors, retries, and final responses. When something surprises you, read the timeline before changing settings.
Agent Memory
Agent memory is durable context that can be useful beyond the current thread. Pioneer can remember stable facts, preferences, recurring instructions, communication style, and project decisions, then recall them in later agent-mode turns.
Memory is different from thread history. Thread history is the conversation transcript. Memory is a smaller set of durable facts stored by the gateway and searched through the memory service. Agent mode can register memory tools and add a Memory Recall prompt section; preflight or request_tools decides which memory tools are visible in a given turn. Chat mode does not mutate memory.
If you ask Pioneer to forget something, memory creates a tombstone so stale search payloads are suppressed later.
Providers And Models
A provider is where models come from. Anthropic, OpenAI, Google, OpenRouter, Azure OpenAI, Bedrock, Ollama, and local OpenAI-compatible servers are all provider choices.
A model is the specific model you choose for a thread or task. Models differ in speed, cost, context size, reasoning ability, and tool behavior. You can use one model for quick chats and another for more careful work.
Provider credentials are configured on the gateway and stored in that gateway’s keystore. If you connect to a second gateway, it needs its own provider setup.
Tools let agents do work outside plain text. Depending on what you enable, tools can read files, search directories, run shell commands, apply patches, fetch web pages, download URLs, call MCP tools, or use dynamic tools from skills.
Tools are currently not sandboxed. Treat tool access as real access to the gateway machine.
Skills
Skills are installable capability packages. A skill can add instructions, workflows, checks, or dynamic tools that Pioneer can use later.
Use skills when you want behavior that should be reusable instead of pasted into every prompt. A writing skill, a repository-review skill, or an internal workflow skill can make Pioneer behave more consistently across threads and tasks.
Skills are controlled by the gateway and the current workspace, so the same desktop app can connect to different gateways with different skill sets.
Installed skills are explicit-only by default. In a thread, attach a skill from the composer add button when you want it for the next turn; make a skill implicit only after you trust it and want Pioneer to consider it automatically.
MCP Servers
MCP servers connect Pioneer to external tools and resources through Model Context Protocol.
Think of MCP as a way to bring an existing system into the gateway: a database, a company API, a project management tool, a filesystem helper, or a SaaS integration. Once connected, the gateway can expose those MCP tools to agents according to the current gateway and workspace configuration.
MCP install rows keep redacted configuration and secret refs. The actual secret values from env and headers live in the gateway keystore.
MCP servers are also explicit-only by default. In a thread, attach a server or specific tools from the composer add button when you want that capability for the next turn.
Tasks And Subagents
A task is repeatable work managed by the gateway. It can run manually, on a schedule, or as part of a larger workflow.
Subagents are agents created by the task system. In many workflows you do not manually delegate to them. Pioneer can create subagents, give them instructions and model settings, let them work in child threads, and bring their candidate results back to the parent.
For attached subagent work, the parent agent reviews the candidate result before it becomes final. It can accept the result or ask the same subagent to revise the work with specific feedback.
Tasks are useful when the work has shape: check this repo every morning, summarize a feed, run a repeated research pass, prepare a report, or coordinate several smaller agent steps. 
