Capability
The permissioned layer between the software you already run and any AI model. Your agents get operations, never credentials — reads at machine speed, writes through a named approver, every call logged.
From $8,000 · 5–8 weeks · fixed scope, agreed in writing
What your team gets
Not a strategy deck. A running system, the permissions around it, and the code in your repository.
What we build
The layer is one piece of infrastructure. What sits on top of it is up to you, and it changes without the layer changing.
The case this was built for. An agent is granted specific operations on specific systems, and can do nothing else — no credentials, no database connection string, no standing access.
An agent that may read inventory and draft a purchase order, but cannot change a price.
The same layer under a conversational interface, so an answer given in Slack is the system’s current answer rather than a stale export.
Asking the ops channel for open invoices on an account and getting the CRM’s live answer.
Two systems that never spoke, connected through operations rather than a nightly CSV. The same permission and audit model applies whether the caller is a model or a cron job.
Storefront orders landing in the ERP continuously, with mismatches queued rather than dropped.
Read-only consumers on the same contracts, so a dashboard and an agent cannot disagree about what a number means.
A branch stock view built on the same operation the agent reads.
How we build it
Most AI integration failures are not integration failures. They are permission failures discovered late — the pilot worked, then somebody asked what happens when it writes, and there was no answer. These five pieces exist so that question has one.
One per system, wrapping REST, SOAP, a database or a file drop behind a typed interface. Each operation is named, documented and versioned, so a change in the vendor’s API is a change in one place.
Operations are granted to consumers, not credentials to models. Permissions are data, reviewable in one table, and changing the model behind an agent changes nothing about what it may touch.
Every state-changing call is held with the proposed change rendered in full — record, field, old value, new value — and routed to a named approver. Approval, rejection and the reason are all recorded.
Append-only, covering every call: caller, operation, arguments, response, latency, approver. Exportable, because the first serious question after go-live is always "what did it do?".
Traces, error rates and cost per operation, with alerts on the two that matter — a connector failing, and spend moving faster than volume.
Before anything is quoted, we prove the integration against your real API or a sandbox copy: read access, a working write into a test record, and a written list of what the system will and will not permit. Vendors routinely discover in week six that the ERP has no write endpoint for the thing the pilot depends on. Two weeks up front removes that risk entirely.
Credentials live in a secret manager and never reach a prompt or a model provider. Connectors run with the narrowest account the vendor allows. Retrieved documents are treated as data, never as instructions, which is what stops a poisoned record from redirecting a caller. Everything crossing a boundary is schema-validated in both directions.
The first agent pays for the layer. The second one costs weeks instead of months, because the connectors, permissions, queue and log already exist. That is the real economics of this capability, and it is why we sell it as infrastructure rather than as part of a single project.
Where it lands
Dealer stock and delivery answers read live from the ERP, replenishment written back through approval.
Production, stock and accounts reconciled continuously across systems that were never designed to talk.
Storefront and ERP kept in step without a person re-keying orders between them.
Core records exposed to AI tooling under operation-level permissions and a full audit trail.
Member records reachable by self-service tools without opening the database to them.
Dispensing and supplier systems connected with every write reviewed before it commits.
Technology
We pick the boring option unless there is a reason not to — the framework is the part most likely to be abandoned before your system is.
How the engagement runs
Every phase ends in a named deliverable. You can stop after any of them and keep what has been built.
Which systems, which operations, and who would have to approve a write. Thirty minutes, and you leave knowing whether this is worth doing.
Read and write proven against your real API or a sandbox, with a written list of what each system will and will not permit.
Connectors built per system, the permission model defined as data, and the operation contracts documented for whoever builds on them next.
The review queue wired to real approvers, the audit log running, traces and cost alerts in place.
Documentation, a worked example of adding a new operation, and the repository transferred. Your team should be able to extend this without us.
Why Devs Core
Competitors list integrations as a line item inside a build. We sell the layer on its own, because it is the piece that decides whether every later agent ships or stalls.
We test the integration against real data before pricing the build. It is the cheapest two weeks in the project and the reason our estimates hold.
Grants attach to operations. When the model you use changes — and it will — nothing about what your systems allow has to be revisited.
It is in from the first connector, because retrofitting attribution into a system that has already written to production is not really possible.
The first agent pays for the layer. The second takes weeks, not months.
100% of the source code, documented, in your repository. No runtime we hold, no licence, no dependency on us continuing to exist.
Questions
AI integration services connect AI models and agents to the business systems an organisation already runs — ERP, CRM, inventory, helpdesk, internal databases — so the AI can work with live data instead of pasted extracts. The work is mostly not model work: it is connectors, a permission model that controls which operations the AI may call, an approval step for changes, and logging that makes every call attributable.
Tools like Zapier move data between applications on triggers. An access layer exposes named operations with permissions, an approval queue and an audit trail, and is designed for a caller that decides at runtime what to do next — which is what an AI agent is. They solve different problems, and many clients keep both.
No. Connectors run under their own least-privilege service accounts, held in a secret manager, and those credentials never enter a prompt or reach a model provider. During the spike we work against a sandbox or a copy wherever the system offers one.
Anything with an API, a database we can read, or a file exchange. In practice that has included SAP Business One, Microsoft Dynamics 365, AutoCount, SQL Account, Odoo, Zoho, Salesforce, HubSpot, Shopify, WooCommerce, Zendesk and Freshdesk, plus internal systems with no documentation at all. The integration spike establishes what is genuinely possible before anything is quoted.
The spike finds that out in week one rather than week six. Where a write endpoint does not exist, the options are a supported staging table, a vendor module, or an honest conclusion that write-back is not available and the agent stays read-only. We would rather tell you that before you have paid for a build that assumes otherwise.
Five to eight weeks for a working access layer across the systems you name, preceded by a two-week integration spike. A single-system connection is faster; the timeline is driven by how many systems are involved and how cooperative each vendor’s API is.
The access layer starts at $8,000 for a fixed scope agreed in writing. The two-week AI Readiness Audit that includes the integration spike is $2,400. Both are starting points sized by how many systems and operations are in scope.
Yes, and that is a design goal. Permissions attach to operations rather than to models, so switching from one provider to another, or moving to a self-hosted open model, does not require revisiting what your systems allow.
For every call: who or what asked, which operation ran, the arguments, the response, the latency, and — for writes — who approved it and when. It is append-only and exportable, which is what makes an answer possible when somebody asks what the system did on a particular day.
Thirty minutes, no preparation, no deck. You describe what keeps going wrong and we tell you whether AI is the answer — including when it is not.
Prefer email? contact@devs-core.com