Tasks, runs and the inbox

A task stands at one station of a line. Runs work it; people answer it from the inbox. The terms are defined in the glossary.

TasksCopy Anchor Link

FieldsCopy Anchor Link

A task created on the board is placed at the back of the station it is created at. A task created at a station with a harness starts a run at once. A task created at the backlog does not.

Task statesCopy Anchor Link

A task has no stored status. Its state follows from its notes, its run and whether it is finished.

A task that is created, moved, answered or reached by a happening, and is then idle at a station with a harness, is handed to a new run at once. A finished task is unfinished again when it moves to a station other than completed, or when a person or a happening adds a note to it.

NotesCopy Anchor Link

A task keeps a trail of notes. Each new note is added at the end of the trail, and a note's words never change.

Each note has a voice, station, person or world (a happening), and a form: words, setup, settled, approval, failure or connection.

A conversation runs from an asked note to the next passed note. It is open until that passed note is written.

HandoverCopy Anchor Link

A task's run ends with a declaration, made with spotlight handover --next (see Agent commands). Keys are compared without regard to case.

Any other ending is handled as review, with one of these notes:

If a reaction was held back while the run held the task, every ending other than a station key moves the task to the latest held-back station instead of the ending above. So does a hook stopped for looping while a run holds the task: the run is let go, and the passed note carries the hook's failure. See Moves.

MovesCopy Anchor Link

A move to another station:

• raises the task's revision;
• ends the task's run, for a person's move: a queued run is withdrawn, a claimed run is asked to stop, and a waiting or parked run is completed;
• finishes the task if the station is completed, and unfinishes it otherwise;
• starts a run if the task is idle at a station with a harness.

A person who moves an unassigned task from the backlog to a work station becomes its assignee. A person's move names the task's current revision; a stale revision is refused with 409. A move to the station the task already stands at only reorders it.

When a happening finds a task, the line decides one of these outcomes:

RunsCopy Anchor Link

A run is one execution of a harness, for a task at a station or for a chat. A replay run, which runs a past task run again under a candidate config, holds no task and is described in Replays. A search's agent run, which proposes candidates, holds no task either; see The search's agent run.

Run statesCopy Anchor Link

On the Runs list and on a task's "Activity", a queued run reads "Queued", a superseded run "Superseded", and a claimed run shows that it is in progress. A run reads "Waiting for you" while it is waiting or parked, and while the asked note it wrote has no later answered or passed note. On the Runs list, that label links to the run's inbox item. On a task's "Activity", such a run is led by a row that reads "Waiting for you", or "Answered" once a later answered or passed note is written, linked to the inbox item. The Runs list's "Waiting for you" view shows only the runs that read "Waiting for you"; with none, it reads Nothing is waiting for you. Switch to All to see every run.

The Run page of a waiting or parked run shows "Waiting for you" with "Answer in the inbox", or "Open in the inbox" when the open question is an approval. An approval can also be decided on the Run page itself, on the same card as in the inbox: copy the call, edit a tool call's inputs, "Approve", or "Dismiss", which first asks for a reason to tell the agent, Tell the agent why (optional). See Approvals.

TransitionsCopy Anchor Link

Words said to a run at the station where its task stands idle, when that station has a harness, start a new run there that resumes the station's session. Words said to a run whose task has left its station are refused with 409, and words from anyone but the task's assignee with 404. Only a claimed, waiting or parked run can be stopped. The web app offers Stop only while a run is claimed. Attempts a run spent parked do not count toward the 3. Only the task's assignee may stop a run or say something to it. See Steer or stop a run.

Run page composerCopy Anchor Link

The "+" button, "Attach files", adds files, and so does dropping or pasting them on the composer. Images show above the text; other files show by name in the text. The composer shows the station's harness, model and effort and the line's repositories, and none of them can be changed there. While a runner holds the run and the composer is empty, "Send" becomes "Stop".

Once the task has left the run's station, the composer is replaced by The task has moved to another station. Messages here reach no one. A replay run and a search's agent run have the composer turned off, with The agent runs autonomously. It can't receive messages.

