Open roles.
Starting points, not job descriptions. Filter by the skill you’d lead with — most of these roles want two of them, and the second is usually what makes someone good at the first. If none of them fit, apply anyway and tell us what you’d build instead; it reaches exactly the same place.
Intelligence EngineerFull time · Remote
Build the systems clients own outright — machine-readable workflows, policy bounds, tool wiring, and the evaluation loop that makes them better each run.
You'd be building the thing CRFT sells: a workflow that stops being a demo and starts being the system a company runs on.
What the work actually is
Most of it is not model work. It's making a real workflow legible to a machine — the inputs, the decision, the bounds it must not cross, the tools it can reach, and the outcome data that comes back. The model is one component inside that, and usually the least interesting one.
You'll go from a scoped diagnostic to something in production in weeks, then stay long enough to watch it compound and to hand it over cleanly. Clients own what we build outright, so "it works on my machine" is not a finish line.
What we look for
- You've shipped something real that other people depend on, end to end.
- You reason about failure before you reason about capability — evals, bounds,
- You can sit with an operator, watch them work, and see the system underneath.
- You write things down. Our handovers are the product as much as the code.
What we don't need
A publication record, a specific framework, or five years of a library that has existed for two. Show us something you built and why it held up.
Intelligence DesignerFull time · Remote
Decide where human judgment sits, what the handoffs look like, and which failure modes to design against — before anything gets built.
Not screen design. You're designing the relationship between a person, a decision, and a model — which is the part that determines whether a system gets adopted or quietly worked around.
What the work actually is
Every workflow we build has a boundary: what the system decides on its own, what it escalates, and what it must never touch. Drawing that boundary is a design problem, and getting it wrong is how AI projects die — either the system is too timid to be worth having, or it's trusted somewhere it shouldn't be.
You'll sit with the people who run the workflow today, find where their judgment actually lives, and design the handoffs so the system earns trust instead of demanding it. Then you'll stay through build to see whether you were right.
What we look for
- You've designed something operators chose to keep using when they had an out.
- You think in states and edge cases, not just happy paths.
- You can hold a strategy conversation and a UI critique in the same hour.
- You're comfortable being upstream of engineering and concurrent with strategy.
What we don't need
A portfolio of beautiful things nobody shipped. Show us a system in use and tell us what you'd change about it now.
Intelligence StrategistFull time · Remote
Own the thesis and the system in one seat — size the opportunity, name the number it's accountable to, and stay on through ship.
The reason most AI strategy work fails is that the person who framed the bet isn't in the room when it gets built. Here they're the same person.
What the work actually is
You'll run the diagnostic: find the workflows worth touching, score them, and put a defensible number against each one. That number is not a slide — it's what the engagement is priced and judged against, and you'll be there when it's tested.
Then you stay. Through scoping, through build, through the part where the real constraint surfaces and the plan has to change. Our prices are published and fixed, so a scope you got wrong is a scope we absorb — which concentrates the mind considerably.
What we look for
- You've owned a recommendation through to a shipped outcome, not a handoff.
- You can build the case and read the code review, at least well enough to know
- You're precise about value: what changes, for whom, measured how.
- You'd rather kill your own idea early than defend it into production.
What we don't need
Frameworks for their own sake. Tell us about a call you made that turned out to be wrong, and what it cost.
Intelligence Data EngineerFull time · Remote
Own the data foundation the systems run on — messy real sources into something a model can be trusted against, in production, for a real client.
Every compounding system needs a loop: the output changes what happens next, what happens next is captured, and the capture improves the next output. You'd own the part that makes that loop real.
What the work actually is
Fifteen messy sources that disagree with each other, an owner for none of them, and a workflow that needs one trustworthy answer. You'll model it, pipeline it, and make it production-grade — then instrument the outcome data that lets the system learn rather than merely run.
This is hands-on and senior at the same time. There is no layer between you and the client's actual data, and no layer between you and the consequences of getting it wrong.
What we look for
- You've built pipelines someone else depended on and you were on call for.
- You're opinionated about data contracts, lineage, and what "correct" means.
- You can tell the difference between a modeling problem and a plumbing one.
- You care about the measurement loop, not just the ingest.
What we don't need
A specific cloud on your CV. We'll take judgement over tooling every time.
Forward-Deployed OperatorFull time · Remote — with client-site travel
Sit inside the client's operation, find where the work actually breaks, and make the system stick after we hand it over.
Deployment is not adoption. This role exists because the gap between the two is where most AI programs quietly fail, and it can't be closed from the outside.
What the work actually is
You'll embed with the team that runs the workflow — not to gather requirements, but to do the work alongside them until you understand why the official process and the real process differ. That difference is usually where the system has to change.
Then you'll build and adjust in place: rules the operators believe, escalation paths they'll actually use, and a scorecard that measures use rather than uptime. You're the last person out, and the reason it's still running a quarter later.
What we look for
- You're technical enough to change the system yourself, not just file a ticket.
- You're comfortable being the outsider in someone else's operation, early.
- You read a room — adoption is a trust problem before it's a product one.
- You'll travel when it matters, and know when it doesn't.
What we don't need
Pure delivery management. If the fix is a config change, we'd like you to make it.
One form. No cover letter theater.
Tell us what you built and why it held up.
Build the intelligence your company compounds on.
Five inputs, a published price, a report in 48 hours. Decide with numbers — then own what gets built.