Data Access and Integration

What this phase is for, and how it fails

The scope from Scoping and the First Win names a workflow, a number and a date. None of it can be built until the agent can see what the people in that workflow see, in a form it can use. That is this phase: getting read access to the right systems, turning their contents into something a model can reason over, and deciding what, if anything, the agent may change in them.

The people who do this work say it is most of the work. Colin Jarvis, who runs forward deployed engineering at OpenAI, says "almost like majority of our time in [FDE] getting things to production" goes into "creating the translation layer between the data, like the raw data, and then uh kind of injecting the business logic" (Altimeter interview, November 2025; T4, a vendor describing its own practice). Nabeel Qureshi, who joined Palantir as an FDE in 2015 and left in 2023, calls the same job "data integration, a term that puts most people to sleep". Its first step is "gaining access to enterprise data, which usually means negotiating with 'data owners' in an organization" (Qureshi, October 2024; T4, one former employee's account).

Be clear about how thin that is. Nobody has measured how FDE hours split between integration and modelling. Jarvis's "almost" majority is a self-report, and Qureshi's account is one person's memory. Independent evidence points the same way, measuring something else. RAND interviewed 65 practitioners (RAND, 2024; T1 as a study, though it rests on interviews and predates most teams' use of large language models). Its second root cause of failure is that "the organization lacks the necessary data to adequately train an effective AI model". Its fourth is that organisations "might not have adequate infrastructure to manage their data and deploy completed AI models". Stanford's Digital Economy Lab found that "77% of the hardest challenges were invisible and intangible costs: change management, data quality, and process redesign" (Pereira, Graylin and Brynjolfsson, April 2026; T2, a draft built only from successful deployments). In 59% of the deployments it could assess, data was "scattered across multiple systems owned by different teams". The next sentence is the one to remember: "Yet success did not require centralization. It required access."

This phase fails in three ways, and each costs more the later it is found.

Waiting. The team asks for access, gets a ticket number, and builds a demo on invented data while the pilot's clock runs. Qureshi's version is blunt: a customer would buy "an 8-12 week pilot, and we'd spend all 8-12 weeks just getting data access, and the final week scrambling to have something to demo" (T4). By the time access lands there is no time left to learn what the real data does to the prototype.

Writing too early. The customer wants the agent to update the system of record, because that is where the efficiency is. The team agrees before it can read reliably, and the write path drags in approvals, rollback and risk review that the pilot cannot carry.

The orphaned connector. The integration works on handoff day, belongs to nobody at the customer, and stops working the next time a source system changes. The model gets the blame.

The composite: three approvers and a side table

Three choices carry the chapter. The request went in during week one, to named people, asking for the least that would do. The build did not wait for it. The output landed where the customer already looks, without touching the system they cannot afford to break. A fourth, who keeps it working after you leave, comes last.

The access request is a negotiation

An access request is not a ticket. It asks several people to accept a risk for your benefit, so treat it as a negotiation and give each of them what they need to say yes.

Qureshi names both things you are negotiating with (T4). One is politics: the team that controls a source often justifies itself "by being the gatekeepers of that data source". The other is real: "data access tussles were partly about genuine data security concerns", which Palantir answered by building controls into the integration layer itself. Take both seriously. Answer the security concern with controls written into the request. Answer the gatekeeper by giving them a job: the team that guards a source is the natural owner of the connector to it, and a team that will own the connector has a reason to say yes.

Name the approvers before you write the request. Discovery should have given you, for each system, the person who can grant read access. In practice there are usually three: the owner of the system (who worries about load and stability), security (who worries about identity, network path and credentials), and privacy or data protection (who worries about which personal fields move, why, and for how long). Send each of them the same document, and say in it which question is theirs.

Ask for the minimum, in writing. A request for "access to the claims data" gets routed to a committee. A request for read-only access to four named tables and the document store, excluding three named fields, from one service identity, inside the customer's network, for the length of the pilot, gets a decision. List the fields you will not touch as carefully as the ones you will.

Bring security in at the start, not at the end. Alpine Edge's plan for a forward deployed engagement puts it plainly: "Bring security and IAM into discovery; build on sanitised fixtures meanwhile". In week three it adds "Separate read and write permissions; no credentials in code" (Alpine Edge, August 2026; T4, one consultancy's practice). The identity the agent runs under is a design decision, not paperwork. The wiki's page on scoped credentials for agents covers why the agent should never borrow a person's access. If the agent will retrieve documents on behalf of different users, permission-aware retrieval covers why the access rules must be enforced before the search, not filtered after it.

