Agents and jobs

An agent is an autonomous worker that receives a job, reasons about it with an LLM, uses tools from a Virtual MCP, produces artifacts, and reports a result. A job is a single unit of work handed to an agent.

What an agent is made of

  • Skills: markdown instructions packaged with the agent that describe how it should behave.
  • Tools: an attached Virtual MCP grants the agent access to every tool in that bundle.
  • LLM: the model the agent reasons with (OpenAI, Anthropic, or Gemini providers).

The platform provides the runtime, workspace isolation, state management, LLM access, and tool access. The intelligence lives in the agent’s skills and its tools.

Jobs

Each job is independent and moves through a clear lifecycle:

Queued -> Running -> Completed | Partial | Failed | Cancelled

A job carries:

  • Input: a prompt message, metadata key-value pairs, and optional input files.
  • Configuration: an optional timeout override and callback URL.
  • Workspace: an isolated storage prefix for the job’s files.
  • Output: artifacts (files), a structured result summary, and a text reply.
  • Session: the full conversation trace as structured cells.

Jobs do not share state. Each job gets its own workspace and its own memory; there is no conversation continuity between jobs.

Workspaces

Every job runs in an isolated workspace with a predictable layout:

input/     files uploaded when the job was submitted
output/    artifacts the agent produced (the deliverables)
scratch/   intermediate working files

The agent reads and writes files in this workspace through built-in tools. Session and bookkeeping files are kept outside the agent’s view so it cannot tamper with its own execution record.

Sessions

A session is the full trace of a job’s execution: a sequence of cells, like a notebook. Each cell records one atomic event.

Cell typeContent
userThe initial job message or injected system messages.
assistantAn LLM response.
tool_callA tool name plus its arguments.
tool_resultThe tool’s output.
systemSystem events, such as a compaction summary or timeout warning.

The console renders sessions as structured cells: responses as markdown, tool calls as collapsible blocks, and results as output. This replaces opaque log lines with a readable, inspectable trace.

Agent bundles

An agent is deployed as an Agent Bundle: a .zip package with a single entry point and an optional .agent/ directory holding everything the agent loads at runtime.

support-triage.zip
├─ AGENTS.md                          entry point (required): system prompt + metadata
└─ .agent/
   ├─ skills/<name>/SKILL.md          skills, loaded on demand via the skill tool
   └─ agents/<name>/AGENT.md          sub-agents, spawned via the task tool

AGENTS.md at the root is required; skills and sub-agents live under .agent/. The full format, frontmatter fields, and packaging rules are documented in the Agent Bundle specification.

Deploying an agent

Package your agent’s bundle, upload it, attach a Virtual MCP, and submit jobs. The CLI streamlines packaging and deployment; see CLI usage.

Next steps