Sentinel Reads Your App Before It Tests It

Sentinel is pitching a different kind of QA agent: one that reads the codebase first, figures out what the product actually does, and then tests those business flows across both the frontend and backend. The tool is open source under the MIT license.

The team says most agents stop at surface-level checks: opening pages, clicking buttons, spotting layout issues or console errors, and calling it done. Sentinel instead tries to work more like a human QA engineer by learning the product before testing it.

When the developers pointed Sentinel at KaribuKit, their own full-stack hotel PMS built with a Next.js frontend, a separate API service, and a Postgres database, they gave it only the repo and admin credentials for a disposable test tenant. No test plan or predefined flows.

Sentinel reportedly inferred that the app was a boutique and safari hotel PMS and derived nine critical business flows on its own, including:

Recommended reading

Avito eyes free dating inside its app

• the full reservation lifecycle
• group bookings
• the lead-to-proposal pipeline
• rate management
• guest self-service
• mid-stay room changes
• the night audit
• payment through invoice to refund
• the AI copilot

It then deep-tested the top two flows twice each and ran a visual pass over every screen it visited. In one run, it called GET /api/availability, got a 400, inferred the missing parameters, retried with adults=2&children=0, and got a 200. It created a reservation with POST /api/reservations (201), fetched it back to confirm persistence, and probed the check-in flow until it found the right endpoint: /checkin returned 404, /check-in returned 400, and a valid call eventually returned 200.

×

That run surfaced bugs the team argues a UI-only tester would miss:

• a confirmed reservation that came back NO_AVAILABILITY
• a backend state-machine issue that surfaced as a misleading “no rooms available” toast or no feedback at all
• a calendar showing a room as available when a booking already existed
• a check-in call returning 200 while the guest’s registrationStatus stayed NONE on the server

×

How Sentinel works

The core pipeline starts with a deterministic recon pass using grep and find rather than model calls. That pass extracts frontend routes, API route modules, services, and database entities, producing a digest for the model to reason over instead of crawling a monorepo blindly.

For flow derivation and next-step decisions, the system uses Mimo, Xiaomi’s model, through the pi agent harness. Browser actions are handled by Playwright, while backend assertions use an api_request tool that runs fetch inside the page and replays the same Authorization header the frontend sent. The model never gets shell or filesystem access, and each attempt is capped at 90 tool calls.

Because agent runs are non-deterministic, each flow runs twice by default via the FLOW_ATTEMPTS setting, and findings are unioned. The agent also runs a visual review on each distinct screen it visits, up to eight per run by default, scoring hierarchy, spacing, likely WCAG contrast failures, typography, and broken states.

×

The current recon layer supports common JavaScript stacks including Next.js routes, Express and Fastify route modules, Prisma, Drizzle, and plain SQL schemas. The system runs on a schedule: a launchd task checks repos every fifteen minutes, triggering review on each new commit and QA on a set cadence such as every 12 or 24 hours.

The same platform also includes three related agents:

• a code-review agent for new diffs
• a docs-sync agent that updates Markdown to match code
• a brain-sync agent that summarizes repo changes into a shared knowledge repo

The two agents that write changes do so in isolated worktrees and open PRs, but do not merge them.

Cost, model choices, and Web3 testing

The team says Sentinel started with Mimo partly because the local pi agent harness was already configured for it. Early versions were more limited: a deterministic Node loop could find bugs in a small product-search app for as little as $0.0044, and one three-cent run caught truncated prices such as “₹4,19” and cut-off product cards. But that setup lacked memory and could not sustain longer multi-step flows.

Later versions moved to a model-driven loop, and the current system adds automatic flow derivation from the repo. For visual review, the team switched from the text-only mimo-v2.5-pro to the multimodal mimo-v2-omni, increasing its budget to 6,000 max tokens so it would reliably emit JSON verdicts. The broader system also uses claude for Markdown edits in docs-sync and brain-sync, and codex, on gpt-5.5, as an optional read-only review engine.

Cost is one reason Mimo remains the default for always-on runs. According to the team, a Mimo decision costs a fraction of a cent, a shallow QA run costs a few cents, and the deepest multi-attempt run on the hotel PMS took 364 steps and cost $1.95.

The project also tackles apps that require wallet login instead of a standard form. Before page load, Sentinel injects its own window.ethereum or EIP-6963 wallet interface, backed by a throwaway private key stored in Node. To prevent accidental spending, transaction-submitting methods are blocked entirely, only an explicit read-only allow-list is permitted, and any key that has ever been used aborts the run.

In testing against a perpetuals exchange frontend booted locally from a feature branch in a throwaway git worktree, the team says the real backend never ran while on-chain reads still hit the live chain. That effort surfaced familiar engineering issues too, including a server-rendered landing page that returned 500 without the backend, and a public RPC endpoint that sent a malformed CORS header of *',', breaking browser reads. One short seven-step run accumulated 71,597* — a sharp reminder that the messy parts of QA are often in the integrations, not the clicking.