Summary
Mozilla is building a position in open source AI through research, community, tooling, and public advocacy. A big part of that work is showing, not just telling.
We need an engineer who ships fast and in public — working code and real demos that developers can install, fork, and build on. The current focus is Harbor, a Firefox and Chrome extension implementing a proposed Web Agent API that puts model choice, tool permissions, and agent oversight back in the hands of the user and the browser, rather than the vendor. Harbor is three layers: the browser extension at the bottom managing permissions, model access, and revocation; the SDK/API layer on top exposing primitives like window.ai, window.agent, and WebMCP tools; and the application and workflow layer at the top — the actual experiences being built. The thesis is that agents should only be able to do what a page explicitly declares, not free-roam the DOM.
Making those layer boundaries legible is core to the role — if a developer or their coding assistant keeps reaching for the wrong primitive, that's yours to fix. If you've shipped a browser extension, authored MCP servers, run models locally with Ollama or llama.cpp, and thought seriously about prompt injection as an architectural problem rather than a prompt-level concern, this is the specific intersection we're hiring for.
Beyond Harbor, Mozilla is building across a broader sovereignty stack — open identity, privacy-preserving verification, and other surfaces where the same thesis applies: users should own the layer, not the platform. The right person will find adjacent prototyping work as that develops, and will be energized by the problem space broadly enough to move fluidly across it.
What you'll do
- Ship working tools, demos, and reference implementations on top of Harbor and open source AI tooling — fast. Days, not weeks. Code that makes architectural choices concrete enough for another developer to install, read, fork, and build on.
- Make the layer architecture legible — reference implementations clean enough to read, documentation that maps the repo structure and clarifies the relationship between Web Agents API and Harbor SDK. If a developer or their coding assistant keeps reaching for the wrong primitive, that's yours to fix.
- Be the technical practitioner in the room when it matters — a WICG call, a hackathon, a GitHub thread where a hard architecture question comes up. A community manager handles distribution and presence; your job is to show up with working code and real opinions when the conversation turns technical, and come back with a clear read on what developers are missing or getting wrong.
- Use coding agents and AI-assisted development tools as the way you work, not a novelty. The repo already has a Cursor agent as a contributor.
- Engage with the standards process — WICG, W3C — as a practitioner.
- Fix the real technical gaps. Real problems on the table right now: proper function calling in the bridge (currently using response parsing), permission granularity beyond origin-level, streaming abort, WASM MCP server tooling, Safari support. The shape of the work is this specific, but evolving.
- As Mozilla's broader prototyping surface expands, identify and ship into adjacent opportunities where working code can move a conversation forward.
What we're looking for
- Strong software engineering fundamentals. You write code others can read — clear structure, obvious intent, reusable patterns. You know the difference between prototype-quality and production-quality and make that call deliberately.
- Hands-on experience with the open source AI stack — inference, orchestration, agent frameworks, evaluation. You've built something real on top of open models, and you have opinions about where current frameworks get the abstraction wrong.
- Security instincts around agentic systems. You understand prompt injection as an architectural problem. You have a view on typed-verb surfaces vs. DOM-driving agents.
- You can explain layered architectures to developers who don't share your context — in code, in docs, and in writing — clearly enough that developers and their AI assistants route to the right layer without guessing.
- Strong written communication and credibility in public as a practitioner. You can explain what you built, why you shaped it the way you did, and what's still unresolved.
- Fluency in Python and/or TypeScript, with enough range to pick up whatever the project needs.
- Firefox and Chrome extension development. WebExtensions API, content scripts, background workers, message passing, native messaging — you've shipped something here.
- MCP fluency. You've authored MCP servers — JS and ideally WASM — and designed tool schemas. OAuth integration for MCP servers is directly relevant. You understand what makes a tool surface good and where the current protocol has edges.
- Local inference experience. Ollama, llama.cpp, MLX — you've run models on-device and understand what that imposes on API design.
- Permission and capability system design is a real plus — scoped access, revocable grants, per-origin controls, OCAP patterns, information-flow controls, capability tokens.
- Browser standards familiarity — WICG, W3C, explainer authorship — is a plus.
What success looks like
- A growing set of prototypes, reference implementations, and demos that the community manager can put in front of developers with confidence, because the code is readable, the docs are clear, and the layer boundaries are unambiguous.
- Codebase and documentation that are clean enough that a developer can clone the repo, understand the layer architecture, and build correctly on top of it without asking for help — and their coding assistant routes to the right primitives without being corrected.
- Real technical gaps — function calling, streaming abort, WASM MCP tooling, Safari support — closed, with clean implementations that hold up to scrutiny.
- Influence on the standards conversation earned through shipping — a concrete contribution to WICG or W3C that came from being a practitioner, not just a participant.
- A technical voice that developers trust because what you shipped worked and what you said was right.
Engagement model
- Fixed-term, contract-based engagement
- Flexible hours and outcome-oriented working style
- Work produced through this engagement is expected to be developed in the open where appropriate, including public repositories and community-facing channels
- This opportunity is scoped around specific prototyping and ecosystem-facing deliverables, rather than a permanent employee role
Budget for this opportunity: $200,000–$227,250 annualized equivalent.
This is a fixed-term contract opportunity, not a permanent employee role. Final contract terms — including scope, weekly hours, duration, and payment structure — will be determined based on the needs of the engagement and the selected contractor’s experience. This posting reflects Mozilla’s good-faith budgeted range for the work at the time of posting.