Ask for a smaller thing in parallel. A replica is a big request. A redacted export of a few hundred recent cases is a small one, often within the authority of a single manager, and it is what the first demo and the baseline need anyway. File both on the same day. The export keeps the work honest while the replica moves.

Climb the ladder one rung at a time. Access comes in steps, and each needs a different approval:

1. Synthetic data that you write yourself. It needs nobody's approval and tells you nothing about the customer.
2. Sanitised fixtures: real structure, invented contents.
3. A redacted export of real cases.
4. Read access to a replica or a reporting copy.
5. Read access to live systems.
6. Write access, to a side store first and to the system of record last.

The pilot needs rung four by the end of week one; that was the data term in Before the Engagement. Most pilots never need rung six. Say so in the request; an approver who believes you will stop at rung four approves faster.

Escalate on a date, not a feeling. Write the consequence of a late answer into the request as one sentence the sponsor has already agreed: "If read access has not landed by day 5, the pilot clock pauses and we proceed on the redacted export." When the date passes, you are not asking anyone for anything. You are reporting that a rule fired, and the sponsor chases the approver.

Build on fixtures while you wait

Sanitised fixtures are the difference between a pilot that pauses and a pilot that stops. Build them from what you can already see: the redacted export, the screens you watched during discovery, and the document types the adjusters named. A good fixture set has three properties.

• It has the real shape. The same file types, the same field names, the same nesting, the same identifiers joining one system to another.
• It has the real mess. Missing fields, duplicates, mixed languages, handwriting, the abbreviation every adjuster uses and no document defines. Fake the worst cases the people you shadowed saw last month first.
• It is labelled with what it is. Every fixture is marked synthetic, so that nobody ever measures the threshold on it. Fixtures are for building, never for scoring.

Fixtures hold only the cases you thought of. RAND quotes an interviewee on business leaders: "They think they have great data because they get weekly sales reports, but they don't realize the data they have currently may not meet its new purpose." Legacy data, RAND adds, was often kept "for compliance or logging purposes", while analysis "often requires considerable context about why things happened as opposed to simply what happened" (RAND, T1). A claims system records what happened to a claim. It does not record why an adjuster routed it, which is what the agent needs. Expect the first run on real data to break something the fixtures did not, and plan days, not hours, for it.

Messy data stops fewer projects than it used to. Stanford found that only 6% of the deployments it studied had data "fully ready for AI", yet 91% "successfully processed unstructured data, including voice transcripts, scanned documents, images, chat logs, and legacy code" (Stanford, T2). The authors add the caveat themselves: the sample "likely underrepresents cases where data quality proved insurmountable." Read it as "teams that succeeded designed around the mess", not as a promise. Designing around it means a parsing stage you test as hard as the model; the wiki's deep dive on document parsing and ingestion quality covers layout, tables and OCR.

The translation layer

Access gets you rows and files. It does not get you meaning. Jarvis's warning is about the shortcut most teams take: "people like often just start with MCP and they just stick the MCP connectors". What his team has "had to repeatedly do", he says, is "build almost like a sort of light like logic layer in between the two that the model then uses to make best use" of the data (Altimeter, T4). He calls it a "metadata translation layer", and notes that it is "an old-school concept" made useful again because a model now reads it.

In practice the layer is four things, and the customer's experts write most of them:

• A field map. Which column in which system holds the thing the workflow cares about, and which of three similar-looking columns is the one people actually use.
• A glossary. What "open", "reserved", "assigned" and "litigation" mean in this business, including the regional variants. The composite's status code that meant different things in different regions belongs here.
• The joins. How a document in the store finds its claim in the claims system, and what happens when it cannot.
• The rules the model must not be left to infer. Which claim types always go to a person, which flags override everything else. Chapter 10 enforces some of them in code outside the model.

Without this layer the model must guess the semantics. It will guess plausibly and wrongly, and the errors will look like model errors. Expose the layer through whatever interface you use, including MCP, as named, documented operations rather than raw tables; the wiki's guide to building MCP servers in practice covers how to shape those tools. And write the glossary where the customer can edit it, because they will correct it for as long as the system runs.

Read first, write later

Sooner or later the customer asks the agent to write its answer into the system of record. Their reason is good. The clearest public account comes from the NHS Federated Data Platform. Louis Mosley, an executive vice-president at Palantir, told MPs that writing back to NHS systems "is more challenging than reading from these systems, especially in systems that are very old". He also said that "If ultimately the end step of that process is a manual write back, where someone has to key in a decision into a system, then a lot of the efficiency is lost." Amy Freeman, a trust's chief digital information officer, agreed from the customer side: "If you can't write back into source systems, that can be a productivity challenge" (The Register, July 2025; T3, secondary reporting, and the vendor has an interest in blaming the old systems).

