“Can we promise 40 pumps to St. Mary’s by Friday?” The sales assistant finds 64 on hand and writes a convincing yes. The warehouse has 22 allocated to another order and eight in quarantine. That leaves 34 available before anyone checks the carrier cutoff. In this illustrative case, the arithmetic is elementary. The expensive mistake is what the company means by available.
Give that assistant a better language model and it may explain its answer more elegantly. Give it a governed way to ask the inventory system what can be promised, for which customer and at what time, and it can produce a different answer: “We can offer 34. I can ask the planner about the other six.” That is a useful enterprise AI pilot. A salesperson can act on it, a warehouse supervisor can challenge it, and an engineer can investigate it.
The first integration problem is usually a noun
Which St. Mary’s? Sales maintains a parent account in the CRM. The ERP has separate bill-to and ship-to records. A warehouse spreadsheet abbreviates two hospitals to the same name. Matching the wording more confidently can make the error worse: a delivery to the wrong facility can still have the right parent account. The useful piece of architecture is a maintained mapping between system identifiers, with a named owner for exceptions. When two matches remain plausible, the assistant should ask for the ship-to location.
A spreadsheet deserves the same attention. A planner’s yellow cell might mean “quality cleared this lot by phone,” a fact that has never reached the ERP. Deleting the spreadsheet on migration day loses an operating rule. Importing it wholesale promotes an undocumented exception into policy. Ask the planner who may release the hold, what evidence they receive and when it expires. Then give that decision a recorded approval, an owner and a place in the availability calculation. The hardest part of this project may be an hour at the shipping desk.
Even an answer that takes no action needs an evidence trail. For the pump order, record the item and location identifiers, when each source was read, which availability rule ran and the figures it returned. Show the salesperson the counts, their meaning and the observation time. An investigator can then distinguish an arithmetic error from a stale stock feed or a mistaken customer match. A transcript of a model explaining itself after the event cannot establish which inventory record it actually read.
Trace one promise from question to commitment
Read. The application resolves the signed-in employee, tenant and permitted locations on the server. A narrowly scoped inventory operation returns the quantities this employee may see. A product manual in a search index can help explain quarantine policy. It is a poor source for whether lot 814 is still on hold at 3:07 p.m. For that, ask the system that owns the hold and include the time of the answer.
Propose. The assistant prepares a split shipment of 34 and six. At this point nothing has been reserved. The screen should say so. Show the customer, destination, quantities, surcharge if any, and what still needs planner approval. A proposal is cheap to change. A promise already emailed to a hospital is considerably harder to unwind.
Commit. Between the proposal and the salesperson’s click, another desk sells four pumps. A sound write path rechecks both present authority and present availability. The database or ERP must arbitrate competing reservations, including orders placed by people who never use the assistant. If the quantity changed, return the new offer for review. A beautifully governed AI interface cannot protect stock from a second application that bypasses the same reservation rule.
There is a concrete vendor example. Microsoft’s Dynamics 365 Business Central sales-order update requires an If-Match header. Supplying the version tag actually read lets the caller condition its update on that version still being current. That protects against silently overwriting a newer order edit. It does not reserve inventory across several orders. For that you still need the ERP’s reservation operation or equivalent transaction boundary. This distinction is why “connected to the ERP” tells a buyer so little. Ask which operation the integration can perform and which business rule that operation enforces. Microsoft: Update sales orders in Business Central
Confirm. Keep the original request identifier and the reservation receipt. If a connection drops after the write, the next step is to look up its outcome before creating another reservation. The meaningful audit record ties the employee, approval, order version, requested change and external result together. It can explain what the business did even if the model or prompt has since changed. Amazon Builders’ Library: Making retries safe with idempotent APIs
Put the permission check where it can refuse the work
An unpredictable, opaque session identifier is a useful design choice. The browser can present it in a protected cookie while the server resolves identity, expiration, revocation and tenant membership. When those decisions depend on a stored session record, the design is stateful. Hashing an identifier does not by itself establish permission. A browser can hold data the user is authorized to see; hiding a column or a button in that browser cannot prevent a crafted request from asking for more. OWASP: Session Management Cheat Sheet
Apply the same reasoning to retrieval. Imagine two distributors use the same SaaS application and both have an order 1048. If a search service retrieves both orders and tells the model to ignore one, the other tenant’s record has already crossed the boundary. Restrict the search before results enter model context. When an employee changes accounts or roles, cached results must respect the new scope too. Test this with identical order numbers and different prices in two tenants. Run the test using the application’s real database role: PostgreSQL documents that table owners ordinarily bypass row security, as do superusers and roles granted BYPASSRLS. A test run under the wrong identity can give the team a wholly misleading picture. PostgreSQL: Row security policies
For internal software, a stored procedure can expose a bounded operation such as requesting a reservation without granting callers general table-write access. For a vendor ERP, the supported API may be the only place that correctly applies allocations, credit holds and posting rules. Putting the model close to business data does not require giving it database credentials. A service can offer an action with a small set of validated inputs and enforce the same permissions whether the request came from a person, a scheduled job or an agent.
That boundary matters when untrusted content enters a workflow. A supplier PDF could contain text directing the assistant to change a remittance account. The document is evidence to inspect. Its author has no authority to change where the buyer sends money. A document-reading tool should lack that capability. A separately authorized payment-change workflow can require independent verification. OWASP calls unnecessarily powerful tools, permissions and autonomy excessive agency and recommends enforcing authorization downstream. OWASP: Excessive Agency
What senior engineers can delegate
A senior engineer can give an agent a small, precise job: implement the approved reservation interface and write a test in which two salespeople compete for the last four units. An agent can draft the adapter, propose test data, and flag differences between the documented response and a sandbox result. A reviewer can inspect the change independently and ask a more valuable question than “Does it compile?” Which real paths, including the warehouse terminal, can still reserve the same four units?
Modularity helps because inventory policy, ERP credentials, user presentation and audit evidence can be reviewed and changed independently. A menu, top bar and content panel describe a screen layout. Containers describe a deployment choice. Neither establishes that a compromised reporting component lacks write access to inventory. Check the permissions, contracts and tests that separate those responsibilities. If a release needs a database migration, rehearse it against representative data and agree on a recovery path before authorizing production deployment.
The mobile angle is real in a modest, useful sense. A technology leader can see that an agent’s change failed the cross-tenant test, stop a release from a phone and assign the failure to the engineer who owns the integration. That is meaningful control from a small screen. The release decision still depends on evidence collected elsewhere: the proposed change, the test result and an accountable reviewer.
Claims about speed deserve that same discipline. A randomized METR study of experienced open-source developers working in familiar repositories found that access to early-2025 AI tools increased completion time by 19% in that setting. In February 2026, METR explained why selection effects in a follow-up made a clean updated estimate difficult. Neither result predicts how many SaaS products a particular team can ship. Track time from specification to accepted change, review and rework hours, and defects found after release. Count the work it takes to make the output usable. METR: Randomized developer productivity study · METR: Follow-up experiment design
The same question travels across industries
In construction, an assistant can summarize a change order while the signed revision controls what may be billed. In manufacturing, a substitute part may fit the dimensions but lack approval for that production run. In banking, a customer-service agent can explain a hold without having authority to release funds. In healthcare, finding the right referral document and confirming the receiving clinic accepted it are different milestones. Each industry gives the engineering team a different definition of a completed action.
The distinction carries through legal filing receipts, insurance claim approvals, telecom provisioning, utility dispatch and government eligibility decisions. Field-service and physical-security teams must account for a technician who works offline while the assignment changes. A media publisher needs to know whether a channel accepted a post after a timeout. In CRM, suggesting a follow-up and actually emailing a prospect call for different permissions. Start with the consequence of getting one action wrong. It tells you which records, people and controls the design must bring together.
A better pilot demonstration
Give the vendor the pump order. Ask it to show why it offered 34, which location it consulted and how old the answer is. Sell four units from another terminal before accepting. Try the same order number from a second tenant. Then disconnect the client immediately after committing the revised reservation and try again. Compare the resulting inventory movement, order history and customer-facing message. Measure how many cases required a human, how long reconciliation took and whether the customer got a promise the warehouse could keep.
If the assistant declines to promise the final six pumps, it may have delivered the most valuable answer of the demonstration. Someone designed the system to know the difference between a sentence it could generate and a commitment the business could honor.