Core concepts
Understand the small set of building blocks used throughout Guest Machines.
Guest Machines treats agents like programs: they accept input, use tools and knowledge, call other agents when allowed, and return output. The product builds on that model with a few reusable concepts.
Chat
A chat is a conversation with an agent. Use it to explore a problem, test behavior, and iterate before introducing automation.
Agent
An agent is a reusable AI worker with a purpose, instructions, model, tools, knowledge, and execution policy. An agent definition is the program; each execution is a run.
Knowledge
Knowledge is the context an agent can retrieve from files you upload. My Files holds private working material. Workspace Library holds material intentionally shared with the rest of the workspace.
An agent's knowledge access selection can narrow retrieval to specific files and folders from either location. It does not override the files' visibility permissions.
Team
A team is a group of agents that answer one request together. A team's work style decides how the request is broken up and how member output is recombined — one agent handles it, agents work one after another, plan first then divide the work, review before answering, or split the work then combine it. Members can carry an optional role label describing what each agent is there for.
A team takes an agent's place wherever work is started for it: a pipeline step, a schedule, or an inbound webhook.
Pipeline
A pipeline is a repeatable sequence of steps. Steps can map inputs and outputs, skip work conditionally, retry failures, or hand off to a backup agent.
Run
A run is one execution attempt. Its execution status and verification status answer different questions: Completed means execution finished, while Checks passed means Guest Machines ran every required result check and all passed. A completed run can show Not checked, so completion alone is not a claim that the output is correct.
Verification is check-scoped. For example, an output-schema check means the platform locally validated one exact JSON result against the run's configured Draft 2020-12 contract. It proves the declared structure, not that the facts are true or that the result solved the task well. A schema mismatch fails the run; execution that pauses, is cancelled, or fails before producing a terminal result is not evaluated by the output verifier.
A run can also be required to create at least one downloadable file. The API
calls this setting require_artifact=true. The run shows Checks passed only
after it creates a file; finishing without one fails both the run and its result
checks.
Creating or providing a file when this setting is off does not, by itself,
verify the run's result.
Open Run Files to find every downloadable file you can access in the workspace. Supported files can be previewed there without downloading them. You can also download a file, use it in another run or automation, add an independent copy to Knowledge, or remove uploads and run outputs you manage. A file cannot be removed while an active run is still using it; the page shows which runs must finish or be stopped first. A Knowledge copy has its own lifecycle, so removing either copy does not remove the other. When the source was a run output, the Knowledge copy also keeps that run link.
Every workspace has a shared run file storage allowance. A file starts using space as soon as it begins saving, and deleting a file frees that space after cleanup finishes. The Usage page shows storage used, available storage, the file limit, and files still being saved. It also reports Files used by runs as activity: reusing the same file in three runs counts as three uses, but it remains one stored copy and does not use more storage.
Adding a run file to Knowledge creates an independent copy. The original uses run file storage and the new copy uses Knowledge storage; either can then be removed without deleting the other.
In a shared workspace a run also carries three optional attribution tags — project, ticket, and cost center. They are a reporting dimension and nothing more: a tag never changes whether a run is admitted, what it costs, or which budgets and limits apply to it. Child runs inherit their parent's tags, so a fan-out or a pipeline reports as one unit of work rather than as scattered fragments. Personal workspaces have no attribution, because there is nobody to charge the work back to.
Events, tool calls, child runs, output, verification evidence, errors, and resource usage provide the operational record of what happened. A run can also stop part-way and wait for a person — to answer a question, approve a tool call, or approve a plan — until someone responds.
Trigger
A trigger starts work without a person clicking Run. Guest Machines supports scheduled work and inbound webhook flows.
A trigger points at exactly one target: an agent or a team. You choose the target when you create the trigger and it stays fixed for the trigger's life, so sending the same work somewhere else means creating a new trigger. Add a trigger only after the agent or team behind it is stable. Build a team covers what a team must satisfy before it accepts one.
In a shared workspace a trigger also carries its own attribution tags. Nobody is present when a schedule fires or a webhook arrives, so there is no launch form to ask at: the tags belong to the trigger's configuration, and every fire stamps them onto the run it starts. An untagged trigger produces untagged runs, so tag it when you create it rather than after it has been running for a month.
A trigger can also provide the same files on every run. Choose a file from a completed run, then add it while creating or editing the schedule or inbound webhook. The platform checks that the file is still available and that the trigger's owner can still use it each time the automation fires. For a team, the file's short name must match one of the file assignments in the team's settings so it reaches the intended members.