A Pioneer thread is not just a chat transcript. It is a record of what happened.
That record matters because agents can call tools. A good answer is useful, but the timeline shows how the answer was produced: which model responded, which tools ran, what each tool returned, whether anything failed, and whether anything changed.
Read The Timeline
When a turn is simple, the timeline may only show your message and the assistant response.
When a turn uses tools, open the tool events. Check the tool name, arguments, working directory, file paths, output, error output, and whether the tool changed anything. This is especially important on remote gateways, where a path that looks local may actually belong to a server.
Tool calls execute on the gateway host. In a remote gateway thread, commands and file paths belong to the remote machine.
Delegated Work In The Timeline
In Agent mode, a parent turn can create attached subagent tasks. Each subagent runs in a hidden child thread, but the parent timeline still shows the task activity: task creation, child progress, task waits, review-required candidates, revision requests, accept decisions, and final task completion.
When a subagent result needs review, the parent agent does not have to accept it immediately. It can call task_revise with concrete feedback. Pioneer then records the rejected candidate, starts a revision turn in the same child thread, and shows the revised child activity under the parent workflow. When the parent accepts the revised candidate, the task completes and the accepted result becomes the task result.
Use the timeline to audit multi-agent work: expand the task items, read the child result summaries, check parent review feedback, and confirm which candidate was accepted.
Start With Narrow Prompts
When you are learning a project or testing a gateway, ask for read-only work first:
Inspect the repository and summarize the major folders. Do not modify files.
Find where provider keys are configured. Do not print any secrets.
Explain what you would change first, but do not edit files yet.
Update only the README. Do not modify source code. Summarize the exact changes when done.
Fix the failing CLI test. Keep the change scoped to the CLI crate unless you find a direct dependency.
Keep Threads Clean
Use one thread for one goal. A thread that starts as research and turns into edits, deployment, provider debugging, and task design will become hard to reason about.
Start a new thread when the goal changes. Put high-risk tool work in its own thread. Give threads names that make sense when you come back a week later.
When Something Fails
Open the failed item first. Provider errors usually point to API keys, model names, quota, endpoint, or network access. Tool errors usually point to permissions, missing commands, wrong working directories, timeouts, or file paths that exist on one gateway but not another.
If the error is unclear, retry with a smaller prompt. Ask the agent to inspect and explain before asking it to fix.
Attachments
Use attachments for screenshots, logs, text files, and documents that are directly relevant to the thread. Avoid dumping unrelated context into a thread just because it might help. Smaller, cleaner context usually produces better behavior.
Uploaded files and agent-created files are stored as workspace-scoped artifacts. See Artifacts for upload, preview, download, and reuse workflows.
The composer add button can attach files or folders, skills, and MCP capabilities. Skill and MCP selections appear as chips above the input, just like file attachments, and are scoped to the next turn. They are not inserted into the message text.
When a turn is sent, file, skill, and MCP chips are rendered on the user message in the timeline. For MCP, you can attach either a whole server or individual tools; selecting the whole server is the server-level choice for that turn.
Use AGENTS.md when you want persistent instructions to apply automatically to threads in a folder or across the whole thread tree. 
