Package
Fixed scope5–8 weeksAccess Layer — the permissioned layer between your systems and any model
The first agent is a project. The fourth is a platform problem. The Access Layer is the part that makes the difference: one connector set, one permission model, one approval queue and one audit trail, sitting between everything you run and whatever model you use — so the next agent is a fortnight of work instead of another integration project.
$8,000 from · 5–8 weeks · scope agreed in writing
- Scope agreed before we start
- From $8,000Scope agreed before we start
- To a layer your team can build on
- 5–8 weeksTo a layer your team can build on
- Permissions, not per system
- Per operationPermissions, not per system
- Swap providers without a rewrite
- Model-agnosticSwap providers without a rewrite
What you receive
6 named artefacts, not a summary call
This is infrastructure, so what you get is infrastructure — documented, tested and extensible by your own engineers without us.
- 01
Connectors across the systems you name
One adapter per system, not one per agent: authentication, the read and write operations, pagination, rate-limit handling, retries and idempotency. Written once and reused by everything that comes afterwards.
You getAdapter library with integration tests - 02
A per-operation permission model
Permissions expressed as "may create an order in the ERP" rather than "has ERP access". Every agent gets the narrowest credential that lets it do its job, and the matrix of who may do what is a document your security team can read and sign.
You getPermission matrix and the enforcement code - 03
A central approval queue with named reviewers
One queue for every proposed write across every agent, with the evidence, the rule that stopped it and a one-click accept or amend. Routing by category to the person who should actually decide, with escalation when something sits too long.
You getReviewer interface and routing rules - 04
An exportable audit trail
Every read, every proposed write, every approval and every rejection — with inputs, rule version, model version and the person who signed. Queryable and exportable, because "we log it somewhere" is not an answer to an auditor.
You getAudit store with query and export - 05
Model routing and cost control
A single place where model choice, keys, fallbacks and per-run cost limits are configured. Switching provider, or moving one step to a self-hosted model, is configuration rather than a rewrite.
You getRouting configuration and cost dashboards - 06
Documentation your team can extend from
How to add a connector, how to define a new agent, how to scope its permissions and how to add a review category — written for an engineer who has never met us, and tested by having one follow it.
You getDeveloper documentation and a worked example
How it is done
Why this is a layer and not a platform you rent
Plenty of vendors will sell you the same capability as a subscription with their runtime in the middle of your business. We build it inside your infrastructure, because the layer that sits between your ERP and your models is the last thing you want to be renting from a company that might change its pricing or disappear.
Permissions are per operation, which is the whole point
Most integrations authenticate with one powerful credential and rely on the application to behave. That is fine until an agent is the application. Scoping to operations means a compromised or confused agent cannot do something it was never meant to.
One queue beats one queue per agent
When the third agent brings its own approval flow, reviewers stop reviewing. A single queue with routing keeps the human check in a place people actually look, which is what makes the control real rather than nominal.
Retrieval and memory are scoped too
What an agent may read is a permission, not a convenience. Indexes are partitioned so an agent serving one team cannot retrieve another team’s documents, which is the quiet failure mode of most internal assistants.
Built so the next one is cheap
The measure of this engagement is not the first agent on the layer. It is how long the second takes. If adding one is not substantially faster, we have built the wrong thing.
Week by week
What happens, and what it costs you in hours
The last column is the one nobody publishes: how much of your own team’s time each stage takes. It is the question every buyer has and almost nobody asks out loud.
- Week 1
Inventory and permission design
Every system in scope, what lives in it, who may do what today, and what each planned agent will need. The permission matrix is designed and signed off before any code is written.
Your time3–4 hours across IT, security and process owners - Week 1–4
Connectors
Built one system at a time, each with its tests, against sandboxes where they exist. The awkward system is always taken first, because that is the one that decides the timeline.
Your timeAccess provisioning, then on call - Week 3–5
Permissions, queue and audit
Enforcement, the reviewer interface, routing, escalation and the audit store. Reviewed with your security team while it is being built rather than presented at the end.
Your time1 hour a week, security reviewer - Week 5–7
Prove it with an agent
A real agent built on the layer end to end, both to demonstrate the layer works and to find the sharp edges before your team does.
Your time2 hours, process owner - Week 7–8
Handover
Documentation walkthrough, a session where your engineer adds a connector with us watching rather than helping, monitoring in your accounts and the repository handed over.
Your timeHalf a day, engineering team
Not included
What this package does not cover
Published rather than discovered. A fixed price only means anything if the edge of it is written down.
- Every agent your business will eventually want — the layer is the foundation, not the fleet
- Replacing or upgrading any of the systems being connected
- A security certification or a penetration test, though we will work to your pen-test findings
- Cloud and model spend, which sits in your accounts at cost
- A system with no API, no database access and no export — those need a separate conversation
- Ongoing operation, unless you separately choose a support arrangement
Is this the right package
Who this is for, and who it is not for
We would rather lose the sale here than three weeks in. If the right-hand column describes you, say so on the call and we will point you somewhere better.
A good fit when
- A first agent has already worked and you can see the next three coming
- More than one team wants to automate against the same systems
- Your security team wants a permission model they can inspect and sign
- You need an audit trail that survives a regulator or an internal audit
- You want your own engineers to extend this rather than keep buying projects
Not this package when
- You have one process and no plans for a second — build the pilot instead
- Nobody has yet proved an agent works in your environment at all
- You want a hosted platform and are happy renting the middle of your stack
- The systems involved are entirely closed with no API, database or export path
- There is no engineering capacity on your side to own it after handover
The money
$8,000 from — what that covers
From $8,000, quoted against a named system list
The price is driven by how many systems and how hostile they are. You get a fixed number against a written list before anything starts, and the list is what the price is anchored to.
What moves the price
Systems without an API that need a file or database path, single sign-on and enterprise identity integration, self-hosted model infrastructure, and any residency requirement that changes where things run.
No licence, no runtime fee, no per-seat cost
This is code in your repository running in your accounts. There is nothing to renew, and if you never speak to us again the layer keeps working.
After this
Where people go next
- $6,500 from · 4–6 weeks
Agent Pilot
Each additional agent built on the layer is scoped like a pilot, and takes materially less time because the connectors and permissions already exist.
- $2,400 fixed · 2 weeks
AI Readiness Audit
If the list of systems and agents is not settled yet, the audit produces exactly that list and the fee comes off the build.
Questions
Access Layer — before you commit
Is this the same as an MCP server?
It overlaps. Model Context Protocol is one good way to expose tools to a model, and we use it where it fits. The layer is broader: the permission model, the approval queue, the audit trail and the cost controls are the parts that make it safe to point an agent at a system of record, and no protocol gives you those by itself.
Why not use an integration platform we already pay for?
If your iPaaS already handles the connections, we will build on it rather than replace it — and we will tell you so. Where those tools tend to run out is agent-shaped requirements: per-operation scoping, a review queue with evidence attached, and an audit trail that records why a model proposed something. That is the part we add.
How long does a second agent take once the layer exists?
Substantially less than the first, because the connectors, permissions, queue and audit trail are already there — what remains is the logic and the rules for that process. We will not put a fixed multiplier on it, because it depends on whether the new agent needs a system the layer has not met yet.
Can it run entirely inside our network?
Yes. Everything can run in your cloud account or on your own hardware, including inference on open-weights models where data cannot leave. That costs more to set up and it removes the data question entirely, which several clients consider an obvious trade.
What does our security team actually get to review?
The permission matrix, the enforcement code, the audit schema and the credential scopes — before the code is written, and again before handover. We would rather have that argument in week one than in a pen-test report.
What if we want to change model provider later?
That is configuration. Model choice, keys and fallbacks live in one routing layer, which is deliberate — provider pricing and quality have both moved sharply in the last two years and anything welded to one vendor is a liability.
Do we need our own engineers for this?
To own it afterwards, yes — at least one engineer who can read the code and follow the documentation. If you have nobody, the layer will still work but you will be dependent on somebody to extend it, and we would rather you knew that before buying it than after.
Can you take over a layer another vendor started?
Yes — that is AI Build Rescue, and it starts with a read-only assessment of what exists before anything is promised. Sometimes the right answer is to keep most of it, and sometimes it is to keep the connectors and rebuild the controls.
Tell us which process is costing you.
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