The Short Answer
Read-only agents stall because the value is in the write. Ampersand's $15M Series A, led by Bessemer on 6 October 2026, prices the layer that lets agents write into Salesforce and NetSuite safely. The buyer question is ownership of that layer: with ibl.ai you own all the code and the data, run it model-agnostic across any LLM, and pay with no per-seat pricing.
An agent that can only read gives you a better answer. An agent that can write gives you a finished task. Everything expensive about enterprise AI lives in the gap between those two sentences.
Why do enterprise AI agent pilots stall before production?
Because the pilot was scoped to reading, and production work requires writing.
Ampersand announced a $15M Series A on 6 October 2026, led by Bessemer Venture Partners, with Lauri Moore joining the board and total funding reaching $20M.
The announcement is explicit about the problem being funded: "Without access to systems of record, enterprise AI is just vaporware."
The company has spent three years on it alongside customers including 11x, Orb and Square, and shipped a beta of Andi, an integration agent that maps data models, configures connections and diagnoses failures inside deterministic infrastructure.
Note what is not in that description. No model. No reasoning breakthrough. The funded asset is the plumbing between an agent and the database your business runs on.
That is consistent with what the adoption data has been saying all year.
Kaufman Rossin's mid-market survey, published 14 May 2026, found 94% of companies using generative AI and 2% operating it at scale, with legacy systems integration named as one of three barriers. We drew that gap out in 94% of the mid-market uses GenAI and 2% have scaled it.
A pilot touches one system and reads. An operation touches all of them and writes. The 92-point gap between those numbers is largely that distinction.
What makes writing to a system of record harder than reading from one?
The failure is silent, durable, and it propagates.
A bad read is visible at the point of use. Somebody reads a wrong summary and pushes back, and the cost is one wasted answer.
A bad write lands in a row that other systems trust.
The wrong opportunity gets updated, the journal entry posts to the wrong cost center, the enrollment record changes, and the error flows outward into forecasts, invoices, dashboards and downstream automations before anyone notices.
| Dimension | Agent reads | Agent writes |
|---|---|---|
| Blast radius of an error | One answer, one user | One record, every system downstream of it |
| Detection | Immediate, by the person reading | Later, by reconciliation or a customer |
| Permission model needed | Can this caller see this field | Can this caller change this field, on this object, in this state |
| Schema sensitivity | Tolerates an imperfect mapping | Requires the customer-specific model to be exactly right |
| Audit requirement | Useful | Mandatory, because "who did this" will be asked |
The schema row is the one that consumes budget. Ampersand's own framing is that agents must handle complex, customer-specific data models where every customer is another implementation, which is why three years of engineering went into it.
Nothing in a context window supplies that mapping. It has to be modeled as typed relationships over the systems you already run, the work described in the ontology-first approach to enterprise AI data integration.
Who should own the connector layer between agents and your CRM or ERP?
You should, because it is the most specific and least portable thing in the deployment.
Rank the layers of an agent stack by how hard each is to replace. The model is the easiest: re-point an API and re-run your evaluations. The agent definition is next, since a persona and a set of skills are configuration.
The connector and ontology layer is the hardest, because it encodes how your instance of Salesforce actually works, which fields matter, which writes are legal, and who may make them.
So the lock-in risk of the agentic era is not the model. It is one layer down, in the mapping, and it is less visible precisely because it is infrastructure rather than a product you look at every day.
This is also a governance surface, not only a commercial one. The IBM 2026 breach report put shadow AI in 43% of security incidents, roughly double the prior year, with most breached organizations having no governance policy covering unapproved AI use.
We covered the consequences in shadow IT stored data, shadow agents take actions.
An agent write path that lives in a vendor's cloud, under a vendor's credentials, is a governance gap with a contract around it. The question "which agent changed this record, under whose authority" needs an answer that does not require a support ticket to a third party.
What does a safe agent write path look like?
Four properties, all of which are architecture decisions rather than features you can add later.
Deny by default. Every write is an explicitly granted capability scoped to the caller's role, not a side effect of a service account with broad access. A shared API key that can write anything is the single most common finding in a pilot built for speed.
Credentials injected, never held by the agent. The runtime presents the credential at call time inside a sandbox; the agent's prompt, logs and transcripts never contain it. Model-side prompt injection then cannot exfiltrate what the model never had.
A typed mapping between systems, so "update the student's status" resolves to one field on one object in one system, with the relationship to the CRM contact and the ERP record declared rather than inferred.
An audit log that records the actor, the target, the before and after values, and the authority, for every write. That is what makes the agent reviewable after the fact, and it is the artifact your auditors will ask for.
On ibl.ai these are the MCP broker and connector layers: one control plane over many MCP servers with deny-by-default RBAC, caching, credential injection and audit logging, and a sandboxed harness that runs in your own infrastructure.
The agent above it is composition. The write path below it is engineering, and it is yours.
You own all the code and the data, run it model-agnostic across any LLM and switch anytime, and pay by usage with no per-seat pricing, so you can deploy anywhere, from your own cloud to a fully air-gapped network.
What should you ask a vendor before an agent touches production data?
Five questions, and the answers are short enough to fit in an email.
Which systems can this agent write to, and what is the exact list of fields and objects. A vendor who answers at the level of "your CRM" has not scoped the write path.
Where does the credential live at the moment of the call, and does it ever enter the model's context.
What does the audit record contain, who can read it, and does it stay inside our perimeter.
If we end this contract, do we keep the connectors and the mapping, as source code we can run.
What happens on a partial failure, when the agent wrote to one system and the second write failed. Enterprise data lives in more than one place, and a half-finished write is the quiet way records diverge.
The fourth question is the one that separates ownership from rental. Three years of mapping work that you cannot take with you is not an integration, it is a dependency.
ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned long-term partner, not a vendor that sells licenses and moves on.
The Edge
A $15M Series A for integration infrastructure is a price signal, and the thing it prices is not intelligence.
It is the mapping between an agent and the records your business is actually made of, which is the one part of an agentic stack that cannot be downloaded, re-pointed or swapped in an afternoon.
That inverts the usual lock-in conversation. Buyers spent two years negotiating about models, which are the most fungible layer in the stack, while the layer that genuinely binds them gets built quietly by whoever happens to be holding the integration contract.
The defensible position is to treat the write path as owned infrastructure from day one: connectors over the systems you already run, typed relationships you can read, role-scoped permissions on every write, and an audit log inside your own perimeter.
Rent that layer and you have not avoided lock-in, you have moved it somewhere harder to see.