An open-weights research lab just posted a job that tells you where the money actually is.

Nous Research, the group behind the Hermes models, is hiring a Forward Deployed Engineer. Not a researcher. Not a pretraining lead. A field engineer whose whole job is to walk into a customer’s environment and make an agent work there. That is a strange hire for a lab whose reputation was built on releasing weights to the internet and letting the community do the rest. It is also the clearest signal I have seen this quarter about where enterprise AI value has actually moved.

What the job posting actually says

The tell is in the responsibilities, not the title. The role is to deploy something called Hermes Agent Enterprise across cloud, on-prem, and hybrid environments. To integrate it with internal APIs, authentication systems, and data stores. To debug production issues that span infrastructure, orchestration, and the model layer at once. To sit with a customer, scope the problem, ship a solution, and feed what breaks back to the product team.

Notice what is not on that list. Nobody is being asked to make the model smarter. The intelligence is assumed. The entire job is getting that intelligence to survive contact with a real company’s stack. Nous now has a productized SKU, Hermes Agent Enterprise, and it is staffing people whose job is to install it. A lab that trains models in the open, runs a decentralized training network called Psyche, and raised a $50M Series A led by Paradigm is now doing white-glove enterprise delivery. When the most anti-enterprise shop in the space starts hiring the most enterprise role in the space, the pattern is worth naming.

The role has a name, and it came from Palantir

The Forward Deployed Engineer is not a new invention. Palantir built the model in the mid-2000s for customers whose problems could not be specified in advance. The idea was blunt: stop trying to gather requirements in a conference room, and instead embed an engineer next to the analyst doing the actual work. Build bespoke tooling in the customer’s environment. Then pull the recurring logic upstream into product over time. The Pragmatic Engineer breakdown notes Palantir internally called these people Deltas, and for years ran more of them than traditional software engineers.

The reason this matters now is that the whole industry has adopted the pattern in the span of about eighteen months. Anthropic hires Forward Deployed Engineers for its Applied AI team to embed with strategic customers and give white-glove deployment support. OpenAI runs the same motion across several cities. AWS is reportedly standing up a billion-dollar Forward Deployed Engineering unit. Google is in the same race. One industry analysis calls it one of the fastest-growing roles in AI, with postings up several hundred percent through 2025.

When every serious lab converges on the same hire at the same time, it is not a coincidence. It is a confession.

The confession: capability commoditized, integration did not

Here is what the labs are quietly admitting. The model is no longer the scarce thing. Frontier capability is converging, open weights are catching up, and the gap between the best model and the second-best model narrows every quarter while the price of both falls. If your differentiation was raw benchmark score, you watched your moat evaporate in real time.

What did not commoditize is the last mile. Getting an agent to authenticate against a company’s identity provider, read from the systems that actually hold the data, respect the controls the business runs on, and keep working when any of those change, that is still brutally hard, still bespoke, and still where the value concentrates. So the margin moved. It moved from the model to the deployment, from the artifact to the installation, from a thing you download to a person you fly in.

I have argued a version of this before. In You’re Renting the Model. Own the Harness. the point was that the model is the rental and the harness around it is the asset. The Forward Deployed Engineer is the same truth seen from the vendor side. The vendor cannot sell you the harness as a product, because the harness is your environment. So the vendor sells you a person to build it. The FDE is the harness, walking in the door with a badge.

This is also why the vendor pitch and the vendor reality keep diverging. I wrote in Agent as a Service Is Real. The Vendor Pitch Isn’t. that the keynote sells a turnkey agent and the invoice buys an integration project. The FDE hiring wave is the proof. If the agent were actually turnkey, you would not need to embed an engineer for months to stand it up.

Why finance is the first place this lands hard

Forward deployment is expensive, so it only works where three conditions hold at once. The problems have to be complicated and idiosyncratic enough that no off-the-shelf product fits. The stakes have to be high enough to justify the cost. And the customer has to have the budget to pay for embedded humans. Financial services checks all three harder than almost any other industry, which is exactly why it is becoming the proving ground.

