Teach Kyber to behave like the best coordinator. Role shape: Own Kyber's data and modelling layer: infer the temporal dependencies of live operations, learn how coordinators allocate, and close the loop between real-time execution and forward scheduling. Environment: Python, Postgres, AWS, time-series and sequence models, learned cost functions, imitation and reinforcement learning, data pipelines, evaluation harnesses, technical hiring, on-site deployment, close work with the optimization role. Experience: Minimum three years applying machine learning in production. Practical reality: direct customer contact, time in live operations starting on the airport ramp, meaningful founding equity, coding credits, London-based, remote only by exception, UK work authorization preferred. The Problem: Operations in critical infrastructure look organized from the outside, but behind the curtain they run on radios, Excel sheets, emails, paper manifests, phone calls, and constant improvisation. Plans are built statically ahead of time for an operation that changes by the minute. What Kyber Brings: Kyber builds the plan before operations start, then turns it into live control as the day unfolds using algorithms, stateful systems, and agentic AI to continuously recompute the best allocation as conditions change. The old playbook no longer holds, and the technology is finally good enough to replace it. The Challenge: In any coordinated operation, coordinators make thousands of allocation decisions a shift using knowledge that exists nowhere in the system. What gets recorded is the outcome, not the reasoning behind it. We hold the trace: plan, execution, coordinator intervention with timestamp, and end-of-day result. It is sparse, confounded by the decisions we are trying to learn from, and temporally dependent. The problem is to estimate task duration and delay propagation from it, recover the implicit objective behind coordinator overrides, and feed both back into the forward scheduler so each shift updates the next. Because the platform is not domain-specific, the models have to fit the shared schema and be retrained per deployment rather than rebuilt per customer. What We Are Looking For: You own the data and the modelling: the data pipelines and operational event labelling; the feature layer; the work of making live data trustworthy before anything is built on it. You propose the architecture, covering: task duration and delay propagation; disruption forecasting; learned cost functions that feed the scheduler; and the reinforcement loop that lets forward scheduling compound over time. The role sits directly against the optimization work. The scheduler should behave the way a good coordinator behaves without an engineer encoding every effect by hand, so the interface between the learned components and the solver is designed jointly. This is a founding role. You will spend time on site as well as in the data, and you will talk to customers directly and hire the people who come after you. At least three years applying machine learning in production, where the model had consequences and had to survive messy data. Depth in time series and sequence modelling, probabilistic forecasting, and evaluation that holds up under distribution shift. Experience learning from human behaviour through imitation learning, inverse optimisation, preference learning, or reinforcement learning maps closely to what we need. Strong Python, and enough engineering to ship your own pipelines. The bar is high because the problem is hard, and Kyber will only become an exceptional company if the people building it are exceptional. We look for highly agentic engineers who move without being told what to do next, take on hard problems, and hold their standards when the operation is live and the stakes are real. Salary is not a constraint for the right person, and the role carries meaningful founding equity and coding credits. London-based, remote only by exception. UK work authorization preferred.