Internal AI & Forward Deployed Engineering

AI has changed the way we write code. But it has yet to fundamentally change the way we deliver software. We're still operating under a model that was designed for multi-week implementations where engineers simply needed enough stability to work without requirements changing underneath them.

The real bottleneck is feedback

I've spent roughly the same number of years as a founder and PM as I have an engineer. The uncomfortable truth is that product and leadership teams rarely know exactly what to build upfront, especially with the breakneck speed of AI advancements. In the modern landscape, requirements can be like a house of cards passed through a game of telephone on a high speed train.

The stakeholder often can't know exactly what they want before seeing it. The exec may be borrowing a playbook from a name-brand company. The PM role is often evaluated based on delivery instead of outcome. There are hundreds of reasons why the first thing you build could fail, frustrate users, or simply exist without getting all that much traction. Products only get good when you create a feedback loop and make adjustments based on real usage.

But now that we can write and empirically validate code at multiple times the speed we have the opportunity to do something that used to be out of our reach: we can check in with users and adapt to their needs in super fast iteration cycles. Additional properties needed? Parallelism required due to unexpected volume? We can get those changes into production in less than 24 hrs.

Let's stop pretending that we have perfect information. If we really want to call ourselves agile, let's adopt the OODA loop (Observe, Orient, Decide, Act) and optimize for feedback and autonomy, not the illusion of 20/20 vision on day 1.

The Capability and Instructions Loop

There are implications for B2C, B2B, and the unique dynamics of every business. For internal AI, I've developed a model that takes into account these changes, but also notions of flexibility, abstraction and separation of concerns. I call this approach to internal AI transformation the Capability and Instructions Loop. Use it to automate time-intensive tasks, unlock more revenue with a larger funnel, and move people toward higher-value work. Any digital work can be automated with this method, and all it takes is an AI workspace like Claude or ChatGPT plus an engineer to own the capabilities layer. In many companies, that person is an FDE. Here's how it works:

1. Build the capabilities layer

Many MCPs already exist and can just be connected without any dev work. The way to think about it is that these are generic tools/functions that pull in context or take action. They are not tied to any specific workflow. Once you have a secure framework they can be vibe-coded and validated quickly. This is the capabilities layer.

2. Ask for the outcome

Yes it's that simple. Let's not overcomplicate things for people who have spent a career becoming an expert in their specific field. They don't need to be AI experts. They just need to tell the agent what they need. This is the start of the instructions loop.

3. Guide the agent

Don't write the perfect prompt, just give feedback to the agent until it gets you exactly the output you need, whether that's a document, a ticket, or any other digital output.

4. Turn the workflow into a skill

Literally just ask. The agent did the thing. It has everything it needs in context: the inputs, the required MCPs, the potential pitfalls, the format, the judgement calls. The agent has the full working context at this point and is in the best position to write the repeatable instructions.

5. Test and refine the skill

This is the QA portion. Ask for what you want again in a fresh chat. Your agent will invoke the skill you built and get to your desired outcome significantly faster and with fewer side-quests now. You can expect around 90% accuracy on this first test; keep nudging and asking for edits to the skill until you have full confidence the agent is going to do exactly what you want. It may take 5 or 6 passes to break 99% reliability if the skill is complex.

6. Move the skill to the cloud

At this point you no longer need to even ask. Your skill performs locally and now it's time to remove yourself from the equation. Instead of "Make that weekly report that I need", it's "Run my weekly report skill every Friday at 9am". You'll need one generic cloud agent that supports skills and machine authenticated tools for this. Claude tag is one option.

7. Compile the stable parts into code

Your skill runs reliably without you in the cloud now. But every time it runs, the agent has to relearn the same things it learned the last run. It has to reason about its tool responses, operate linearly, and torch tokens in the process. Chances are, only 10% of your skill actually requires intelligence, much of it can just be rote, deterministic code. This step is optional, though. Wait until a skill is stable in production and you have a clear reason to optimize its speed, cost, or reliability, then compile the parts that don't need intelligence.

Why the loop works

I've seen this process work at multiple companies. The unlock is that once capabilities are covered, stakeholders can do the iteration themselves. The process itself clarifies what it is that they wanted in the first place. There are no change requests, no tickets, no SLAs. Just "can you reference our SOP doc for that part?", or "send a slack to the CX channel after this step" from the person who actually knows what work needs to be automated.

Sure, there will be times where the capability layer doesn't have what the subject matter expert needs. There are also governance decisions to be made. But if your capabilities layer has a tool that can message your engineers, the SME doesn't even need to know what to ask for or how to translate their blocker into requirements. Their agent gives your engineers exactly the right context about what to build, and they can often implement it quickly. Or better yet, set up an automated coding agent to take a first pass as a result of the issue that came in via the MCP.

This can evolve further if you capture all traces. Using an LLM-judge, you can eval every AI interaction and tag sessions by unmet need. At this point, you have full visibility into the latent demand across an entire company. Every department, every person, all telling a text box what they need and figuring out what the blockers are for you. The priorities become clear. The noise begins to fade.

Where FDEs fit

Companies are clamoring to hire Forward Deployed Engineers right now. They're publishing pieces about deploying them internally to sit closely with teams, learn their problems, constraints, and preferences, and create custom agents to automate previously manual processes.

The problem with one-off delivery

That is a meaningful improvement over doing nothing, and good FDEs can create enormous leverage. But the operating model still has a few inherent problems:

Dependency instead of enablement. Not only will teams have to ask each time they need a new solution, they'll have to ask for changes to what you've already delivered. Maintenance will become a burden. When the FDEs have moved onto the next problem, they'll still be pulled back into the previous one.

One-offs instead of platform improvements. The original Palantir FDE model didn't have engineers rebuilding ML from scratch for each deployment; they used the company's platform and IP, making upstream changes that improved the product as a whole with every engagement.

The translation problem remains. You're still requiring SMEs to translate requirements to the person ultimately solving the problem. Yes it's not filtering through a PM anymore but it's still inefficient friction.

Another tool nobody asked for. Do we really want another UI to learn? Or a dropdown of agents to choose from depending on the task? Skills and generic subagents, built into all leading agent harnesses, already solve the context isolation problem that once justified reaching for "an agent per job." Your employees can work through one primary agent.

No exit plan. The first agent came out of the ReAct agent paper: agents are defined by a tool use and reasoning loop. It's a simple and extremely effective way to solve problems in all domains. But it's not cheap or fast or reliable. Don't make the mistake of thinking you're done when you deliver an agent; your most business critical functions should solidify as code once the kinks have been worked out.

FDEs should own the capabilities layer

So let's stop thinking that hiring FDEs is a strategy by itself. FDEs are most valuable when they own the capabilities layer: building it, supporting it, and helping non-technical teams learn the instructions loop. They bring the technical judgment and customer proximity needed to turn messy workflows into durable systems. You're better off setting audacious goals that create the right environment for power users than deploying engineers to solve every problem as a one-off. With every capability an FDE builds, they solve future problems the company hasn't encountered yet.

Build an advantage that compounds

The Capability and Instructions Loop is harder. But it's a real strategy. It's how you invest in your team and your IP instead of creating a permanent consulting dependency. It's how you accrue competitive advantage instead of adopting the same tools at the same pace as everyone else while burning tokens on work that should eventually become deterministic.