Forward Deployed Engineering Keeps Rebuilding the Same Layer

No organization accepts a change to all of its current systems in one day. Not for AI, and not for anything before it. That was true of every ERP migration, every CRM consolidation and every plan to retire a mainframe, and it's true of a model that can genuinely do a piece of the work. The systems already in place carry the daily operations, the data, the access rights and the decisions, and they go on carrying them while anything new is introduced beside them — gradually, with the old path still working, often for years.

So this isn't a problem the AI era invented. It inherited it. What's new is only that the thing arriving beside the existing system is a model rather than another application, and that people keep describing it as a replacement when every organization already knows it will be an addition.

That's the constraint a forward deployed engineer actually works under. An FDE works across software engineering, applied AI, enterprise integration and somebody else's business problem, and the deliverable isn't a demonstration of what a model can do. It's judgment added at a few points inside a process the customer keeps running, in a form their auditor, their security review and their on-call rota can live with.

And the model is rarely what makes that hard.

The layer nobody puts in the design doc

Between "the model can do this" and "the business can rely on this" there's a layer every deployment needs:

• Which step runs next, and who decided — a rule, a model, or a person.
• What context each step can see, and what it must not.
• Where deterministic logic ends and probabilistic judgment begins.
• What happens on a failure, a retry, a timeout, or an approval that takes four days.
• What shape an output has to be in before anything downstream may use it.
• What a second run does to the first run's results.

Each of those is tractable alone. The cost is holding them together so the whole thing is reliable, and that cost lands again at the next customer, whose systems, policies and exceptions are different. So it gets rebuilt — a framework, a scheduler, a queue and a pile of glue, assembled a little differently each time, and described in the design doc as "the orchestration" if it's described at all.

FloMorphic is that layer, made explicit and drawn. The rest of this is where it sits and what it actually does for the job.

Cooperating with what's already running

Because nothing gets replaced, the real work is integration, and it runs in both directions.

Into the model. The customer's systems know things the model needs, and the useful version of that isn't a nightly export pasted into a prompt. It's the relevant slice, pulled at the moment the decision is being made, from the system that is actually the record — because the facts that matter most in a decision are usually the ones that changed this morning.

Out of the model. The answer has to come back in a form an existing system will accept: a row, a ticket, a field, a signed approval. Not a paragraph that someone retypes. That means a schema on the way out, and a write that goes through the same account and the same permissions a person would have used, so the audit trail doesn't suddenly have a robot in it with more authority than the staff.

And with the people already in the process. Most enterprise processes have a point where a human signs, and that step exists for a reason that predates you. Keep it — as a real step the process waits on, not a notification sent after the fact.

In FloMorphic, a legacy system joins the graph as a node, which puts it on equal footing with the model step rather than behind it. Neither one is in charge of the other; the process is. That's what lets a system the customer already runs become AI-native without a rewrite — the existing software keeps doing its job, and the judgment gets added at the points where judgment was the missing piece.

Where it sits

  CUSTOMER & BUSINESS     requirements, rules, acceptance criteria, the auditor
        │
  INTEGRATION & CONTEXT   APIs, databases, repos, document and vector stores
        │
  APPLICATION  ← FloMorphic   the graph: routing, decisions, context scope,
        │                     approvals, schemas, who may do what next
        │
  EXECUTION    ← Inflowenger  durable runs, loops, waits, resumption, plugins
        │
  PRODUCT & OPERATIONS    dashboards, findings, actions, the business outcome

It doesn't remove customer discovery, the integration you'll hand-write for the one system with a SOAP endpoint, the security review or the deployment work. It removes rebuilding the application layer underneath all of that.

Four things it does for the job

The process holds the authority, not the agent. You draw the states, the transitions, the decision points, the context each node can see and the places a person has to sign. The model contributes judgment at a node. A prompt says what the model should do; an edge says what the application will let it do next, and the difference shows up the first time an agent decides, reasonably, to do something the customer's compliance team never agreed to. An agent node's outcomes are ports drawn before the run — it answered, it needs a person, it ran out of budget, it failed — and where each one leads was settled at design time. When the path goes through a human, the run parks and nothing is held open, because resumption is a property of the runtime rather than a feature on a node. FloMorphic runs on the Inflowenger runtime, which supplies that durable cyclic execution and reserves nothing for itself there.

