Website quality for Fimo agents

Brainstorm

Fable brainstorm · browser, Lighthouse, and preview targets

One work unit: what the current browser stack already does, what Lighthouse adds, and three ways Fimo could own the flow.

Slack thread Files 13 context files Diff None

Outcome

Fimo already has the path the Slack discussion assumes. A run can receive a preview URL or a user-supplied URL, open it with agent-browser, inspect the page, take screenshots, query WebMCP, and use agent-browser's vitals and accessibility commands. The missing piece is not URL opening.

Agent-browser 0.36.0 does not run Lighthouse. It is a browser driver with browser-observed Web Vitals, an embedded axe audit, network inspection, profiling, and WebMCP. Lighthouse could run beside it in the same sandbox, against the URL the agent already has, if the binary and Chrome path work there.

The best next move is a goal-oriented quality recipe. Teach the agent when to use browser observation, vitals, Lighthouse, HTTP checks, field data, and WebMCP. Keep those outputs separate. Add a first-class capability or a branch-preview deploy only after one narrow Lighthouse probe proves the need.

Entry path

The agent can already open the supplied URL

The managed run has shell execution and a browser skill. The run can use a URL supplied in the task, ask the person for missing information, or resolve the current project preview through the CLI. In each case, the browser action is the same: open the reachable URL and inspect the result.

That makes the original framing too strong. Fimo does not need a new browser path to reach a preview. It needs to teach the agent what the URL represents and which measurement is appropriate for it.

Input

Task URLProvided by the person or task

Preview commandResolves the current project target

Run

Managed agentRuns commands inside the sandbox

Agent-browserOpens and observes the page

› CLI fimo preview url --json Existing Returns machine and human preview destinations

Agents use the fetchable sandbox URL for curl, screenshots, and other machine reads. The authenticated viewer URL is for a person in Fimo Studio. The raw sandbox URL expires and can be resolved again.

Task or CLI Reachable URL agent-browser open

Existing browser tools

Agent-browser already measures Web Vitals, but not Lighthouse

The pinned upstream v0.36.0 command reference lists a framework-agnostic vitals command for LCP, CLS, TTFB, FCP, INP, and hydration timing when available. It also lists an embedded axe accessibility audit, network and HAR inspection, profiling, tracing, and WebMCP commands.

It does not list a Lighthouse command. That distinction matters. Vitals are measurements observed in the browser session. Lighthouse is a separate audit runner with category audits, diagnostic findings, and a JSON report. The same URL can feed both tools, but the tools do not own the same contract.

Read the pinned agent-browser v0.36.0 command reference.

vitalsAvailable

Output: LCP, CLS, TTFB, FCP, INP
Owner: Browser session
Use: Fast page-level observation

a11yAvailable

Output: Embedded axe violations
Owner: Browser session
Use: Accessible page checks

WebMCPExperimental

Output: Page-provided tools
Owner: Visited page
Use: Agent-readiness checks

LighthouseNot included

Output: Category audits and JSON
Owner: Separate CLI runner
Use: Lab quality audit

Preview target

Preview URL acquisition is real, but the preview runtime changes the meaning of a score

The current preview flow gives an agent a concrete machine URL. The platform can also build a task-branch preview with plain fimo deploy, which the run may inspect or screenshot. This is enough for browser exploration, screenshots, HTML checks, console errors, accessibility, and WebMCP discovery.

The catch is that the documented project sandbox runs a framework development server. So the URL is valid for seeing the page, but it is not automatically valid for claiming production-like performance. A supplied production URL is equally easy to open. The target problem is classification, not navigation.

flowchart TB
  Input[Task URL] --> Open[Open page]
  Preview[fimo preview url] --> Sandbox[Sandbox URL]
  Sandbox --> Open
  Publish[Published URL] --> Open
  Open --> Observe[Browser checks]
  Open --> Measure[Choose metric]

The browser path is shared. The target and the requested metric decide what the result means.

› CLI fimo deploy Existing Builds a preview without publishing the live site

The managed prompt allows a plain deploy for a preview and forbids publish. That is a useful browser target, but it does not answer whether the build has production caching, compression, headers, or a public origin.

Measurement boundary

Lighthouse can run on a preview, but performance needs a built target

Lighthouse can audit a reachable public or authenticated page through its CLI or Node entry point, so a production domain is not a prerequisite. The meaningful requirement is a production-like build. A development server adds tooling overhead and can make a performance result say more about the dev server than the website.

That leaves three useful target classes. A development preview is good for browser behavior and markup. A built branch preview is good for lab performance if it actually serves the intended build. A published URL is good for lab checks and is the only class that can be joined to real-user field data.

Lighthouse can run from DevTools, the CLI, or Node. Field Core Web Vitals remain a separate production-data question.

Development previewBrowser

Good for: DOM, screenshots, a11y, WebMCP
Performance: Do not publish as a score

Built branch previewLab

Good for: Lighthouse and HTTP checks
Requirement: Reachable intended build

Published URLField

Good for: Lab plus public behavior
Requirement: Real production origin

URL reachableThe runner must hit the intended page, not a viewer, login screen, or 404.
Build identityA lab result must name which build or commit served the page.
Field boundaryCrUX or RUM data belongs to a public production origin, not a short-lived preview.

