M
Staff Platform Engineer, AI Enablement
M
Staff Platform Engineer, AI Enablement
manifest globalEarly Applicant
- Posted 14 hours ago
- Be among the first 10 applicants
Job Description
Manifest Global empowers in building companies that connect the world towards growth, prosperity, and innovation. Our portfolio includes trailblazer brands such as Cialfo, BridgeU, Explore, Kaaiser, EduGo, and Flow AI and which are dedicated to expanding global student mobility by serving their respective stakeholders in the ecosystem.
Our Mission
To create a world where every student, regardless of their ethnicity, nationality, socio-economic status, and learning preference, gets equal access to higher education through our world-class network of portfolio brands; a network that globally connects community stakeholders that provide the finest resources and support material, anywhere in the world and at any time.
What This Role Is
Every year, millions of students make a decision that sets the direction of their lives: where to study, what to study, and which country they will build a career in. That decision runs through a counselor's office, a university's admissions funnel, a family's conversation with an advisor, and a visa timeline — and almost none of the signal from one step reaches the next. Manifest exists to connect that journey, and it does it through products that each serve one part of it exceptionally well.
This role owns the part that sits underneath all of them. As Staff Platform Engineer, you take full technical ownership of the shared layer every product is built on — identity, notifications, reporting, integrations, and the toolchain our engineers use every day — accountable for one thing above all: making the engineers who build on it successful at what they are trying to do. You go deep on those users — their workflow, their friction, what success actually means for them — and you build the platform that delivers it.
This is a hands-on individual contributor seat with a small team under it. Your leverage comes from how completely you understand the teams you serve, how good the platform you build for them becomes, and how well you bring the rest of the business along with you.
You report to the SVP of Engineering. You are assessed on two things: the adoption of the shared layer you're leading and the engineering-outcome metrics aligned to it — the measures of whether the teams you serve are genuinely more successful. Both move together, and both are how your performance is judged.
You do this inside a larger system. Manifest is several products becoming one connected whole, and the shared intelligence layer running underneath is the part you hold. You don't own what each product decides to build or the architecture that spans them — but you understand the portfolio deeply, you know how every unit depends on you, and you build in a way that lets each one draw on the shared layer and feed signal back into it. Your focus is narrow by design. Your awareness of the whole is not.
How the Role Grows
You own the shared layer as it is today, not as it stays. As the business evolves and as you grow, the scope moves — a new set of services, a new product line to support, a new generation of tooling — typically on a twelve- to eighteen-month horizon. Changes are deliberate, not arbitrary: they happen when a part of the platform reaches a stable state you've brought it to, and they're a mutual decision between you and the SVP of Engineering, weighing what the business needs against where you want to grow. You won't be pulled off something mid-flight the moment it starts working. It's how Manifest puts its strongest engineering where the business needs it most, and it's how you build range: the engineer who has gone deep on shared services, then developer experience, then the foundations our AI products run on understands this ecosystem in a way almost no one else can. The constant across every rotation is the mandate — own the shared half completely, make the teams that depend on it successful, build AI-native foundations that plug into the whole.
What Makes This Role Different
Most platform roles ask you to maintain a backlog of shared services. This one asks you to own an outcome for a specific set of users — our own engineers — and build whatever it takes to get there, including getting it genuinely adopted, and including the AI-native foundations this company has never had before.
The leverage is the Manifest ecosystem. You are not building for your users from scratch and in isolation. You have several products that need the same things, signal from across the portfolio to draw on, and a company that is AI-native from first principles. That means you can build services, workflows, and agentic foundations that a single-product platform team could never see well enough to build.
The timing is the argument. Across Manifest's units, AI is at the point where it stops being a feature and becomes the way the product works, and the foundations that carry it are being designed this year. The person who defines them, now, sets the direction for years.
What's Hard — And Why It's Worth It
The best engineers we know are drawn to the hard version of a problem, not the safe one. So here's the honest shape of it.
You build one shared layer, but every product team has its own gravity and its own deadlines pulling on it. Getting what your users need sometimes means making your case against someone else's, and not always winning. That friction isn't noise. It's what forces the sharpest thinking you'll do here, and the engineer who learns to fight for the shared answer while strengthening each product becomes the rarest kind of operator this company has.
The lead who runs a product knows their codebase cold and has their own conviction about what they need from you. Sometimes your judgement will say they're wrong. The moment you tell them that — in the language of their own product — and come out with their trust intact is the moment you stop being an engineer who ships and become one other engineers actually follow. Get it wrong and nobody tells you: they simply route around what you built, politely and permanently.
And because nobody has owned this before, you'll inherit the work mid-stride: several half-built versions of the same service, live commitments, teams already in motion. Deciding what to keep, what to kill, and what to reimagine — without burning the trust that came before you — is how you build the range almost no one in this market has.
None of this is the easy version of a platform job. That's exactly the point.
What You Own
Manifest Intelligence as a product
The markers below are directional — we will calibrate specifics once you are in the seat.
In your first weeks you will produce the clearest account anyone has of what our platforms have duplicated: where the same problem has been solved more than once, what each version costs us, and which three are worth consolidating first. Nobody has this today.
By the middle of your first year, one shared service will be live on more than one platform and genuinely preferred by the teams using it, the developer-experience problems will be ranked by the time they cost rather than by who complained loudest, and at least one of them will be fixed in a way every engineer can feel.
Over a year, a new platform starts from existing rails rather than from scratch — the test being whether the next product we stand up is visibly faster to build than the last one was. Every platform reads from the shared layer in production. And the engineers on it report to someone who makes the calls, rather than to an empty seat.
What You Bring
You have spent eight years or so building production systems, with real depth in at least one of our stacks — Rails, services, or the data platform. You are still hands-on and intend to stay that way.
You have built an internal platform that other teams actually adopted, and you can say honestly how you got that adoption. Anyone can build a shared library; the skill here is the part where people choose to use it. You know the failure mode — the beautiful abstraction nobody wanted — because you have either caused it or narrowly avoided it.
You treat developer experience as a discipline rather than a side effect. CI, environments, build and deploy, the patience to make them unremarkable. You can quantify friction, not just complain about it.
You lead without a reporting line. You can tell a platform lead their request is not special, explain why in terms of their own product, and have them come back next time. You have worked in a multi-product company, or you understand why shared platform in a single-product company is a different and easier job.
You are AI-native or visibly becoming it. Our agent products integrate with everything, and the shared layer is what makes that tractable. You do not need to be an ML engineer; you do need to understand what agentic systems ask of the platform underneath them.
You are comfortable in a distributed team across time zones — ours sits across Delhi, Pakistan and South India — and comfortable writing things down, because most of what makes a shared layer adoptable is documentation and contracts rather than code.
Most importantly: you read this and your first reaction was not this is a solid platform job. It was four teams are building the same thing four times and I want to be the one who stops it.
Why Manifest
Manifest Global is building the infrastructure for global human capital mobility, connecting students, schools, universities, and employers across 150+ countries. Our portfolio spans Cialfo (AI-powered college counseling, 2,000+ schools), BridgeU (university guidance for international schools globally), Kaaiser (trusted study abroad counseling since 1997 across India and Southeast Asia), Explore (AI-powered university outreach, 1,000+ university partners), and EduGo (study abroad counseling and student placement). Together, we move talent across borders at scale. $700B flows annually in remittances from migrant workers. 85M workers will be missing from developed economies by 2030. We're building the operating system that changes that. $76M raised. Still early.
The ecosystem only compounds if the products are genuinely one system rather than five that share a logo. This seat is the part of the company where that is literally true or literally not.
Our Mission
To create a world where every student, regardless of their ethnicity, nationality, socio-economic status, and learning preference, gets equal access to higher education through our world-class network of portfolio brands; a network that globally connects community stakeholders that provide the finest resources and support material, anywhere in the world and at any time.
What This Role Is
Every year, millions of students make a decision that sets the direction of their lives: where to study, what to study, and which country they will build a career in. That decision runs through a counselor's office, a university's admissions funnel, a family's conversation with an advisor, and a visa timeline — and almost none of the signal from one step reaches the next. Manifest exists to connect that journey, and it does it through products that each serve one part of it exceptionally well.
This role owns the part that sits underneath all of them. As Staff Platform Engineer, you take full technical ownership of the shared layer every product is built on — identity, notifications, reporting, integrations, and the toolchain our engineers use every day — accountable for one thing above all: making the engineers who build on it successful at what they are trying to do. You go deep on those users — their workflow, their friction, what success actually means for them — and you build the platform that delivers it.
This is a hands-on individual contributor seat with a small team under it. Your leverage comes from how completely you understand the teams you serve, how good the platform you build for them becomes, and how well you bring the rest of the business along with you.
You report to the SVP of Engineering. You are assessed on two things: the adoption of the shared layer you're leading and the engineering-outcome metrics aligned to it — the measures of whether the teams you serve are genuinely more successful. Both move together, and both are how your performance is judged.
You do this inside a larger system. Manifest is several products becoming one connected whole, and the shared intelligence layer running underneath is the part you hold. You don't own what each product decides to build or the architecture that spans them — but you understand the portfolio deeply, you know how every unit depends on you, and you build in a way that lets each one draw on the shared layer and feed signal back into it. Your focus is narrow by design. Your awareness of the whole is not.
How the Role Grows
You own the shared layer as it is today, not as it stays. As the business evolves and as you grow, the scope moves — a new set of services, a new product line to support, a new generation of tooling — typically on a twelve- to eighteen-month horizon. Changes are deliberate, not arbitrary: they happen when a part of the platform reaches a stable state you've brought it to, and they're a mutual decision between you and the SVP of Engineering, weighing what the business needs against where you want to grow. You won't be pulled off something mid-flight the moment it starts working. It's how Manifest puts its strongest engineering where the business needs it most, and it's how you build range: the engineer who has gone deep on shared services, then developer experience, then the foundations our AI products run on understands this ecosystem in a way almost no one else can. The constant across every rotation is the mandate — own the shared half completely, make the teams that depend on it successful, build AI-native foundations that plug into the whole.
What Makes This Role Different
Most platform roles ask you to maintain a backlog of shared services. This one asks you to own an outcome for a specific set of users — our own engineers — and build whatever it takes to get there, including getting it genuinely adopted, and including the AI-native foundations this company has never had before.
The leverage is the Manifest ecosystem. You are not building for your users from scratch and in isolation. You have several products that need the same things, signal from across the portfolio to draw on, and a company that is AI-native from first principles. That means you can build services, workflows, and agentic foundations that a single-product platform team could never see well enough to build.
The timing is the argument. Across Manifest's units, AI is at the point where it stops being a feature and becomes the way the product works, and the foundations that carry it are being designed this year. The person who defines them, now, sets the direction for years.
What's Hard — And Why It's Worth It
The best engineers we know are drawn to the hard version of a problem, not the safe one. So here's the honest shape of it.
You build one shared layer, but every product team has its own gravity and its own deadlines pulling on it. Getting what your users need sometimes means making your case against someone else's, and not always winning. That friction isn't noise. It's what forces the sharpest thinking you'll do here, and the engineer who learns to fight for the shared answer while strengthening each product becomes the rarest kind of operator this company has.
The lead who runs a product knows their codebase cold and has their own conviction about what they need from you. Sometimes your judgement will say they're wrong. The moment you tell them that — in the language of their own product — and come out with their trust intact is the moment you stop being an engineer who ships and become one other engineers actually follow. Get it wrong and nobody tells you: they simply route around what you built, politely and permanently.
And because nobody has owned this before, you'll inherit the work mid-stride: several half-built versions of the same service, live commitments, teams already in motion. Deciding what to keep, what to kill, and what to reimagine — without burning the trust that came before you — is how you build the range almost no one in this market has.
None of this is the easy version of a platform job. That's exactly the point.
What You Own
Manifest Intelligence as a product
- Identity, notifications, reporting and integrations — designed, built and maintained once, for every platform
- The roadmap for the shared layer, anchored to one question: is a platform team faster because of what we built
- Service and API contracts, versioned, so a change here does not break four products
- How each business platform actually connects into MI — the migration, the support, the thing that makes switching worth it
- The decision about what belongs in the shared layer and what should stay in a product, made deliberately rather than by whoever asked first
- Deprecating the duplicated versions once the shared one lands, so we do not end up with five implementations instead of four
- The tooling, environments and build-and-deploy path the whole engineering team uses every day
- The friction inventory: what each team works around, how much time it costs, and which three things are worth fixing first
- Making the boring things boring — CI that is trusted, environments that match, deploys that are unremarkable
- Being the person platform leads come to when they hit something they should not have to solve alone
- Turning a recurring individual blocker into a structural fix rather than a repeated favour
- Two engineers today, growing as shared services do — their technical direction, their growth, and the standard of what they ship
- Working with the Principal Software Architect on the design, and with the Staff Infrastructure Engineer on what it runs on
The markers below are directional — we will calibrate specifics once you are in the seat.
In your first weeks you will produce the clearest account anyone has of what our platforms have duplicated: where the same problem has been solved more than once, what each version costs us, and which three are worth consolidating first. Nobody has this today.
By the middle of your first year, one shared service will be live on more than one platform and genuinely preferred by the teams using it, the developer-experience problems will be ranked by the time they cost rather than by who complained loudest, and at least one of them will be fixed in a way every engineer can feel.
Over a year, a new platform starts from existing rails rather than from scratch — the test being whether the next product we stand up is visibly faster to build than the last one was. Every platform reads from the shared layer in production. And the engineers on it report to someone who makes the calls, rather than to an empty seat.
What You Bring
You have spent eight years or so building production systems, with real depth in at least one of our stacks — Rails, services, or the data platform. You are still hands-on and intend to stay that way.
You have built an internal platform that other teams actually adopted, and you can say honestly how you got that adoption. Anyone can build a shared library; the skill here is the part where people choose to use it. You know the failure mode — the beautiful abstraction nobody wanted — because you have either caused it or narrowly avoided it.
You treat developer experience as a discipline rather than a side effect. CI, environments, build and deploy, the patience to make them unremarkable. You can quantify friction, not just complain about it.
You lead without a reporting line. You can tell a platform lead their request is not special, explain why in terms of their own product, and have them come back next time. You have worked in a multi-product company, or you understand why shared platform in a single-product company is a different and easier job.
You are AI-native or visibly becoming it. Our agent products integrate with everything, and the shared layer is what makes that tractable. You do not need to be an ML engineer; you do need to understand what agentic systems ask of the platform underneath them.
You are comfortable in a distributed team across time zones — ours sits across Delhi, Pakistan and South India — and comfortable writing things down, because most of what makes a shared layer adoptable is documentation and contracts rather than code.
Most importantly: you read this and your first reaction was not this is a solid platform job. It was four teams are building the same thing four times and I want to be the one who stops it.
Why Manifest
Manifest Global is building the infrastructure for global human capital mobility, connecting students, schools, universities, and employers across 150+ countries. Our portfolio spans Cialfo (AI-powered college counseling, 2,000+ schools), BridgeU (university guidance for international schools globally), Kaaiser (trusted study abroad counseling since 1997 across India and Southeast Asia), Explore (AI-powered university outreach, 1,000+ university partners), and EduGo (study abroad counseling and student placement). Together, we move talent across borders at scale. $700B flows annually in remittances from migrant workers. 85M workers will be missing from developed economies by 2030. We're building the operating system that changes that. $76M raised. Still early.
The ecosystem only compounds if the products are genuinely one system rather than five that share a logo. This seat is the part of the company where that is literally true or literally not.
More Info
Key Skills
developer experience
data platform
Rails services
CI environments
About Company