A palette, instead of one agent abstraction. The best solution to a customer's problem is rarely the one that uses AI for everything; it's the one that gives each responsibility to the component that can be held to it. So a flow can use a model to read something unstructured, a Contract node to apply the policy as a rule evaluated outside the model, a bounded decision model where you want a choice rather than free text, a store node for retrieval, a schema to say what an acceptable output is, an agent for the part that genuinely needs to investigate, a person for the part that needs authority, and GoTo to call a child flow and come back. Providers and tools arrive as plugins, so which vendor sits behind a step is a settings change rather than an architectural commitment.

Patterns you install, not snippets you adapt. A reusable foundation has to be more than a repo of examples. A flow package carries a manifest, a version, operator params and declared requirements, and the import tells you what will and won't run against the estate you have before anything executes. Exports carry no credentials by design — accounts and keys are selected per install — so a pattern is safe to publish, and the knobs that adapt it to one organization are substituted at install time and then live on the run's context, where they can be changed without reinstalling. Retrieval and normalization, classification, policy evaluation, RAG, tool orchestration, review and approval, schema validation: those are the patterns worth packaging, and each one packaged is one an FDE doesn't rebuild.

Change without a redeploy window. This is the one that matters most in the field, and it's easy to undersell. The customer exception that arrives on Friday is an edit to a graph, not a release — the logic lives in a dynamic layer rather than compiled into the product, a legacy system joins the graph as a node, and a new capability is installed the way you install a browser extension. The deployed application keeps getting more capable after it ships instead of slowly drifting from what the customer now needs.

The thread through all four is that the control flow is designed before execution and can be read afterwards. For FDE work that's not an aesthetic preference. It's what lets you hand the thing over, explain it to a security reviewer, and change it next quarter without becoming the only person who can.

One deployment, as a division of labour

A security review of a customer's repository is the shape we've actually run, and the useful thing about it is how cleanly the responsibilities separate:

• The GitHub integration supplies the repository, through a connected account, so the flow itself never holds a token.
• FloMorphic owns the sequence, the branching and the application logic.
• A Claude agent node investigates the code, inside the tools and the workspace it was given.
• A schema defines what a finding is, so every step after it reads fields instead of parsing prose.
• Venapce turns those rows into a posture someone can work from, where nothing is promoted automatically — each one waits for a person to decide it's real.

That's a different thing from connecting a model to an API. It's a domain application composed out of parts that each answer for something, and the composition is visible.

Structured output doesn't make a finding true, and I'd rather not pretend otherwise. What the graph gives you is that the controls are steps rather than sentences in a prompt: the severity threshold, the evidence the agent has to return, the human who promotes a row. Those are real, and they're still controls on a process that can be wrong.

Change the domain logic and the schema and the same shape carries a compliance check, an infrastructure assessment, a document pipeline or an operational triage. The way the process is put together doesn't change much.

What I'd still be skeptical about

If you'd be evaluating this for real customer deployments, these are the places to push, and I'd rather say them myself.

Evaluation is the weakest. There's no flow-level test harness — no fixtures, no golden runs, no regression gate for CI, no acceptance threshold the platform enforces. Today you run the flow and read the trace, and for anything consequential that isn't enough. It's the gap I'd close first.

Durable execution is the part I'll defend: loops are backward edges, long waits and resumption are primitives, and a parked human step holds nothing open. Observability is thinner than it should be once you want to tie an outcome back to a flow version plus a model configuration across many runs. And untrusted input reaching a step that holds tools deserves more isolation than we currently give it — a workspace boundary is organisation, not a sandbox, and it's worth knowing which of your boundaries are which.

None of those are side quests. They're the difference between a promising agent builder and something you'd hand a customer, and they're where contributed work — test suites, integrations, domain patterns — would compound fastest.

Enterprise AI is only half a model problem. The other half is building the process that can carry a model into a real organization, alongside the software already running it, in a way you can control and trust — and that half is engineering, not capability.

Venapce is where we're proving the whole shape rather than one flow of it: every piece of its business logic lives in FloMorphic workflows, and the product is only the view. It gets its own write-up.

If you do forward deployed work, the question I'd actually like answered is where you put this layer today. My guess is that you have one, that it's assembled rather than designed, and that it isn't in the architecture diagram.

Try it: inflowenger.com/flomorphic — one command to a running stack:

curl -fsSL https://raw.githubusercontent.com/FloMorphic/getting-started/main/install.sh | bash

Related: Flow Engineering Is an Architecture, Not a Prompting Trick for the discipline, and Glass-Box Agents Are Not Optional for why the path has to stay readable.