Build into the business you actually have

Most organisations that could use AI have already spent years, and a great deal of money, implementing an ERP, a CRM, an HR system, case management and some kind of data platform. Those systems are imperfect, and the people who run them know it better than anyone. They are also where the business keeps its records, its controls and its audit trail.

An AI proposal that begins with "first, replace the core system" asks the organisation to fund a migration before it sees any value. It will meet resistance, and the resistance is usually justified.

The forward deployed approach starts somewhere else: with the installed estate as it is. For each capability the work needs, the team decides whether to extend the existing system, wrap it, integrate with it, gradually move away from it, or replace it, and records why.

Sandveld Foods and Ironbark Digital are fictional, and their systems and figures are illustrative. Sandveld, a Paarl fruit and vegetable processor, runs accounts payable on a 14-year-old ERP. It can read purchase orders and goods-received notes through a SOAP API. It has no API for posting invoices; invoices go in through an existing nightly import file. Its first "AI invoice" product, bought a year before Ironbark's pod arrived, assumed a modern posting API and never got past the demo. Part 3 settled which steps belong to rules, AI and people. This part is about how those steps connect to systems that were never designed for them.

Five integration strategies

These are not alternatives you pick one of. Most real designs combine several. Sandveld's uses three at once:

• Overlay: an exception workbench for the AP clerks, showing each exception with the extracted invoice, the matched purchase order, the evidence and a recommended action.
• Integrate: the matching service reads purchase orders and goods-received notes through the ERP's SOAP API.
• Wrap: posting goes through a small controlled service that writes to the existing nightly import file, rather than anything touching the ERP's database directly.

Strangling is planned. Replacement is not on the table, because nothing in the invoice work requires it.

Respect the system of record

The fastest way to create a new legacy problem is to let AI components quietly become authoritative. Conversation history, agent memory, vector stores and workbench databases are all places where a second version of the truth can grow.

The architecture has to state:

• which system owns each data entity;
• which updates are allowed, and by whom;
• how conflicts are resolved;
• how transactions are identified and made idempotent;
• how eventual consistency is explained to users;
• how corrections and deletions propagate;
• which evidence is retained for audit.

At Sandveld the rule is simple: the ERP is the system of record, and the workbench holds no approval state the ERP does not also have. A clerk's approval in the workbench becomes a posted line in the import file, and the ERP's own status is what the workbench shows afterwards. If the two ever disagree, the ERP wins and the workbench flags the difference.

Idempotency matters here because the import is a file, and files get re-run. The wrapped posting service builds a key from supplier, invoice number and amount, and refuses a second line with the same key, so a re-run import can never post an invoice twice. That key is the last line of defence, not the first. The case Part 4 found in shadow, a grower who sent the same invoice twice by different routes with the number written differently, would have produced two different keys. It is caught earlier, by the duplicate check that compares supplier, amount, date and delivery before anything reaches the posting service.

"We will integrate with the ERP" is not an architecture

That sentence appears in a great many AI proposals. Discovery has to turn it into facts:

• which API operations are actually available and supported;
• how the service authenticates, and under which identity;
• rate and concurrency limits;
• whether webhooks or events exist;
• sandbox and test-data access;
• schema stability and versioning;
• network and regional constraints;
• licensing and per-transaction costs;
• where the vendor's support ends;
• what batch, file or user-interface alternatives exist where an API does not.

Sandveld's answers were mixed. Reads were possible and reasonably fast. Posting was file-only. The test environment was a two-year-old copy of production with personal information that had to be masked before Ironbark's team could use it, which took three weeks nobody had planned for. And the ERP locks posting for the last two working days of each month, which the import service has to respect rather than retry against.

Browser automation can bridge a short-term gap, but it breaks when the interface changes and it tends to outlive its welcome. Sandveld uses it in exactly one place: downloading invoices from one large packaging supplier's portal, which has no other export. It runs as a named, monitored exception with a fallback: if the download fails, a clerk is told and fetches the file by hand. It has an end date tied to the supplier's promised API.