Failure codesCopy Anchor Link

A run whose run.starting hooks could not be asked is handed back and tried again, 6 attempts in all, waiting 5 seconds and doubling to at most 2 minutes. A run whose runner is lost, or that timed out, is queued again at once, 3 attempts in all, counted together.

A failed run puts the task to a person with a failure of source run and the run's code. A failing hook reports a failure of source hook:<key>; see spotlight_hook for its codes. A failure with the same source and code as one already open on the task raises that failure's count instead of asking again. runner-lost and timed-out count as one repeating failure: the count carries on across both, and the failure is named for the latest code. Every other code, and each hook's failures, repeat only with themselves.

Run failure messagesCopy Anchor Link

A failed run's note reads The run failed: <message>. Where a run is refused for more than one reason, the reasons are joined with ; .

A run whose runner is lost, or that times out, on its last attempt is noted Spotlight gave up on the run after <n> attempts. The run did not finish., with the failure runner-lost or timed-out, as its last attempt ended. The run's own outcome reads No runner finished the run after <n> attempts., or Sandbox stopped at the host's time limit. No runner finished the run after <n> attempts. for a timeout, where <n> leaves out the attempts that were parked. See Inside a sandbox for the phase each runner message comes from.

ConfigCopy Anchor Link

When a task's run is queued at a station with a harness, it records the station's config as it stands then. A replay run records its candidate's config. A chat's run records none.

The run's config fingerprint is a SHA-256 of these parts. The task's title, description and marks are not part of it.

The config in force at a station shows under "Config" on the station's "Overview" tab, and the station's view on Insights groups its runs by config under "Runs by config"; see Station outcomes. GET /api/teams/{teamId}/runs/{runId}/config returns a run's config and its fingerprint, and, when the station's previous run with a recorded config ran another config, that run under changedSince, with the changes since it.

The web app words each change as one phrase, in the names of the groups under "Runs by config" and in what a search candidate changes:

For example: Effort high → xhigh.

Starting pointCopy Anchor Link

Once its checkouts are ready, a task's run records where it started: the workspace archive it restored, if any, and the commit each repository's checkout is at. A later attempt of the same run does not replace what the first attempt recorded. If the starting point cannot be recorded, the run carries on and its start step reads Where the run started was not recorded: <error>. A run with no starting point cannot be replayed. The archive is kept for 30 days after the run started; see Workspace archives.

SpendCopy Anchor Link

Once a run has ended and its journal has been digested, Spotlight records what it spent. GET /api/teams/{teamId}/runs/{runId}/conversation returns it under spend:

Each count is added up over every turn of the attempts the run kept. A count or cost the harness did not report is unknown, not zero, and is null.

The task trace shows a run's cost as "Cost" in the run's details, as $1.87, or to four decimals under $0.01. The Insights "Cost" tab adds the runs' costs up and gives each station's "Cache read", "Cache write" and "Input" tokens under "Read from cache", where a count the harness did not report reads not reported; see Cost. There, a count under 1,000 is shown whole, a larger one in thousands (3.1k) or millions (2.4M) to one decimal. In the task trace, a span that reports its own token use shows "Tokens", its input and output tokens together.

What each harness reports:

JudgingCopy Anchor Link

When a task's run ends at a station with a judge, the run is judged if all of these hold:

• It ended Completed or Stopped. Failed, abandoned, withdrawn and superseded runs are not judged.
• Its task still exists.
• It falls in the judge's sample. Whether a run falls in it is worked out from the run's id, so it never changes. A sample of 1 judges every run, and 0 none.
• The rubric's scale can be read. A judge with claims always scores claim by claim.
• It has not been judged before. A run is judged once.

At most 4 runs are judged at once. The judge reads the task's title (up to 300 characters) and description (up to 4,000), the run's steps from every attempt, and the hunks of its file changes, each file compared from before its first change to after its last, with 3 lines of context.

The judge is told how many steps and hunks were left out.

