Field Note: Unexpected Delays During the Integration Phase

This is a field note. That is, a first-person account not from theory but from the least-discussed yet most timeline-slipping phase of enterprise AI projects: integration. The model worked, the demo pleased everyone, the team relaxed. Then someone said "now let us just connect it" and the project got stuck there for months. This article describes the integration-delay experience I have seen in the field behind that "let us just connect it" sentence, and why these delays are not technical but largely organizational.

The purpose of the article is to show integration delays not as an inevitable fate but as a foreseeable and largely preventable pattern. Every delay source has a symptom and a preventive action; I will gather these in a delay source × symptom × preventive action table. I will not give a fabricated case or an imaginary number; everything I describe is a field observation distilled from patterns I have seen again and again.

Definition

Integration delay (in AI projects)

When an AI project's timeline slips at the stage of connecting the solution to surrounding systems (legacy systems, databases, identity services, security layers), even though the model and application side are ready, for unexpected reasons. Most causes are organizational rather than technical: waiting on the other system, the absence of a test environment, data-mapping exceptions, undocumented legacy system APIs, authentication and rate limits, data access permissions and the security review queue.

Also known as: integration-delay experience, waiting on the other system, integration risk, external-dependency delay

I like to compare the progress of an AI project to an iceberg. The part above the water, the part everyone talks about, is the model: accuracy, prompt, architecture. The part below the water, the part that actually sinks the project, is integration. Most of my integration-delay experience in the field comes from here: the heart of the solution is ready, but connecting it to the organization's real systems takes many times longer than expected.

Over the years I summarized the reason like this: the model side is under your control, the integration side is under others' control. You fix your own code however you like; but the legacy system you connect to is in the hands of another team, another vendor or another organization. The essence of an integration-delay experience is hidden in this handoff, in this state of "depending on someone else." Writing code is fast; waiting for someone else to become available is slow.

Seeing this distinction early matters, because the solution comes from here too. You can shorten a technical delay with better engineering; but you can shorten an organizational delay only with coordination, early discovery and realistic planning. I discuss more broadly why AI projects get stuck moving from pilot to production in from PoC to production AI projects and PoC-to-production AI engineering mistakes; this field note focuses on a single piece of that picture, integration.

Let me clarify one point from the start: an integration-delay experience is not a sign of incompetence. Even the best teams experience these delays; the difference is that good teams experience the delay early, small and manageable, while inexperienced teams experience it late, large and in panic. That is the promise of this article: to pull the same delays earlier and shrink them.

When people hear "integration," the first thing that comes to mind is the code connecting two systems. Yet perhaps the most surprising aspect of my integration-delay experience is this: most delays come not from the code but from the human and process layer around the code. The technical work is usually the shortest part; the real time is lost in non-technical sources.

Over the years I could group these non-technical delay sources under a few headings. First, waiting: nothing moves until the owner of the system you connect to becomes available. Second, uncertainty: who is authorized for what, which system holds which data, whom to ask, is not clear. Third, approval: touching a system requires security, legal or management approval, and these approvals wait in a queue. Fourth, coordination: different teams' schedules do not align, everyone is busy with something else.

Their common feature is that none of them can be solved with a better model or a faster server. Doubling an engineer does not make the counterpart system's owner available sooner. That is why managing an integration-delay experience is not an engineering problem but a project-management and communication problem. My biggest mistake in the field was mistaking these sources for technical problems and seeking technical solutions; whereas the solution is to talk early, ask early and try early.

Another non-technical source is knowledge loss. In most organizations, the person who knows how the system you connect to works has either retired, left, or moved to another department. The system runs but no one knows exactly how it works. This "organizational memory gap" is a quiet but powerful component of the integration-delay experience; because understanding an undocumented system can sometimes take longer than writing one from scratch. The what is data governance guide, which addresses these data-side uncertainties more broadly, offers a good frame for seeing the root of the problem.

If I had to pick the single most frequent delay source I encounter in the field, its name would be "waiting on the other system." Integration is by definition two-sided: you write one side, but the counterpart system you connect to also has an owner, and that owner's availability directly determines your timeline. Waiting on the other system is perhaps the most seemingly inevitable yet actually most manageable part of an integration-delay experience.

Concretely, waiting on the other system looks like this: you ask a question — "what does this field mean," "can you open a test user," "can you grant access to that endpoint" — and the answer comes days, sometimes weeks later. Because that system's owner is not obliged to put your project at the top of their priority list; they have their own work, their own maintenance, their own emergencies. The integration critical to you is, for them, an entry in an ordinary queue of requests.

This waiting grows especially when the counterpart system is in the hands of an external vendor. With internal teams you are at least within the same organization; with an external vendor, a contract, commercial priorities and formal request processes come between you. What you call "a small change" becomes, on the vendor's side, a work order, a quote, an approval and a planning cycle. Here waiting on the other system stretches from hours to weeks.

You cannot eliminate this delay entirely, but you can shrink it. The approach that worked in the field for me was this: bring the counterpart system's owner to the table on the project's first day, list everything I would need from them (access, documentation, a test user, sample data) in one written list at once, and agree on a realistic response time for each request. This way I write waiting on the other system into the timeline from the start; it stops being a surprise and becomes a planned dependency. I address the place of this coordination within enterprise architecture holistically in enterprise AI architecture.

