Jobs

Nearly everything the platform does happens as a job: discovery, to-be generation, implementation, merges, test runs, index refreshes. The Jobs page is where you find out what is happening, what is waiting on you, and what went wrong.

The groups

Every job status is in exactly one group, and none is hidden. That is deliberate — a job in no group would be a job doing work you cannot see.

Group	What it holds
Queued	Accepted, not started
Running	In flight now
Needs attention	Stopped and waiting on a person
Open	Started, neither finished nor waiting
History	Finished, whatever the outcome

Finished background polling jobs are hidden from the list. They are how the platform keeps itself up to date, they run constantly, and showing them would bury everything else.

Needs attention

This is the group to read first, because it is the one that will not clear itself. A job lands here when it needs something only you can supply — most often a preflight answer, a decision, or a clarification where your installation has agent questions enabled.

Cancelling

You can cancel a running job.

• Cancelling is recorded as cancelled, not failed. The history distinguishes "we stopped this" from "this broke", which matters when you are looking back at why a feature took three attempts.
• Cancelling a feature's background job leaves the feature's status untouched. Stopping a job is not a statement about the feature it was working on.
• An interrupted implementation is paused, not ended — see Implementing a feature.

Memory

Every agent step runs in two containers, each with its own memory limit: the agent itself, and its Docker sandbox, which holds everything the agent starts with Docker — the dev stack, test databases, browsers. When either reaches its limit, the kernel kills a process inside it, and the job fails or stalls with nothing else to say why. The Queue shows it.

• A running agent shows two meters on its In Progress row, Agent and Docker, each as used against its limit. A bar turns amber at 90% of its limit. A job running several agents at once shows the one closest to its limit, labelled with how many are running ("2 agents"). A job between steps has no agent running, so it shows no meters.
• A process killed for memory puts an Out of memory badge on the row and names the limit to raise. On a running agent the meter counts the processes killed in this step.
• After the job has ended, the badge stays. Each step records how high its containers' memory went and how many processes were killed before the containers are removed, so a failed job still says, for example, "Agent peaked at 8.0 / 8 GiB · 12 processes killed". A job that was never short of memory shows nothing extra.

Both limits are under Container resources in the project's General settings — Agent container and Docker sandbox — and the hint's Project Settings link goes straight there. A step already running keeps the limit it started with, so a new limit applies from the next run.

Agent Logs

Jobs tell you what ran. Agent Logs tells you what an agent did: a single timeline of its steps, the files it touched, and what it said along the way.

Some specifics worth knowing when you are reading one:

• The log lists jobs, not agent sessions, so a job that resumed is one entry rather than several.
• Background poll jobs are hidden here too.
• A resumed run's log shows the session it continued, rather than starting blank.
• The Session started entry names the model and counts the tools and skills the agent was given. Expand it, then use Show skill names to see which skills the agent could load — the how-to guides it reads when it reaches a step they cover. A run given no skills shows no such control.
• Memory injected at start lists the project memories the agent was handed when it started, in the order it received them. A run that compacts its context is handed memory again, shown as Memory injected after compaction. Show raw context shows the exact text the agent read.
• Memory search shows what the agent searched its memory for and which memories came back. A result too large for the agent's tool is marked Too large: the agent was handed a file instead of the results.
• View next to a memory opens it on the Memory page. A memory forgotten since the run stays listed as Forgotten.

Memory

Agents remember what they learn about a project, and hand it to later runs. Operations → Memory shows every memory the project holds, newest first.

• The newest 50 are handed to every new run; a line in the table marks where they end. Older memories are reached only when an agent searches for them.
• Injected is how many runs started with a memory, and Found how many runs' searches returned it. The page says from which date runs are counted.
• Select a memory to read it and see every run that used it. Open log takes you to that run's agent log.
• Search finds memories the same way an agent's memory search does.
• Forget removes a memory that is wrong or out of date, so no later run is handed it. Forget takes effect after 30 seconds; until then Undo brings it back. Only project editors can forget a memory.

Talking to an agent while it runs

Every agent can ask you things in its agent chat, and you can tell it things, without waiting for it to finish. Open a run from Running agents, from Agent Logs, or from the feature it works on. This is on for every project unless it has turned off Agents can ask you and hear from you in Project settings; with it off, agents run without stopping, as they did before.

The chat opens with Prompt, collapsed: what the agent was told when it started. Expand it to read the whole thing. A resumed run shows the message it was resumed with under its own heading.

When the agent has a question. If its task, the project's design, specifications and code, and its instructions do not settle a decision, the agent asks you instead of guessing. A card titled The agent has a question appears in the chat. A choice question has a button per option (radio buttons when it takes one answer, checkboxes when it takes several); you can pick an option and add detail to it, or choose None of these — describe your own answer. A free-text question has a box to type in. Choose Send answer when every question has an answer, or Let the agent decide if you have no preference, and it carries on with its own best judgment and says what it assumed.

When the agent wants to run something it needs your approval for. The agent works under a safety check that approves routine actions on its own. When the check hands an action back to you, a card titled The agent is waiting for you shows what it wants to run and why:

• Allow lets it run this once.
• Always allow lets it run, and every later agent run in this project runs that command without asking. A command the safety check always reviews cannot be allowed this way.
• Deny stops it. Choose + Add a note first to tell the agent why, or what to do instead.

An action the safety check refuses outright is shown in the chat as Blocked, with the reason. It cannot be approved; the agent will ask you what to do instead when it needs to.

The run waits for you. There is no time limit on a question or an approval, including in a background job nobody is watching, so keep an eye on Waiting for you. While one is waiting, Running agents shows the run as Waiting for you, the notification bell has a Needs your input entry, and if you have turned on desktop notifications your browser notifies you once. Cancelling the run, or the run ending, withdraws the question.

Telling the agent something. Type in Message the agent… under the chat at any time. While the run is working, the agent reads your message at its next step; if it is waiting for your answer to a question or approval, your message is marked Queued and it reads it once you have answered. Each message you send appears in the conversation, at the point the agent read it, and reads Delivered once it has. If the run stopped before finishing (it failed, timed out or was cancelled), sending resumes it with your message. A run that finished cannot be continued from the chat: start a new run to change its result. Only project editors can answer the agent or message it.

When several agents run in one job, each has its own questions; a message goes to whichever agent reads it first.

Approvals depend on the model: the safety check runs with Sonnet, Opus and Fable models on a project that connects to Anthropic directly. On other models or connections the agent works without asking for approval, and questions and messages work the same.

When a job fails

Read the failure message first — the platform tries hard to make failures say what actually happened rather than surfacing a stack trace. A provider error inside an agent container stops the job and reports the provider's own error, and a run that stops for a recoverable reason resumes rather than failing. When the provider refuses a request after the agent has already done some work — the provider is overloaded or rate-limited — the retry continues that agent's session rather than starting it over, and so does Retry preflight after such a failure.

A completed feature surfaces its latest job failure whatever the job was, so a feature that looks finished but has something broken behind it says so on the feature itself.

Next: Project settings.