The judge answers with a score on the rubric's scale and 1 to 5 reasons. Each reason is up to 1,000 characters and cites 1 to 10 steps, by their place in the run's journal, or hunks, by name. A reason citing a step or hunk the judge did not read is dropped.

A judge with claims answers each claim, in order, met or not, with 1 to 3 reasons of its own in the same form. It is told that a claim the steps and hunks do not show to hold is not met. Its score is the share of claims met, and each claim keeps its mark and its reasons.

A score is recorded against the rubric version: the SHA-256 of the rubric, the claims and the pass share together.

A run whose judging failed shows no score.

AgreementCopy Anchor Link

A judged run's people's score is the latest grade a person gave it on the judge's scale. A grade counts only for the rubric version it was given under: the version of the run's judge score, or else the station's rubric at the time. On a yes-or-no scale, a run no one graded takes its people's score from its next act: Yes when it was Closed, No when it was Sent back; failing those, Yes when its pull request merged and No when it closed unmerged. Approving or refusing an approval is never a next act. A 1 to 5 scale and claims use grades only.

Agreement is measured from the station's latest 500 judge scores, across rubric versions, grouped by version, from the runs with both scores. The measure decides whether the judge is trusted; the statistics are shown under "Statistics" on the station's view on Insights (see One station):

On claims, a run counts once toward the runs with both scores, however many claims it has. Statistics are shown to two decimals, and "Overall agreement" as a percentage. A statistic that cannot be worked out reads –.

Cohen's kappa, each claim's kappa and the two correlations each carry a reading, shown on hover with what the statistic measures. "F1 score", "Mean absolute error" and "Root mean square error" have no reading.

The judge's scores show only when the station's current rubric is trusted:

The measure reads "Cohen's kappa" or "Spearman's ρ", and the value and trust are shown to two decimals.

While the judge is not trusted, a run's score and its reasons are both hidden. A score given under an earlier rubric version stays hidden, whatever the standing. A new rubric version starts with no runs that have both scores.

The station's view on Insights shows, under "How far to trust the judge", the measure with the standing, then how many of the station's latest 200 ended runs, less those withdrawn, have "Both scores", "Judge only", "People only" and "Neither", each with <share> of the last <n>. A trusted judge's standing there reads Trusted. Minimum required: <trust>. With no judged runs, it reads "No judged runs yet" and Judge agreement with people shows here per rubric once the judge scores runs. To a person who may not read it, Only team members can see judge agreement. Each rubric version then shows:

"Rubric" picks the version when the judge has judged runs under more than one: "Current version", or Version until <day>.

Judge and alertsCopy Anchor Link

A work station's "Overview" tab shows its judge under "Judge" and its alerts under Alert rules · <n>, read-only. "Judge" has the anchor #judge. Alert rules · <n> shows only when the station has alerts.

Only people on the team, the workspace's owners and admins, and workspace tokens with the read scope can read the judge's agreement with people. Anyone else is answered 404. See Team outcomes.

A station with no judge reads "No judge" and Only people score runs here. Otherwise "Judge" shows <sample>, as a percentage, with "of runs judged". Then, when the agreement value and trust are both known, the measure and its value on a bar marked at trust; see Agreement. Under it, a trusted judge reads Trusted above <trust> over <n> runs, and any other judge its standing. When the agreement cannot be read, the part reads Trusted from <trust> agreement. A judge with claims lists them under "Claims", numbered, then A run passes when it meets every claim., or A run passes when it meets at least <share> of its claims. "Show rubric" opens the rubric, and "Hide rubric" closes it, when the judge has one. "How it agrees with people" opens the station's view on Insights at #judge; see One station.

Alert rules · <n> lists the alerts in the order written, on a track that scrolls sideways. When they do not all fit, arrows and dots page through them. Each alert shows the measure's label, then the threshold: +<change> for risesBy, −<change> for fallsBy, > <amount> for above and < <amount> for below, with a change in a rate as <n> pts. Under it, how many runs it compares: over <over> runs. With over set to 1, this reads from one run to the next for risesBy and fallsBy, and in a single run for above and below. See Station alerts for when an alert goes off.

