Everyone Has the Models. Almost Nobody Has the Results.

The companies building frontier AI models are hiring engineers to work inside their customers' businesses. Anthropic describes its forward-deployed engineers as members of an applied AI team who embed with customers. OpenAI's Frontier Alliances announcement puts its own forward-deployed engineering team alongside firms doing enterprise transformation. Even the companies developing the technology are investing in people who can help an enterprise decide where to use it and get it working in that environment.

I spent my career working across those technical and organizational responsibilities. I wrote code, ran networks and handled security before eventually serving as CIO of a large regulated enterprise. I was part of the executive team making AI decisions while also being involved in deploying the technology. That experience shapes how I think about implementation at LockedIn Labs: a technical capability becomes valuable when people can use it to improve work they are responsible for, and getting there requires understanding their business as well as their systems.

Andrej Karpathy describes some of the engineering involved in his conversation with Dwarkesh Patel, where he discusses the “march of nines.” A demonstration can be impressive well before a product is dependable, and improving reliability takes repeated investigation and refinement. In an enterprise, that work includes finding out how the application behaves with the existing platforms and what happens when a case falls outside the demonstration. The people who will operate it need to be involved because they understand consequences that may be difficult to see from the code.

When implementation gets faster

Enterprise planning practices developed around work that took considerable time and competed for limited engineering capacity. Teams needed to estimate effort, prioritize competing requests and justify the people assigned to a project. Those decisions still matter, but agentic coding can change how much implementation a team can attempt and how quickly it can put a working version in front of someone. When those tools change the work, we should also revisit how the company makes decisions about it.

For example, a team may produce a useful prototype while responsibility for the workflow is still being discussed. It may be ready to test against realistic data before anyone has agreed who can grant access. Changing the coding tools has little effect on either situation. The company needs to identify the decisions that are holding up a particular implementation and bring the people responsible into the work early enough to resolve them.

That does not mean treating every review as unnecessary. A security review can establish the access conditions an engineer needs to build correctly. An operating team can explain why a seemingly small change affects a responsibility elsewhere in the business. The question is whether those conversations result in decisions the team can act on. In Faster at the Wrong Thing, I look more closely at how an AI-enabled development process changes planning and review, including the judgment involved in deciding which work is worth doing.

Understanding the workflow well enough to change it

At LockedIn Labs, we use forward-deployed engineer to mean a senior engineer who works in the client's operating environment with its team and remains accountable for a defined outcome through production and transfer. Technical depth is essential to that role because the engineer has to work with the systems the client actually runs. Just as important is the ability to understand why the work is being done and what an improvement would mean to the people responsible for it.

Consider a fictional invoice-review workflow. A demonstration might extract the expected fields from a set of clean invoices. In normal use, the same invoice could arrive twice, or a supplier could request payment after changing its bank details. Those cases raise questions about whether a payment should proceed and who has authority to decide. An operator may already handle them using information held in another system or knowledge that has never been written into a requirement. Extracting the fields correctly would address only part of that person's work.

The engineer needs time with that operator to follow actual cases and understand the handoffs. As they work through exceptions together, they can make the rules explicit and agree on what the implementation should do when it cannot reach a dependable answer. A bounded first version then gives them something they can examine in detail. Its value can be judged against the original problem, including any extra checking or reconciliation it creates for the operating team.

This is also how a business can avoid spending its opportunity on the wrong target. A technically interesting application may have little effect on the work that consumes people's time. Understanding the operation well enough to choose a useful problem is part of the engineering responsibility, especially when building another prototype has become relatively easy.

Keeping the people affected involved

People can agree that AI matters while having different views about what should change in their organization. Someone who has spent years working with the tools may be comfortable trying an approach that another stakeholder has good reasons to question. That stakeholder may have responsibility for the service affected, or experience with an earlier change that created work nobody anticipated. Those concerns need to be understood well enough to influence the implementation.

When a smaller team moves quickly, the timing of that participation becomes important. A stakeholder may discover that a decision has already been made before the meeting where they expected to discuss it. The team then has to revisit work that could have been shaped earlier. Shorter development cycles make it more useful to agree which decisions need that person's involvement and when the team will need an answer.

For the invoice example, the people responsible for payments should help decide how changes to supplier details are handled before the implementation is allowed to act on them. They need to see the relevant cases and the proposed behavior, with enough time to question the assumptions. Keeping that review close to the work gives people a practical way to influence it and lets engineers address concerns while changes are still easier to make.

Deciding what an agent is allowed to do

An agentic workflow also needs clear decisions about access and responsibility. Before an agent acts, the implementation needs to establish which identity it uses, what that identity is permitted to do and how requests outside that authority are handled. Reading an invoice and changing a payment destination carry different responsibilities. The permission model and approval process need to reflect the actual action, including the information available when somebody authorizes it.

The same reasoning applies when agents help develop the software. Having another model examine a proposed change can be useful for finding assumptions worth questioning. The release owner still needs evidence from checks appropriate to the change, such as tests that exercise the affected behavior and a review of the permissions involved. If several agents contribute, responsibility for accepting and merging their work has to remain clear enough that somebody can explain why the release was approved.

A useful operational record makes that explanation possible. It connects the action to its inputs and software version, identifies the permission under which it ran, and retains the relevant checks and approval. The team also needs to verify that consequential events are being captured. Alongside that record, least-privilege access and authorization checks limit the actions an agent can take, while controls for untrusted content and tool use address how a misleading request could reach it.

I want separation of duties to be understandable in those terms when an agent has written the code. The person accepting the release should be able to examine the evidence and know which responsibilities remain theirs. Our agentic workflow production contract provides a practical way to work through those decisions with a team.

Making the change usable after the engagement

AI transformation and platform modernization may support each other, but they involve different decisions. A useful AI workflow may be able to work with the existing platform. When modernization is justified, the old system contains business rules and accumulated operating knowledge that deserve careful examination. The new design should preserve the behaviors the business still depends on while giving the team a considered opportunity to improve how they are implemented.

That work also affects the handover. The operating team needs to understand why the implementation behaves as it does and how to recognize a problem that requires intervention. A recovery procedure is more useful when the people expected to use it have practiced it. The same is true of the reasoning behind a design decision: documenting the tradeoff helps the next engineer decide whether it still holds when the requirements or available models change.

This is part of what I want to understand when an engineer shows me a portfolio. I want to hear about the problem they worked on, their own contribution and how the result was checked. Someone whose enterprise work is confidential can describe the parts they have permission to discuss. A beginner can explain a practice project and what they learned from having somebody else use or review it. That discussion gives the work enough context for another person to judge it fairly.

Show Me Your Portfolio develops that argument for people learning the work. The Field Is the Interview examines how to assess it. Both connect to the same responsibility in delivery: being able to explain what happened and provide evidence that is appropriate to the claim being made.

We built LockedIn Labs around AI consulting and implementation that involves this kind of work inside the enterprise. For a company deciding where to begin, I would start with a workflow that matters to its operation and involve the people who can authorize and use the change. Agree on what improvement they need to see, then use the implementation to find out whether it can deliver that improvement under the conditions they actually work in. The result should be something the organization understands well enough to operate and develop further.

About the author

Sam M. Sweilem is CEO of LockedIn Labs. Read his company-site articles on AI implementation, transformation, and agentic engineering.

Read or download the plain-text article