The cockpit for an AI-run engineering loop

Feedback in. Shipped code out.
On the seats you already pay for.

A customer reports something inside your app. It lands on a board as a card. Agents plan it, build it and verify it — through gates that a person opens — and it ships as a pull request. The work runs on your engineers' own machines, drawing on the AI subscriptions they already have, and OnStudio shows you how much of that capacity is actually being used.

Open OnStudio →See the loop
Inboxa personPlannera runnerPlan reviewa personBuildinga runnerLandedONB-231 · storyGST before discount
One card, the whole loop. The ring lights when a person opens a gate.12s
Engineering board · lanesgate a personagent a runner
InboxPlannerPlan reviewBuildingBuiltVerifyingReviewedLanded → PR open

A card's lane is derived from what actually happened — a plan approved, a run that succeeded, verdicts recorded — never from a status someone set by hand. Nothing moves a card; the facts change and it is drawn somewhere else.

The loop

Five steps. Two are yours.

Agents do the planning, building and verifying. People open the gates. A gate is a lane watched by a person and it will wait forever — that is the design, not a limitation.

  1. 1a customer

    Reports it, in your app

    Screenshots across pages, numbered pins on the spot, the page it happened on, who reported it. It becomes a card in Inbox.

  2. 2an agent

    Plans it

    The planner reads the card and the repos, writes a plan with test criteria, and stops.

  3. 3you

    Approve the plan

    The first gate. A person reads the plan. Nothing builds until they open it.

  4. 4an agent

    Builds and verifies

    The engineer works in its own worktree; the verifier records verdicts against the plan’s criteria.

  5. 5you

    Approve and land

    The last gate offers both hand-off and merge — your choice. It ships as a pull request.

Every button on the board is the same command an engineer could type. opr.sh actions --key STUDIO-118 lists what is legal on a card right now — and for each thing that is not, why. A button never offers what the CLI would refuse, because they are one answer read twice.

1 · Real-time customer feedback

The distance from “this is broken” to a pull request is one card.

A feedback widget lives inside every OnSuite app. A user files what they saw, where they saw it, and what they expected — without leaving the page and without a cockpit login. The report is the work item. It carries its screenshots and pins all the way to the engineer's worktree and the verifier's verdicts, so nobody re-describes the bug.

  • 01Captures across pages. Paste, drag in, or one-click from the browser extension; the tray persists while the user navigates, then submits once.
  • 02Numbered pins on the spot. Up to twenty per capture. The drawer renders the same image with the same pins for whoever picks it up.
  • 03A recommended solution and test criteria, in the reporter's words — the planner reads them, the verifier checks against them.
  • 04“My submissions.” The reporter sees where their card is — Inbox, Plan review, Building, Landed — without asking anyone.
app.onbooks.onsuite.in/invoices/new
New invoiceINV-0192 · draft
Customer
Meridian Traders
Date
06 Sep 2026
ItemQtyRateGST
Consulting · Sep150,0009,000
Discount (10%)−5,000
Total₹54,000
Feedbackanita@meridian…
Captures · 1
  1. 1GST is computed before the discount.
  2. 2Total doesn't match the preview.
Recommended solution
Apply the discount first, then tax.
Test criteria
Preview total equals invoice total.

→ ONB-231 in Inbox · with both pins

2 · AI engineering workflow

Roles that run. Gates that wait. A workflow you can edit.

A workflow is stops, lanes and rules — configuration, not code. Which role is next, what a drop on a lane records, when a card counts as built: all of it is data the board reads, and all of it is editable. Install a shape from the catalogue, name it for your team, change a lane, add an action. No deploy.

Four roles

  • planner — reads the card and the repos, writes a plan with test criteria, stops at the gate
  • engineer — builds in its own worktree on the request’s branch; every phase of an epic shares its tree
  • verifier — records verdicts against the plan’s criteria; a failing verdict disables land, with the reason
  • nudger — moves already-approved work with no human action — by pressing the board’s own buttons, never through a gate

Refusals that teach

A button that vanishes teaches nothing. One that says why teaches the rule.

$ opr.sh actions --key ONB-231
ONB-231 · eng · ready_to_verify
▸ land Approve & land
✗ pr Open PRs
✗ nothing landed yet — Approve & land first
· discard Reject

Work runs where your code is

A runner on an engineer's machine claims cards for the roles it provides, in the worktrees it holds. Adding a machine is starting the runner on it.

Nothing executes in the browser