Instruction gap

The prompt gap is narrower than the capability gap

Fimo already injects browser guidance when the global agent-browser skill is present. That guidance tells the run to load the version-matched core skill before using browser commands. It does not give the agent a website-quality decision tree.

The older discovery agent is even thinner. It teaches browser commands through bash, screenshot, and snapshot, but it does not mention vitals, a11y, Lighthouse, or a target-class rule. Its screenshot guidance also says "full page" while the implementation only accepts a viewport capture. That stale instruction is a separate repair, not a reason to invent a new browser capability.

packages/agents/src/autonomous/prompt.tsBrowser knowledge is conditional and generic

1431if (skills.some((skill) => skill.name === 'agent-browser')) {
144  sections.push('## Browser automation')
148  'Load the agent-browser skill, then run agent-browser skills get core.'
149}

1
Discoverability gate. The run learns that a browser exists, but not which quality question each command answers or which target makes a performance result meaningful.

System shape

Fimo should expose several quality lenses, not one website score

The useful product is a small set of named checks that share target resolution but keep ownership and evidence separate. Browser observation belongs with agent-browser. Lab performance belongs with a Lighthouse runner. SEO markup can reuse the existing audit scripts. HTTP and edge behavior belongs with network inspection and fetches. Field metrics need a production data integration. WebMCP answers whether a page exposes useful tools to agents.

This gives an agent more useful answers than a single number. It can say that the page looks correct, has an accessibility violation, has a slow lab load, lacks field data, and exposes no WebMCP tools without pretending those are one measurement.

flowchart TB
  Target[Reachable target] --> Browser[Browser observation]
  Target --> Lab[Lighthouse lab]
  Target --> Edge[HTTP and edge]
  Page[Published page] --> Field[CrUX or RUM]
  Page --> Agent[WebMCP readiness]
  Browser --> Report[Separate findings]
  Lab --> Report
  Edge --> Report
  Field --> Report
  Agent --> Report

One target resolver can feed separate quality lenses without creating a composite score.

BrowserExisting owner

Checks: Visual, DOM, interaction, vitals
Target: Any reachable page

LabAdd runner

Checks: Lighthouse categories and audits
Target: Built reachable page

FieldSeparate data

Checks: Real-user Core Web Vitals
Target: Public production origin

Product options

There are three reasonable shapes for the next step

All three options use the browser path that already exists. They differ in where Fimo puts the recipe, the Lighthouse process, and the responsibility for producing a built target.

The quality skill is the right first move because it tests the user journey with existing authority. The audit capability buys consistency later. The built branch preview changes deployment lifecycle, so it should be justified as a platform feature rather than smuggled in as a Lighthouse dependency.

1. Quality skillSmallest

Shape: Goal-oriented instructions plus commands
Uses: Preview URL, vitals, a11y, optional Lighthouse
Cost: Low, but target rules stay in prose

2. Site audit capabilityRicher

Shape: One Fimo-owned audit operation
Uses: Target resolver, runner, separate findings
Cost: Medium, with runtime and report design

3. Built branch previewPlatform

Shape: Preview deploy that serves a production build
Uses: Lab checks before publishing
Cost: High, with deploy consent and cleanup

Start with the skillProve the command recipe and target rules before creating a new capability.
Keep deploy separateA branch preview is a platform lifecycle feature, not a hidden Lighthouse dependency.
Do not combine yetWebMCP, field data, Lighthouse, axe, and one composite score should remain separate tracks.

Next experiment

One bounded Lighthouse probe settles the only runtime unknown

The next useful action is empirical, not architectural. In the sandbox image that already installs Node 24, Chrome, and agent-browser 0.36.0, run Lighthouse once against a controlled public page. Point Lighthouse at the Chrome binary installed for agent-browser if it does not find Chrome automatically.

Record whether the command exits successfully, the wall time, the memory cost, and whether the JSON contains a performance category score. If the probe passes, add the runner to the quality recipe and decide later whether repeated use warrants a Fimo-owned operation. If it fails, keep the browser path and report the exact runtime failure. Do not fill the gap with an estimated score.

› Probe npx -y lighthouse https://example.com --output=json Not run Check Lighthouse inside the existing sandbox

Use the Chrome installed by agent-browser, add a headless flag only if the sandbox requires it, and save the JSON outside the repository. A passing probe is runtime evidence. It is not yet product acceptance.

VerifiedBrowser substrate

The sandbox image pins agent-browser 0.36.0, installs Chrome, and smoke-tests a page, WebMCP listing, screenshot, and cleanup.

VerifiedUpstream browser metrics

The pinned v0.36.0 command reference includes vitals and embedded axe a11y. It does not include a Lighthouse command.

PartialPreview path

Source inspection confirms the machine URL contract. A live preview resolution was not run for this brainstorm.

UnknownLighthouse in the microVM

No probe has established Chrome discovery, runtime compatibility, duration, or memory cost.

UnknownLive URL injection

This pass did not inspect the exact run trigger that produced the Slack hallucination, so it cannot say whether that run already had a production URL in context.

Evidence-bearing files13 context files

⌄▱tools/fimo-sandbox

⌄▱packages/agents/src

⌄▱apps/cli and apps/api

⌄▱Audit contracts