If I were asked to mark the single most expensive item of my integration-delay experience, I would say without hesitation "the absence of a test environment." Integration is trial-and-error by nature: you send a request, look at the response, fix something, try again. Without a test environment isolated from production where you can safely run this loop, the whole rhythm of integration breaks.

The absence of a test environment confronts you in several forms. Sometimes there is no test environment at all; there is only production, and experimenting on production means risking the real customer, real data and real operations. Sometimes there is a test environment but it does not reflect real data; it is empty, or its sample data does not contain real-life exceptions, so everything looks fine in the test and blows up in production. Sometimes there is a test environment but access to it is behind an approval queue; the environment sits there but you cannot use it.

The absence of a test environment enlarges the delay on two fronts. First, direct slowdown: when you must work on production, you wait for approval on every attempt and move carefully and slowly, because the cost of a mistake is real. Second, hidden delay: because there is no realistic test environment, you discover data-mapping exceptions, rate limits and authentication problems late; these problems blow up at the worst moment, when going to production. So the absence of a test environment is like a multiplier that triggers other delays too.

The lesson I learned in the field is clear: one of the first three questions I ask when starting an integration project is "do I have an authorized test environment with realistic data that I can use." If the answer is "no," the project's first technical task is to build this environment — even before the model work. Because trying to advance integration without a test environment is like driving with your eyes closed; you can hit a wall at any moment, and when you do, it happens in production. Building and monitoring this environment is part of production discipline; the what is MLOps guide and, for keeping production systems standing, model monitoring and drift give the frame of this discipline.

When connecting two systems, the most underestimated task is data mapping. On paper it looks very innocent: you match the fields in one system with their counterparts in the other. "Customer name here, order number there." It seems to fit in a table and finish in a meeting. Yet one of the most insidious parts of my integration-delay experience hides exactly here, in the detail of data mapping.

The real delay appears not in the mapping itself but in the exceptions discovered during mapping. The exceptions I have seen again and again in the field are these: the two systems name the same concept differently (on one side "customer," on the other "account holder," but not exactly the same thing). The same field is mandatory on one side and can be left empty on the other; when you try to process the empty record, the integration stops. Date formats mismatch; one system uses day-month-year, the other year-month-day, and this difference silently produces wrong data. Identity-number formats, currency representations and decimal separators differ. What is a single record on one side is multiple records on the other.

The common feature of these exceptions is that they do not appear in the design meeting. In the meeting everyone thinks of the "clean" example: a full, tidy, rule-abiding record. Exceptions, on the other hand, live in real data — empty fields, inconsistencies in old records, manually entered erroneous data, records entered into the system years ago under different rules. That is why data mapping can never be counted as "done" without being tried on real sample data. I address the technical side of such format and definition mismatches in data type mismatch and field structures that change over time in schema drift.

Exceptions frequently discovered in data mapping, how they show and how to prevent them

Exception	Symptom	Preventive action
Same concept, different name	Two fields seem to match but content does not	Validate meaning with sample data
Empty/exceptional record	Works on clean data, stops on real data	Add empty and edge records to the test set
Date/format mismatch	Silent wrong data, no error raised	Define and validate formats from the start
Single vs multiple record	Relationship is more complex than expected	Clarify cardinality early
Manually entered erroneous data	Outliers that break the rules	Profile the data, see the outliers

The most effective way to shrink exceptions in data mapping is to see them early. That is why in the field I put data mapping not at the end of the project but at the start, and test it with the most realistic sample data possible. A two-hour experiment with a handful of real records can catch, at the outset, a delay that would otherwise blow up in production months later. To measure the general quality of the data, the what is data quality guide provides the foundation of this early-discovery discipline.

When the technical work finishes, the project does not finish. The phase where I most often hear "but we had finished the code" in my integration-delay experience is the security and data-access-permission review. Because connecting to a system, obtaining data access permissions and especially touching fields that contain personal data is not merely technical work; it is a queue that requires approval by security, legal and compliance teams.

This queue has its own pace, and that pace is not under your control. The security team evaluates every system you want to connect to, every access you will request and every piece of data you will touch; this evaluation can take days or weeks depending on the organization's risk policies, current workload and the sensitivity of the matter. Even if the technical work finishes in a day, the review queue does not move at the same speed.

One of the most expensive mistakes I made in the field was starting this queue late. The logic went like this: "let us finish the technical work first, then get security approval." The result was two waits stacking — first the technical work, then an approval queue starting from scratch. The lesson I learned is this: start the security and data-access-permission review on the project's first day, in parallel with the technical work. That way, when the technical work finishes the approval has matured too; the two waits are experienced concurrently, not sequentially.

The content of this queue matters too. Access permissions, which user can access which data, how fields containing personal data will be protected, how the audit trail will be kept — all of these must be discussed from the start. In the Türkiye context, integrations containing personal data trigger KVKK obligations; I address this frame in what is KVKK and, for a KVKK-compliant architecture, what is KVKK-compliant AI. The audit trail layer, which records who accessed which data and when, is one of the basic elements this queue expects for both security and compliance. I evaluate the effect of the cloud-versus-own-infrastructure question on this queue in the self-hosted LLM vs API decision guide.

When connecting a modern AI solution to the organization's real world, most of the systems you face are not modern. The technically hardest part of my integration-delay experience is working with legacy systems. These systems were built years ago, with different standards, for different needs, and usually carry three problems at once: lack of documentation, old authentication and strict rate limits.