The board records an intent; the runner does the work. Two authorities: OnStudio says who you are, the host's own key file says whether it trusts you.

Ships as a pull request

The last gate never merges to main for you. It opens the PRs, or opens and merges — the operator's call, on the record.

3 · AI content & marketing workflow

You plan the week. The agents drive it. You publish.

Write the week's briefs — a blog, a LinkedIn post, an X thread, a creator shortlist, a check on what the AI engines say about you. Each becomes a card on a board shaped for that kind of work: a writer drafts into your marketing repo, a verifier checks links, front-matter and the build, and nothing goes live until a person approves it — from the same drawer, with the same gate, as an engineering card.

This week, as you planned it5 briefs · 3 shapes · live

A brief per slot: what, for which channel, through which shape. Each is a card; the lane it sits in says who has it. Agent lanes tick on their own — a gate waits for you.

  1. MonWhy refusals should say whyBlog · draftIdeasWriterDraft reviewApprove & publishPublished
  2. WedOne card, the whole loopLinkedIn · draftIdeasWriterDraft reviewApprove & publishPublished
  3. ThuCapacity, in one lineX thread · draftIdeasWriterDraft reviewApprove & publishPublished
  4. ThuCreators for the launchOutreach · selectTargetsSourceShortlistDelivered
  5. FriDoes ChatGPT know us?GEO · measureTargetsAnalyseFindingsProduceReviewDone
gate yoursagent theirs✓ you opened a gatebriefs seed the board · you publish
Three shapes for marketing workfrom the catalogue

Nine marketing agents need gates in different places, and one lane chain cannot express all of them — so there are three. Install one under your own name; edit it if it does not fit.

DraftWriter · LinkedIn · X · UGC
IdeasWriterDraft reviewApprove & publishPublished
SelectInfluencer outreach — one agent, one gate, and the gate is the delivery
TargetsSourceShortlistDelivered
MeasureSEO · GEO · coding — the middle gate is the cost gate
TargetsAnalyseFindingsProduceReviewDone

Measure's input is Signals — every tracked prompt, and what each AI engine actually said about you.

Content board · lanes
IdeasWriterDraft reviewBlog verifierApprove & publishPublished

Briefs seed the board

A backlog of topics with a priority and a target day is all the planning there is. Seeding is idempotent — re-run it and nothing duplicates.

Voice rules outrank tasks

An EDITORIAL.md in the repo carries voice and claims rules. Agents read it every run; it wins over any brief.

Drafts live in the repo

Front-matter status draft → review → published. Review on your local dev server; a mechanical check gates the build; you press publish.

4 · Capacity

Your team already pays for the compute. Most of it goes undrawn.

Every engineer's AI subscription is a budget with a five-hour window and a weekly one. OnStudio reads each seat's own usage figure, turns it into week pace — how much of the week's budget is drawn against how much of the week has passed — and shows every seat on one line. The goal is simple: raise the feature load until the pace stays near 0.9×, on machines that would otherwise sit idle overnight.

  • 01Every seat, one line. The week by five-hour windows, every seat on one time axis. A box's shade is its peak draw; the tan boxes and empty tracks are the capacity nobody used.
  • 02What the seat bought. A per-run ledger: which card, which role, how long, what it cost the window — so utilisation is a number you can act on, not a feeling.
  • 03The lever is dispatch volume. The nudger keeps approved work moving without a person present; a pace-aware claim stops a host from being throttled before its window resets.
  • 04Unknown is never zero. If a seat's usage can't be read, it reports unknown — never “idle, dispatch everything.”
The week, by 5hrone row per seat · one box per 5-hour window

Who drew what, when — every seat on one time axis. A box sits at its window's true clock position; its shade is the peak draw inside it.

seat · Aseat · Bseat · Cbuild · 1seat · Dseat · EMonTueWedThuFriSatSun
each box = one 5-hour window · shade = its peak drawblank 0%<30%<80%<100%maxed — throttled

empty track = no session sampled (not 0%) · illustrative week; seats anonymised

Part of OnSuite

One widget in every app. One board for all of them.

Feedback from any OnSuite app

The widget ships in the shared UI kit. Mount it once; every report names the app and the page it came from.

Your workspaces, your SSO

Sign in once on the platform; OnStudio is a workspace like any other. Roles decide who opens which gate.

Your machines, your keys

Runners live on hardware you control. A host's trust list is a file on that host — the API has no code path that opens it.

Put the feedback where the work is.

Open the board, file the first card from your own app, and watch a planner pick it up.

Open OnStudio →Create a workspace