The clearest current example is not hypothetical. FIS and Anthropic are building a financial-crimes AI agent for banks, with Anthropic’s applied and forward-deployed teams embedded alongside FIS to co-design it, and named early deployers including BMO and Amalgamated Bank. A CIO analysis of that arrangement is worth reading closely, because it exposes the mechanics. The agent gets built in the customer’s environment by embedded engineers. The FDE cost is real. And there is a twist specific to finance: a core-banking platform like FIS can absorb the forward-deployment cost once, then resell the resulting agent across its entire base of banks.

Sit with that channel for a second. It means many banks will not get an FDE-built agent by contracting a lab directly. They will get it through the core vendor they already depend on, bundled into a platform they already can’t easily leave. That improves the economics and deepens the lock-in at the same time.

The trap: the capability cliff after the engineer leaves

Every forward-deployed engagement has the same failure mode, and it is not the agent breaking. It is the agent working, beautifully, right up until the engineer rolls off.

The CIO piece has the line that should be pinned above every procurement meeting: the result is often a dependency with better stationery. The agent runs while the FDEs are on-site. Then they leave, and the bank discovers it cannot independently operate, modify, or reason about the workflow that is now load-bearing in production. The same analysis cites a Gartner prediction that a large majority of enterprises will be forced to abandon agentic solutions from these FDE-led engagements, on cost and on the internal skills gap. Treat that specific number as the article’s claim rather than gospel, but the mechanism behind it is real and easy to reproduce anywhere.

For a bank, the cliff is not just operational. It is regulatory. Under SR 11-7, the supervisory guidance on model risk management, the bank, not the vendor, owns validation, monitoring, and governance of every model it uses, including third-party ones. An opaque vendor agent is hard to validate because you cannot see inside it. And a fast-iterating deployed agent creates a version-drift problem the guidance was never shaped to hold: if the vendor ships a new model version while you validated the old one, you either pause a production workload pending re-validation or you accept uncontrolled change in a system an examiner will ask you to account for. I traced the deeper version of that mismatch in From Paperclip to Production, which is also where I first wrote about Hermes as an enterprise option worth weighing.

The FDE gets you to working. Working is not the same as owned, and in a regulated shop, owned is the only state that survives an exam.

The decision the FDE forces: self-host or managed

The Nous hire is interesting precisely because it puts a second option on the table that the closed labs cannot offer. There are now two shapes of forward-deployed AI, and a bank has to choose deliberately rather than drift into one.

Self-hosted open weights. This is the Nous and Hermes shape, and the FDE posting names it directly by covering on-prem and hybrid deployment. You run the weights inside your own boundary. You get data residency by construction, because the data never leaves. You can pin a model version and control exactly when it changes, which is the single hardest thing to get from a managed vendor. The cost is operational: you own the serving infrastructure, the scaling, the security patching, and the deep expertise to keep an open-weights agent healthy. The model-risk story is stronger; the day-two burden is heavier.

Managed API. This is the Anthropic and OpenAI shape. You get to production faster, you inherit the vendor’s reliability engineering, and you never touch a GPU. You pay for it in opacity and in version drift you do not fully control, and in the uncomfortable fact that your most sensitive workflows now depend on an endpoint you do not run. For a smaller institution without a platform team, this is often the correct trade. For a large bank with strict data-residency and model-risk constraints, it is a set of concessions that need to be made on purpose.

The wrong way to choose is by benchmark score, which is the one axis that no longer differentiates anything. The right way is to start from your constraints. Where does the data have to live. How much version control does the model-risk framework demand. Do you have, or can you build, the internal team to own an open-weights deployment. Answer those first, and the model selection falls out at the end instead of driving the decision from the front.

What a bank engineering team should actually do

If you run engineering inside a bank, the FDE wave changes how you buy, not just what you buy. Treat an embedded-engineer engagement as staff augmentation with a knowledge-transfer obligation, never as turnkey delivery. Concretely, before an FDE ever badges in, get these into the contract and the plan:

A model-version re-validation gate. No vendor model version reaches production without passing your validation, and the contract names who re-validates and how fast when the vendor ships an update. This is the control that keeps SR 11-7 satisfiable against a moving target.