Each alert also has a one-line description: the accessible name of its slide, and the title of the chart on its inbox item. It reads Alerts when the <measure>, with the measure's label in lower case, then:

In the description, a change in a rate is in points, as 20 points, and an amount of a rate is a percentage. Cost is a number, to two decimals, or four under 0.01, with no currency on the slide and in the currency of the station's runs on the inbox item. With over set to 1, the description ends with from one run to the next or in a single run, as on the slide. For example: Alerts when the sent-back rate rises 20 points or more over 20 runs.

Judge scoreCopy Anchor Link

A judged run's score shows in the task trace. The judge's score is Yes, No, <n> of 5 or <n> of <m> claims met, and it is shown when the station's current rubric is trusted and the score was given under it. While it is shown, the run's row in the trace carries it. Selecting the row shows "Judged" in the run's details, then the judge's score, or score hidden. People's grades follow as People said <grades>, with (you) beside the reader's own. While the judge is not trusted, its standing is shown beneath. A shown score lists its reasons under it, each with the steps and hunks it cites, as Step <n> or the file's name and hunk header. Selecting a step shows Step <n> with its tool or kind, and its text; selecting a hunk shows its lines. On claims, each claim is listed with "Met" or "Not met" and its own reasons under it.

A run's judge score and people's grades can be read only by people on the team, the workspace's owners and admins, and workspace tokens with the read scope. Anyone else is answered 404.

A run that was not judged shows none of this.

Station outcomesCopy Anchor Link

Spotlight records how each task run at a work station turned out, as runs end and as people act. A run that ended before recording began has no outcome. Replay runs have none; see Replays.

Only people on the team, the workspace's owners and admins, and workspace tokens with the read scope can read a station's outcomes. Anyone else is answered 404. See Team outcomes.

The outcomes of the station's latest 50 ended runs, in the order they started, are shown in these places:

Runs are grouped by config, in the order they started: each group holds runs that started one after another with the same fingerprint. A config that returns after another starts a new group. A group is named by the first of its changes from the last config that ran before it, or Config <fingerprint>, the fingerprint's first 8 characters. The group of runs before any recorded config reads Before the first run with a config. A group whose runs never started on its config, because they failed before starting or were withdrawn, is marked "Never started".

A run's outcome:

Only Closed accepts a run, and only Sent back sends it back. Approving or refusing an approval is never a next act: it does not decide whether a run was accepted or sent back. When two acts come at the same moment, the first of Sent back, Closed, Answered, Parked and Started counts.

A tally counts:

"Latest runs on this config" shows "Runs", "Accepted", "Sent back", "Failed", "Cost" and "Median". "Runs by config" shows each group's shares, median, cost and days. The other figures are returned only by GET /api/teams/{teamId}/lines/{lineId}/stations/{stationId}/outcomes; the Insights Stations tab counts them in the same way.

On "Runs by config", each group shows "Checks" as <share> passed, of the runs whose check passed or failed; "Next" as <share> accepted and "Delivery" as <share> merged, of its runs; "Took", the median; "Cost"; and "Ended", the day or days its runs ended. Each run row shows the ending, linked to the run, then the failure, "Round", "Checks", "Next", "Delivery", "Took", "Cost" and "Ended". A part with no value shows –.

The inboxCopy Anchor Link

A person's inbox holds every conversation, open or resolved, on every task in the workspace that is assigned to them, and the notices put to them. Items are ordered by their latest note, notices by when they were raised, newest first, in the sections "Open" and "Resolved".

Only the task's assignee can answer an item, and only an open conversation can be answered. An answer writes an answered note. The run that asked carries on; if no run holds the task and the station has a harness, a run starts there, taking up the harness session where the last run left it.

A resolved item shows no answer box. In its place it reads The task is settled here. Nothing is left to answer. while the task stands at the item's station, or The task moved on to <Station>. Nothing is left to answer.

NoticesCopy Anchor Link

A notice tells one person about their team's work, outside any task. Spotlight raises one when a search stalls. Nothing waits on it, and it cannot be answered.

