AI Engineer

About the role

We are hiring an AI Engineer into Applied AI, the team that builds agentic capability across SQC's engineering, science, manufacturing and corporate teams, and runs the platform it is built on.

You will embed with a different host team every three to four months, across engineering, research, manufacturing and the corporate functions, and learn how each one actually works, digitally and physically, before you build anything for it. One rotation might be inspection tooling for lithography; the next, tracking devices through fabrication; the next, a corporate workflow nobody has automated. At the frontier of quantum computing, the problems arrive unsolved, often unstated, and with little precedent to copy.

You map the problem and the operating environment, then own what you build. Some of it will be messy. Getting it right takes judgement about data, system design and risk, not just prompting. Alongside the agents, you will teach as you go, so the capability outlasts the rotation. Applied AI sets the sequence of rotations and agrees with each host team what it commits before you arrive.

Based in Sydney, you will work hands-on with physicists, fabrication staff, engineers and corporate teams. This is a role for someone properly deep in applied AI: someone who thinks in loops and graphs, reaches for backpressure and ontologies before a bigger prompt, and already builds with agents as their default way of working.

Role responsibilities

• Work with the host team to define and deliver agentic capabilities, inside their domain and their constraints
• Model the domain before you automate it: the ontology, the data, and the state that has to match what is happening on the bench
• Find the quick wins and the fundamental shifts in how a team operates, prioritise between them, and deliver through the rotation
• Build, optimise and evaluate production agents
• Decide what the model does and what code does
• Design for backpressure, retries and idempotency; your agents sit in front of instruments, fab equipment and inference endpoints, and all of them have limits and bad days
• Say plainly what an agent will and will not do, including when a problem does not need one
• Build on the Applied AI platform (inference, MCP and web proxies, the evaluation harness, the agent registry and orchestration), improving it rather than working around it, and taking your share of running it
• Account for the impact and the cost of what you build, in terms the host team can defend after you have gone
• Hand over completely: code, runbook, evaluation and ownership to the host team, with no maintenance tail and no system that depends on one person remaining in the room
• Leave the host team more capable than you found them: the training, the habits and the judgement that outlast the agent

Your experience

Essential

• 4+ years building and running production software, with responsibility for it after release, and a record of shipping
• Building, optimising and evaluating production agents or LLM-backed systems, beyond prototypes and demos
• Strong Python, Go, Rust or C++
• Agent-first practice: coding agents are already your default way of working
• Tool use and context design, and the practical business of making an agent reliable rather than impressive (you can pick up our harness, MCP and proxy stack here)
• Accountability for an inference budget, even for a single agent: you have had to justify the spend and keep it inside a number
• High autonomy: you have worked embedded in someone else's team, without daily supervision, and been effective there
• Working directly with people who are not software engineers, and translating what they describe into what they need
• The judgement to say a problem does not need an agent, and to hold that position with a keen stakeholder
• Learning an unfamiliar domain quickly enough to be useful in it within weeks
• Handover as a habit: documentation, runbooks and tests good enough for someone else to own what you built
• Clear technical writing, and the ability to diagram a system so someone else can follow it

Nice to have

• Retrieval over messy internal data: documents, wikis, tickets, instrument output
• Evaluation practice: building the harness, offline and online scoring
• Data engineering: pipelines, storage and the modelling that has to match a real-world process
• Enough frontend to give a user something usable
• Scientific, laboratory or manufacturing environments, and users whose requirements arrive as a problem rather than a specification
• Consulting, internal platform or enablement work, where the deliverable was someone else's capability
• On-premise or air-gapped environments, including work with material that cannot leave the building
• Infrastructure as code and container orchestration (Terraform, Ansible, Kubernetes)
• Quantum computing exposure of any kind (no physics degree required)