A VP of engineering at a mid-market manufacturer told me last fall that he’d spent four months trying to hire one senior ML engineer. Two offers fell through. The candidate who finally accepted needed a month to give notice, then three months to learn the codebase well enough to ship anything that mattered. By the time that person was productive, the project that justified the hire had shifted underneath them. The roadmap moves faster than recruiting does.
That’s not a recruiting failure. It’s a structural mismatch. AI work tends to arrive in bursts — a document-extraction problem this quarter, a forecasting model the next, a pile of integration glue after that — and none of it is steady enough to justify a permanent specialist, yet all of it is too specialized for the team you already have. So leaders reach for the two tools they know: hire someone in-house, or scope a project.
Both have a failure mode that nobody talks about until they’re living in it. Hiring locks you into fixed cost and a long ramp before you know whether the work even pays off. Project work gets you a clean deliverable and then leaves — and the next thing you need starts cold, with a new statement of work, a new kickoff, and a team relearning everything they knew six weeks ago.
There’s a third shape for this, and it’s the model behind Ryshe Forge. I want to describe it plainly, because the name “reserved capacity” sounds like a billing trick and it isn’t one. It’s a different way of holding the relationship between your roadmap and the people who build against it.
The two defaults, and what each one actually costs
Before the alternative makes sense, it’s worth being honest about why the obvious options disappoint.
Hiring is the right call when the work is permanent, the volume is predictable, and you can carry the person through the slow quarters. For a steady production ML platform with a real backlog, hire. But for the typical mid-market firm exploring where AI fits, none of those conditions hold yet. You’re paying a fixed salary against demand that’s still lumpy, and you’re absorbing a ramp that runs months before the new hire understands your data, your constraints, and the political map of which systems you’re allowed to touch. If the first initiative turns out to be a dead end — and some will — you’ve converted exploratory risk into a permanent line item.
Project work fixes the commitment problem and creates a new one. You scope a thing, a team builds it, they hand it over, they leave. Clean. But AI initiatives almost never end where the SOW said they would. The extraction model works, and now you want it wired into the ERP. The pilot proves out, and now three other departments want a variant. Each of those is a new engagement: new scoping calls, new contracts, new ramp. The team that just spent six weeks learning your environment takes that context out the door with them, and the next team pays to rebuild it.
I think of that lost context as a restart tax. You pay it every time the work stops and starts. For a single well-bounded project it’s tolerable. For an evolving program — which is what AI adoption actually is — it compounds into something absurd. You can spend more on repeated kickoffs than on the engineering itself.
What reserved capacity actually is
Reserved capacity means you hold a standing block of senior delivery time, and we apply it to whatever is highest-value on your roadmap right now.
You’re not buying a fixed deliverable. You’re not buying a person you have to keep busy. You’re reserving a known amount of build throughput per month — and what it builds can change as your priorities change, without renegotiating the relationship each time.
The distinction that matters:
- Hiring buys a person, with all the fixed cost and ramp that implies.
- Project work buys a deliverable, and ends when the deliverable ships.
- Reserved capacity buys throughput, and stays pointed at your roadmap as the roadmap moves.
The practical effect is that the context stays in the room. The team that built your extraction pipeline is the same team that wires it into the ERP next month, because they never left. The restart tax goes to roughly zero. You stop paying to re-explain your environment and start spending that budget on actual engineering.
This is closer to how you already treat infrastructure than how you treat staffing. You don’t hire an electrician onto payroll to keep the lights on, and you don’t sign a fresh contract every time you flip a switch. You reserve a connection to a utility and draw against it. Reserved delivery capacity treats senior AI engineering the same way — as a utility you draw from, not a headcount you carry or a project you restart.
Why “scoped on a call” instead of a price list
We don’t publish a rate, and the reason is mechanical, not coy. The right amount of reserved capacity depends entirely on how much your roadmap actually demands and how concurrent that demand is. A team running one workstream at a measured pace needs a very different reservation than one pushing three things at once before a product launch. We scope that on a 30-minute call — what’s on the roadmap, how fast it’s moving, how many threads run in parallel — and size the reservation to fit. Anything else is guessing.
Concurrency: the part most people miss
Here’s the lever that makes this more than a retainer with a nicer name. Reserved capacity lets you run more than one workstream at the same time, and you decide how the throughput splits across them.
A real roadmap is rarely one thing. It’s usually something like:
- A primary build that’s the quarter’s headline — say, a forecasting model going to production.
- A secondary track that’s lower-stakes but real — internal tooling, a data-quality cleanup, an integration.
- A standing “keep things alive” thread — monitoring the models already in production, handling drift, fixing the thing that broke when an upstream API changed.
Hire one person and they do these in sequence, badly, because no single human context-switches across all three without dropping something. Scope three projects and you’re managing three contracts and three kickoffs for work that should share context. Reserved capacity lets a small senior team carry all three concurrently and rebalance as urgency shifts. When the forecasting model hits a wall and needs everyone, you pull capacity onto it for a sprint. When it stabilizes, you push that throughput back toward the tooling track. You’re steering one pool, not coordinating three vendors.
That flexibility is the thing you can’t buy with the other two models. Headcount is rigid by definition. Projects are rigid by contract. Reserved capacity is fluid on purpose.
Cadence is the quiet advantage
The other thing a standing reservation buys you is rhythm, and rhythm is underrated.
Project work runs in big, infrequent beats: kickoff, a long quiet middle, a delivery, a gap. Reserved capacity runs on a steady cadence — regular planning, regular shipping, regular review. You see progress every week or two, not every quarter. That tighter loop matters more for AI than for ordinary software, because AI work is empirical. You often don’t know whether an approach holds until you’ve built enough to test it against real data. A fast cadence means you find the dead ends in week two instead of week ten, and you redirect before the budget’s gone.
It also changes the conversation with your own stakeholders. When your CFO asks what the AI program is doing, “we ship something reviewable every sprint” is a very different answer than “the vendor is heads-down, we’ll see the deliverable in Q3.” Visible, steady output buys you organizational patience, which is often the scarcest resource in an AI effort that hasn’t yet produced its first undeniable win.
A note on what cadence is not
It is not busywork. A standing reservation does not mean inventing tasks to fill the hours. If the roadmap genuinely goes quiet, the honest move is to say so and right-size the reservation — not to manufacture motion. Telling a client they’re reserving more than they need is exactly the kind of thing we’d rather say on a call than discover six months in. The model only works if the capacity maps to real demand.
Why this fits a living roadmap
Most AI roadmaps are wrong in their specifics and right in their direction. You know roughly where you’re headed — better forecasting, less manual document handling, models that actually make it to production — but the precise sequence shifts every time you learn something. A pilot succeeds and pulls the next three items forward. A data problem surfaces and reorders everything. A regulatory change makes a “later” item suddenly urgent.
Hiring and project work both assume the plan holds still long enough to commit to it. The plan does not hold still. Reserved capacity is built for the version of reality where it doesn’t — where the destination is stable but the route keeps changing, and you want a team that re-points without a renegotiation every time.
That’s the whole idea. You’re not buying a prediction about what you’ll need in October. You’re buying the ability to do whatever October turns out to require, with a team that already knows your systems when October arrives.
Where this leaves you
If your AI work is genuinely steady and permanent, hire — and carry the ramp, because it’ll pay back. If you have one clean, bounded thing and no roadmap behind it, scope a project and be done. Those are real answers and I’d tell you so.
But if what you actually have is a living roadmap — a sequence of AI initiatives that keep evolving, that share context, that you’d rather not restart every quarter — then headcount and project work are both fighting the shape of the problem. Reserved capacity fits that shape. It holds the context, runs your workstreams concurrently, ships on a cadence you can see, and bends as your priorities bend.
That’s the model under Ryshe Forge. What the right reservation looks like for you depends on your roadmap and how concurrent it really is, which is a fifteen-minute conversation more than a sales pitch. If it’s worth pressure-testing against your situation, book a 30-minute call and we’ll size it honestly — including telling you if one of the other two models is the better fit.
