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.

Who started a job

Every row says who started the job: Started by Dana Ruiz, or Started by you for your own. A job that another job queued on someone's behalf (a follow-on fix, a scan after a clone) names the person who started the original run. A job the platform started on its own, and any job from before Repave recorded this, shows only its time.

Started by, above the cards, narrows the page to one person's jobs: Me, or anyone who has started a job in this project. It applies to every card, and the page's address keeps it, so you can send someone a link to "Dana's jobs".

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 container that hits its limit gets an Out of memory badge on the row and the limit to raise. On a running agent the Agent meter counts the processes killed in this step. The Docker meter says "Hit its memory limit" without a number, because what the sandbox runs sits in containers of its own, where the kills cannot be counted exactly.
• After the job has ended, the badge stays. Each step records how high its containers' memory went and what was killed before the containers are removed, so a failed job still says, for example, "Agent peaked at 8.0 / 8 GiB · 12 processes killed" or "Docker peaked at 8.0 / 8 GiB · hit its memory limit". 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.
• Started by names who started each job, and the line under a log's title repeats it. It is empty for a job the platform started on its own.
• 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.

A run's record

An agent log for a job that works in a feature's worktree, such as implementing the feature, has two tabs: Conversation, where it opens, and Record. Record shows what each run of the job was given and what it changed, so you can tell why a run produced the code it did without reading the whole conversation. A job that resumed has a record per run, headed Run 2 of 3 in this job. Switching back to Conversation keeps your place in it.

• Inputs — the prompt (Show prompt opens it as sent), the model, the Claude Code version, the runner image, the Repave release, the legacy code and the Gherkin the run worked from.
• Skills — every skill the run was offered, whether it came from Repave or the Project, the version in use, and whether the agent loaded it.
• Tools — the tools the agent called and how often. Show allowed lists every tool and MCP server it was allowed.
• Files changed — the run's diff, from the worktree before it started to after it finished. While the run is going it reads Shown when the run finishes.

The badges at the top say how far to trust it. Recorded means it was captured while the run happened. Transcript kept means the agent's full session file was saved when the run finished. Others wrote means the Repave IDE or another job changed the worktree during the run, so some of the changes may not be the agent's. Incomplete means a step of recording failed; the run itself was not affected.

Runs from before Repave kept records are Backfilled: built afterwards from what Repave had kept. Values worked out rather than captured are marked (inferred), missing ones read Not recorded, and the files the agent edited take the place of a diff. Until the backfill reaches a run, its tab reads This run's record is being built from its history. A job still queued reads This run's record appears when it starts. A job that works outside a feature's worktree, such as discovery, has no Record tab.

On a feature's AI Usage tab, each session links to its run's record.

Memory

Agents remember what they learn about a project, and hand it to later runs. Management → 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. Once you answer, the card is replaced by your reply on the right of the conversation, like a message you typed: each question with your answer under it, or Let the agent decide.

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 — if you started the run or own the feature. When neither of those people can answer (for a run nobody started, say), every project editor is notified instead. Viewers see the bell entry but get no browser notification, since they cannot answer. 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. Any of them can, so each answer to the agent's questions, each approval and each message says who gave it: You for your own, the person's name for anyone else's.

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 and the connection. On a project that connects to Anthropic directly, the safety check runs with Sonnet, Opus and Fable models. On a project that connects through Vertex AI, it runs with Sonnet 5 or later, Opus 4.7 or later, Haiku 5.5 and Fable models; enable a newer model in your Google Cloud project and set the tier to it to turn approvals on. 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.

On a Gemini or Codex model, a response the model provider stops before delivering it is also recovered once. That most often happens because a tool call it generated was malformed. The agent's session is continued and the agent is told to repeat the step, so the job goes on. If it happens twice in a row, the job fails with the provider's message, "can't help with this". On a Claude model that message is a real refusal, and the job fails without a retry.

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.