Runbooks and documented deployment patterns as a deliverable. The engagement is not done when the agent works. It is done when your team can rebuild and operate it from documentation the FDE leaves behind. Make the runbook a line item, not a courtesy.

A knowledge-transfer clause with named internal owners. Every workflow the FDE builds gets a named engineer on your side who shadows it and can maintain it. If you cannot staff the shadow, you cannot afford the agent, because you are buying a cliff.

A kill switch and an exit path. You need to be able to turn the agent off without turning the business off, and you need a defined route to operate without the vendor. Design the exit before you sign the entry.

An audit trail that satisfies an examiner, not just an engineer. Every consequential action the agent takes needs a durable, reconstructable record. The vendor’s demo will show you a dashboard. Ask what it emits when the regulator asks what happened on a specific transaction at a specific time.

None of this is anti-vendor. Forward deployment can be the fastest way to get real value into a hard environment. It is anti-dependency. The engineer is a bridge, and a bridge is only useful if you can still cross the river after it is gone.

Signals worth watching

Strip the narrative away and here is the short list I would pin to the wall if I ran an engineering org inside a bank. Each one is a read you can act on this quarter.

Value has moved from the model to the deployment. Stop ranking vendors by benchmark score, which is the axis that stopped differentiating anything. Weight deployment and integration capability heavily, because that is the part that is still scarce and still expensive.

Open weights is now a go-to-market, not just a research posture. Nous productizing an enterprise SKU means self-hosting is a real commercial option with a vendor behind it, not a science project. For data residency and version control, that changes the choice set in your favor.

Forward deployment is becoming the default enterprise sales motion. Palantir, then OpenAI, Anthropic, AWS, and now an open-weights lab. Expect every serious vendor to push for on-site embedding. Budget for it, and negotiate it as staff augmentation with knowledge transfer, not as delivery.

The capability cliff is the central risk, not model quality. The documented failure is the agent working until the engineer leaves. If your evaluation of a vendor spends more time on model accuracy than on what happens after roll-off, you are measuring the wrong risk.

Model-risk governance is the gating function. SR 11-7 makes you, not the vendor, accountable for validating and monitoring third-party models, including a fast-iterating deployed agent. Whichever engagement cannot produce version control and an audit trail is disqualified before the demo starts.

Watch the core-vendor channel. The FIS and Anthropic pattern, where a platform absorbs the forward-deployment cost and resells the agent across its bank base, is likely to be the dominant distribution path in finance. Decide deliberately whether receiving an FDE-built agent through a core vendor you already can’t leave improves your position or quietly worsens it.

What I don’t have figured out

I am not neutral on this, so here is the other side honestly. Self-hosting open weights is not free freedom. It trades vendor dependency for an operational burden that a lot of banks are not staffed to carry, and a badly run self-hosted agent is worse than a well-run managed one. The enterprise maturity of open-weights agents is also unproven at the scale a large bank needs, and Nous productizing a SKU is a start, not a track record. Several of the market figures floating around this trend, the exact valuations, the precise posting-growth percentages, the specific abandonment rates, are softer than they are quoted, and I have tried to flag them as claims rather than facts throughout. The honest position is that the direction is clear and the magnitudes are noisy.

What is not noisy is the signal in the hire. When an open-weights research lab, of all the players, decides its next critical hire is the person who installs the thing rather than the person who trains it, the argument about whether the model is the product is over. It is not. The deployment is. The banks that internalize that early will treat every AI vendor engagement as a build-vs-own decision with an exit plan attached. The ones that don’t will find out what the cliff feels like on their own production floor, at the worst possible time, with an examiner asking why.

---

The model was always going to commoditize. The install never will, which is exactly why the vendor is flying in a person instead of shipping you a product. Own that person’s work before they leave, or you bought a countdown. For the other half of this argument, read You’re Renting the Model. Own the Harness.

I write about AI-assisted development, enterprise architecture, and the widening gap between what AI vendors sell and what regulated institutions can actually run. Find me on X @orestesgarcia or LinkedIn /in/setsero.