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 the mapping, let a human confirm.;

What we are looking for

• You've built agentic systems that survived contact with paying customers: tool design, context engineering, multi-step and long-running flows, structured output, retrieval where it earns its keep, and the judgement to keep a step as deterministic code when that's the better answer. And you've operated them after launch: the evals, the regressions and the surprises that only surface once real users are on it.
• Evals as a habit rather than an afterthought: you have built eval harnesses for non-deterministic systems, decided what "good" means for a feature before shipping it, and used them to catch regressions.
• You've put guardrails around business-critical data: permission-aware, tenant-isolated, auditable, with a human in the loop wherever a wrong answer costs money.
• You've designed tool surfaces for models rather than people: hands-on with MCP and agent SDKs, and clear that exposing a good tool is a design problem, not a wrapper around an endpoint.
• Strong software engineering in Python: you write code other people maintain, and you have opinions about tests, CI and rollback.

Strong plusses

• Document understanding at scale: extraction from messy real-world PDFs where every supplier has its own layout.
• Comfortable enough in TypeScript and React to build the interface your feature needs.
• Streaming and long-running task UX, so an agent's work stays legible while it is still working.
• SQL and time series data at volume (PostgreSQL/TimescaleDB or similar).
• Knowledge of energy systems: electricity markets, contracts and tariffs, grid fees, load profiles, or related domains.
• Previous working experience in a fast growing start up or scale up.

Location

Ghent, Belgium (hybrid)

How we hire

Intro call → technical case → follow-up conversations with the team and founders.
We keep it simple and can move fast.

Ready to apply?

Send a short email to apply@companion.energy with your resume attached. Tell us why this role excites you and share something relevant: an AI feature you shipped to real users (what it got wrong at first, how you found out, and what you changed), or an agent you built and then had to keep working