Run the agent & review changes

The daily loop: give the agent context, let it run, keep your hands on the controls, read every change before it lands, and turn the result into a report.

A full run: prompt, approvals, and results

Attach context files

Start by showing the agent what you mean. Click the paperclip to attach files, paste a screenshot, or drag and drop files onto the panel: they appear as chips above the composer. Send takes the chips with that message, and they stay listed under it in the conversation, so attach a file again when a later message needs it. Remove a chip before you send when a file should not go.

Attaching context with the paperclip and drag-and-drop

Approve commands and patches

The agent asks before it acts. When it wants to run a command or apply a patch, an approval prompt appears in the conversation with the exact command or change spelled out. Read it, then approve or deny. How often you are asked is set by your run mode — see Approval policies & sandbox modes for the dials.

Steer a run in progress

While a run is going, the panel keeps you oriented. Long tasks fan out into helpers, and subagent activity chips show each one the agent has working and what it is doing. To change course, press Stop or Escape, or just keep typing: messages sent mid-run are queued and delivered when the agent reaches a stopping point. A queued message offers Send now, which interrupts the run and sends it, and Delete, which takes it back. To change one before it lands, press Up in an empty message box: the newest queued message comes back to edit and send again.

Work with the response

Responses are built to be acted on. File references open the file in the editor. Links open in your browser. Code snippets have a run action that pastes them into a terminal for review — nothing executes until you press Enter, so you read before you run. And every message shows a Copy button on hover for taking output elsewhere.

Review diffs before they land

Reviewing a proposed change in the diff viewer

A patch approval names the files it wants to change, and you approve or deny from that prompt. Once a turn finishes, Agent Dev opens the files it touched so you can read the result in the editor with your usual history and source control beside it.

Wingman checks its own work before saying it is done

An agent is the worst possible judge of whether it finished: the message that says the work is done is written by the same engine that decided to stop. So when a run settles, Wingman sends your original request, the closing message, and a short factual summary of what the run actually changed and ran to a second engine, which reviews the work and scores it out of 10. The second engine is never the one that did the work: Axelera Earth 1.0 and Axelera Venus 1.0 check each other, Axelera Mercury 1.0 is checked by Axelera Venus 1.0, and a run on your own local engine is checked by Axelera Venus 1.0. Only runs that actually built something are checked: a turn that wrote a file or ran a command. Asking a question and reading the answer costs you nothing extra and gets no score.

What the score means

The score is the answer to five questions at once: how much of the goal is delivered, whether it is right, whether the agent proved it instead of asserting it, whether it stayed inside what you asked for, and whether you can tell what changed. 8.5 and above is the bar and ends the run; 7 is good; 5 is okay. One badly failed area caps the score however good the rest is, so a high number cannot be averaged out of a real gap. Below the bar, Wingman keeps working: the gaps come back as one more message, marked in your chat as an automated verification follow-up so you can always see what the agent was told and why.

Stars, and what would make it better

The line Wingman leaves in your chat leads with a rating out of five stars, because that is the part you can read without stopping, and keeps the score out of 10 right beside it as the precise figure. One point of score is one half star, so the rating follows the score to the nearest half; a result below the bar is then held at least half a star under whatever the bar itself would earn, so a near miss can show half a star less than the rounding alone would give it and a failure is never dressed up as the rating a pass would get. Every line ends by naming the one thing most worth improving next, taken from the review itself. That holds for a run that passed too: the rating is the quality the work is at right now, not a claim that nothing more could be done. A finished line reads like this: [****-] 4.5 of 5 stars. Verified 8.7 of 10. Independent check on a second engine (Axelera Venus 1.0). Worth improving next: Add a test for the error path.

Staying in control of the check

The loop always ends, and it always says why. It stops when the score reaches the bar, after three automatic rounds, when two rounds in a row bring no improvement, when the same gaps come back, and the moment you type anything. A run you stopped, a run that errored, and a run with nothing to check are never scored at all. Each check is one extra call on a hosted engine, billed to the same credits as the run it checks, which is why every check leaves a line in your chat naming the score. To turn it off, set wingman.agentDev.verification.enabled to false; wingman.agentDev.verification.threshold moves the bar and wingman.agentDev.verification.maxContinuations changes how many automatic rounds a chat may use, with 0 switching the whole thing off.

Turn the work into a report

When the work is worth showing, Wingman turns it into a PDF report you can send to a customer or a manager. Type /report, click Create report beside the attach button, or accept the offer that appears once under a finished benchmark or launch run that measured something new: Create a report of this? Words you type after /report reach the agent with the request, for example /report keep the summary short.

All three open one card. Pick a format from the preview of its first page, check the title and your author block (name, company and logo, remembered for next time), fill in Prepared for if you like, set the classification label (Confidential unless you change it or clear it), tick the sections, and press Create report. Wingman collects the evidence, the agent drafts the outline, and the report is typeset on your machine. The first page appears in the chat and the PDF opens in your system viewer; in a remote workspace the chat shows the first page only.

Every figure carries its source

A report states only what the session can back up. Wingman collects the evidence itself, never the agent: the results files in your workspace (METIS_PROOF.json, telemetry.json, the SDK tracer CSV files and the files under benchmark_results), the output of the commands the chat ran, and any figure you type under Figures you provide on the card. It skips hidden, key and credential files, and it removes keys, tokens, passwords, private addresses and host names, and the user part of home folder paths before the agent sees anything. Every figure in the report cites one piece of that evidence with the value quoted from it, and Wingman refuses to typeset a figure whose quote or value does not match. An estimate shows its formula and the figures it was worked out from.

The results brief is made of figures, so the card keeps Create report disabled until the session holds a measured result or you add one under Figures you provide, and says why beside the button. A solution study and a technical report can be created with no figures at all: the sections that need figures start unticked.

Where the file goes, and changing it

The PDF is saved in the reports folder of your workspace, named with the date and the title, with its outline beside it as a .outline.json file. With no folder open, Wingman asks once whether to save in Documents, in the Wingman Reports folder, or to open a folder first.

To change a report, ask in the chat, for example make the executive summary shorter. The agent edits the saved outline and Wingman typesets it again. A revision is always a new file with the next number (-2, then -3), and nothing is ever replaced: the chat names the new file and the earlier one it kept. The report stays open for changes until a turn after a successful render finishes without a new one, and Cancel on the card closes it at any time.

What stays on your machine, and what leaves it

Typesetting and storage stay on your machine. The compiler runs inside the app with no network, and the PDF, its outline and the collected evidence stay on disk. Your author block is saved in the extension's global state under reportAuthorProfile, with one copy of your logo (PNG, JPG or SVG, up to 1 MiB) in the extension's global storage. Forget saved details on the card deletes both at once.

Drafting follows the provider you chose for the chat. The agent reads the evidence and writes the outline through that provider like any other turn, so a hosted provider sees the evidence and the outline. While a report is in progress, each turn also carries the report instructions, which count toward that turn's context.

When a turn is refused

A turn on an Axelera model can come back refused, and the card that appears tells you which of five things happened instead of calling all of them a limit. Two of them clear on their own and the card counts down; three of them need you to do something, and the card says so plainly. An empty credit balance is never described as a rate limit, because waiting would not help.

When a run gets stuck