Its row shows a lightbulb, the headline, an unread dot, the day it was raised, and the first point. Its page, /w/<slug>/inbox/notices/<noticeId>, shows when it was raised, the headline, the points under "Details", and a button that opens the link.

A notice reaches only its person, and only while they are a member of its team's workspace. To anyone else, and once it has left the inbox, its page reads No longer waiting for you. Settling is POST /api/workspaces/{slug}/inbox/notices/{noticeId}/settle, answering 204, or 404 for a notice not put to the caller. Disbanding a team forgets its notices.

GradesCopy Anchor Link

When a judge score is recorded, 1 in 5 judged runs is also put to people to grade, chosen from the run's id. The item reads A judged run needs your grade. Grades check the judge. and, once graded, Run graded.

It reaches the inbox of the task's assignee, or of everyone on the team when the task has no assignee. It never reaches a person who is neither on the team nor an owner or admin of the workspace. The item shows the run's conversation, then a card with the question, the judge's rubric when the station's judge has one, and the answers:

A grade saves as soon as it is chosen, and on claims once every claim is answered. While it saves, the card reads "Saving…". A claim whose words changed since the judge marked it reads Claim <n>. The judge's score is not shown on it.

• Any person on the team, and any owner or admin of the workspace, can grade a run. Anyone else is answered 404, and the card reads Only team members can grade this run. One grade settles the item for everyone.
• A person's later grade of the same run replaces their earlier one.
• A run is graded on its judge's scale, else on the scale of its station's rubric, else yes or no. On claims, a grade marks every claim met or not, and counts as the share met.
• Nothing waits on a grade. The task moves on as it would without one.

Memory reviewsCopy Anchor Link

An item is raised for a run when it proposes at least one memory: drafted after the run at a station with memories: true, or proposed by the agent with spotlight remember. The item reads A run proposed memories for the team. It settles, and reads Proposed memories decided., once no memory of the run is left to decide: every one is approved or rejected, or a later run's drafting has dropped the undecided ones.

It reaches the inbox of the task's assignee, or of everyone who can see the team when the task has no assignee. The item shows the run's conversation, then a summary line that folds the cards and starts open. <proposed> is how many memories the run proposed, and <open> how many are still undecided:

• <agent> proposed <proposed> memories · <open> to review, or <agent> proposed 1 memory · 1 to review;
• <agent> proposed <proposed> memories · all decided, or <agent> proposed 1 memory · all decided.

<agent> is the run's harness, or "The agent" when it is not known. Each memory is a card titled "Waiting for your approval" while undecided, then Memory approved by <name> or Memory rejected by <name>, or Memory approved or Memory rejected when the person who decided is not known:

An undecided card has a copy icon, an edit icon, "Reject" and "Approve". The edit icon changes the memory in place, at most 1,000 characters. While it is edited, "Reject" becomes "Cancel", which puts the memory back, and "Approve", which keeps it as edited, is off while the text is empty. A decided card keeps the copy icon, with "Reject" and "Approve" off.

• An approved memory stands, with a new handle. If it corrects a standing memory, that one is retired in its favour.
• A rejected memory is kept and never briefed. When a station drafts memories, the drafter is shown the 20 newest memories the team rejected in the last 90 days that apply where the run ran. spotlight remember does not check rejected memories.
• A memory from outside the team cannot be approved together with other memories in one request. The web app approves one memory at a time.
• When a later run's drafting finds something to draw on, it drops every undecided drafted memory of the task's earlier runs, whether or not it proposes any itself. Memories proposed with spotlight remember stay.
• Nothing waits on a review. The task moves on as it would without one.

Station alertsCopy Anchor Link

Spotlight checks a work station's alerts when one of its task runs ends or settles, when the pull request of a task it worked closes, and when its line is changed or retired. A run counts toward a measure once it has settled for that measure:

Only runs that ran count, ordered by when they ended. An alert reads its measure over the latest over settled runs and, for risesBy and fallsBy, over the over settled runs before those. Settled runs are looked for among the station's latest runs, 4 times as many as its alerts need at most. Until enough runs have settled, or while the measure cannot be worked out, as for cost with no priced runs, the alert is not checked.