The first problem is the lack of documentation. A legacy system's API — if it has one — often has no written documentation. What each endpoint returns, what each field means, which code represents which state, is not written down. This knowledge lives in the head of the person who built the system years ago, and that person is often no longer at the organization. Trying to understand an undocumented system proceeds by trial and error, and every attempt turns into waiting on the other system.

The second problem is old authentication. Instead of modern standards, legacy systems may use custom, fragile and sometimes undocumented session mechanisms. How to obtain a token, how long it is valid, how to renew it — all of these are unknowns to be discovered. A single surprise in the authentication layer can cause a delay lasting days; because until you solve it, no request goes through.

The third problem is strict rate limits. Legacy systems were not designed for high request volume; that is why they allow a certain number of calls per minute or second. While your modern solution is used to sending hundreds of requests per second, if the counterpart system says "ten requests per minute," you must rethink your entire architecture around this limit. Techniques like batch processing, queuing and caching come into play, and if these were not planned, delay is inevitable.

These three problems are manageable on their own; but combined, every integration step turns into an obstacle course. The approach that worked in the field for me is to bring the legacy system's owner to the table early and to discover the system's real behavior — based not on documentation but on real experimentation — as early as possible. I address the architectural pitfalls of integrating with legacy systems more broadly in PoC-to-production architectural mistakes, and the protocols connecting models to tools and data in what is function calling and what is MCP.

A frequently skipped layer of integration is not the technical connection itself but the matter of being "authorized" to make that connection. Being technically able to connect to a system does not mean you have permission to connect to it. Data access permissions are an invisible but powerful component of the integration-delay experience; because permissions are the result not of one person but, often, of an approval chain.

An approval chain works like this: to access data you request permission from the data owner, the data owner consults security, security asks legal, legal directs to compliance. Each link moves at its own pace, and the total duration of the chain is determined by the pace of the slowest link. The pattern I have seen in the field is this: if this chain is not mapped from the start, every new approval need creates a surprise delay and the project slows step by step.

Another reality that complicates the permission matter is granularity. "Access to the system" is not one thing; which table, which field, which record range, for which purpose you access can be evaluated separately. Especially for fields containing personal data, by the principles of purpose limitation and data minimization, access is granted only to the data you truly need. This is a correct approach but must be accounted for in integration planning. I address what personal data is in what is personal data and the concept of data ownership in data ownership.

The way that works in the field to manage these permission chains is to start them before the technical work and to send each access request as early, clearly and with as much justification as possible. A clear request in the form of "I want to access this data for this purpose, for this duration, with these protection measures" makes the job of each link in the chain easier and speeds up the queue. Vague, broad and unjustified requests are rejected or debated at length — and that debate is a delay directly.

When starting an integration project, the first thing I do is not write code but draw up an inventory. This inventory lists in one place all the external systems the solution will touch and asks the same questions for each. Teams that skip this step experience the integration-delay experience piece by piece, as each new dependency emerges; teams that draw up an inventory see the whole picture from the start and minimize surprises.

In the dependency inventory I answer these questions for each system: Why are we connecting to this system, which data will we read and which will we write? Who owns the system, an internal team or an external vendor? Is there an API, and if so is it documented? How does authentication work? What are the rate limits? Is there an authorized test environment? Which data access permissions are needed and which approval chain do they pass through? The answers to these questions are often unknown on the first day; but even asking them shows where the uncertainty is and therefore where the risk concentrates.

The real value of the inventory is that it makes uncertainty visible. When you write a line saying "we do not know who owns this system," that line is now a risk and can be managed. Invisible risk cannot be managed; visible risk can be planned. That is why I see the inventory not as a formality but as the project's risk map. Drawing up this map requires understanding the whole of enterprise architecture; I address this view in the enterprise RAG guide and the disciplining of data flow in data contracts.

While drawing up the inventory a reality must also be accepted: as the list grows, the project becomes more complex. A solution connecting to five systems is not five times but far more complex than one connecting to a single system; because dependencies affect one another. That is why the inventory is also a scope-narrowing tool: asking "is this connection truly required in the first version, or can it be left for later" is one of the strongest levers for shrinking an integration-delay experience. The best integration is the one you never have to do.

Legacy systems' strict rate limits are the part of an integration-delay experience that technically requires the most redesign. A modern AI solution is used to sending many requests per second; if the counterpart system says "this many per minute," you must rethink your solution's architecture around this limit. This is a constraint to be designed from the start, not patched on later.

There are several established methods for coping with a limit. First, queuing: instead of sending requests immediately, putting them in a queue and releasing them at a rate the counterpart system can bear. Second, batch processing: where possible, turning many small requests into a single batch request. Third, caching: fetching and storing frequently requested, rarely changing data once, so you do not go back to the counterpart system again and again for the same data. Fourth, scheduling: shifting heavy work to hours when the counterpart system is idle.

The common aim of these methods is to turn waiting on the other system from a bottleneck into a manageable flow. But they all require planning from the start; if you discover the rate limit while going to production, you have to build all this architecture in the middle of a crisis — which is one of the most expensive scenarios of an integration-delay experience. That is why learning the rate limit early is one of the inventory's most critical lines. I address this flow and queue architecture more broadly in pipeline, workflow orchestration and stream processing.

Let me add a field observation: rate limits are often lower than what the documentation states. The documentation says "a hundred requests per minute" but in reality the system starts slowing at fifty; because the documentation reflects the ideal condition while reality reflects the current load. That is why the rate limit must be discovered based not on documentation but on real experimentation. A load experiment done in the test environment shows a bottleneck that would blow up in production from the start. This is where the test environment's role in seeing rate limits early comes into play too.

