Applied AI Engineer
Enregistrez cette offre et organisez votre recherche
Créez un compte gratuit pour enregistrer des offres d'emploi, créer des alertes et revenir à cette liste depuis votre tableau de bord.
TL;DR
We help large enterprises cut energy costs and valorize flexibility in the age of AI.
We're hiring a Applied AI Engineer to own the foundation under our agentic features: the architecture, the harnesses, the evals, the tool surface, the model choices and the guardrails that let AI workflows run reliably for large enterprise customers.
About Companion.energy
Companion.energy connects the financial side of energy management (contracts, markets, risk) with the operational side (assets, processes, sites). We model complex energy contracts and flexible assets, forecast demand and production, and translate predictions into automated, second-by-second control decisions that move megawatts and money. Our software is used by large B2B enterprises and energy players to lower OPEX, maximize revenue, increase renewable usage, and manage risk.
Why Companion.energy?
- Where this is going. Energy management today runs on spreadsheets, manual checks and consultants who bill by the hour. Reading a contract, checking a year of invoices line by line, comparing one site against another, writing the monthly report. Almost none of that work needs a person, and all of it has to be right. We believe agents do that work, inside the platform, on the customer's own data, and that this is what rebuilds the category rather than making it look nicer.
- Insight on demand instead of by project. When the platform can benchmark a portfolio of sites or explain a cost deviation itself, analysis stops being an annual consulting engagement and becomes something a customer asks for on a Tuesday afternoon. That changes what our customers are able to do, not just how quickly they click.
- It ends in the physical world. The same platform steers batteries, shifts industrial loads and bids into balancing markets. Insight here does not end in a report that gets filed. It ends in megawatts moving at a different moment, which is what makes an energy asset pay for itself and what makes a renewable grid workable.
- The repetitive work is a bottleneck we feel ourselves. A lot of the configuration and analysis behind our features is still done by hand on our side, and that is precisely what stops us rolling them out to more customers. Automating it is not an internal efficiency project. It is how the company scales.
- Real stakes. Large enterprises act on what our system tells them. A reconciliation that gets a number wrong becomes a claim against a supplier, not a bad chat reply. That constraint is what makes this interesting engineering rather than a demo problem.
- Room to decide. The agentic part of the product is early, already live with customers, and the place on our roadmap with the most room in it. You will be setting the direction rather than inheriting someone else's framework.
What you'll work on
- The agentic architecture. How an agent is defined, how tools are exposed to it, how context gets assembled, how a run is traced, and how state and long-running work are handled. Today each of our AI workflows answers those questions its own way. You decide how we answer them once, so that building the next agentic feature is routine rather than a new invention.
- Evaluation. Deciding what "good" means for a feature whose output differs on every run, then building the harnesses and datasets that hold it to that standard and catch a regression before a customer does. This is the part most teams skip and the part that separates a demo from a product.
- The tool surface. We serve the platform to agents over MCP today, through an internal management server and a customer-facing analytics server. Designing tools to be used by models rather than people is real design work, and so is deciding which steps of a workflow should stay deterministic code instead.
- Multi-model. Which model runs which step, how we stay able to swap them as they change, and how that decision gets made on evaluation evidence rather than on release notes.
- Cost, latency and reliability as product constraints. A budget per feature, caching, retries and fallbacks, and the monitoring that tells us when a workflow has become slower or more expensive than the value it delivers.
- Guardrails our customers can accept. Permission‑aware, tenant‑isolated and auditable, with human‑in‑the‑loop wherever a wrong number turns into a claim against a supplier. Our customers are large enterprises, and their data cannot leak across tenants or into the wrong hands.
- The workflows on top. You will build features as well as foundations, and the foundation gets judged by how fast the next feature ships. Contract and hedge position ingestion is next in line, following the pattern reconciliation established: take the document, parse it, propose th