Tarmac is now an OpenAI Select Partner

Tarmac has joined the OpenAI Partner Network as a Select Partner.

We keep a small number of these. We are an NVIDIA Solution Advisor and a Databricks Consulting Partner, and now we work with OpenAI. Each one earns its place the same way: it puts our engineers closer to the people who build the thing. In practice that means seeing how a model or platform behaves before it reaches general availability, getting our team into training built by the vendor rather than a reseller, and having a real support path when something misbehaves in production at two in the morning. Those are unglamorous benefits. They are also the ones that shorten the gap between what a client asks for and a system that holds up under load.

OpenAI has put serious money behind this one. It launched the Partner Network in June 2026 with a $150 million investment in its partner ecosystem, a stated goal of training and enabling 300,000 certified consultants by the end of 2026, and specializations in Codex, agents, and cybersecurity.

Look at where that spending is pointed. All of it goes toward implementation capacity. Frontier models have moved faster over the last two years than most organizations can absorb, and the thing standing between a company and useful AI is usually the supply of engineers who have shipped it before. OpenAI is funding that supply. We have argued for a while that this is where AI projects live or die, so a vendor spending nine figures on the same problem is one we want to be close to.

What this changes for our clients

Working with OpenAI improves two things we care about: the quality of our agentic workflows, and the training we give the engineers who use these models every day. That is what puts Tarmac in a position to get the full value of these frontier models on behalf of our clients.

Brent Kastner, CTO, Tarmac

Both of those are specific enough to hold us to.

Better agentic workflows. Agents fail in ways that single-shot prompting never does. A tool call returns something unexpected, the model recovers by inventing a plausible next step, and the error compounds four turns later where nobody is looking. Catching that is empirical work. It means knowing how a given model behaves under tool use, where it gives up, where it bluffs, and what an eval has to catch before a user ever sees it. Closer access to the people who build the models shortens that learning loop, and the shortened loop shows up in our clients’ systems as fewer silent failures in production.

Training that reaches the engineers. Vendor enablement often stops at the sales team. OpenAI’s certification track is aimed at practitioners, and the people taking it here are the engineers doing the work, who average 14 years of experience and use these models daily. Clients feel that as better judgment on the calls that matter: when a frontier model earns its cost, when a smaller one does the job, and what has to be true before either goes live.

How we choose models

A partnership with OpenAI does not turn us into an OpenAI shop. Clients hire us for judgment about which model fits which job, and that judgment only has value while it stays independent.

Our portfolio shows how this works. The agentic system we are proudest of runs on Claude: an agentic support triage workflow for INaudio spanning more than 100 inherited repositories, which took ticket triage from two days to twenty minutes. We chose that model because of how it behaved under the actual work, and that remains our only criterion.

The right answer to “which model should this run on” changes every few months, and it depends on the task, the latency budget, and the cost per call. A build partner who always lands on the same model is describing their own contracts. Ours stays what it has always been: evals before hype, with a senior engineer accountable for the call.

If you have AI work that has to survive real users, that is the standard we will hold it to. Here is how we build it, with the case studies attached.