Put agents on top of systems of record

The third responsibility of a forward-deployed engineer (FDE) is to deploy the redesigned workflow into the customer's existing enterprise environment. The key idea is simple:

Add the agent above the systems the company already uses. Do not assume that the company will replace those systems first.

In this section, the speaker names NetSuite, Dynamics, SAP, and Salesforce as examples of established enterprise systems. These systems are not just software choices. They are part of how the organization already stores and runs its work.

What is a system of record?

A system of record is an established system that an organization relies on for important operational information and processes. For example, a company may already depend on one system for customer information, another for financial work, or another for enterprise resource planning.

For this lesson, the important point is not which product is best. It is that the customer's real workflow is already connected to these systems. People have built procedures around them, and the organization has invested time and money in keeping them in place.

So an agent has an operational dependency:

Customer's existing process
          |
          v
System of record  <--- the place where the organization already works
          ^
          |
        Agent  <--- assists with the process while fitting that environment

The diagram is a teaching model, not an architecture diagram from the talk. The transcript does not specify the exact APIs, data schema, or control mechanisms used to connect an agent to any named product.

Why migration is a serious constraint

It is easy to imagine a clean solution: build a new AI-native application and move the customer onto it. In a large enterprise, that move can be more difficult than building the agent itself.

The speaker reports that one client said moving away from NetSuite would cost $5 million and take five years. This is a client quote reported in the talk, not a general estimate for every NetSuite migration. It illustrates three constraints:

1. Migration cost: replacing a core system can require a large financial investment.
2. Migration time: the organization may need years to plan, transfer, test, and adopt the replacement.
3. Organizational commitment: many teams already depend on the current system, so changing it affects more than the software team.

These constraints change the deployment question. Instead of asking, “How do we make the customer abandon its current system?” an FDE can ask, “How do we make the new agent useful within the system the customer already has?”

Layering is not replacing

Layering means introducing an agent on top of an existing system and connecting the new behavior to the current operating environment. Replacing means migrating the organization away from that system and making a different product the new foundation.

Approach	What changes first?	Main implication
Replace or migrate	The system that the organization already depends on	The customer takes on a large transformation before receiving the agent's value.
Layer an agent	The way selected work is performed around the existing system	The agent can target a workflow without requiring an immediate core-system migration.

This does not mean that layering is automatically easy. The agent still has to fit the customer's actual processes, permissions, data, and responsibilities. The talk gives no detailed design for those integrations. The point is the deployment strategy: preserve the existing system of record and place the agent where it can help the work that already depends on it.

The role of the platform

The speaker describes a platform, referred to in the talk as Varick OS, for operating these agents. He assigns the platform four high-level responsibilities:

• Agent spin-up: create or start agents for the required work.
• Monitoring: observe agents after they are deployed.
• Governance: provide organizational oversight for how agents are used.
• Evaluations: assess agent behavior or results.

The speaker does not describe the platform's internal architecture, specific governance rules, or evaluation metrics. Therefore, these four items should be understood as claimed platform capabilities, not as a complete implementation specification.

The platform matters because an enterprise deployment is not finished when one agent works in a demonstration. An organization may need several agents, continued observation, rules for their use, and a way to check whether they are performing acceptably. The platform is presented as the layer that helps manage that growing collection.

Why the earlier FDE work still matters

Putting an agent on top of a system of record does not remove the need to understand the business. It makes that understanding more important.

Earlier in the FDE motion, the team maps how people actually work and redesigns the workflow around AI. That work identifies the process steps, handoffs, exceptions, and dependencies that the agent must fit. The existing enterprise system is then the environment in which the redesigned process must operate.

This gives the deployment chain:

Understand the real workflow
        ->
Redesign the workflow around AI
        ->
Deploy an agent over the customer's existing systems
        ->
Monitor, govern, and evaluate the deployed agent

If the first two steps are skipped, an agent can be technically impressive but operationally disconnected. For example, an agent designed without knowledge of a customer's actual ownership and handoffs may produce an action that does not fit the way work is assigned. Connecting to the system of record would not, by itself, reveal or repair every process problem.

A concrete contrast

Imagine that a customer runs an important process through Salesforce. There are two different proposals:

1. Standalone replacement: ask the customer to move the process into a new AI product and leave Salesforce behind.
2. Agent layer: keep Salesforce as the established system and deploy an agent that supports the redesigned process in that environment.

The second proposal matches the constraint emphasized in the talk. It does not promise that every problem disappears. It avoids making core-system migration a prerequisite for trying to improve the workflow.

The same reasoning applies to the other systems named by the speaker, including NetSuite, Dynamics, and SAP. The specific integration would depend on the customer, and the talk does not provide those implementation details.

The broader conclusion

The speaker concludes that enterprise needs AI the most because large organizations are especially difficult to move. This is his conclusion from the deployment challenge, not a quantified market finding.

The chapter's argument is therefore broader than “build an agent that can call an enterprise API.” The agent must be placed inside an organization with existing systems, history, and operating commitments. FDEs supply the customer-specific understanding. The platform supplies a way to deploy and manage agents without requiring the organization to discard its systems of record.

That is how this chapter connects the talk's three FDE responsibilities: first understand the real operation, then redesign it around AI, and finally put the resulting agents where the business already keeps and performs its work.