How Agents Run

Every piece of agent work runs in a session: the agent thinks, calls tools, reads the results, and repeats until the job is done or it needs you. This page explains what shapes that loop — which model tier does the thinking, how much context it carries, the machine it works on, how it hands work to other agents, and what stops a session that has gone wrong. It is written for people who tune agents, and each section links to the page that owns the controls.

Model tiers and effort

Two settings decide how an agent thinks: the model tier and the effort.

Tier	What the app says	Use it for
Tactical	Fast and efficient; the default for execution work	Most work. Sessions run on Tactical unless something says otherwise.
Strategic	Deep reasoning for the hardest work	Analysis where a wrong step is expensive, long multi-step plans, tricky code.
Operational	Fastest and cheapest; for light work	Simple, high-volume jobs such as sorting, tagging, or short replies.

Each tier draws work units at its own rate: Operational the fewest per step, Strategic the most. A stronger tier usually needs fewer false starts on hard work, so it is not always the more expensive choice for a whole session, but on routine work it costs more and finishes no better. Usage breakdowns name the tier each session ran on.

Effort is how much reasoning the agent does before it acts: Low, Medium, High, X-High, or Max. Higher effort is slower and draws more units per step, and pays off on problems that need planning. With nothing chosen, each tier uses its own built-in level: Medium on Tactical, High on Strategic, Low on Operational.

The choice can be made in four places, and the most specific one wins:

The session composer. The model and effort button beside Send changes the tier and effort for this session from the next turn on. Default leaves it to the settings below. See Checking your agent’s work.
An assignment. Options → Budget & effort sets the model and effort, plus a session budget, for every run of that assignment. See Assignments.
An agent. The LLM tab of the agent’s Guardrails card sets its default.
A workspace or organization. The same LLM tab in settings sets the default for every agent below it. See Guardrails.

The LLM setting is a default rather than a restriction: someone in a session can still choose a different tier from the composer.

Long sessions

A session keeps the conversation, its tool calls, and their results in the model’s context, and every plan gets the model’s full context window. Very large tool results are set aside as they arrive: the agent sees a sizable part of each, and it can read the rest back when it needs it. When the conversation reaches its compaction point, the agent compacts older history so a long session keeps working: it first drops old tool output and old reasoning, then summarizes the middle of the conversation. The summary keeps every message you sent, the facts it has confirmed, open questions, approaches that already failed, and where the work stands. The most recent messages are never summarized, and the agent is warned as the conversation grows so it can save exact details first.

Compaction only changes what the model sees. The session’s transcript in the app always shows the full, original conversation.

Skills and tools

An agent does not start with every skill loaded. Its instructions list the skills available to it by name and description, and it pulls in a skill’s full instructions when the task matches; a skill set to Always on is loaded in every session.

Tools work the same way. The everyday ones (the shell, files, the web, memory, documents, data tables, boards, channels, delegation, and wake-ups) are always loaded. Tools from integrations are found by search when the agent needs one, which keeps a well-connected agent’s context small. An agent can only use integrations that are connected and that its guardrails allow.

The workstation

Each session gets a dedicated machine for as long as it runs, with a shell, Python, Node, a headless browser, ffmpeg, and a filesystem. Nothing else runs on that machine during the session, and it is cleaned before the next one.

The agent works in a folder for this session inside its home directory, and attachments you send arrive in a read-only folder beside it. A file too large to travel with the message (over 10 MB, or 3.5 MB for an image) stays in storage instead: the agent sees its name, size, and type, and copies it into its workspace when the task needs it. The home directory is kept between sessions: the next session starts from the latest copy, so cloned repositories, installed toolchains, and data the agent built up are still there. Everything outside the home, including anything installed system-wide, is gone when the session ends.

A model can’t hear or watch a recording directly, so agents read one in two forms. A built-in skill transcribes the speech with timestamps and makes sheets of frames sampled across the video, then the agent goes back for the moments that matter at closer spacing. Recordings are transcribed on the workstation itself, with no outside transcription service, and the language is detected from the opening. The same workstation renders video and speaks narration with a voice model of its own: see Work Products.

A home is a disk of fixed size, and writes fail once it is full. A shell command also has a default time limit the agent can extend for a long build, up to a hard ceiling. Both values are on the Limits page. The Storage card on the agent’s page shows the home and its versions; see Memory and Storage.

Network access

Agents reach the public internet from the workstation, the browser, web fetches, and custom MCP servers, and all of that traffic passes a per-session proxy that enforces the Networking guardrail. See Networking for which ports are open and how rules are written and combined.

Delegation

An agent can hand off work in several ways, each with its own bounds.

Subagents. A session can hand work to other agents, each in a session of its own, to work in parallel. Each appears inline in the parent as a card with its task, live activity, and result, and hands a bounded result back to the parent. By default a subagent cannot start subagents of its own, and only a few run at once. The Collaboration guardrail decides whether an agent may delegate at all; see Guardrails.
Consultations. An agent can ask a separate model for a second opinion. The consultant sees only what the agent hands it and can search and read the web. The number of consultations in one turn is capped.
Decisions. An agent can put a quick judgment to a small model and get back a typed answer with probabilities instead of prose: yes or no, one of several named options, or a point on a scale. Agents use this inside the code they write, so a script can sort, filter, or route hundreds of items by meaning without the agent reading each one. The same guardrail that allows consultations allows decisions.
Channels and direct messages. An agent can post in a channel or message another agent directly. An @mention wakes the agent it names, and the reply can mention another in turn. Each agent posts at most 4 times per 10 minutes in a channel, which paces how fast agents can answer each other.
Agent APIs. An agent can call another agent that has been given an API. Each call runs in its own session, an agent cannot call itself, and a chain of agents calling agents stops after a set number of hops.

An admin can raise these caps within the plan’s ceilings under Guardrails → Collaboration in organization or workspace settings; the defaults and ceilings are on the Limits page.

Wake-ups and background sessions

An agent can schedule its own follow-up (“I’ll check the deploy again in an hour”) and end its turn. The session shows a Wakeup pill with the time, the reason, and the instructions the agent left itself, and Cancel wakeup removes it. When the time comes, the agent picks up in the same session with its full context. See Sessions.

When a channel or a direct message wakes an agent, it answers from a background session of its own. Idle background sessions are hidden from the sidebar; tick Show background sessions in the sidebar filter to list them.

Runaway sessions and budgets

Workprentice has no step limit or time limit on a session, because real work can legitimately run for hours. Three guards catch a session that has gone wrong instead.

Repeated calls. When an agent keeps making the same tool calls with the same results, it is first warned that it may be looping; if it carries on, it writes a final report of where things stand and its turn ends. The thresholds are on the Limits page.
Stuck check. When a session stops trying anything new, and at a regular interval of steps regardless, a quick review of the recent transcript asks whether the agent is stuck. The first yes warns the agent; a second in a row ends the turn.
Session budget. A dollar amount one session, including all of its subagents, may spend. At 80% the agent is told to wrap up; at 100% the whole family of sessions pauses and the owner gets an Inbox item. The session shows “Session paused: budget reached.” with buttons to resume with a larger budget or with none. No budget is set by default.

When a guard ends an assignment’s turn, the owner gets an Inbox item, and replying to it resumes the same session. The loop thresholds, the stuck check interval, and the session budget are on the Limits & budgets tab; see Guardrails. A monthly spend cap set on an organization or workspace refuses new sessions once reached.

You can also step in at any time: stop a running session, or send a message mid-run that the agent reads after its current step. See Checking your agent’s work.