There is a theme I repeat throughout this field note: managing integration well is not writing the best code but building the best communication. What shrinks waiting on the other system is not technical mastery but the discipline of asking the right question of the right person at the right time. This is a skill that sounds simple but is constantly violated in the field.

The first rule of communication is finding the right counterpart. In large organizations, the person who technically knows the system you connect to and the person who can grant access permission to it are often different; and finding both takes time. The right question asked of the wrong person wanders for days and comes back. That is why, while drawing up the inventory, I try to answer for each system, separately, "who is the technical counterpart, who is the permission counterpart."

The second rule is asking the question clearly and in bulk. Sending the counterpart team one question every day means entering their queue anew each time; whereas conveying your needs at once, in a written and justified list, gets them resolved in a single queue round. A clear request in the form of "I want this access, for this purpose, by this date" makes the counterpart's job easier and shortens waiting on the other system. Vague questions produce vague and late answers.

The third rule is building the relationship as a continuous rather than a one-off thing. Throughout integration you will talk with the same team many times; that is why being well-intentioned, clear and predictable from the first contact makes your later requests come back faster. The fastest integrations I have seen in the field were not those with the best tools but those that built the healthiest relationship with the counterpart team. I address strengthening this human and organizational side with training in what is enterprise AI training. Communication discipline is perhaps the most underestimated tool for managing an integration-delay experience.

The existence of a test environment is necessary but not sufficient; what and how you test in that environment also matters. Integration testing is not one thing but consists of several layers, and each layer catches a different delay source early. Skipping these layers means carrying the integration-delay experience into production.

The first layer is unit-level connection testing: can you send a single request to the counterpart system and get the correct response? This catches authentication and basic connection problems. The second layer is data-mapping testing: trying, with real sample data, whether the two systems' fields match correctly and whether exceptions are handled correctly. This layer surfaces exceptions like empty records, format mismatches and single-versus-multiple records.

The third layer is end-to-end testing: running a real user scenario from start to finish. Even if individual steps work, unexpected problems can arise when they all come together; end-to-end testing catches these. The fourth layer is load testing: seeing how the counterpart system behaves under real volume and where rate limits kick in. This layer discovers, in the test environment, bottlenecks that would blow up in production and perhaps prevents the most expensive delay.

The common logic of these layers is to catch the problem in the smallest and earliest form possible. If you catch a connection problem in a unit test you solve it in five minutes; if you catch the same problem in production it becomes a crisis. That is why testing is not a check added at the end of integration but a discovery process that runs intertwined with it. I address the discipline of testing and post-production monitoring in model monitoring and drift and the service level of data collection in data collection SLA. As a field observation: speed that skips the test layers almost always turns into a bigger slowdown later.

If the counterpart system is in the hands of an external vendor, an entirely new dimension is added to the integration-delay experience: commercial and contractual reality. With internal teams you at least share the same organizational priority; with an external vendor, contract scope, a service-level agreement (SLA) and commercial priorities come between you. A plan that does not account for this layer constantly meets surprises in external dependencies.

The problem I see most often is that the needed work falls outside the contract scope. What you call "a small change" may not be defined in the vendor's existing contract; in that case, first a scope discussion, then a quote, then an approval, and only after that the work begins. This commercial cycle can add weeks independently of the technical work. That is why, when working with an external vendor, clarifying at the earliest whether the work you will need is within the contract scope is critical.

The second reality is that the SLA may not work in your favor. A vendor's commitment of "a response within five business days" may be too slow for your urgent need; but if that is the contract, waiting on the other system is bounded by this duration and speeding it up is often not possible. That is why building your plan around the vendor's real SLA is far sounder than building it around an optimistic estimate. I evaluate the effect of the cloud-service-versus-own-infrastructure question on this dependency in the self-hosted LLM vs API decision guide.

The third reality is information asymmetry. The vendor knows its own system far better than you do; this leaves you exposed to the risk of not being able to ask the right question. The way to reduce this asymmetry is to explicitly request from the vendor, during the inventory phase, the system's real behavior, limits and exceptions. The lesson I learned in the field is this: in integration with an external vendor the biggest delay source is not technical difficulty but commercial and communicational friction. Reducing this friction with an early and clear frame is an inseparable part of managing an integration-delay experience. I address the budget side of this commercial planning in enterprise AI budget planning.

Now let us gather the essence of this field note in one place. The table below shows, together, the delay sources I have seen again and again in my integration-delay experience, how each shows a symptom in the field, and the preventive action you can take early to shrink that delay. I recommend using this table like a checklist when starting an integration project; each row is the distilled form of a lesson whose cost I have seen in the field.

Integration delay source × symptom × preventive action (field-note summary)

Delay source	Symptom in the field	Preventive action
Waiting on the other system	Answers to questions come days/weeks later	Bring the counterpart owner to the table on day one, give all requests written in one list
Absence of a test environment	Only production exists; every attempt risky and slow	Build an isolated test environment with realistic data as the first technical task
Data-mapping exceptions	Works on clean data, stops on real data	Test data mapping early and with real sample data
Undocumented legacy API	Field meanings unclear, trial-and-error stretches	Find the person who knows the system early, discover behavior by experiment
Old authentication	Token/session mechanism fragile, requests fail	Validate authentication end-to-end at the earliest
Strict rate limits	Counterpart rejects with 'too many requests'	Learn the limit early; plan queue, batching, caching
Data access permissions	Technical connection exists but no authorization	Map the permission chain, send clear justified requests early
Security review queue	Code done but project waiting in approval	Start the security/permission process on day one in parallel

