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.
• Token usage is on a card you can collapse.
• A resumed run's log shows the session it continued, rather than starting blank.
• 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.

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.