Part 4 of the FDE skills series. The first three parts covered product thinking, business metrics and people skills. This part covers the hard-stack skill at the center of Aater Suleman’s definition of the role: bridging the gap between what a platform provides and what a customer needs, and doing it fast enough to show a working prototype on the first call.
1. The gap is mostly integration
In his Dallas talk, Aater defined forward deployed engineering simply: a big vendor provides the core technology, a customer needs something, and there’s a gap in between that somebody has to fill. In practice, most of that gap isn’t the model. It’s everything around it:
- Data spread across systems that were never designed to talk to each other
- Identity, permissions and network rules that block access for good reasons
- Legacy platforms with decades of customization
- Workflows that live in email, spreadsheets and people’s heads
Aater gave a vivid example: before an AI project could touch one company’s SAP environment, it took two weeks of discovery just to map the custom objects. He also described his own lesson from being acquired: moving a large company from one chat tool to another sounded simple until they discovered how many features and integrations the larger company relied on. Enterprise complexity is the reason FDEs exist. As he put it, you can’t write a piece of software that walks into a 135-year-old company and finds its own way around.
2. Choosing a deployment shape
Before writing any integration code, decide how the AI will live in the customer’s world. Aater described three shapes, and each one implies very different integration work.
| Shape | What it looks like | Integration work | Example from the talk |
|---|---|---|---|
| AI employee | An AI persona with an email, chat account and desktop, trained like a new hire | Accounts, remote desktop, onboarding materials; few APIs | AI “contractors” for HVAC businesses |
| Embedded agents | Agents built around the customer’s own systems on a licensed platform | APIs, connectors, data pipelines, identity, monitoring | The classic FDE engagement |
| AI-native service | Work goes in, results come back; the AI stays outside the company | File exchange, secure portals, output formats | Legal and accounting services |
The lesson from the HVAC example is worth remembering: the company stopped asking small business owners for API keys, because that’s where conversations stalled. They asked for what any contractor would get. Choose the shape that creates the least friction for this customer, not the one that’s most elegant for you.
3. Integration patterns, from least to most invasive
A useful habit is to rank integration options by how much trust they require, and start at the bottom. This mirrors Aater’s “earn the right to write.”
Some practical rules for each step:
- File exports are the fastest way to start. Ask for a de-identified sample of real records on day one. It unblocks prototyping while access requests work through the system.
- Read-only connectors should use a dedicated, narrowly scoped service account, never a person’s credentials. Log every call.
- Events and webhooks let the AI react to real work as it happens (a new claim, a new ticket) without changing anything.
- Human-approved writes are the workhorse of most enterprise AI: the AI prepares the update, a person reviews and commits it. Design the approval to fit inside the tool people already use.
- Autonomous writes come last, only for tasks with a proven track record, with monitoring, limits and a way to undo.
Standard protocols for connecting AI to tools, such as the Model Context Protocol (MCP), make many of these connections faster to build. They don’t change the ladder. A connector that can write is still a write.
4. Messy data: what to expect and how to handle it
Aater named data quality as one of the main reasons AI pilots fail: train or ground a system on poor data and you get poor results. Every FDE engagement starts with a data reality check. These are the problems I meet most often, and how to handle each:
| Problem | What it looks like | What to do |
|---|---|---|
| Same thing, many names | A customer, part or patient appears differently across systems | Build a simple matching layer; ask the business which system wins |
| Missing context | The key fact lives in free text, email or someone’s memory | Interview for it; extract it with an LLM, then validate a sample |
| Stale or inconsistent data | Fields updated in one system but not another | Find the system of record for each field; timestamp everything |
| Undocumented meaning | Codes, flags and status values nobody can explain | Build a data dictionary with the people who use the data |
| Bias and gaps | Some groups, sites or time periods barely represented | Measure coverage before modeling; report it to stakeholders |
| Access lag | Permissions take weeks | Prototype on samples or synthetic data in the meantime |
Two habits make a big difference:
- Profile before you promise. Spend the first days measuring completeness, consistency and volume of the data you’ll depend on. Share the results with the client. It sets realistic expectations and often reveals the real project.
- Keep a data dictionary from day one. One shared page explaining every field, code and source. It becomes the most-used document in the engagement and a gift you leave behind.
5. Prototyping in hours
Asked how long a prototype should take, Aater said that in 2026 he wouldn’t measure it in days at all, especially with newer models like Opus 5.5. His guidance: hours, maybe days, but definitely not weeks. And if it’s taking weeks, the problem isn’t your tools. You’ve taken too big a bite.
Here’s a realistic same-day workflow:
Hour 0–1: frame it. Write one sentence: who uses it, for which task, and which number should move. If you can’t write it, go back to discovery.
Hour 1–2: get data. Use the de-identified sample, or generate synthetic data that mirrors the real structure. As Aater said in answer to an audience question, you don’t need the customer’s data for the first prototype.
Hours 2–5: build three options. Use AI coding tools (Aater mentioned Claude Code and hosting tools like Netlify) to build genuinely different approaches: maybe a chat assistant, a dashboard and an inbox-style triage queue. Focus on the user flow, not the infrastructure.
Hour 5–6: walk the path. Click through every step as the user would. It doesn’t need to be debugged “to the nth degree,” in Aater’s words, but the flow must make sense.
What a good prototype has, and doesn’t have:
| Include | Skip for now |
|---|---|
| The real user flow, end to end | Authentication, scaling, edge-case handling |
| Realistic data (sample or synthetic) | Production infrastructure |
| The output in the format users actually need | Perfect accuracy |
| A visible note of what’s simulated | Anything that writes to real systems |
6. From prototype to production: the honest gap
Aater’s framing was clear: you build the application, but you don’t take the prototype to production. Many projects die in the space between a demo that wowed everyone and a system that works every day. Being honest about that gap is part of the job. Before calling anything production-ready, check:
- Integration: real connectors, service accounts, error handling, retries
- Data: pipelines that refresh, with monitoring for missing or late data
- Evaluation: a golden test set and agreed quality thresholds (Part 5 covers this)
- Security and compliance: access reviews, logging, data handling approval (Part 6)
- Operations: who gets alerted when it breaks, and how to roll back
- Adoption: embedded in the users’ tools, with a feedback loop
Tell the client which of these are done and which aren’t, every time you demo. It keeps expectations honest and builds the trust you’ll need for the next step.
7. How to build these skills
- Practice integration on real systems. Build a small project that pulls from two different sources (an API and a spreadsheet, say) and reconciles them. The reconciliation is the real lesson.
- Get comfortable with one enterprise platform. Salesforce, SAP, ServiceNow, Epic or Microsoft 365. Knowing how one of them models data and permissions makes the others easier to learn.
- Time yourself. Pick a real problem and build three prototype options in a single day. Do it monthly. Speed comes from repetition.
- Learn to generate good synthetic data. It unblocks you whenever access is slow, and it’s essential in regulated industries.
- Write the data dictionary, even on personal projects. It trains you to ask “what does this field really mean?”
Let’s talk
What’s the messiest integration you’ve had to make work? And how fast can you really go from conversation to prototype today? Tell me on LinkedIn or at mohcine@evaltrust.cloud.
The FDE skills series
- Think like a product manager
- From business KPI to F1 score
- The people stack
- Integration and rapid prototyping (this article)
- Evaluation, guardrails and observability
- Security, privacy and compliance
- Domain expertise and scoping
- Communication and ownership
Sources and notes
- Aater Suleman, talk on forward deployed engineering, Dallas, November 5, 2026: the definition of the gap, the three deployment shapes, the HVAC and SAP examples, prototyping in hours, synthetic data, and not taking prototypes straight to production.
- The data problems table and the same-day timeline reflect the author’s experience and are illustrative.