Both halves are true: write-back is harder, and its absence costs efficiency. But a pilot is the wrong place to pay for it. A write into a system of record needs the system owner's approval for a change, not just a read. It needs an identity allowed to change records, a rollback when the agent is wrong, an audit trail the customer's risk function accepts, and an answer to what happens when a malicious document persuades the agent to write something it should not. That last question belongs to the next chapter, Security, Governance and Model Risk. None of them tells you whether the routing is accurate.

The way through is to separate the agent's output from the customer's action:

• Write to a side store the customer owns. A table, a queue or a folder that the customer's team controls, outside the system of record. The agent may write there and nowhere else.
• Surface it where people already work. The existing queue view, the inbox, the case screen. A new tool people have to open is an adoption problem you created.
• Let a person make the change. The human who accepts a suggestion writes it into the system of record through the path they already use, with the audit trail that path already has.
• Log the accept and the override. Every suggestion a person accepts or changes is a label you did not have to pay for, and the evals chapter (Chapter 9) will need them.

Mosley's point stands: a person keying in a decision costs some of the gain. Accept that cost knowingly during the pilot, and put write-back on the "not now" list with a trigger. Write-back is earned when four things are true: the threshold has been met on real data; the owner of the target system has approved a change, not just a read; every write can be traced and reversed; and the people whose work it changes have seen enough suggestions to trust them. Until then the agent proposes and people act.

Integrations decay; give them an owner

A model you deploy is pinned: you chose a version, you tested it, and it changes when somebody decides to change it. The systems it reads from change on the customer's calendar, for the customer's reasons, and nobody tells you. A field is renamed, a region adopts a new status code, the claims system is upgraded. The integration breaks silently, and the agent keeps answering from inputs that no longer mean what they did.

The starkest public case is old, and it is not an FDE engagement, but it shows the mechanism with an audit behind it. MD Anderson's Oncology Expert Advisor, built with IBM Watson, cost "US$62 million" over more than four years. The University of Texas audit found that after the hospital moved its records system to Epic in 2016, "OEA has not been updated to integrate with the current system", and that "The system is not in clinical use and has not been piloted outside of M.D. Anderson" (Network World, March 2017; T3, reporting of an internal audit we have not read in the original). Its governance failures belong to the next chapter. The integration point stands on its own: whatever the model could do, it could no longer read the hospital's records.

RAND's interviewees describe the everyday version. Without infrastructure, nobody monitors "whether a data source changes formats or fails to arrive promptly". Teams that move from prototype to prototype "often find that they are completely blind to failures that arise after the AI model has been completed and deployed." Then the human half: data engineers who leave "take all of their knowledge about the organization's data and infrastructure" with them, and "no one knows which datasets are reliable or how the meaning of a dataset might have shifted over time" (RAND, T1). In a forward deployed engagement, you are the data engineer who leaves.

So build the integration to be handed over, from the first week:

• A contract test on every source. A check, run on a schedule, that the fields, types and codes the translation layer depends on are still there and still mean what they did. When it fails, the agent stops suggesting rather than suggesting from bad inputs.
• A freshness alarm. If documents stop arriving, or arrive late, somebody is told before the adjusters notice an empty queue.
• A named owner at the customer for each connector, agreed now and written on the access request, not discovered at handoff. If nobody will own a connector, treat it like a workflow with no owner: a reason to change the design, not to proceed.
• The glossary and field map in the customer's repository, not yours, so that the next person to change a source system can see what depends on it.

The handoff itself belongs to Chapter 11. The owner does not: it is decided when the access request is written.

The template: the data-access request

One document, sent on day one to every approver, with each approver's question marked. It does three jobs: it asks for the minimum, it says what you will do while you wait, and it names who owns the connector after you leave.

DATA-ACCESS REQUEST                             version / date: ____

1. PURPOSE
   Workflow served:   ______________________________________________
   Metric it serves:  ______________________________________________
   Needed by (date):  ________   If late: ___________________________

2. WHAT WE NEED (the minimum)
   System / store     Objects (tables, folders)    Access    Rung
   ______________     _________________________    read      ____
   ______________     _________________________    read      ____
   Fields excluded:   ______________________________________________
   Personal data:     categories: __________  minimised how: _______

