Fractional AI Platform Team
Last verified: October 2026· engagement
We act as your AI platform team for 20–40 hrs/week and build whatever the roadmap demands — the highest-leverage option when you need momentum before you hire.
- Outcome
- A senior AI platform team, on retainer
- Timeline
- Ongoing
- Pricing
- $20–40k/mo, 3–6 month minimum
- Buyer
- Founders, VP Eng without internal AI talent
The problem
You need an AI platform team but can’t hire one fast enough — and the roadmap can’t wait two quarters for the first senior hire to ramp.
What we do
- Act as your AI platform team for 20–40 hrs/week against your roadmap.
- Build whatever moves the needle — cost work, evals, tooling, MCP, agents.
- Set the standards and patterns your future in-house team inherits.
- Transition out cleanly as you hire, leaving documented systems behind.
What you get
Built on our open source
brat — A multi-agent harness for AI coding tools — crash-safe state, parallel execution, one CLI.
How a fractional team is meant to end
The engagement is designed backwards from its own conclusion, which is the part that distinguishes it from a staffing arrangement. At the start we agree what has to be true for us to leave: which systems are running, who owns them, what they know how to do without us. Everything is then built to be handed over — runbooks written as we go rather than at the end, decisions recorded with their reasoning, no component that only one of our engineers understands. If we are still essential at month six, something has gone wrong.
In the meantime we work as a platform team rather than a pool of hands. That means saying no to work that would create dependency, arguing for the boring option when it is the right one, and sequencing the roadmap so the pieces compound — instrumentation before cost work, tests before refactors, one internal system exposed properly before five exposed badly. Teams occasionally want us to move faster by skipping that sequencing, and the honest answer is that the order is what makes the speed real.
The shape that works best in practice is a senior internal owner paired with us from the first week, even part-time. They learn the systems as they are built rather than inheriting them cold, they are the person who says what fits your organisation and what does not, and they become the reason the work survives our departure. Where that person does not exist yet, helping you hire them is a legitimate part of the engagement — and frequently the most valuable part.
When this is not the right engagement
This model is built to hand over, which rules out several shapes of need. It is a poor fit when:
- You need one specific thing built. Take a fixed-scope engagement instead; it will cost less and finish sooner.
- You want capacity rather than a platform team. We are a poor and expensive substitute for contract engineers.
- There is no intention to hire internally, ever. This model is built to hand over, and without a destination the handover never happens.
Common questions about this engagement
Do you work under NDA?
Yes — we sign your mutual NDA before any data or repo access. For audits we prefer read-only access to start; for builds we work in a clean repo under your ownership.
Will we own what you ship?
Always. You own the code, the runbooks, the dashboards. We are explicitly set up to hand off and transition out, not to create dependency.
Vendor-agnostic — what does that mean in practice?
We integrate with what you already run — OpenAI, Anthropic, open-weight models on your cloud, your CI/CD, your observability stack. If a hosted vendor solves it, we will not reinvent it; if a self-hosted tool is the right answer, we will not pretend the hosted one is.
How is this different from a Big Four consulting deck?
We are the engineers doing the work, not analysts handing recommendations to a different team. The deliverable is working software in your repo, not a slide deck.
Can you work with our in-house AI team instead of replacing them?
Yes — most of our engagements pair with an internal owner and ramp them up to run the system after we leave. Many of our best engagements start with "we hired an AI team, help us get them productive."
How is this different from contract engineers?
A contractor takes the work you assign. We argue about the order, say no to work that would create dependency, and sequence the roadmap so the pieces compound — instrumentation before cost work, tests before refactors, one internal system exposed properly before five exposed badly. That judgement is most of the value, and it makes us a poor and expensive substitute if what you actually need is capacity.
What happens when the engagement ends?
It is designed backwards from that point. At the start we agree what has to be true for us to leave: which systems are running, who owns them, what your team can do without us. Runbooks are written as the work happens, decisions are recorded with their reasoning, and no component is left that only one of our engineers understands. If we are still essential at month six, something has gone wrong and we will say so.
Guides for this work
How to choose an AI engineering consultancy
Three very different businesses all call themselves an 'AI consultancy'; only one of them writes production code you own, and telling them apart is most of the buying decision.
Hiring & partnersHow to hire an LLM cost optimization consultant
Hire an LLM cost consultant when your bill is large enough to matter but your team is too busy to instrument, route, and eval their way out of it themselves — and only hire one who leaves you owning the result.
Let’s scope it on a call
Thirty minutes with an engineer. We’ll tell you straight whether this is the right first move for your team.