This page explains the terms you will see while using Pioneer. It stays at the product level. See Architecture for implementation details.
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 and secrets, 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.
The gateway is where work happens; the client app is how you control it.
That rule matters because the gateway owns execution and enforcement. If the gateway is on your laptop, tool work is planned and checked against your laptop environment. If the gateway is on a server, the same permission and sandbox/resource policy applies to the server environment.
Desktop, mobile, and other clients
The desktop app gives you the full native 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.
The mobile app connects iOS and Android devices to existing gateways. It stores remote gateway tokens in platform secure storage and does not start a local gateway process on the phone.
Pioneer is not limited to the official apps. The gateway exposes a protocol that other clients can use too. That means custom clients can be built on top of Pioneer 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 create more workspaces, switch between them, and rename them from the workspace selector in the main thread sidebar.
Use separate workspaces to organize different projects, clients, or experiments inside one gateway. Each workspace can also have its own provider keys, MCP servers, skills, task schedules, and artifacts.
Use separate gateways when the work needs a different machine, filesystem, network, account, or security boundary.
Threads
A thread is a conversation inside a workspace. In a normal collaborative thread, sending a message starts an independent piece of work instead of freezing the whole conversation until the agent finishes.
Use a new thread when you want fresh context. Keep coding, research, planning, and tool testing in separate threads when that makes the work easier to follow. Long threads can be useful, but they also accumulate assumptions.
You can keep typing while work is running. Send a follow-up, start another piece of work, or switch to another thread without waiting for the previous request. Each request keeps the model, provider, reasoning level, permission mode, skills, attachments, and runtime settings that were selected when you sent it.
The timeline shows a separate work card next to the message that started it. The card shows whether the work is running, completed, failed, or interrupted, and how long it has been running. Open the card’s child conversation when you want to inspect the agent’s detailed work, send a follow-up there, or stop it. When the work finishes, its result is delivered back to the original thread and can become part of the continuing conversation and memory processing.
Some internal or direct-message thread types still use foreground execution. The client follows the execution behavior assigned to the thread; it should not infer it from whether the thread is visible in the sidebar.
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 recalled when they are useful. Chat mode does not mutate memory.
If you ask Pioneer to forget something, memory creates a tombstone so stale search payloads are suppressed later.
Thread context
Thread context is Pioneer’s searchable memory of conversation history. It is not the same as durable memory.
Keep the distinction clear:
- Durable memory is for facts Pioneer should keep, such as “my name is Alexander” or “this project uses a hook runtime.”
- Thread context is for old discussion fragments, such as “what did you say yesterday in that research answer?” or “continue from the API plan we discussed earlier.”
Pioneer indexes visible conversation items into a separate thread episodic store. Later, active recall can search that store and include only the most useful snippets in the prompt. This is how Pioneer can use old thread context without sending thousands of old messages every time.
Thread context is bounded and best-effort. It helps continuity, but it is not a guarantee that every old line will be recalled. If something is a long-lived fact or project rule, it should become durable memory instead.
Artifacts
Artifacts are files owned by the gateway: uploaded images, PDFs, CSVs, logs, generated reports, screenshots, and agent-created outputs.
Artifacts matter because Pioneer may run on a different machine than your desktop. A local file path from your laptop is not useful to a remote gateway. Uploading a file as an artifact gives the gateway a real copy that can stay linked to the thread.
Pioneer also uses artifact references for continuity. If a recent history message or recalled thread snippet had an attached file, the model can see a compact reference to that file. It does not automatically receive every old file. If it needs the content, it can request the artifact tool domain and read that specific artifact.
That means follow-ups like “look again at the car photo” can work without attaching every photo from the whole thread to every turn.
Providers and models
A provider is where API-backed models come from. Anthropic, OpenAI, Google, OpenRouter, Azure OpenAI, Bedrock, Ollama, and supported OpenAI-compatible endpoints are provider choices. CLI-backed agent tools such as Codex CLI are configured separately from ordinary API providers.
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 and CLI runtime settings are configured on the gateway. Provider secrets are stored in that gateway’s keystore. If you connect to a second gateway, it needs its own provider and runtime 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.
Treat tool access as real work inside the gateway environment. Permission modes and sandbox/resource policy let Pioneer ask, allow, audit, or block file writes, commands, network actions, skill tools, MCP writes, computer use, and subagent launches.
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 configuration can include secrets such as environment variables or HTTP headers. Pioneer stores the secret values in the gateway keystore instead of showing them back in ordinary configuration.
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.
An asynchronous message and an explicit task serve different purposes. A message in a collaborative thread can run independently in the background. Use an explicit task when the work needs a durable schedule, dependencies, retries, deliveries, write locks, or a repeatable workflow. Both have visible lifecycle state, but tasks add a durable automation contract.
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.
Further reading
Use this page for product vocabulary. Use Architecture when you want the implementation model.
