Every large company runs on enterprise software. SAP, Salesforce, Dynamics 365, Kinaxis, Ariba, Coupa, and dozens of systems wired around them. Keeping all of it running, and changing it when the business changes, costs over $100B a year in consultants. The way it gets done today is with people. System integrators put 20 to 50 of them on a single problem, fixes get made under time pressure and go undocumented, and the company ends up dependent on whoever still remembers why things are the way they are.
We're building the software that does that work instead. Dodge AI is an AI platform for enterprise systems, with agents that understand a company's landscape well enough to investigate it, plan changes, and carry them out.
The understanding is the hard part. Every enterprise runs a thick layer of company-specific logic sitting on top of standard software, and almost none of it is written down. One warehouse allocates stock differently. One country has an extra approval step. One job runs overnight because the system used to fall over during the day. That layer is why a consultant takes three weeks to answer a question, and it is what we're building software to learn.
We're backed by leading Bay Area funds including Accel and Google's AI Futures Fund, and live with Fortune 500 customers.
This is a full-stack role with the product decisions attached. We call it product engineering because judgement is part of the job: you get a say in what a feature should be, not just how it gets built. If you think we've got something wrong, we'd rather hear it early than find out later.
You will work directly with enterprise customers and the founding team. In one week you might design a workflow for an IT team, trace an agent's bad decision through its context and tools, change the data model underneath it, and ship the fix to production.
The product has to earn trust. Our users watch an agent reason about systems they cannot afford to break and propose changes to them. They need to understand what the agent is doing, why it reached a conclusion, what it is uncertain about, and what will happen if they approve it. The interface, the agent, and the systems behind them are one product.
Own Features End To End. A problem comes to you, usually loosely defined. You work out what it means, decide what to build, build it, ship it, and then watch how it gets used. Ask any of us when you want a second opinion, and the call still stays yours.
Push On The Agent Itself. A lot of what this product does is generated rather than written by hand, and making that dependable is the most interesting work here. You'll benchmark harnesses against each other and go deep on context engineering: what goes into the window and in what order, in-context learning and which examples actually change behaviour, compaction and memory across long runs, tool design, and retrieving things just in time instead of stuffing everything in up front.
Build The Product Around The Agent. Create the screens and workflows enterprise IT teams use while an agent is working. That includes streaming output, partial results, interruption, reconnection, out-of-order state, approvals, failure states, and the explanation a user needs before trusting a proposed change.
Prove It With Evidence. Instrument what you ship and read what happened. Build the evaluation harness or the dashboard that turns "I think this got better" into something anyone can check. It's also much easier to argue for a direction when you have the numbers.
Stay Close To The Customer. There is no product manager sitting between you and the people using this. When you want to understand why something is not landing, you can get on a call and find out.
Product Judgement