A single pattern underlines this table: the preventive action for every delay source is "early." Bring the counterpart system to the table early, build the test environment early, try data mapping early, request permissions early, start security early. The secret to managing an integration-delay experience is not writing faster code but bringing the risky work forward. A problem discovered early is small and cheap; the same problem, if discovered late, is large and expensive.

Every delay source I have described so far actually points to a single root cause: leaving integration to the end of the project, to "the last week." The essence of realistic planning is to reverse this. Integration is the riskiest and least controllable part of the project; that is why it should be placed at the start, not the end. The steps below summarize the planning approach that most shrinks the integration-delay experience in the field.

How to

Realistic planning that shrinks integration delays

A way to plan integration in an AI project as a discovery and risk-management step from the very start, rather than leaving it to the last week.

1. 1

   List external dependencies in the first week

   Lay out every system to connect to, its owner, the API/documentation/test-environment status and the required permissions in one table.

2. 2

   Assign an owner and a buffer to each dependency

   Write waiting on the other system into the timeline from the start; leave a realistic buffer for each external request.

3. 3

   Try the riskiest integration earliest

   Put the most uncertain and most critical connection first; a problem found early is small, one found late sinks the project.

4. 4

   Build the test environment and real sample data early

   Do not count any integration as 'progressing' without an isolated test environment with realistic data.

5. 5

   Start security and permissions on day one

   Run the approval queue in parallel with the technical work; prepare the expected documents in advance.

6. 6

   Validate data mapping with real data

   Add empty, exceptional and outlier records to the test set; test with real data, not a clean example.

7. 7

   Report progress by waiting items

   Track status by 'which external dependency is at which stage' rather than 'how ready the code is'.

At the heart of this planning approach is a mindset shift: seeing integration not as a technical detail but as a risk item. In an AI project the biggest uncertainty is usually not in the model but in the systems the model will connect to. That is why building the project plan not as "model first, then integration" but as "discover the riskiest integration early, advance it in parallel with the model" fundamentally changes the integration-delay experience. I address this holistic planning at the enterprise level in what is an AI roadmap and the budgeting side in enterprise AI budget planning.

A caveat: realistic planning does not mean "foresee everything perfectly from the start." There will always be surprises you cannot foresee. The purpose of realistic planning is not to eliminate the surprise but to pull the surprise earlier and shrink it. A delay discovered early is manageable; the same delay discovered late is a crisis. The difference is in the quality of the planning — not in the quality of the model.

This is perhaps the most-asked question of this field note: why does integration get delayed? Let me gather everything I have described so far into a single answer. Integration gets delayed because integration is less a task under your control than a chain of dependencies outside your control. You write your own code at the pace you like; but you do not determine the counterpart system's availability, the existence of a test environment, the approval of permissions, or the pace of the security queue.

Let me put this more concretely. The recurring chain of causes in an integration-delay experience is this: you wait until the counterpart system's owner becomes available (waiting on the other system); you proceed slowly and riskily because there is no authorized test environment to try in; when you experiment with real data you meet unexpected data-mapping exceptions; the legacy system's undocumented API, old authentication and strict rate limits stretch every step; and even when all of this is done, you wait in the security and permission review queue. Each is small on its own, but stacked together they become a delay reaching months.

The critical point is this: almost all of these causes are organizational, not technical. That is, they are not solved with a better model, a faster server or a more skilled engineer. They are communication, coordination, prioritization and approval problems. That is why truly understanding integration delay begins with ceasing to see it as an engineering problem and seeing it as a project-management and organization problem. This perspective also explains why projects that stay in pilot cannot move to production; I address this pattern in detail in projects stuck in pilot field note.

Integration delay also has a hidden psychological dimension. When the model works, the team feels "the hard part is over" and relaxes; it mistakes integration for a formality. Yet the field reality is the opposite: the model is often the easy part, integration is the hard part. This false relief leads to not approaching integration early and seriously enough — and this is the deepest root of the delay. I see a similar fallacy in the transition from training to production; the training-to-production transition — the model alone is not enough guide addresses this "the job is done once the model is done" fallacy more broadly.

It is no coincidence that I open a separate heading for the importance of a test environment in this field note; because in the integration-delay experience, the absence of a test environment is the item that produces the most delay, both directly and indirectly. Why a test environment is so critical must be seen from three angles.

First, integration is trial-and-error, and trial-and-error wants a safe place. Sending a request and seeing the response, fixing a field and trying again, catching an exception and handling it — all of these require repeated attempts. Doing these attempts on production means risking the real customer and real data every time. An authorized test environment lets you run this loop fearlessly; without a test environment the loop either stops or waits for approval at every step.

Second, a test environment lets you see exceptions early. But for this the test environment must be realistic, that is, contain the exceptions of real data. An empty test environment is misleading: everything looks fine because there is no data in it to cause trouble. A test environment that reflects real data (appropriately anonymized) surfaces data-mapping exceptions, rate limits and authentication problems before going to production. This turns the most expensive delay (a surprise blowing up in production) into the cheapest delay (a problem caught in the test).

