Est. 2014  /  Austin, TX  ·  Pune, IN

The demo always works.

Commerce Wright is an AI-first software engineering firm. We build the version that runs on a Tuesday — evaluated before it ships, traced after it does, and owned by an engineer whose name you know. AI is in everything we make and in how we make it. Neither one is left unsupervised.

Kickoff to first production release
41days
Change failure rate, trailing 12 mo
2.1%
Builds we've told clients to stop
9
Fig. 01 Reference build — retrieval agent, in production
TRACED END TO END INGRESS / API auth · rate limit AGENT ORCHESTRATOR p95 1.9s · streamed RETRIEVAL hybrid · reranked TOOL EXECUTORS typed · idempotent CONTEXT STORE pgvector · row-level ACL SYSTEM OF RECORD read-through EVAL SUITE 312 cases · runs in CI OBSERVABILITY traces · cost · drift HUMAN APPROVAL ON WRITE ACTIONS

Under contract

Named with permission. Four more are under NDA and we won't pretend otherwise.

  • Halstead Outdoor
  • Portway Logistics
  • Merit Dental Group
  • Cavalier Foods
  • Ridgeline Property Co.
  • Baxter & Lowe
AWS Advanced Tier Services Partner Microsoft Solutions Partner — Digital & App Innovation SOC 2 Type II — audited annually ISO/IEC 42001:2023 — AI management system

011 — Where it breaks

None of these looked like risks at the time.

Three situations we get called into more than any others. Each one started as a sensible decision made by competent people. If you recognise your own build in one of them, that's the conversation to have.

  1. 01

    The pilot that never left the pilot

    It demoed beautifully in March. Eleven months later it is still in staging. There was never an eval set, so nobody can prove it got better — or notice when it got worse. The one person who understood the prompt has moved teams, the board is asking for the return, and the honest answer is that the number was never being measured.

    The cost isn't the pilot. It's the two years of nobody trusting the next proposal.

  2. 02

    The prototype that became production

    Somebody built it over a weekend and it was genuinely impressive. Now invoices go through it. The prompt is a string literal three functions deep, the retrieval step reads a bucket nobody tagged, there are no tests because it was never meant to last, and the deploy is one script on one laptop. Every change now costs a third more than the last one, and that curve does not flatten by itself.

    Speed borrowed at the prototype is repaid, with interest, on every feature after it.

  3. 03

    The change nobody could measure

    A provider deprecates the model version you pinned. Or a supplier reformats the documents you index. Nothing throws an error — the answers just quietly get worse in a way no dashboard is watching. You find out from a customer, six weeks in, and then you get to explain to your regulator why you cannot reconstruct what the system said or what it was looking at when it said it.

    Without evals, "it got worse" is an argument. With them, it's a failing test on a Tuesday morning.

022 — What we build

Four benches, one team.

An AI feature is a product feature: it needs a front end, a data path, a deploy pipeline and somebody accountable for it at 3 a.m. Hire four vendors for that and you'll spend the difference translating between them. Pick a bench to see how it wires together.

Fig. 02 Pilot to production — the path

We take the thing that worked once and make it work every time.

  • Agents with typed tools, hard step and spend ceilings, and a human approval gate on anything irreversible
  • Retrieval built as an engineering problem — hybrid search, reranking, chunking chosen by measurement rather than by blog post
  • An eval suite before a launch date: golden cases, adversarial cases, and the trajectory, not just the final answer
  • Model routing with fallbacks, so a provider outage or a deprecation degrades quality instead of ending your day
  • Fine-tuning and distillation only where the evals show it pays for itself — usually as a cost move, not a quality one

And what we don't do

  • Foundation models. Training one is somebody else's capital expenditure, and you almost certainly don't need it.
  • An assistant on your website because the board asked for AI. If a form, a search box or a rules engine wins, we'll say so and it'll cost you a Survey to hear it.
  • Bodies by the hour with no ownership. We staff teams that finish things, not seats on someone else's org chart.
  • Anything we can't evaluate. If nobody can define what a right answer looks like, we can't tell you when it starts being wrong — and the contract would be a lie.

033 — How we work

Survey. Drawing.
Build. Watch.

Borrowed from people who build things that hold weight. Every stage ends in something you keep, whether or not you keep us, and nothing is scoped or priced before the Survey has told us what's actually there. After that the work takes one of three shapes — a fixed-scope project, a standing squad, or one engineer embedded in your team.

01

Two weeks · fixed fee

Survey

We sit with the people who do the work and watch them do it. What the system is, what the data actually looks like as opposed to what the schema claims, where the hours go, and what "better" would have to mean in numbers before anyone would call this a success. Most of the interesting findings are in the undocumented half.

You get A baseline measured today, a ranked list of what to build with an honest cost and confidence against each, and a shorter list of what not to build.

Nine times we've finished a Survey and said the answer isn't AI — it's a rules engine, a schema change, or hiring one person. You keep the document either way.

