Loomworks

Proof / Case study

Internal platform build. No client engagement.

Catch visual web failures that DOM-based tests can miss.

QA Vision tests web interfaces through screenshots and coordinate-based actions. Before each action, it records the expected result and flags a mismatch when the screen responds differently.

Built and operated by Loomworks as an internal platform. The evidence below covers shipped software and test results. No client outcome is claimed.

Industry
Internal platform (developer tooling)
Service
Custom Software Development

01

Starting point

Most automated web QA tools rely on the DOM or the accessibility tree, which means they test what the code says is there. What a real user perceives can differ.

The goal was an agent that sees a web app the way a human tester does, with screenshots and clicks only, so its findings reflect actual visual and usability problems.

02

Constraints

  • The no-DOM, no-selector constraint had to be enforced architecturally, rather than left as a convention.
  • The agent had to protect the caller's context window instead of flooding it with raw session data.

03

Scope

  • A vision-only browser controller with the no-DOM, no-selector constraint enforced at the controller level.
  • A server-side agent pattern with automatic context compaction at a high threshold and disk-based artifact storage for full audit trails.
  • Prediction-based anomaly detection: the agent records its expected outcome before each action, then compares it to what actually happened.
  • A pytest and pytest-asyncio suite covering the agent, browser controller, artifact storage, and the QA-findings engine.
  • Screenshot handling optimized to cut context usage.

04

Approach

Stack

MCP server 路 screenshot-only browser controller 路 server-side agent loop 路 pytest / pytest-asyncio

  1. 01

    Vision-Only Architecture

    Enforced the no-DOM, no-selector constraint at the browser-controller level, so the agent physically cannot fall back to structural access even under pressure to find the button anyway.

  2. 02

    Server-Side Agent & Context Management

    Built a server-side agent pattern that keeps the MCP caller's context window clean, with automatic context compaction and disk-based artifact storage for full audit trails.

  3. 03

    Prediction-Based Anomaly Detection

    Implemented the core idea: the agent records its expected outcome before each action, then compares it to what actually happened. Mismatches become QA findings rather than silent failures.

  4. 04

    Testing & Optimization

    Built out a full pytest/pytest-asyncio suite covering the agent, browser controller, artifact storage, and QA-findings engine, and optimized screenshot handling for a forty percent reduction in context usage.

05

Evidence

A working MCP server (qa_inspect, get_results, get_session_status) with an autonomous agent loop and a findings engine spanning ten issue categories and five severity levels.

Full screenshot-evidence audit trails back every finding, and the screenshot optimization cut context usage by forty percent.

06

Limitations

  • Internal platform build: there was no client engagement to oversee, and no client outcome metrics exist.
  • It is not an Odoo deliverable. It demonstrates general agentic-systems and MCP-server engineering capability rather than Odoo-specific work.
  • Because the agent is restricted to screenshots and coordinates, structural signals a DOM-based tool would catch are outside its view by design.

Start a project

Have a project like this one?

Tell us which document your team retypes into your ERP. A senior engineer replies with a written plan. Fixed price, agreed before we start.

Start a project

Free written plan and a quote. No meeting.

Back to all case studies