3. HOW WE CONNECT                        [security's questions]
   Environment:       replica / reporting copy / live
   Network path:      ______________________________________________
   Identity:          one service identity, read-only: ____________
   Credentials:       held in: ____________   never in code
   Write access:      NONE in this phase  |  side store only: _____

4. DATA HANDLING                         [privacy's questions]
   Leaves the customer's environment:  yes / no   what: __________
   Residency:         ______________________________________________
   Retention:         ______   Deletion on: pilot end / on request
   Model provider retention / training: __________________________

5. LOAD AND STABILITY                    [system owner's questions]
   Query pattern:     ______________   Peak volume: ______________
   Scheduled runs:    ______________   Kill switch: ______________

6. WHILE ACCESS IS PENDING
   Fallback:          sanitised fixtures / redacted export: _______
   Export owner:      ______________   Size: ______________________
   Fixtures used for scoring: NEVER

7. AFTER THE PILOT
   Connector owner (customer):  ____________________________________
   Contract tests and freshness alarm run by: _____________________
   Glossary and field map kept in: ________________________________

8. APPROVALS                     name              date
   System owner (load, change):  ______________    ______
   Security (identity, path):    ______________    ______
   Privacy / DPO (fields, use):  ______________    ______
   Requested by (vendor):        ______________    ______

Filled from the composite, in ranges; a real request carries exact table names, volumes and dates.

DATA-ACCESS REQUEST: auto FNOL triage           version 1 / week 1

1. PURPOSE
   Workflow served:   auto first-notice-of-loss document triage
   Metric it serves:  routing accuracy; time to first action
   Needed by (date):  day 5   If late: 30-day clock pauses (agreed)

2. WHAT WE NEED (the minimum)
   System / store     Objects (tables, folders)    Access    Rung
   claims system      claim header, status,        read      4
                      assignment, event times
   document store     auto FNOL intake folders     read      4
   Fields excluded:   bank details, medical notes, full DOB
   Personal data:     categories: name, contact, vehicle, policy
                      minimised how: masked in logs and fixtures

3. HOW WE CONNECT                        [security's questions]
   Environment:       read-only replica, refreshed nightly
   Network path:      inside the insurer's network; no egress of
                      raw documents
   Identity:          one service identity, read-only, from the
                      insurer's identity provider
   Credentials:       held in: insurer's secret store; never in code
   Write access:      NONE to claims system; side table only, owned
                      by claims-platform IT

4. DATA HANDLING                         [privacy's questions]
   Leaves the customer's environment:  no raw data; prompts go only
                      to the endpoint model risk approves (Ch 8)
   Residency:         in-region
   Retention:         pilot length   Deletion on: pilot end
   Model provider retention / training: see security answers (Ch 8)

5. LOAD AND STABILITY                    [system owner's questions]
   Query pattern:     batch reads    Peak volume: hundreds to a
                                     few thousand documents a week
   Scheduled runs:    off-peak       Kill switch: revoke identity

6. WHILE ACCESS IS PENDING
   Fallback:          sanitised fixtures + redacted export
   Export owner:      claims operations   Size: a few hundred claims
   Fixtures used for scoring: NEVER

7. AFTER THE PILOT
   Connector owner (customer):  claims-platform IT lead
   Contract tests and freshness alarm run by: claims-platform IT
   Glossary and field map kept in: insurer's repository

8. APPROVALS                     name              date
   System owner (load, change):  claims-system owner   week 3
   Security (identity, path):    IT security           week 3
   Privacy / DPO (fields, use):  data-protection off.  week 3
   Requested by (vendor):        the FDE (lead cc)     week 1

Two lines in the filled version do most of the work. "If late: 30-day clock pauses (agreed)" turns a slipping request into a decision the sponsor already made, instead of an argument in week 4. And section 7 names an owner before anything has been built, which is the only time it is easy to get one. The pointers to Chapter 8 are deliberate: the model-risk review asks the same retention and residency questions, so answer them once.

Failure signals

Each shows up in the first three weeks, while there is still time to act.

Ready to move on

Move into the security review's decision and the eval when every box is ticked:

• Read access to production-like data has landed, or the sponsor has agreed in writing what happens while it has not.
• The pipeline has run end to end on real or redacted cases, not only on fixtures, and no reported number came from fixtures.
• The field map and glossary exist, were checked by the customer's experts, and live where the customer can edit them.
• The agent writes nowhere except a side store the customer owns, and write-back is on the "not now" list with its conditions.
• Every connector has a named owner at the customer, a contract test and a freshness alarm.