For how tool access should be controlled once it exists, see the gateway is a control point, not a trust boundary.

The strangler path for AI-enabled modernisation

The strangler pattern replaces a system one bounded piece at a time, with the old path available until the new one has proved itself.

1. Observe and measure the current workflow.
2. Introduce an assistant that drafts or retrieves information.
3. Move one bounded decision into a controlled service.
4. Route new cases through the new service, with the legacy path kept as a fallback.
5. Migrate adjacent steps when the evidence supports it.
6. Retire the legacy function only once its dependencies and records are resolved.

Sandveld has reached step 4. Suppliers to the Wellington plant go through the new service; the other plants still run the old way while the evidence accumulates. Steps 5 and 6 are planned: retailer short-delivery claims and supplier onboarding are the adjacent workflows, and the old invoice capture function will only be retired as part of the ERP upgrade the Head of IT already has on the roadmap.

The sequence reduces the size of each change. It does not remove the need for a destination. Without an agreed target architecture, "temporary" overlays pile up into the next legacy estate. Sandveld's architecture decision records (below) name the target state for each integration, so that each temporary measure has a reason to end.

Adoption is part of technical delivery

People resist a new agent for reasons that are usually rational: fear of job loss, loss of control, closer monitoring, or being held responsible for mistakes the AI made. Technical teams that treat these concerns as change-management noise build systems nobody uses.

Sandveld's clerks raised the monitoring concern within the first week of shadowing. The workbench records every correction a clerk makes to an AI recommendation, because those corrections are the most valuable evaluation data the project has. To the clerks, it looked like a record of their mistakes. Ironbark's pod changed two things: correction statistics are reported by process and exception type, never by person, and the AP manager said so in writing. The concern did not disappear, but participation in the shadow period recovered.

Designing with users means:

• explaining what the system will and will not do;
• preserving meaningful control;
• showing the evidence behind each recommendation;
• making corrections easy, and visibly used;
• measuring whether workload actually improves;
• avoiding a hidden transfer of work onto reviewers;
• training the support team before go-live, not after;
• using feedback to improve both the software and the process.

The clerk who knew the fresh-produce weight tolerance in Part 2 became one of the workbench's strongest advocates, because the system now applied that rule consistently, and the design record credits the clerk as its source. That is not a coincidence. People adopt systems that respect what they know.

The architecture decision record

For each major integration choice, record:

• the business capability affected;
• the current system and its owner;
• the options considered;
• the chosen strategy and the reason;
• the data and identity flows;
• failure and fallback behaviour;
• the transitional and target states;
• the cost and licensing impact;
• the conditions for exit or replacement.

The posting service's record at Sandveld fits on a page: capability "invoice posting", owner the Head of IT, options considered "direct database write (rejected), screen automation (rejected), wrapped import file (chosen)", fallback "clerk posts manually", target state "native API after the ERP upgrade", exit condition "upgrade complete and the API tested". Anyone joining the project later can see why it looks the way it does.

The short version

Start with the installed estate. Replacement is the most expensive assumption in any AI proposal.

Combine strategies deliberately. Overlay, integrate and wrap usually come before strangle or replace.

The system of record stays authoritative. AI components must not grow a second truth.

Turn "we will integrate" into facts. Operations, identity, limits, test data, costs and alternatives.

Strangle with a destination. Each temporary measure needs a reason to end.

Adoption is engineering work. Design for the people whose work changes.

A forward deployed solution should meet the organisation where it is while giving it a credible path to where it needs to be.

Previous: Part 4, the demo is the beginning. Next: Part 6, sell the discovery, not the fantasy. All parts are on the series page.

How CloudNala can help

We help organisations bring AI into the systems they already run: establishing what an ERP or line-of-business platform can really support, choosing between overlay, integration, wrapping and gradual replacement for each capability, keeping the system of record authoritative, and writing architecture decision records with a target state and an exit condition. We design with the people whose work changes, so the first integration is also the start of adoption.

Work with CloudNala

CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.

Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.

Book an AI Opportunity Sprint or write to us at consult@cloudnala.co.za