An alert goes off once per crossing. While it is open, later checks do not raise it again. It recovers once it has stayed within its threshold for over further settled runs: each check whose newest settled run is a new one, and finds the alert no longer crossed, counts one, and a check that finds it crossed again starts the count over. For over settled runs after it recovers, a crossing reopens the same alert, and its inbox item, instead of raising a new one. After that, a crossing raises a new alert.

If an open alert's amount or over is changed, the next check judges it by the new values: crossed, it stays open with the new reading; otherwise the check counts toward its recovery. An open alert whose measure or threshold is removed from the station recovers at once, at the station's next check, and a crossing after that raises a new alert. Changing or retiring a line checks each of its stations, those it had and those it has. Deleting a task forgets the alerts raised on it.

When an alert goes off, the task of the run that set off the check gets an inbox item: the run that ended or settled, or, when a pull request closed, the task's latest run at the station. The item reads Station crossed an alert threshold. and, once the alert recovers, Station back within its alert threshold. A reopened alert opens its item again. It reaches the task's assignee, or everyone on the team when the task has no assignee. It never reaches a person who is neither on the team nor an owner or admin of the workspace, and to anyone else it is not found: its card reads Only team members can see this alert. Nothing waits on it.

The item shows:

Requests to connectCopy Anchor Link

When a run calls a tool of an integration whose connection.holder is requester, and the person who started the task has not connected it or the host refused to renew their connection, nothing is sent. The task is assigned to that person and put to them with an asked note of form connection:

I need to use `<tool>`, which acts as you in <integration>, and you haven't connected <integration> yet.

Connect <integration> and I will carry on. Nothing has been sent yet.

For a refused renewal, <integration> refused to renew your connection, so it has to be made again takes the place of you haven't connected <integration> yet. <integration> is the integration's name.

Below the note, a card titled Connect <integration> offers "Connect" to that person only; anyone else sees Waiting for <person> to connect <integration>. Once they connect, the card reads Connected <integration>. Connecting answers it with Connected <integration>., in their voice, on every task waiting on that connection in the team; the run resumes as for any answer. A request is never met with the team's connection. See Holder.

ApprovalsCopy Anchor Link

A run asks for approval when a tool with approval in its integration is called, when the person whose connection a tool acts with set it to "Ask me first", or when the harness profile's ask rules match a harness action. See spotlight_integration, Person rules and spotlight_harness_profile.

In the inbox, the card's title reads "Waiting for your approval" while it is asked, then "Request approved", "Request approved with changes" or "Request dismissed". An undecided card offers copy and, for a tool call with inputs, edit, beside "Dismiss" and "Approve". For a call that asks because of a person's own rule, everyone else sees Only <Name> can approve this, with "Approve" turned off and edit hidden.

When a run asks, Spotlight looks for the latest approval of the same subject at the same station. The subject is the tool with the same inputs, or the same harness permission. An approval granted with changed inputs also matches a call with the changed inputs.

• A grant is spent by one call. The next call asks again.
• An approval asked at one station does not count at another.
• Only a person can approve or dismiss. A workspace token cannot.
• A call that asks because of a person's own tool rule can be approved only by that person. See Person rules.
• An approval is decided once. A second decision is refused with 409.
• An answer without a decision answers the conversation and leaves the approval undecided.
• A decision without words is recorded as Approved. or Dismissed..

Person rulesCopy Anchor Link

A tool of an integration whose connection.holder is requester acts with the connection of the person who started the task, and follows that person's rule for it as well as the team's. Of the two, the stricter wins:

• When a call waits because of a person's rule, the task is put to that person: they become its assignee.
• Approving it by anyone else is refused with 409. Whoever may answer the task can still dismiss it.
• A grant from someone else does not cover such a call. It asks that person again.
• A person's rule applies only to calls made with their own connection, never to calls made with the team's. It stays when they disconnect and connect again.
• The run's list of tools shows the team's rule. The person's rule takes effect when the tool is called.

