Talk to us
Why Moring

Work on AI that a regulator can inspect

Regulated enterprises do not lack AI demos. They lack agents they are allowed to run. That gap is the job: build the agent, then build the evidence that it only did what it was permitted to do.

What the work actually is

Agents that run in a customer’s own cloud

Every engagement ships into the customer’s account, against the systems they already operate. Nothing we build is a demo that stays a demo: the agent either reaches production behind approval gates, or the engagement has not delivered.

The AI control plane

Governance as architecture, not paperwork

The interesting engineering is the boundary: a gateway that scopes each agent key to the models and tools it was granted, policy that decides before the call executes, a stop control that refuses every subsequent call, and a record that reconstructs the run without asking the model what it did.

AI governance

The delivery lifecycle itself is governed

AI-DLC is how the engineering team works: one command routes coding agents through the gateway, policy blocks secrets before they leave the machine, and every pull request of a protected repository gets seven checks that fail closed.

AI-DLC

What you would touch

The stack is deliberately unglamorous. Model access through Amazon Bedrock and Anthropic Claude, agent runtimes over MCP tool servers, policy in OPA and Cedar, an audit lake in the customer’s own storage, and a delivery lifecycle that treats every AI-generated change as a change that needs review. The hard part is never the model call — it is the identity, the boundary and the record around it.

You can see the shape of it before you apply:the control plane,the workflow walkthroughs, andthe writing the team publishes about what holds up in production.

How the team works

01

Bespoke, not boxed

Scoped to the customer’s stack, data and regulators, composed on top of what they already run.

02

Governed underneath

Policy enforced at the substrate — hooks, scoped MCP, signed plugins, an audit lake — not optimism.

03

Outcome-priced

Baseline first, verify second, bill third. If the outcome does not ship, the fee does not trigger.

04

Knowledge transferred

Source, runbooks, evals and decision logs are the customer’s at handoff. No lock-in unless they choose support.

Open roles

Questions

What is a forward-deployed engineer at Moring?

A forward-deployed engineer works inside the customer’s environment rather than behind a product boundary: scoping the workflow with the business owner, building the agent against the systems of record, putting identity, policy and approval gates around it, and staying until it is running in production and the customer’s own team can operate it.

Do I need a governance or compliance background to work here?

No. The engineering roles need strong cloud-native and LLM application experience; the regulatory context — bank model-risk guidance, insurance model bulletins, the EU AI Act — is learned on the engagement with the customer’s risk team. What does help is an instinct for evidence: wanting to prove what an agent did, not just that it worked.

Where are Moring’s teams based?

Chennai, India and Atlanta, United States. Engineering, marketing and people roles sit in Chennai; forward-deployed engineering and enterprise solutions sit in Atlanta and travel to customer sites. Each open role states its own location.

What does the interview process look like?

A conversation about the work, a technical discussion grounded in something you have actually shipped, and a session with the person you would report to. There is no take-home that takes a weekend, and no stage where you present to an empty room.

Not sure the role fits? Tell us what you have built and what you want to build next.