Third, a test environment preserves the team's confidence and speed. A team working on production proceeds at every step with the fear of "what if I break something"; this fear lowers speed and creates tension. An isolated test environment gives the confidence of "nothing happens if I make a mistake here"; this confidence speeds up experimentation and therefore speeds up integration. I address building the test environment and the discipline of a safe transition to production in what is LLMOps and what is MLOps.

The third critical question: how should integration be planned? I gave the answer implicitly throughout this field note; now let me set it in a clear frame. Integration planning revolves around a single principle: discover external dependencies early, pull them earlier and parallelize them. A few concrete decisions bring this principle to life.

The first decision is to put integration at the start of the timeline, not the end. The traditional approach says "let us build the solution first, then connect it"; this means leaving the riskiest work for last and is the main source of an integration-delay experience. The right approach is the opposite: try the most uncertain and most critical integration in the project's first days, before the model has even matured. That way, if there is a problem, you have the whole project duration to fix it; had you left it to the end, the same problem would have made you miss the deadline.

The second decision is to define an owner and a buffer for each external dependency. "We will connect to this system" is not a plan; "we will connect to this system, by this date, coordinated by this person, with this buffer" is a plan. Turning waiting on the other system from a surprise into a planned item makes the delay manageable. The frame in the AI use-case prioritization matrix guide helps in prioritizing these dependencies.

The third decision is to measure progress correctly. During the integration phase, "how ready the code is" is a misleading measure; because even if the code is ready, the project may be waiting on external dependencies. The right measure is this: which external dependency is at which stage — was it requested, did the answer come, was it tested, was it approved? Tracking progress by waiting items shows the project's real status and makes delays visible early. Communicating this visibility to senior management is a separate skill; the presenting an AI project to senior management guide addresses this communication.

Finally, planning should be something continuously updated. Integration is a phase full of discovery; every new discovery changes the plan. A flexible plan updated as new information arrives, rather than a rigid, unchanging plan, fits the reality of integration far better. The goal is not a perfect first plan but a process that learns fast and adapts fast.

Seeing an integration-delay experience only as a "timeline slip" is to understand its cost incompletely. The visible cost of the delay is time; but its invisible costs are often heavier, and a plan that does not account for them underestimates the delay's real price.

The first invisible cost is opportunity cost. A solution waiting in integration produces no value during that time; the productivity it would provide, the problem it would solve, the opportunity it would open are postponed. The model may be working, but as long as it is not connected to production it is merely a demo. The second cost is team morale: an integration that keeps being called "almost done" for months without finishing erodes the team's motivation and its faith in the project. The third cost is loss of trust: as the delay stretches, stakeholders' trust in the project and the team running it decreases, and the next AI initiative is met with more suspicion.

The fourth and perhaps most insidious cost is loss of context. As integration stretches, the rationales for decisions made at the start of the project are forgotten, team members change, priorities shift. A design decision that was clear months ago turns into today's question "why did we do this this way." This context erosion enlarges the delay further; because every forgotten decision is re-debated. That is why finishing integration quickly is not only a timeline matter but also the way to preserve the project's whole knowledge and momentum.

Making these costs visible is the strongest justification for giving integration the right priority. A phase belittled as "we will just connect it" may actually harbor the project's most expensive delay. That is why explicitly separating integration as a line item when building an AI project's budget and timeline takes it out of being an invisible assumption. I address this budgeting discipline in enterprise AI budget planning and prioritization in AI use-case prioritization matrix. A team that accepts the real cost of the delay approaches integration with the seriousness it deserves — and that seriousness fundamentally shrinks the integration-delay experience.

I want to close this field note with a few patterns I have seen again and again across different projects. These do not belong to a single project; they are sector-independent observations spread across my integration-delay experience as a whole. Each is a signal to watch for in your next project.

The first field observation: teams that try the delay early experience it small, those that try late experience it large. The same integration problem — say a data-mapping exception — is a two-hour fix if discovered at the start of the project; it is a crisis that makes you miss the deadline if discovered at the end. The size of the problem is not fixed; it grows or shrinks depending on when it is discovered. That is why the most valuable integration skill is not writing code but bringing the risky work forward.

The second field observation: the feeling of "the model is done, the rest is easy" is almost always misleading. When teams see the model working they relax and underestimate integration. Yet the field reality is the opposite: the model is often the easy half of the work, integration the hard half. This false relief leads to approaching integration late and loosely. I see this pattern on the user-adoption side too; even when the technical solution is ready, the user's adoption of it takes separate effort, and I address this in user adoption field note.

The third field observation: external dependencies are always slower than you predict. You plan "they will respond in a day," it takes a week. This is not the counterpart team's incompetence but a difference of priorities; your urgent work is their ordinary request. Accepting this observation makes planning realistic: always leave more buffer for external dependencies than you think.

The fourth field observation: lack of documentation is the most expensive hidden cost. Legacy systems being undocumented turns integration into trial-and-error, and every attempt stretches with waiting on the other system. Finding the person who knows the system is often more valuable than writing code. This observation becomes even more pronounced when combined with approval processes in regulated sectors; I describe the intersection of approval and integration in regulated-sector approval field note and the reality of on-premise constraints in on-premise realities field note.

The fifth field observation: the common feature of teams that manage integration well is not technical superiority but communication discipline. The best integrators are not the best coders but those who ask the right question of the right person early. What shrinks an integration-delay experience is not a library or a tool but a habit: ask early, try early, discover early. I complete this human side in the context of transformation patterns in transformation patterns field note and the document-preparation side in document preparation field note.