See Let a person ask first or block a tool.

Changed inputsCopy Anchor Link

A person may approve a tool call with changed inputs, given as inputs with approve: true when answering the inbox item.

• The changes name exactly the inputs the call was asked with. Inputs cannot be added or removed.
• Each value has the type of the input it replaces: any text for a string, a finite number for a number, true or false for a boolean.
• A changed list or object is checked against the input's schema, and refused naming where it does not fit. See Input schemas.
• A value may not be blank where the call was asked with one.
• A harness permission and a dismissal take no changes.
• Changes that leave every input as it was are recorded as no change.

A refused answer is 409. See Answering an approval.

The answer the agent reads is the person's words, or Approved., followed by I changed what it runs with. Call it again as you asked and it runs with these instead: and every input of the changed call. A one-line value reads <input>: `<value>` ; a longer one follows its name in a code block. Values over 400 characters are cut, ending in ….

What the agent wantsCopy Anchor Link

A tool that requires approval also takes intent, given as --intent to spotlight <tool>: what the agent wants to do, as a phrase that completes "Spotlight would like to …". It is kept with the approval and never passed to the tool.

• Spaces and line breaks become single spaces, and final full stops are dropped.
• It is cut to 200 characters, ending in ….
• A tool that requires approval may not declare an input named intent.
• A call made while a person still owes an answer keeps the first intent.
• A harness permission has none.

ChatsCopy Anchor Link

A chat belongs to a team and to the person who started it. Only that person can list or read it. Each chat names its harness, and optionally a model, an effort, repositories and a work station it is improving. The harness and the repositories are fixed when the chat starts. A message may name another model or effort. The agent answers that message, and the messages after it, with the model and effort it names. A chat message holds up to 20,000 characters and at most 20 traces.

The Agent page's composer reads "What do you want to plan?", and a chat's composer reads "Reply…". One picker in the composer names the harness, then the model and effort when they are set. Under it, "Model" reads "Default" when no model is set, and is turned off for a harness that offers no models. "Effort" reads "Default" when no effort is set, and is left out for a harness that offers no efforts. A new chat takes the harness picked last, or the first one offered. In a chat, only the model and effort can be changed, and the web app sends them with each reply. Repositories are picked below the composer, which reads "No repositories", the repository's name, or <n> repositories; in a chat they are read-only. Files are attached as on the Run page. While the agent works, the chat shows "The agent is working…", and with the composer empty "Send" becomes "Stop".

A chat started from a station's "Improve", "Ask the agent" or "Review with the agent" names that station. Its agent is briefed to write the station's runs with spotlight history and to propose one change at a time, as a unified diff of the station's block in the line's spotlight_line resource and of its prompt file, prompts/<team>/<line>/<station>.md. The chat's first message names the station as <station> on <line>, linked to the station. If the station has left the team's lines, the agent is told so.

A setup chat, started from the setup task's "Set up configuration as code" (see Setup task), names a configuration repository and a folder in it. The repository joins the chat's repositories. The folder is 1 to 200 characters, from the repository root, each part made of letters, digits, ., _ and -, and never . or ... Its agent is briefed to survey the repositories and the team's tools and to open a pull request with the team's Terraform there, with setup-pull-request. The chat keeps the pull request. Its runs reach Spotlight's API with the run's Spotlight token.

Chat runs have priority over task runs. Which run goes first gives the reasons.

ProposalsCopy Anchor Link

The agent proposes a task with the propose-task tool, naming a line and a station by key.

Each proposal shows in the chat as a card titled by its state. "Task" holds the proposed title, linked to the task once it is created. "Station" reads <Line> › <Station>, or "Station deleted" once the station is gone. "Details" holds the description, when there is one. "Dismiss" and "Create task" act only on an open proposal, and "Create task" is off while the station is deleted. Copy <title> copies the title and the description.

An accepted proposal creates the task at the proposed station. A task created at a station with a harness starts a run at once.

AttachmentsCopy Anchor Link