02

Three weeks

Drawing

Target architecture, build sequence, and the cost model — this is where the number comes from, with every assumption written down so you can argue with it. It's also where the eval set gets written: the cases the system has to get right, agreed with the people who will have to defend the answers, before a line of it exists.

You get A runbook, an eval suite, and a fixed price for the build. Actual cases, actual thresholds, actual owners. Not a slide deck with a robot on it.

03

Six to twenty weeks

Build

Two-week increments, demoed to whoever will have to live with it. The eval suite runs from the first increment and nothing ships past it failing, so quality is a chart rather than an opinion. Anything customer-facing runs in shadow against real traffic before it answers anybody — the first time it meets production is never the first time it matters.

You get Working software, the repositories that built it, the eval history in full, and a burn-down that is honest about the weeks it slipped.

04

Ongoing · monthly

Watch

AI systems don't hold still. Providers deprecate versions, your documents change shape, and users find phrasings nobody anticipated. We watch traces, cost per session, eval regressions and drift, and we run the model upgrades so you aren't pinned to a version that gets retired on somebody else's calendar. Thirty minutes a month with the same engineer, not an account manager reading a dashboard for the first time in the car park.

You get A monthly report with the ugly numbers left in — what it cost, what got worse, and which cases we added to the suite because of it. Thirty days' notice, either direction.

044 — Proof

Three jobs, with the constraint that made each one hard.

Halstead Outdoor · DTC retail · 210 staff

A support assistant that shipped nine weeks before Black Friday

Constraint Peak season starts whether or not you're ready, and a wrong answer about a returns window is a chargeback.

The pilot answered well and took eleven seconds, because it asked the model six times in a row. We rebuilt it as two calls over a properly indexed policy corpus, wrote 312 eval cases from real transcripts, and gave it exactly one write action — issuing a return label — behind a spend cap and a human approval above $200.

Assistant p95
11.4s 1.9s
Conversations closed without a human
0% 41%

Portway Logistics · Freight brokerage · 3 depots

Nine hundred documents a day, keyed in by hand

Constraint A warehouse system the vendor abandoned in 2022, and rate confirmations arriving as scans, faxes and photographs of paper.

Extraction was the easy half. The work was the boring half: a review queue that shows the clerk the source document beside every extracted field, confidence thresholds tuned so low-certainty rows route to a human instead of guessing, and a gateway wrapped around the legacy system so we could test against it without modernising it first.

Handling time per load
7 min 40 s
Fields needing correction
1 in 3 1 in 46

Merit Dental Group · Healthcare · 34 clinics

Proving what the thing said, six months later

Constraint PHI, thirty-four sites, and an auditor who is entitled to ask why a specific summary said what it said.

We scoped it down first: the assistant drafts, a clinician signs, and it is never the last word on anything clinical. Then retrieval was restricted by the same row-level permissions as the record system, every generation was traced with its exact context and model version, and an adversarial set was written specifically to try to pull one patient's chart into another patient's answer.

Ungrounded statements, sampled
6.4% 0.3%
Time to audit one answer
2 days 90 s
2.1%

Change failure rate across every client repository, trailing twelve months

2.4days

Median lead time from merged pull request to production

19

AI systems we run in production today, not counting the ones we handed over

41

Engineers. Twenty-four in Austin, seventeen in Pune. No offshore relabelling

055 — The bench

You'll meet these people, not a sales team.

Whoever scopes your work stays on it. We have never once handed an account to someone the client hadn't already argued with.

  • Priya Raghunathan

    Principal Architect, AI Systems · Pune

    Fourteen years, most of them in regulated environments. Owns the evaluation harness every engagement is built on, and the opinion that retrieval quality — not model choice — decides whether a system is any good.

  • Marcus Bell

    Head of Delivery · Austin

    Ran the night shift at a 900-seat operations firm for six years and has strong, specific opinions about alert thresholds. Rewrote our on-call rota after the second time someone got paged twice in one night. Decides what ships.

  • Dan Okonkwo

    Security & Model Risk Lead · Austin

    CISSP, eight years in digital forensics before this. Now spends his weeks trying to talk other people's agents into doing things they shouldn't, and enjoys it more than is strictly normal. Has told two prospective clients their data wasn't fit to be indexed yet.

  • Elena Vasquez

    Principal Engineer, Product · Austin

    TypeScript and Python, twelve years. Specialises in the systems nobody wants to touch — the ones with no tests, one deploy script, and an integration that only runs on Tuesdays. Usually the reason a prototype becomes a product.

066 — The awkward questions

Asked in almost every first call.

077 — Start here

An engineering review takes forty minutes.

No deck. An engineer, your system, and a list of what we'd look at first. If the answer is that you don't need AI for this, or don't need us yet, that's what you'll hear — it's happened often enough that we stopped being surprised by it.

Request an engineering review

Goes to a shared inbox both offices read. Replies inside one business day, usually the same afternoon.