A powerful but underused way to shrink an integration-delay experience is to design integration not as a single big step but as a phased rollout. The "all or nothing" approach waits for all dependencies to be ready at the same time; yet in the real world dependencies become ready at different speeds. The phased approach brings the ready piece live without waiting and adds the rest as it matures.

One technique for this is to proceed with a mock endpoint before the counterpart system is ready. If you know what the counterpart system will return, you can build a temporary component imitating that response and continue developing your side; when the counterpart system is ready you replace the mock with the real thing. This way, waiting on the other system does not stop your progress; both sides mature in parallel. This turns an integration-delay experience from a serial chain of waiting into a parallel flow.

Another form of phased rollout is to open the integration first with a narrow scope: a single user group, a single data type, a single scenario. A narrow scope both shrinks the risk and surfaces real-world exceptions at low volume, in a manageable way. Seeing and fixing problems at small scale is far cheaper than experiencing them all at once at large scale. It is useful to read this phased logic together with projects stuck in pilot field note, where I address projects' transition from pilot to production, and what is an AI roadmap, where I address roadmap design.

The hidden benefit of the phased approach is that it speeds up learning. Each phase produces a lesson for the next; a data-mapping exception you discover in the first narrow rollout lets you fix the next phases from the start. That is why phased rollout reduces not only risk but uncertainty. As a field observation: teams that try to finish integration in a single move usually finish slower; those that proceed piece by piece reach a faster and sounder result while continuously producing value.

Integration planning must cover not only the "if everything goes well" scenario but also the "if something goes wrong" scenario. Some of the delays I have seen in the field come from not thinking through, from the start, what to do at the moment of failure. What will your solution do if the counterpart system does not respond, slows down, returns erroneous data or breaks halfway? If the answers to these questions are not designed from the start, the project stops at the first failure and a crisis-management delay begins.

A sound integration assumes the counterpart system will behave imperfectly. That is why retry logic, timeout limits, and the solution's graceful degradation when the counterpart system goes down are planned from the start. Instead of the whole solution crashing when the counterpart system is temporarily unreachable, that section being disabled while the rest keeps working preserves both the user experience and the project's resilience. I address the logic of these protective layers in what is a guardrail and error handling in autonomous agents in agent error handling and rollback.

Reversibility is also a critical design principle. If an integration step goes wrong, you must be able to return the system to a safe previous state; especially in integrations that write data to the counterpart system, undoing a wrongly written record must be planned from the start. Otherwise a single error turns into a data contamination that takes days to clean up — which is one of the most insidious forms of an integration-delay experience. From a security standpoint, you must also account for the risk of misuse of write authority to the counterpart system; I address such attack surfaces in what is prompt injection.

Thinking through failure scenarios from the start feels to many teams like an extra burden; yet in the field the opposite is true. Teams that do not plan for the moment of failure experience larger delays with panic and improvised solutions when it arrives; teams that plan for it get through the same event with a foreseen, rehearsed procedure. Resilience is not a cost but an investment against delay.

A little-discussed aspect of the integration-delay experience is not technical but communicational: how the delay is conveyed to stakeholders. While a project waits in the integration phase, senior management and business units often do not understand what is going on; the question "the model was ready, why is it still not done" hangs in the air. This communication gap adds a loss of trust to the technical delay.

The way to close this gap is to report progress with the right metric. A statement like "the code is ninety percent ready" is misleading; because the project is actually waiting on external dependencies. The right report shows the real status by waiting items, in the form of "this dependency is in the approval queue, this is being tested, this is awaiting a counterpart response." This transparency lets stakeholders see the delay not as a failure but as a managed process. I address this communication at the senior-management level in presenting an AI project to senior management.

Another important point in stakeholder communication is managing expectations from the start. Saying clearly at the beginning of the project that integration involves external dependencies and that these dependencies can affect the timeline creates far less damage than surprise delays arriving toward the end. Establishing the sentence "the model part is on us, the integration part largely depends on others' pace" early creates a realistic expectation frame. I complete this frame in the context of enterprise transformation in transformation patterns field note.

A final field observation: teams that manage integration delay well do not hide the delay, they make it visible. Sharing a delay early and honestly is always less costly than hiding it to the end and detonating it. Stakeholders want to hear bad news early, not late; because a delay heard early is manageable, the same delay heard late is a trust crisis. Managing the perception of integration, as much as its technical management, is a part of this field note.

I want to end this field note with the plainest lessons I could distill. The integration-delay experience taught me the same thing over and over: the source of the delay is almost never where you think it is. The effort you invest in the model side is visible and satisfying; but what actually delays your project is the invisible, scattered systems under others' control that the model will connect to.

First lesson: see integration not as a technical detail but as a risk item. The project's biggest uncertainty is usually not in the model but in the integration. So give the most attention to where the most uncertainty is. Postponing integration with "we will handle it later" is leaving the riskiest work for the worst time.

Second lesson: discover early. The common word of every preventive action in this field note was "early." Bring the counterpart system to the table early, build the test environment early, try data mapping early, request permissions early, start security early. A problem discovered early is small and cheap, the same problem discovered late is large and expensive. This is integration's golden rule.

