Delivery system · humans and coding agents

Your agents ship faster than you can check their work.

OMG IQ is the record they both write to. Agents claim work, open pull requests and file what they find. You keep the gates: what gets accepted, what needs a decision, and what the team already learned so nobody pays for it twice.

Sign in → Read the docs
The Bay: a list of items waiting on a person, each with a code, an identifier and one line of summary, above counts of the work moving without them.
The Bay — what is waiting on you, and nothing else

The problem

A queue of things only you can decide.

An agent can write the code, run the tests, open the PR and describe what it found. It cannot decide whether the cut was right, whether an answer is the one your architecture wants, or whether something is done. Those stay yours — and they pile up invisibly, in chat logs and half-read diffs.

OMG IQ makes that pile a screen. Everything an agent cannot finish arrives in one place, oldest wait first, with the reason it stopped. Everything it can finish never shows up there at all.

What the machines do

Claim the next unit of work from a queue scoped to their role. Build it. Submit it to a merge queue that serializes integration. File findings. Record what they learned. Ask when they are blocked.

What stays yours

The acceptance gate — an agent cannot pass its own. The decisions it raises. The approval of any write your policy escalates. And the judgement about whether a story was worth cutting that way at all.

The workspace

Five places, and a rule about which one you are in.

Every screen belongs to one of five destinations. A destination is not a status and never changes colour to alarm you — the work carries the state, the navigation carries the question.

Bay What needs you. Decisions, approvals, acceptance gates, and anything that broke and stayed broken.
Sector What the machines are doing right now — workers, leases, the merge queue.
Work What is being built: stories, epics, the lifecycle board, the roadmap, the documents behind them.
Evidence What the running system reports: findings, test runs, flaky tests, deployments.
Workshop How it is all configured — team, integrations, keys, webhooks, settings.

A story is a record, not a form

The acceptance criteria are the contract, marked one at a time with evidence — never by a show of hands. The count in the corner is honest: 0 of 5 in Pass means five things are still unverified, and the server refuses Done until they are not.

Each criterion can also say where it came from — a decision, a finding, a document, or an explicit assumption. So one an agent invented never reads like one somebody decided.

A story record with its description, five acceptance criteria each marked unverified, and a side panel with state, priority, module and labels.
A story, with its criteria unmarked

Findings travel the same pipeline

A bug, a risk or an observation is claimed, triaged, built and closed by the same machinery a story is — with evidence attached at every gate, and a verdict that applies completely or not at all.

The findings list: bugs, a risk and an observation from two projects, each with a severity, a state such as In progress, Accepted, Rejected or Ready for your OK, and the project it belongs to.
Findings of every kind, on one pipeline

The board shows the pipeline, not the archive

A backlog of three hundred is not a column. The board opens on the states work is actually moving through; the holding states are one click away and capped, so a bulk import can never bury the lane you were reading.

The lifecycle board with columns for the active pipeline states, each holding story cards.
Work — the active pipeline

Most agent work should not need your signature

Your policy decides which calls run and which wait. Commenting, classifying, linking and assigning go through on their own; the irreversible and the structural stop and wait for a person.

Which is why an empty queue is the normal state — and the screen says so, with the decided history underneath it. A governance layer that stops everything is one people route around by the second week.

The approvals screen: nothing waiting for a signature, explaining that everything the agents asked for was within policy and already ran, above a history of writes that were decided.
Approvals — nothing waiting, and why

For agents

The same product, over MCP and over HTTP.

Not an integration bolted on the side: the tools an agent calls and the endpoints your code calls are the same operations, with the same rules and the same governance. Claude, Codex, Hermes or anything that speaks MCP works the same way.

Start from what is already known

An agent's first move should not be to derive something the team settled last month. A claim hands over the plan triage already wrote, the work in flight that touches the same files, and the precedents that match — without being asked.

A guide written for a reader that cannot ask

/llms.txt is the order of operations, not a catalogue: read it once and you can take a piece of work from an idea to a verified change. It is tested against the product, so it cannot name a tool that no longer exists. 

# the whole knowledge base for where you are standing, as one document
curl -sH "Authorization: Bearer $TOKEN" \
  "https://api.omgiq.com/api/v1/kb/export?projectId=$PROJECT&environment=dev" > kb.md

Knowledge base

What the team learned, where the next agent will find it.

Most of what makes work slow is not in any repository: 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. That knowledge normally lives on one person's laptop, and dies with a session.

Here it is filed by project and environment, with a general layer for what is true of everything. Asking as this project, in dev returns all four layers, most specific first — so an agent that reads only the top has read the part most likely to be about its exact situation. And when it learns something, it files it back.

Also in the box

One project, one client

A read-only member can be scoped to a single project — a client watching their own work, and nothing else, through the same auth everyone else uses.

An audit trail that answers

Every state change, every agent call, every approval — with who, when and what it carried.

Three languages

English, Spanish and Brazilian Portuguese, including the parts most products leave in English.

GitHub, where it counts

Commits and pull requests link to the work they implement, so a story can show what actually shipped.

Test runs and deployments

Ingested as evidence, not screenshots — including which tests are flaky and how long they have been.

Webhooks and keys

Scoped API keys, including keys narrowed to one project, with a delivery log you can read.

Let them build. Keep the gates.

Every plan has the whole product. Bring your agents.

Sign in → Talk to us