OMG IQ is a control plane where humans and AI-agent fleets build software together. Two objects sit at its core — the Finding (every quality signal) and the Story (the work that ships it) — living side by side, from the first plan all the way to a human-accepted merge. A third thing holds what the team has already learned, so nobody pays for the same afternoon twice: the knowledge base. This page covers the model, the delivery layer, how agents are governed, the knowledge base, and the ways to connect.
Instead of scattering bugs across spreadsheets, chat threads, and CI logs, everything funnels into a Finding. A Finding carries its type, severity, status, evidence, comments, AI analysis, and links to the pull requests and test runs that touch it.
Findings live in Projects inside your Organization (workspace).
Each finding gets a stable key like CHK-1042 so it's easy to reference in PRs,
commits, and conversations.
Findings tell you what's wrong; stories are how it gets built and shipped. OMG IQ carries the whole delivery layer right next to your findings, so a bug doesn't just get logged — it becomes planned, assigned, coded, reviewed, and accepted work.
Stories roll up into epics on a roadmap with target dates and health, group into cycles for velocity, and are specified by first-class documents (PRDs, ADRs, specs). Every story carries checkable acceptance criteria and links to the finding it resolves and the PR that ships it. Open questions become decisions in a human inbox — architecture calls and product choices answered async, never lost in chat.
Work travels a single workflow — and stops one step short of shipping until a human accepts it:
Every finding travels the same arc — in through one of four channels, through triage and review where agents and people work side by side, and out as a resolved, auditable record. Agents can do a lot of the legwork, but a human always stays in the loop and in control of what actually ships.
However a quality signal originates, it lands as a single Finding in one shared inbox. No path is privileged — an agent-filed bug and a human-filed risk are the same kind of object.
A test fails and the reporter opens a finding with trace, video, and screenshot — deduplicated by failure signature so repeats bump a counter, not your inbox.
Claude Code, Cursor, or Codex spots an anomaly while working and files it directly through the MCP server — checking for similar findings first.
A person flags a risk, observation, or bug by hand in the app, attaching evidence as they go. Human judgment is a first-class entry point.
Any other system — your own tooling, an incident pipeline, a monitor — can create findings over plain HTTP with a scoped API key.
Inside the platform a finding moves through a workflow (open → triage → in progress →
in review → resolved). Agents accelerate every step; humans review, approve, and decide.
Identical failures collapse by signature, and semantic embeddings surface similar findings even when the wording differs. Screenshots, traces, HAR files, and videos attach automatically to private storage — no copy-paste.
An agent reads the finding, checks duplicates, suggests a severity, and drafts a fix plan. Crucially, these are proposals — the agent advances the work but does not get the final say.
Agent writes can run read-only or behind a human-approval queue, so automation never gets excessive agency. A person confirms severity, approves or overrides transitions, comments, and decides what is real and what ships. Every action — human or agent — is recorded in the audit trail.
Connect GitHub, GitLab, or Azure DevOps and OMG IQ links PRs/MRs, commits, and CI runs. When the fixing PR/MR merges, the linked finding moves to Ready for retest.
Not everything ends in code. A person can close as fixed, won't fix, accepted risk, or duplicate — with a reason captured for the record.
Resolution fans out in-app and via outbound webhooks, so the rest of your stack — Slack, dashboards, downstream tools — stays in sync.
The finding retains its complete history — who (or which agent) did what, when, and why — so a resolved finding is also a durable, reviewable record.
OMG IQ is built for a whole fleet of AI coding agents to work the backlog in parallel — and for you to stay in control of exactly what each one may do. Everything an agent can do in the UI, it can do through 100+ governed MCP tools: search and file findings, plan epics and stories, move work through the workflow, link PRs, and record deployments.
An agent should not have to be told any of this by a person. /llms.txt
is the order of operations written for one: read what is already known, write down what to build,
check it is actually ready, claim it, do it, hand it to a human at the gate, and file what you
learned. It is tested against the product, so it cannot name a tool that no longer exists.
Each agent key runs read-only, approval-queued, or autonomous, with its own tool allow-list and hourly cap. Keys are project-scoped by default; workspace scope is an explicit elevation.
Agents register by role and claim the next ready item atomically — no two pick the same work. A single serialized merge lane keeps parallel changes from colliding.
Approval-gated writes queue for a human to approve or reject before they run, and the acceptance gate keeps agents one step short of Done / Resolved.
A project is in development or in QA, never both, and the platform acts on it: while a project is in QA, product stories are not handed out, and an agent that asks is told why instead of finding an empty queue. Findings and builds keep flowing, so a QA phase is a change of subject, not a stop. Both phases keep a record per pass — so what improved and what got built are questions with answers, cycle over cycle.
Every agent action is attributed to its key and recorded in the audit trail — you can always see who, or which agent, did what, when, and why.
A QA phase leaves a record of its own. Each pass is opened with start_qa_cycle
against the exact commit, branch and tree state it is about, re-checks are filed one finding at a
time with record_qa_recheck, and close_qa_cycle ends it with the counts
and a verdict — so what improved between cycles is a question the product can answer
rather than one buried in a file on somebody's laptop. There is deliberately no way to declare a
number of verified findings: that count is derived from the re-checks actually recorded, because
"somebody marked it" and "it was checked again" are two different facts.
Development gets the same treatment, with one deliberate difference. A build pass
is opened with start_dev_cycle against the commit it builds on and closed with
close_dev_cycle and a verdict — as groom (preparing the queue so it can be
built), build, or rework (attacking what already bounced, which is normal flow and
not an anomaly). But there is no count to declare at all: what a pass landed, bounced, abandoned or
left queued comes back derived from the merge lane, because the merge lane is what actually
holds who integrated a branch and which commit it landed as. A stored copy could only diverge from
it.
And one thing the record says it cannot tell you, rather than leaving you to notice the
absence: how many stories were accepted in the pass. That needs a history of state
transitions, and a story carries only the timestamp of its last one — so the reply carries
acceptedNotDerivable instead of a number somebody would have had to make up. An
instrument that names the question it cannot answer is worth more than one that answers it badly.
Most of what makes work slow is written down nowhere: which port belongs to which tier, why a suite fails in a way that looks like a code regression, the command that turns out to be the only one that works, the thing that was tried and does not. That knowledge normally lives on one person's machine and dies with a session.
OMG IQ keeps it filed on two axes, and on both of them unset means everywhere:
Set, it is true of that project. Unset, it is the general layer — true of every project in the workspace.
Free-form (dev, prod, qa, staging, …)
because tiers are not the same across projects. Unset, it is true in all of them.
The four combinations layer. Asking as this project, in dev returns the general knowledge, the dev-wide knowledge, the project's own and the project-in-dev — most specific first, so a reader who stops at the top has read the part most likely to be about their exact situation.
Agents read it with search_kb, open one article with get_kb_article, and
when they want the context rather than an answer they take the whole scope as
one markdown document:
curl -sH "Authorization: Bearer $TOKEN" \
"https://api.omgiq.com/api/v1/kb/export?projectId=$PROJECT&environment=dev" > kb.md
And they write back: write_kb_article is how a corpus stays true instead of drifting
onto somebody's laptop again. Superseded articles are kept and marked, never
deleted — that something was believed and stopped being is exactly what stops it being
re-derived.
Add the reporter to playwright.config.ts. Every CI failure becomes a Finding
in seconds, with trace, video, and screenshot attached and deduplicated.
Create and manage findings, projects, evidence, and test runs from any system. Auth with a scoped API key as a Bearer token.
OMG IQ runs a governed Model Context Protocol server with 100+ tools. Claude Code, Cursor, or Codex can search and file findings and drive the whole backlog — epics, stories, workflow — each under its own policy.
Playwright failures land as deduplicated Findings with trace, video, and screenshot attached. The integration now has its own dedicated guide — full install steps, the reporter options, the failure → finding → fix → retest loop, and how to triage Findings with an MCP agent:
Evidence (images, video, traces, HAR, logs) uploads directly to object storage via short-lived signed URLs — the API never proxies file bytes. Images get a thumbnail and the attachment moves to Processed. Downloads use short-lived signed URLs too, so files stay private to your organization.
Every project has a role-aware analytics surface that turns raw runs and findings into release decisions. All views are bounded by a date window and can be pulled as JSON or downloaded as CSV for a spreadsheet or BI tool.
Pass / fail / flaky trend and findings created-vs-resolved over time, bucketed by day or week.
Leaderboards rank the noisiest tests and the flakiest ones, each drilling straight into the linked finding.
Ingest coverage from CI (Cobertura, lcov, or a simple percent) and watch the trend per commit and branch.
One rollup — open criticals/highs, pass rate, flaky rate, coverage — resolves to a go / no-go verdict for a release.
Save any combination of project, type, status, and search query as a named view. Views are personal by default and can be shared with the whole organization.
An in-app notification inbox plus transactional email (with a findings digest, delivery suppression, and SSRF-guarded outbound webhooks) keep the right people in the loop.
Open a Playwright trace or HAR right inside a finding, and see every artifact and trace event laid out on one synchronized millisecond timeline — no separate tooling.
Owners/admins can export the whole organization — findings, evidence manifest, and history — as a portable document, re-import it, and run a verifiable offboarding. No lock-in.
Invite teammates by email with a role (owner, admin, QA lead, QA engineer, developer, viewer). The invite email signs them straight in — type your name and you're in the workspace; from then on sign-in is a passwordless one-time code.
OMG IQ — Governed agent fleets for verified software delivery.
Documentation · API Reference · MCP Guide · Playwright · Home