Third lesson: most of the delay is organizational, not technical. That is why the solution is organizational too: communication, coordination, prioritization and realistic planning. A better model or a faster engineer does not shorten waiting on the other system; but an early and clear request speeds up an approval queue. Managing an integration-delay experience is a project-management skill more than an engineering one.

Fourth lesson: be realistic, but not pessimistic. Integration delays are inevitable; but they are not unmanageable. You can foresee them, pull them earlier and shrink them. The purpose of this field note is not to scare you away from integration but to catch you prepared for it. A prepared team experiences the same delay not as a crisis but as a planned dependency — and the difference is exactly there.

Fifth and final lesson: an integration-delay experience is a recurring teacher. Every project shows the same patterns returning in a slightly different guise: waiting on the other system, the absence of a test environment, data-mapping exceptions, undocumented legacy systems and approval queues. This recurrence is not bad news but good news; because a recurring problem is a learnable and preparable one. If, on your next project, you open the delay source × symptom × preventive action table from this field note like a checklist and ask each row early, you will experience the same delays far smaller. Mastering the field is not eliminating surprises but making them familiar.

If you are preparing to move an AI project to production at your organization and want to plan these integration-phase delays correctly from the start, we can talk by adapting the patterns in this field note to your specific context. To draw up an integration and go-to-production roadmap tailored to your organization's systems, constraints and priorities, you can plan an AI consulting session, review corporate training options for your teams to gain this discipline, and deepen all concepts in the learning center.

Why does integration get delayed?

The summary of my integration-delay experience in the field is this: most delays come not from the model or the code but from the organizational realities of connecting to surrounding systems. I most often see four causes. First, waiting on the other system: nothing moves until the owner or vendor of the legacy system you connect to becomes available. Second, the absence of a test environment: if there is no isolated environment where you can safely experiment, every attempt means production risk and waiting. Third, exceptions discovered in data mapping: two systems defining the same information differently surfaces in the middle of integration. Fourth, the security and data-access-permission review queue. These four are coordination problems, not technical ones; that is why early discovery and planning are needed.

Why is a test environment critical?

A test environment is critical because integration is trial-and-error by nature: you send a request, see the response, fix it. Without an authorized environment isolated from production, you either cannot build this loop at all or build it by taking risks on the live system. In the field, the absence of a test environment is the single most expensive item of an integration-delay experience: waiting for approval on every attempt, moving slowly for fear of breaking production, and seeing exceptions late because you cannot work with realistic data multiplies the delay. That is why one of the first questions I ask when starting an integration project is "do I have a test environment and realistic test data I can use."

How should integration be planned?

The essence of realistic planning is to see integration not as a formality left to the end of the project but as a discovery step placed at the very start. In practice, in the very first week we list all external dependencies (which systems we will connect to, who owns them, is there an API, is it documented, is there a test environment, which permissions are needed). For each dependency we define an owner and a realistic buffer; we write the possibility of waiting on the other system into the timeline from the start. We kick off the security and data-access-permission review on day one because it is a queue. And we try the riskiest integration earliest, because a problem discovered early is small, while the same problem discovered late is a project-sinking delay.

Why does data mapping cause delays so often?

Data mapping looks like matching the fields of two systems on paper and is therefore underestimated. The real delay hides in the detail: the two systems name the same concept differently, the same field can be mandatory on one side and left empty on the other, date formats and identity-number formats mismatch, and what is a single record on one side is multiple on the other. These exceptions surface not in the design meeting but while experimenting with real data. That is why testing data mapping early and with real sample data is one of the most effective ways to shrink an integration-delay experience.

How do legacy system APIs slow integration down?

Legacy systems are the hardest part of integration because they usually carry three problems at once. First, lack of documentation: what the API returns and what each field means is not written down. Second, old authentication: instead of modern methods, there may be a custom, fragile session mechanism. Third, strict rate limits: because the system cannot handle high request volume, it allows a certain number of calls per minute. Combined, these turn every integration step into waiting on the other system; the solution is to bring the legacy system's owner to the table early and to discover its real behavior early.

Why does the security review delay integration?

Because the security and data-access-permission review is not a technical step but an approval queue, and that queue has its own pace. Connecting to a system, obtaining data access permissions, touching fields that contain personal data; all of these require review by security, legal and compliance teams. Even if the technical work finishes in a day, the review queue can take weeks. The lesson learned is to start the security and permission review on the project's first day, in parallel with the technical work. That way, when the technical work is done the approval is ready too, and the two waits do not stack.

Let me summarize briefly: this field note focused on the least-discussed yet most timeline-slipping phase of an AI project, integration. The essence of the integration-delay experience I described is this: most delays are organizational, not technical. Waiting on the other system, the absence of a test environment, data-mapping exceptions, undocumented legacy system APIs, authentication and rate limits, data access permissions and the security review queue — all of these are managed not with code but with early discovery, coordination and realistic planning.

The most important message is gathered in a single word: early. Bring the counterpart system to the table early, build the test environment early, try data mapping early, request permissions early, start security early. A delay discovered early is small and cheap; the same delay discovered late is large and expensive. Placing integration not in the last week but at the start of the project as a discovery and risk-management step fundamentally changes the integration-delay experience.

And a final field observation: the secret of teams that manage integration well is not technical superiority but communication discipline. The best integrators are not the best coders but those who ask the right question of the right person earliest. To draw up an integration and go-to-production roadmap tailored to your organization's systems and constraints, you can plan an AI consulting session, evaluate corporate training options for your teams to gain this discipline, and deepen all concepts in the learning center.